Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > PHDL a new HDL for PCB design

Reply
Thread Tools

PHDL a new HDL for PCB design

 
 
self
Guest
Posts: n/a
 
      10-28-2011
Guys

I want to give you an update on the HDL for PCB work I have been
doing. Lately I have collaborated with the Configurable Computing Lab
at Brigham Young University to introduce a new, super simple HDL for
board design capture. A compiler has been written and tested on a few
board designs.

The syntax of the language is highly simplified and efficient compared
to VHDL or even Verilog. The language lets you first define devices,
where functional port names are associated with pin numbers. Then
your instantiate those devices and connect nets to the ports. Device
ports can be single pins or busses.

You can look at the complete code for an example design in these files
https://phdl.svn.sourceforge.net/svn...l/devices.phdl
https://phdl.svn.sourceforge.net/svn...l/fmc_dac.phdl

For boards with Xilinx FPGAs I have published a utility that
automatically generates the device declaration and instantiation
template to cut down on typing and mistakes.

Please let me know what you think.


I include some example code below for your convenience. Here is a
sample syntax for the device definition. Note that data busses and
repeated signals like GND are handled with a single line declaration.

// Analog Devices high speed DAC
device ad9739 is
attr refPrefix = "U";
attr refDes = "";
attr name = "";
attr value = "";
attr pkg_type = "ANALOG_DEVICES_BC-160-1";
attr mfgr = "Analog Devices";
attr PartNumber = "AD9739BBCZ";
attr cost = "70.00";


pin[13:0] DB1_P =
{L14,L13,L12,L11,L10,L9,L8,L7,L6,L5,L4,L3,L2,L1};
pin[13:0] DB1_N =
{M14,M13,M12,M11,M10,M9,M8,M7,M6,M5,M4,M3,M2,M1};
pin[13:0] DB0_P =
{N14,N13,N12,N11,N10,N9,N8,N7,N6,N5,N4,N3,N2,N1};
pin[13:0] DB0_N =
{P14,P13,P12,P11,P10,P9,P8,P7,P6,P5,P4,P3,P2,P1};

pin[1:8] VDDC = {C1, C2, D1, D2, E1, E2, E3, E4};
pin[1:14] VSSC = {A1, A2, A3, A4, A5, B1, B2, B3, B4, B5, C4, C5,
D4, D5};
pin[1:8] VDDA = {A10, A11, B10, B11, C10, C11, D10, D11};
pin[1:8] VSSA = {A12, A13, B12, B13, C12, C13, D12, D13};
pin[1:18] VSSA_SHIELD = {A6, A9, B6, B9, C6, C9, D6, D9, F1, F2,
F3, F4, E11, E12, E13, E14, F11, F12};
pin NC = {A14};
pin[1:4] IOUTN = {A7, B7, C7, D7};
pin[1:4] IOUTP = {A8, B8, C8, D8};
pin I120 = {B14};
pin VREF = {C14};
pin IPTAT = {D14};
pin DACCLK_N = {C3};
pin DACCLK_P = {D3};
pin IRQ = {F13};
pin RESET = {F14};
pin CS = {G13};
pin SDIO = {G14};
pin SCLK = {H13};
pin SDO = {H14};
pin[1:4] VDD33 = {J3,J4,J11,J12};
pin[1:6] VDD = {G1, G2, G3, G4, G11, G12};
pin[1:10] VSS = {H1, H2, H3, H4, H11, H12, K3, K4, K11, K12};
pin SYNC_OUT_P = {J1};
pin SYNC_OUT_N = {J2};
pin SYNC_IN_P = {K1};
pin SYNC_IN_N = {K2};
pin DCO_P = {J13};
pin DCO_N = {J14};
pin DCI_P = {K13};
pin DCI_N = {K14};
end device;


And here is some sample code of how the parts are wired up.

design fmc_dac is

// device definitions
include "devices.phdl";

// Power and ground nets.
net +3V3, +2V5, +1V8, 1V8_sense, gnd;
// net VDDC, VDDA;

