Verilog and PCB layout

[Glen Herrmannsfeldt]

I was wondering today if anyone ever generated a PCB
netlist based on verilog source.

If one uses verilog for the top level design for a system,
then the netlist information for the PCB should be there.

The actual layout (pinout) for each device would have to be
specified, but it would be much easier to be sure that each
trace was there, consistent with the verilog simulation.

-- glen

 

[Allan Herriman]

Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote in news:go9fnn$k9t$2
@aioe.org:

I was wondering today if anyone ever generated a PCB
netlist based on verilog source.

If one uses verilog for the top level design for a system,
then the netlist information for the PCB should be there.

The actual layout (pinout) for each device would have to be
specified, but it would be much easier to be sure that each
trace was there, consistent with the verilog simulation.

-- glen

I can imagine the fun you'll have specifying a switchmode PSU design in
Verilog ... and then simulating it in a digital simulator.


I've done it the other way around, e.g. the PCB tool exports Verilog (or
VHDL) which can be simulated. This is a useful technique for boards that
have many devices (of over 1000 pins each) where most of the connections
are "digital".

Things that worked well: we've found connection errors in real designs
(yay!)

Things that didn't work quite so well the first time:

- A lot of scriping (Perl in my case) was needed to resolve the pinouts
between the board netlist and the HDL source. I was never able to
convince the board designers to use the same names for the schematic
symbols that I used on the HDL ports, forcing a pinout file (e.g. UCF for
Xilinx) to be used to map the pin numbers to names.

More recently (in the last half a decade or so) I've changed my process
such that I take the port names in my HDL source from the pin or net
names on the schematic. I use a (Perl) script to generate most my top
level HDL module directly from the schematic netlist.
My project schedules usually work out such the the board guy has finished
the schematic before I want to write the top level HDL module.

- A large number of connections are related to things that you don't want
to simulate at all, e.g. power supply connections. You will need to be
able to identify these in your scripts.

- There will be passive components on the PCB traces. You will need to
use some heuristic to identify series resistors (which you pretend are
zero ohm for simulation) and parallel resistors (which you replace with
pullup or pulldown elements for simulation if the other end goes to a
supply rail). This can all be scripted.

- VHDL doesn't have a good zero ohm series resistor model. This isn't a
problem if using Verilog. The trick for VHDL was to short the nets
together, which (IIRC) requires that one of the nets be renamed.

Regards,
Allan

 

[John Eaton]

Allan Herriman wrote:

Things that didn't work quite so well the first time:

- A lot of scriping (Perl in my case) was needed to resolve the pinouts
between the board netlist and the HDL source. I was never able to
convince the board designers to use the same names for the schematic
symbols that I used on the HDL ports, forcing a pinout file (e.g. UCF for
Xilinx) to be used to map the pin numbers to names.

More recently (in the last half a decade or so) I've changed my process
such that I take the port names in my HDL source from the pin or net
names on the schematic. I use a (Perl) script to generate most my top
level HDL module directly from the schematic netlist.
My project schedules usually work out such the the board guy has finished
the schematic before I want to write the top level HDL module.

Allan,

How does your team create the schematic symbol for your parts? Do you
have a librarian that takes your data sheet and builds the part? If
they are simply taking shortcuts and renaming your pin_names at will
then you should put a stop to that. Their symbol pin_names should
exactly match what is in your data sheet.

On the other hand if your pca designers have a signal and port naming
convention and they are simply mapping your names into ones that are
legal for their process then you should adopt their standard and create
names that are legal for PCA design. Only one group can pick the pin
names and the other must follow exactly. Close doesn't count.

If your part has a jtag boundary scan chain then you will have a bsdl
file with all the information needed to build the schematic symbol. You
need a script that will read your bsdl file and generate a symbol. That
way they are always in sync.

- A large number of connections are related to things that you don't want
to simulate at all, e.g. power supply connections. You will need to be
able to identify these in your scripts.

If you don't test it then it won't work. If the board designer only
connects 9 out of 10 grounds to your part then your simulation should
catch it.



John Eaton

 

[Allan Herriman]