// DAC Signals.
net IOUTP, IOUTN;
net[13:0] DB1_P, DB1_N, DB0_P, DB0_N;
net DACCLK_P, DACCLK_N, DCI_P, DCI_N, DCO_P, DCO_N, SYNC_IN_P,
SYNC_IN_N, SYNC_OUT_P, SYNC_OUT_N;
net IRQ, RESET, SPI_CS, SPI_SCLK, SPI_SDO, SPI_SDI;
net IRQ_2V5, RESET_2V5, SPI_CS_2V5, SPI_SCLK_2V5, SPI_SDO_2V5,
SPI_SDI_2V5;
net DAC_VREF, IPTAT, I120;
net analog_out;

// Clock signals.
net samp_clk_in, bal_clock_p, bal_clock_n, coup_clock_p,
coup_clock_n;
net clock_buf_p, clock_buf_n;
net ADCLK914_Vref;
net out_coup_clock_p, out_coup_clock_n;

// Test signals.
net test_trace_bottom, test_trace_top;

begin

// This the fast DAC itself. Note how concisely the busses are
connected.
inst fast_dac of ad9739 is refDes = "U1";
VDDC = <+1V8>;
VSSC = <gnd>;
VDDA = <+3V3>;
VSSA = <gnd>;
VSSA_SHIELD = <gnd>;
NC = open;
IOUTN = <IOUTN>;
IOUTP = <IOUTP>;
I120 = I120;
VREF = DAC_VREF;
IPTAT = IPTAT;
DACCLK_N = DACCLK_P; // clock polarity reversed for better
routing.
DACCLK_P = DACCLK_N;
IRQ = IRQ;
RESET = RESET;
CS = SPI_CS;
SDIO = SPI_SDI;
SCLK = SPI_SCLK;
SDO = SPI_SDO;
VDD33 = <+3V3>;
VDD = <+1V8>;
VSS = <gnd>;
SYNC_OUT_P = SYNC_OUT_P;
SYNC_OUT_N = SYNC_OUT_N;
SYNC_IN_P = SYNC_IN_P;
SYNC_IN_N = SYNC_IN_N;
DCO_P = DCO_P;
DCO_N = DCO_N;
DCI_P = DCI_P;
DCI_N = DCI_N;
DB1_P = DB1_P;
DB1_N = DB1_N;
DB0_P = DB0_P;
DB0_N = DB0_N;
end inst;
 
Reply With Quote
 
 
 
 
Brian Drummond
Guest
Posts: n/a
 
      10-28-2011
On Thu, 27 Oct 2011 19:28:14 -0700, self wrote:

> Guys
>
> I want to give you an update on the HDL for PCB work I have been doing.
> Lately I have collaborated with the Configurable Computing Lab at
> Brigham Young University to introduce a new, super simple HDL for board
> design capture. A compiler has been written and tested on a few board
> designs.
>
> The syntax of the language is highly simplified and efficient compared
> to VHDL or even Verilog.


> For boards with Xilinx FPGAs I have published a utility that
> automatically generates the device declaration and instantiation
> template to cut down on typing and mistakes.
>
> Please let me know what you think.


It's a noble effort, but...

To be honest, I suspect many of the changes from VHDL syntax are for no
good reason (except looking "cool" to C programmers) and may be
counterproductive.

The most obvious example on a first look:

Lose the "include".

Learn from VHDL's use of packages and libraries, and move to something
similar (or just copy it)

Or discover that you have to write a new component library for virtually
every PCB you make. Because includes don't scale beyond trivial examples.
Even C programmers have to use a crude hack with #defines to avoid
accidentally #including the same header file twice.

And then consider namespace pollution. When you try to use the
Spartan-3E-1000 from Jim's component library with the ADC from Fred's,
you will find they both defined a Resistor and a Capacitor, and then
you're stuck. Either you convince them to let you delete bits of their
libraries, or you get to write your own...

VHDL gives you tools like embedded configurations to solve the problem:
Library Jim;
Library Fred;
....
use Fred.Components.all;
....
for U1: Spartan3E_1000 use Jim.Components.Spartan3E_1000;


Then, VHDL gives you generics and ports. These map quite well to your
attrs and pins, so why change them?

For example, you have to deal with things like half a dozen package types
for resistors - even on the same board. Use the generic map to override
the package type, and the port map to connect the pins.


Sorry to be so critical, but you did ask.

- Brian



 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      10-28-2011
On Oct 27, 10:28*pm, self <(E-Mail Removed)> wrote:
> Guys
>
> I want to give you an update on the HDL for PCB work I have been
> doing. *Lately I have collaborated with the Configurable Computing Lab
> at Brigham Young University to introduce a new, super simple HDL for
> board design capture.


The first question would be 'Why?'...followed by 'What improvements
over current art does this bring to the table?'...so that would be
some first metrics to hurdle...so we'll see how those questions get
answered.

>
> The syntax of the language is highly simplified and efficient compared
> to VHDL or even Verilog.


These languages are not typically used to design boards so you're
comparing your language to something that is not typically used for
that purpose. The board design info is buried in a database that is
unique to the specific design tool. VHDL and Verilog files can be
generated as output from those tools, but that makes those files
artifacts, not design files.

> *The language lets you first define devices,
> where functional port names are associated with pin numbers. *Then
> your instantiate those devices and connect nets to the ports. *Device
> ports can be single pins or busses.
>


OK...that would be an expected feature of any PCB design tool whether
it is a schematic capture tool or a language.

>
> Please let me know what you think.
>


One basic piece of information that every part would need in a board
design is the physical location on a board. While a property/
attribute could be defined for the part that will eventually contain
that information for a particular board design that information would
need to be editable on a per-instance basis. I'm pretty sure that
when it comes to placement and layout, PCB people would prefer a
graphic tool, not a text editor because part placement is concerned
with visualizing interconnects (i.e. the 'rats nests'). This would
end up meaning that your new language would, at best, become another
file output artifact of the design tool, not the native design
itself. In that sense, it would not appear to offer anything more
than VHDL or Verilog...and since those languages are standards, your
language would offer less.

Kevin Jennings
 
Reply With Quote
 
Rob Gaddi
Guest
Posts: n/a
 
      10-28-2011
On 10/27/2011 7:28 PM, self wrote:
> Guys
>
> I want to give you an update on the HDL for PCB work I have been
> doing. Lately I have collaborated with the Configurable Computing Lab
> at Brigham Young University to introduce a new, super simple HDL for
> board design capture. A compiler has been written and tested on a few
> board designs.


[snip]

Not sure I see the point to the exercise. When I'm writing VHDL to
target an FPGA I've got access to a large (infinite if you consider
device migration to be an option) number of repetitive resources. Under
these circumstances, the idea of a language+compiler makes a lot of
sense; it's mapping my high-level description of what I want onto these
physical resources. That's when a text-based language is at it's best.

The price I pay is, when I want to connect up the pseudo-devices I've
built, I'm forced to use structural descriptions in my HDL. This is
when a text-based language is at its worst. VHDL or Verilog, take your
pick, both are wildly inferior to schematic capture at allowing you to
visualize a design built by connecting together pre-existing blocks.
Even if those blocks are just one file over. If there were any
industry-standard schematic format, one that I could trust I could still
open files in a decade from now, I'd use it for my structural hookup in
a heartbeat.

PCB design is all the connection of pre-existing blocks. You're not
going to have a tool that compiles your high-level description to
2N4400s and 2N4402s. On top of that, where in an FPGA I only very
rarely give a damn about placement, routing, etc, on a PCB it's
absolutely critical. Impedance matching and termination issues,
cross-talk issues, noise immunity issues (damn switchers), thermocouple
effects, all matter and all need to be taken into account by hand.

The board sitting on my desk right now has 550 parts on it, which makes
it the least complex thing I've designed in a long while by nearly half.
The idea of trying to put those parts together in one long sequential
list rather than a graphic spread across two dimensions and multiple
sheets, and to even hope to get it right, strikes me as abject lunacy.

If it ain't broke...


--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
 
Reply With Quote
 
backhus
Guest
Posts: n/a
 
      11-01-2011
Hi,
someone remembering EDIF?
It can be used for all kinds of netlists.
Schematic, Circuit (eg. IP-Cores) and also PCBs.

And it's standardized. (IEC 61690-2)

As already mentioned by others, netlist files are in general created
and read by some software, rarely by humans.
So complexity shouldn't be the problem.
(One might think of some XEDIF format in the future, which makes a
hhange in the syntax to something XML compatible to ease up software
design)

So, what has this "new PHDL" to offer instead of endless lists of name
assignments?
I could see some attributes for device naming purposes and even a cost
factor in the example.
But where can one describe locations, track attributes, timing
constraints and other relevant things that come to mind when designing
a PCB?