John Eaton <nospam@spam.com> wrote in
news:zuKdnXiACdDqjjHUnZ2dnUVZ_jCWnZ2d@posted.palinacquisition:

Allan Herriman wrote:


Things that didn't work quite so well the first time:

- A lot of scriping (Perl in my case) was needed to resolve the
pinouts between the board netlist and the HDL source. I was never
able to convince the board designers to use the same names for the
schematic symbols that I used on the HDL ports, forcing a pinout file
(e.g. UCF for Xilinx) to be used to map the pin numbers to names.

More recently (in the last half a decade or so) I've changed my
process such that I take the port names in my HDL source from the pin
or net names on the schematic. I use a (Perl) script to generate
most my top level HDL module directly from the schematic netlist.
My project schedules usually work out such the the board guy has
finished the schematic before I want to write the top level HDL
module.

Allan,

How does your team create the schematic symbol for your parts?
Do you
have a librarian that takes your data sheet and builds the part? If
they are simply taking shortcuts and renaming your pin_names at will
then you should put a stop to that. Their symbol pin_names should
exactly match what is in your data sheet.

Sometimes the symbol pin_names are created before the data sheet is
created. I find it easier to make the data sheet (and the HDL source)
match the symbol in that case.

- A large number of connections are related to things that you don't
want to simulate at all, e.g. power supply connections. You will
need to be able to identify these in your scripts.


If you don't test it then it won't work. If the board designer only
connects 9 out of 10 grounds to your part then your simulation should
catch it.

[ I should clarify that my statement about not simulating power supplies
was in relation to digital simulations, specifically verilog ones. I
actually spend a lot of time designing, simulating and reviewing power
supplies and their connections, but not in verilog. ]

Interestingly, I don't recall ever finding a power supply or ground
connection fault in simulation. I guess it comes down to whether you
design something so that it works, or whether you believe something needs
to be tested to work.

If it's a PCB, then I'm in the "design & review" camp. An hour or two
eyeballing the power supply connections on the schematic provides a
balance between effort and risk. I don't think I've ever made a power
supply connection error. (YMMV, of course. If you find that your
designers can't connect power supplies correctly, then simulation may
help.)

[This is getting a bit OT for c.l.v] I spend far more time in the PCB
editor verifying the *quality* of the power supply and decoupling than
just about anything else in the board design verification process.
We don't use automatic model extraction for the power supplies here, so
all this is done manually

Regards,
Allan

 

[Symon]

FYI
http://groups.google.com/group/comp.lang.vhdl/msg/0fb995c0914995e9?hl=en

"Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:go9fnn$k9t$2@aioe.org...

I was wondering today if anyone ever generated a PCB
netlist based on verilog source.

If one uses verilog for the top level design for a system,
then the netlist information for the PCB should be there.

The actual layout (pinout) for each device would have to be
specified, but it would be much easier to be sure that each
trace was there, consistent with the verilog simulation.

-- glen

 

[Jonathan Bromley]

On Fri, 27 Feb 2009 12:43:58 -0700, Glen Herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

I was wondering today if anyone ever generated a PCB
netlist based on verilog source.

If one uses verilog for the top level design for a system,
then the netlist information for the PCB should be there.

The actual layout (pinout) for each device would have to be
specified, but it would be much easier to be sure that each
trace was there, consistent with the verilog simulation.

Way back when I was designing boards with dozens of MSI
(TTL/CMOS) logic chips on them, I longed for a textual
netlist format. I even wrote a netlister (in Pascal!)
that could spit out the netlist in a form more suitable
for wire-wrap or Speedwire prototyping. But there were
so many manual (literally paper-and-pencil) steps in the
design flow in those days that it hardly mattered; you
just hacked together whatever productivity tools worked
for you.

Nowadays, when that sort of prototyping makes no sense
and the logic chips on a board are likely to be fewer
and (much) bigger, I suspect I'd go with the majority
and use a schematic editor, possibly asking it to write
a Verilog netlist of the PCB to help with top-level
simulation - any half-decent schematic package should
be able to do this. Fortunately I don't have to do
that sort of thing now, except for increasingly rare
hobby projects. Good luck to all you young 'uns!
--
Jonathan Bromley,
Technician Emeritus and all-round grumpy old git