Instead of just another netlist format it would be more interesting to
have a "language" that just concentrates on doing the real design
stuff for PCBs,
such as constraints, while the pure netlisting is already solved and
noone wants to do it "by hand" anyway.

In the FPGA world we find something similar in the UCF files (from
Xilinx, other vendors may have differnt names for the same).
Tools read in some netlist and then apply the UCF constraints to allow
controll over the physical layout.
Something similar for PCBs, in a standardized way(!), would be nice
indeed.

Have a nice synthesis
Eilert

 
Reply With Quote
 
self
Guest
Posts: n/a
 
      11-15-2011
Hello Guys,

Thanks for responding.

I want to apologize for the original out of context post. I intended
to reply to an existing thread where we were already talking about
using HDL to describe circuits for PCB construction. I'll try to
explain here now.

I have been designing printed circuit assemblies for over 20 years.
During that time HDL has almost completely taken over the logic design
business. You all know the advantages of text for logic design but I
will repeat some of them here.

- Abstraction
- Portability
- Standardization
- Readability
- Maintainability
- Efficiency
- Version control compatibility
- Code generation

PHDL (PCB HDL) is an attempt to achieve the same advantages for
printed circuit connectivity definition, the part of the printed
circuit design process that is currently done with schematic
diagrams. PHDL does nothing for the layout part of the design process
because that is naturally a drafting operation and we are pretty
satisfied with the commercial tools available for layout.

Printed circuit design connectivity definition is a much simpler task
than logic design. You are only instantiating chips and wiring them
up. You don't need data types, signal assignments or boolean functions
for example. For that reason we developed a super simple HDL
specifically for the task of designing printed circuit boards. Also,
printed circuit board design is a very important engineering task,
perhaps as important as logic design, so it deserves its own language
optimized for that purpose.

PHDL is a design language. Component ports are associated with their
physical pin numbers in a device declaration. Then you instantiate
parts and attach signals to them, nothing fancy. The language has
many syntactical features that provide abstraction, reduce typing and
help minimize errors. The current version of the compiler already
provides a good bit of error checking.

At first I thought that we could use VHDL but it does not directly
support pin numbers in component declarations. You have to devise some
new attributes and process them specially to associate pin numbers
with entity ports. The pin number attribute cannot be on the same
line with the entity port but rather has to follow all the port
declarations. You would have to play a similar game for all the other
stuff like PKG_TYPE, PART_NUMBER, etc. The syntax gets very ugly and
requires a tremendous amount of typing.

Our compiler can already output netlist formats for PADS and Eagle. It
is easy to create more output formats and we want to support Altium
and VHDL netlist outputs. The VHDL would be for anyone who might want
to simulate or graphically view the structure of their design in an
RTL viewer.

Eilert, I like your idea of a standard language for PCB physical
constraints but you would have to get a bunch of CAE companies to
agree on a standard. That's not what we are trying to do.

Our compiler is written in java so you can run it on any machine,
including a smart phone in a pinch. The compiler executeable is a
"jar" file that can be archived along with the board design for
infinite maintainability. Of course, the board design source is text
and text editors will exist forever.

I find PHDL syntax to be quite readable and it provides both // and /*
*/ style comment operators. I find myself writing the comments first
then filling in the circuits afterwords.

To avoid most of the typing on big FPGA boards I wrote a Xilinx2PHDL
converter that automatically generates most of the text for the
board. When you have text design entry it opens up all kinds of
possibilities for autogeneration. I'm working on the Actel2PHDL and
Altera2PHDL converters now.

To my mind the biggest advantage of PHDL over graphical schematics is
compatibility with version control tools. Because it is text, I can
look back at every change ever made to the design.

We have already designed several printed circuit boards using PHDL.
Originally I thought it would be best for high pin count FPGA boards
but we have used it for analog and power boards and those read well
also. It is amazing how a few comments can help with the board design
process.

On the other hand, we understand that a lot of people just like
drawing pictures of board designs and are willing to use proprietary
tools to do it. We are just offering an alternative to those HDL types
who prefer a very direct and open design methodology.

Anyway, that is enough for today.

Pete
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      11-16-2011
On Nov 14, 8:24*pm, self <(E-Mail Removed)> wrote:
> Hello Guys,
>
> Thanks for responding.
>
> I want to apologize for the original out of context post. I intended
> to reply to an existing thread where we were already talking about
> using HDL to describe circuits for PCB construction. I'll try to
> explain here now.
>
> I have been designing printed circuit assemblies for over 20 years.
> During that time HDL has almost completely taken over the logic design
> business. *You all know the advantages of text for logic design but I
> will repeat some of them here.
>
> - Abstraction
> - Portability
> - Standardization
> - Readability
> - Maintainability
> - Efficiency
> - Version control compatibility
> - Code generation
>
> PHDL (PCB HDL) is an attempt to achieve the same advantages for
> printed circuit connectivity definition, the part of the printed
> circuit design process that is currently done with schematic
> diagrams. *PHDL does nothing for the layout part of the design process
> because that is naturally a drafting operation and we are pretty
> satisfied with the commercial tools available for layout.
>
> Printed circuit design connectivity definition is a much simpler task
> than logic design. *You are only instantiating chips and wiring them
> up. You don't need data types, signal assignments or boolean functions
> for example. For that reason we developed a super simple HDL
> specifically for the task of designing printed circuit boards. Also,
> printed circuit board design is a very important engineering task,
> perhaps as important as logic design, so it deserves its own language
> optimized for that purpose.
>
> PHDL is a design language. *Component ports are associated with their
> physical pin numbers in a device declaration. Then you instantiate
> parts and attach signals to them, nothing fancy. *The language has
> many syntactical features that provide abstraction, reduce typing and
> help minimize errors. The current version of the compiler already
> provides a good bit of error checking.
>
> At first I thought that we could use VHDL but it does not directly
> support pin numbers in component declarations. You have to devise some
> new attributes and process them specially to associate pin numbers
> with entity ports. *The pin number attribute cannot be on the same
> line with the entity port but rather has to follow all the port
> declarations. You would have to play a similar game for all the other
> stuff like PKG_TYPE, PART_NUMBER, etc. The syntax gets very ugly and
> requires a tremendous amount of typing.
>
> Our compiler can already output netlist formats for PADS and Eagle. It
> is easy to create more output formats and we want to support Altium
> and VHDL netlist outputs. The VHDL would be for anyone who might want
> to simulate or graphically view the structure of their design in an
> RTL viewer.
>
> Eilert, I like your idea of a standard language for PCB physical
> constraints but you would have to get a bunch of CAE companies to
> agree on a standard. That's not what we are trying to do.
>
> Our compiler is written in java so you can run it on any machine,
> including a smart phone in a pinch. *The compiler executeable is a
> "jar" file that can be archived along with the board design for
> infinite maintainability. Of course, the board design source is text
> and text editors will exist forever.
>
> I find PHDL syntax to be quite readable and it provides both // and /*
> */ style comment operators. *I find myself writing the comments first
> then filling in the circuits afterwords.
>
> To avoid most of the typing on big FPGA boards I wrote a Xilinx2PHDL
> converter that automatically generates most of the text for the
> board. *When you have text design entry it opens up all kinds of
> possibilities for autogeneration. I'm working on the Actel2PHDL and
> Altera2PHDL converters now.
>
> To my mind the biggest advantage of PHDL over graphical schematics is
> compatibility with version control tools. Because it is text, I can
> look back at every change ever made to the design.
>
> We have already designed several printed circuit boards using PHDL.
> Originally I thought it would be best for high pin count FPGA boards
> but we have used it for analog and power boards and those read well
> also. *It is amazing how a few comments can help with the board design
> process.
>
> On the other hand, we understand that a lot of people just like
> drawing pictures of board designs and are willing to use proprietary
> tools to do it. We are just offering an alternative to those HDL types
> who prefer a very direct and open design methodology.
>
> Anyway, that is enough for today.
>
> * Pete


Several years ago, I looked at using vhdl for pwb netlists.

Most schematic capture systems understand the distinction between a
symbol and a package. The same symbol may map into multiple packages,
each with different pin numbers.

You can make the vhdl entities be the packages, and components the
"schematic symbols"

Then you define configurations to map component (with logical port
names) to entities (with phisical port names). These can be named
configurations that each map one component to one entity.

Then you would just code up your netlist instantiating the components,
and write a configuration that defines which package each component
will use.

The part I could not figure out was that most schematic capture
systems are capable of using symbols that represent part of a package,
not the whole package (e.g. quad nand gate parts, resistor networks,
etc.).

So I eventually dropped the idea.

I like drawing schematics better anyway. I don't have to name a wire
if I don't want to, it takes care of it for me. I can have one symbol
pin or wire represent an entire bus and one symbol represent multiple
components (e.g. 32 pullup resistors) or multiple parts of one or more
components, etc. Purely structural use of HDL is one of its weaker
applications. You might as well code an edif netlist. It is difficult
to visualize interconnect between a half dozen high port-count
components when the only clue you have is matching signal names.

Andy

 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      11-17-2011
On Nov 14, 9:24*pm, self <(E-Mail Removed)> wrote:
>
> I have been designing printed circuit assemblies for over 20 years.
> During that time HDL has almost completely taken over the logic design
> business.


That's not quite what has happened. Roughly 30 years ago programmable
logic parts came into existence. Fundamentally, the input to these
parts is a bit stream that encodes a functional description of the
logic to be implemented. As the capabilities of these parts changed
it became feasible to rapidly and less expensively (as compared to a
board re-design) deploy logic function changes to an existing board.
Also, over these 30 years the capacity of that described logic has
increased many times over.

HDLs have not "taken over the logic design business", they are simply
a more productive tool for describing large amounts of logic, the
output of which is a bitstream. Printed circuit boards on the other
hand have only increased in density incrementally over that same time
frame. Whether or not the density has reached the point where a text
description is 'better' or not is an opinion that everyone can have,
but not all parts of a board are simply hooking up pins on large
parts. There are analog sections and some power sections that greatly
benefit from a 2D graphical description (i.e. schematic) and are much
worse off in a linear text file.

> You all know the advantages of text for logic design but I
> will repeat some of them here.
>
> - Abstraction
> - Portability
> - Standardization
> - Readability
> - Maintainability
> - Efficiency
> - Version control compatibility
> - Code generation
>
> PHDL (PCB HDL) is an attempt to achieve the same advantages for
> printed circuit connectivity definition, the part of the printed
> circuit design process that is currently done with schematic
> diagrams.


Unfortunately, you have not presented any data or even mentioned that
you have measured anything to indicate that PHDL (or any other HDL)
description is a better and more efficient tool for printed circuit
board design capture. As I asked in my first post 'What improvements
over current art does this bring to the table?'...if PHDL is
measurably better than schematics than you should be able to measure
that difference. If it's not, and it's just another tool that one
could use, OK...but don't assume that any benefits of using one type
of tool then get inherited by another type of use.

> PHDL does nothing for the layout part of the design process
> because that is naturally a drafting operation and we are pretty
> satisfied with the commercial tools available for layout.
>


OK...but then where does one look to find out where in the circuit
resistor R123 is located, what is it connected to etc.? Layout
defines reference designators...reference designators are needed to
relate back to the generating source file (schematic or PHDL) in order
to maintain the design. None of this matters for 'logic design' that
results in a bitstream that gets loaded into a programmable logic
part.

While net list generation (i.e. schematic capture) is a completely
separate process from layout the two processes are not totally
independent. You still need something out of the layout tool that
gets put back to the 'source' whether that source is a schematic or a
PHDL text file or some other file. Since schematics can be
hierarchical with the same circuit repeated more than once, you can't
even say that the reference designator could be used to instantiate
the part in PHDL since, for a repeated circuit, one would have a
single PHDL file (or section of a file) that describes something to be
instantiated...but it needs to be instantiated more than once. Copy/
paste/label each copy? If so, then live with the law that anything
that gets copied by a human will eventually change from whatever it
was first copied from.

> Printed circuit design connectivity definition is a much simpler task
> than logic design. *You are only instantiating chips and wiring them
> up.


While your statement is true, it would be challenging at best to look
at the description of even a simple filter in text form to determine
the function...so this form would likely not be benefiting the people
who have to pick up and support a design after the original designer
has moved on.

> You don't need data types, signal assignments or boolean functions
> for example. For that reason we developed a super simple HDL
> specifically for the task of designing printed circuit boards. Also,
> printed circuit board design is a very important engineering task,
> perhaps as important as logic design, so it deserves its own language
> optimized for that purpose.
>


It is deserving and today the language optimized for that purpose is a
graphical schematics so again we get back to my question 'What
improvements over current art does this bring to the table?'. You
still need to be better than the incumbent to gather outside support.
PHDL might very well be better than schematics, but if it is you
should be able to measure some improvement somewhere, not simply state
that it is better than something that is not used for design (i.e.
VHDL as the board design source) and leave it at that.

> PHDL is a design language. *Component ports are associated with their
> physical pin numbers in a device declaration. Then you instantiate
> parts and attach signals to them, nothing fancy. *The language has
> many syntactical features that provide abstraction, reduce typing and
> help minimize errors. The current version of the compiler already
> provides a good bit of error checking.
>


Simply noting that everything in the above paragraph is equally true
for schematics as well.

<snip>
> Our compiler can already output netlist formats for PADS and Eagle. It
> is easy to create more output formats and we want to support Altium
> and VHDL netlist outputs. The VHDL would be for anyone who might want
> to simulate or graphically view the structure of their design in an
> RTL viewer.
>


RTL viewer generated schematics are usually...well...something that
you don't like to view.

<snip>
> To avoid most of the typing on big FPGA boards


....extra work that is created by choosing to go with linear text
files...

> I wrote a Xilinx2PHDL
> converter that automatically generates most of the text for the
> board.


At least there is a solution to the problem that was self-
created...well for certain suppliers I guess. Does every part
supplier need a converter in order to be productive using PHDL?
Samsung? Intel? On Semi? Lucent? Fairchild?

> When you have text design entry it opens up all kinds of
> possibilities for autogeneration. I'm working on the Actel2PHDL and
> Altera2PHDL converters now.
>


Perhaps you should expound on what those possibilities might be as
compared to schematics. Hierarchy, parameters, generation and reuse
are already there with schematics. What did you have in mind?

> To my mind the biggest advantage of PHDL over graphical schematics is
> compatibility with version control tools. Because it is text, I can
> look back at every change ever made to the design.
>


Any file can be version controlled...whether it is a proprietary data
format or not.

So the biggest advantage you see then is the ability to use 'diff' to
see what has changed which you cannot do with a version controlled
schematic. OK...but since a schematic simply documents intended
connections between devices, the net list CAE file output (which is a
text file as well) can be similarly 'diffed'.

Since the PHDL file is not going to be the 'only' design artifact file
there will need to be other files as well as part of the board design
process. So how is the ability to run 'diff' on a PHDL file
fundamentally any better than running 'diff' on the net list output
from the CAE tools?

Lastly, if what you state actually is the biggest advantage, then ask
yourself who benefits and who pays the cost? Is the cost worth it to
the one who has to pay it? These are all different ways of stating
'What improvements over current art does this bring to the table?'

> We have already designed several printed circuit boards using PHDL.
> Originally I thought it would be best for high pin count FPGA boards
> but we have used it for analog and power boards and those read well
> also. *It is amazing how a few comments can help with the board design
> process.
>


Comments though do not create circuits...therefore one must always
accept that they can be inaccurate and/or misleading

> On the other hand, we understand that a lot of people just like
> drawing pictures of board designs and are willing to use proprietary
> tools to do it. We are just offering an alternative to those HDL types
> who prefer a very direct and open design methodology.
>


People also like to see better ways of doing things and are willing to
change to those better ways. But when there is no indication or it is
not 'obvious' in what way something 'new' is better than the 'old way'
one should question if 'new' is 'better' or 'worse' or just
'different'...ideally being able to back that up with some form of
measurement to support.

As a last point, consider that FPGA tools in some ways return to the
graphical roots for improving designer productivity. FPGA suppliers
provide various widgets (PLLs, memory controllers, image processing
functions, etc.) that can be parameterized by the user with a GUI
wizard for the intended usage. Those widgets in turn can be
instantiated in a graphical tool as well to very quickly generate a
complete design (Altera's SOPC Builder being an example). So even the
area where HDLs are most prominently used by a designer, there is
market pull for a graphical tool to improve productivity...rather
counter to your possible thesis that the text only approach might be
better.


> Anyway, that is enough for today.
>
> * Pete


Thanks for providing the info, hopefully take what I say not so much
as constructive input as it was intended rather than as a rant.

Kevin
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      11-17-2011
On Nov 16, 11:53*pm, KJ <(E-Mail Removed)> wrote:

>
> Thanks for providing the info, hopefully take what I say not so much
> as constructive input as it was intended rather than as a rant.
>


Delete the 'not so much' from above...
 
Reply With Quote
 
self
Guest
Posts: n/a
 
      11-20-2011
Andy

I also started down the "VHDL for PCB" path. I figured out how to use
VHDL attributes to add the extra info we need for PCB netlist
creation. For example, here is how a component declaration might look
using VHDL.

-- This component is a 1:4 LVDS clock buffer.
entity sy89832u is port(
en : inout STD_LOGIC; -- enable pin. internally pulled high.
vref : out std_logic;
vt : in std_logic;
gnd : in std_logic;
vcc : in std_logic_vector(1 downto 0);
in_p : in STD_LOGIC;
in_n : in STD_LOGIC;
q_p : out STD_LOGIC_VECTOR(3 downto 0);
q_n : out STD_LOGIC_VECTOR(3 downto 0));
-- some part attibutes.
attribute pcbl_partlevel of sy89832u : entity is true;
attribute pcbl_package_type of sy89832u : entity is "MLF-16";
attribute pcbl_part_number of sy89832u : entity is "SY89832UMI";
attribute pcbl_part_cost of sy89832u : entity is 15.23;
-- the pin numbers.
attribute pcbl_pin_list of en : signal is "8";
attribute pcbl_pin_list of vref : signal is "10";
attribute pcbl_pin_list of vt : signal is "11";
attribute pcbl_pin_list of gnd : signal is "13";
attribute pcbl_pin_list of vcc : signal is "7,14";
attribute pcbl_pin_list of in_p : signal is "12";
attribute pcbl_pin_list of in_n : signal is "9";
attribute pcbl_pin_list of q_p : signal is "5,3,1,15";
attribute pcbl_pin_list of q_n : signal is "6,4,2,16";
end sy89832u;

It is not too bad but I don't like how the pin numbers are located
down below, disassociated from the port declaration. Also, talking to
compiler designers, I learned that VHDL is notoriously difficult to
parse. VHDL is difficult for the board designer and difficult for the
compiler designer. That is why I dropped the idea of using VHDL for
PCB design.

Here is how a similar device declaration looks in PHDL

// an clock buffer IC
device sy898533 is
attr refPrefix = "U";
attr refDes = "";
attr pkg_type = "SY898533LKZ";
attr mfgr = "MICREL";
attr partNumber = "SY898533LKZ";
attr cost = "4.45";

pin[1:3] vcc = {10,13,18};
pin clk_p = {4};
pin clk_n = {5};
pin pclk_p = {6};
pin pclk_n = {7};
pin clk_en = {2};
pin clk_sel = {3};
pin[1:2] nc = {8,9};
pin[0:3] q_p = {20,17,15,12};
pin[0:3] q_n = {19,16,14,11};
pin vee = {1};
end device;

We optimized the syntax to be easy to type and to be easy to parse. I
really like the way that the list of pin numbers is on the same line
with the port declaration.

I like your suggestion about creating record type busses and routing
those between subsystems. Record types is on the To Do list for
PHDL. I can imagine a record for a DDR3 interface that combines all
the data, address, clocks and control lines into a single record.
Signals from that record would be connected to the individual memory
chips. I think it would be quite readable.

It is possible to do record busses in some proprietary graphical
schematic tools. Unfortunately, every tool does it differently. Even
different versions of the same tool will differ in this sort of
thing.

Our goal is to create an open and free methodology that we could use
for any project that we choose and for any layout back-end program. We
don't want to be controlled by some CAE vendor. We insist that we
control our intellectual property by creating and maintaining it in a
portable format. We want to be free.

Anyway, that's our goal.

Pedro
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
A new approach to FPGA and PCB System Development Platform, SantaClara, CA, USA (By Altium) Vikram VHDL 6 12-10-2009 05:41 PM
VHDL for PCB design? self VHDL 13 10-10-2009 07:11 PM
Book on VHDL basics and HDL based design Brendan Illingworth VHDL 2 01-13-2006 03:01 PM
OT PCB Design s/w Mercury NZ Computing 6 11-25-2005 08:42 AM
Anyone use HDL as design tool for PCBs? Symon VHDL 13 11-20-2003 04:11 AM



Advertisments