Do people do this by hand?

[Mr.CRC]

Hi:

I've been developing a DSP+FPGA engine laboratory experiment controller
for some years. This summer I have a EE intern coming to help me with
hardware and logic development to push toward finishing things.


Some things we need to do:

1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle).
2. Make Eagle model for TI TMS320F2812 DSP.
3. Top level Verilog module to represent all FPGA IOs used and routing
them to sub-modules.
4. Begin developing some sub modules for various functionality.


Steps 1, 2, and 3 seem like extremely tedious processes to perform by
hand, especially the PCB models, since there are 176 pins on the DSP and
may be 200-300 pins on the FPGA depending on the packages we choose.

Also, the system plan is to route nearly all DSP IO and memory interface
pins to the FPGA, so that the FPGA may be used to reconfigure at any
time what specialty DSP IOs appear to the user via a buffered set of BNC
connectors. Thus, we will actually use at least >100 FPGA IOs, all
which therefore must be coded into the top level Verilog module.

What's further boggles my mind is that this is still a relatively simple
system, compared to the high end FPGAs and CPUs which may involve >1000
poins each.

How is this managed efficiently? Employ grunts? Or should I be looking
at the scripting language in Eagle for ex. to attempt to automate the
SMD pad placements, at least? Is there a scripting process which can
assist this on the Xilinx/Verilog side?

Much of this seems difficult to envision how to automate because it is
mainly primary data entry, ie., transcribing signal names from the
system design and datasheets to pin names in PCB schematic symbols and
to FPGA constraint files, which can't be automated.

If anything, it might be possible to develop a central file of signal
names, pad locations, etc., and have scripts generate the PCB models,
Verilog top level module, and constraint file. That way the data entry
only needs to be done once. But will the scripting development be just
as time consuming as typing everything 3 times?


Any ideas on how this is done in the real world would be of interest.




--
_____________________
Mr.CRC
crobcBOGUS@REMOVETHISsbcglobal.net
SuSE 10.3 Linux 2.6.22.17

 

[Gabor]

Mr.CRC wrote:

Hi:

I've been developing a DSP+FPGA engine laboratory experiment controller
for some years. This summer I have a EE intern coming to help me with
hardware and logic development to push toward finishing things.


Some things we need to do:

1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle).
2. Make Eagle model for TI TMS320F2812 DSP.
3. Top level Verilog module to represent all FPGA IOs used and routing
them to sub-modules.
4. Begin developing some sub modules for various functionality.


Steps 1, 2, and 3 seem like extremely tedious processes to perform by
hand, especially the PCB models, since there are 176 pins on the DSP and
may be 200-300 pins on the FPGA depending on the packages we choose.

Also, the system plan is to route nearly all DSP IO and memory interface
pins to the FPGA, so that the FPGA may be used to reconfigure at any
time what specialty DSP IOs appear to the user via a buffered set of BNC
connectors. Thus, we will actually use at least >100 FPGA IOs, all
which therefore must be coded into the top level Verilog module.

What's further boggles my mind is that this is still a relatively simple
system, compared to the high end FPGAs and CPUs which may involve >1000
poins each.

How is this managed efficiently? Employ grunts? Or should I be looking
at the scripting language in Eagle for ex. to attempt to automate the
SMD pad placements, at least? Is there a scripting process which can
assist this on the Xilinx/Verilog side?

Much of this seems difficult to envision how to automate because it is
mainly primary data entry, ie., transcribing signal names from the
system design and datasheets to pin names in PCB schematic symbols and
to FPGA constraint files, which can't be automated.

If anything, it might be possible to develop a central file of signal
names, pad locations, etc., and have scripts generate the PCB models,
Verilog top level module, and constraint file. That way the data entry
only needs to be done once. But will the scripting development be just
as time consuming as typing everything 3 times?


Any ideas on how this is done in the real world would be of interest.

I can't speak for Eagle, because we send out our designs for PC layout
and the outside house uses PADS. We use ViewDraw (a very old Mentor
product) for schematics. You can get some schematic symbols
directly from the IC manufacturer *if* you use a popular capture
program like Orcad. Perhaps Eagle can import these. Otherwise
at least for Xilinx, you can get the ascii pin files which look
like spreadsheets. Usually there is a way to import these into
a schematic program to automatically generate symbols.

Personally I still do this part by hand because I would in any case
have to partition the FPGA into individual pieces (Don't even think
of doing a 1156-ball part in a single schematic symbol) and I
have a preference for the way the symbols are built. With
ViewDraw I have some capability to automate pin names/numbers
by editing the schematics in a text editor (it's an ASCII
file format). I always spend multiple days adding a new
part to the library, including checking every pin against both
the data sheet and the ASCII pin list (in case there are
discrepancies that I might want to ask Xilinx about).

As for the .ucf file for using the FPGA after board layout,
I automate this using an editor that allows regular expressions
and I have macros for taking the ViewDraw netlist and converting
it into a .ucf format that uses the same signal names as the
schematic. This is a multistep process that first extracts
just the board nets that actually go to the FPGA, and then
converting the netlist format to the Xilinx constraints.

Definitely look into automation in every step of the way.
The more you can electronically track your design back to
the manufacturer's data the better you'll sleep nights.

-- Gabor

 

[DJ Delorie]

Having done similar but smaller designs in gEDA, I find a benefit of
using open text files as design files - scripting! I've got a bunch of
tools that do symbols, footprints, and UCF files, from spreadsheets.
Some folks even generate whole schematic pages from spreadsheets and/or
other sources.

To get the spreadsheet started, I often cut-n-paste the data sheets and
clean it up by hand.

 

[KJ]

On Apr 8, 12:47 pm, "Mr.CRC" <crobcBO...@REMOVETHISsbcglobal.net>
wrote:

Hi:

I've been developing a DSP+FPGA engine laboratory experiment controller
for some years.  This summer I have a EE intern coming to help me with
hardware and logic development to push toward finishing things.

Some things we need to do:

1.  Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle).
2.  Make Eagle model for TI TMS320F2812 DSP.
3.  Top level Verilog module to represent all FPGA IOs used and routing
them to sub-modules.
4.  Begin developing some sub modules for various functionality.

Steps 1, 2, and 3 seem like extremely tedious processes to perform by
hand, especially the PCB models, since there are 176 pins on the DSP and
may be 200-300 pins on the FPGA depending on the packages we choose.

The PCB model can be attacked in a couple of ways:
- 'Roll your own' model. This is handy when you don't have a CAD
model yet but you need to test your FPGA code.
- Use a PCB CAD model generated by the CAD tools. Check to see if
your tools allow you to export the schematic as VHDL or Verilog. We
used Cadence and it saved the VHDL/Verilog netlist whenever the
schematic was saved.

There are plusses and minuses with both methods.

The 'roll your own' is obviously prone to errors where the model
differs from the real PCB schematic. It will also take longer to
create since you'll be doing it by hand versus the CAD tool export
which will be essentially 'free' (assuming that the CAD tool rewrites
the file with each save of the schematic). In spite of this, you may
find that you can get to a reasonably accurate model quicker with this
method than with the PCB CAD generated model.

The CAD tool generated model will accurately reflect the actual PCB
design. You'll probably find the high fidelity to be both the best
and worst part of this approach. The stumbling points will have to do
with the most mundane components. I work in VHDL where I solve these
problems mainly with the VHDL configuration statement, I don't know
what facilities Verilog may have, but here are some of the 'gotchas'
and their VHDL work arounds:

- Series terminated clock signal heading into a model that expects the
clock to switch to a '1', not an 'H'. WA=update model to use
'rising_edge()' function instead or use the 'to_x01()' function in the
port map
- Parallel termination to two different voltage levels (i.e. 220 ohm
to +5V; 330 ohm to ground as an example). This situation creates an
unknown at the tie point. WA=Use configuration statement to turn one
of the resistors into an open circuit model (more on that later).
- Terminating a differential pair with a resistor across the pair.
WA=Use configuration statement to turn the resistor into an open
circuit model
- Open pins connected to a 'bus' of pins on a model. For example, a
processor that has a 16 bit data bus, the model has the bus named
DATA(15 downto 0), but only an 8 bit bus is needed and it is
acceptable to leave the unused pins unconnected to the device. VHDL
says that this is an error, maybe Verilog does not. WA=Connect one
pin nets on the schematic. That doesn't result in any actual copper
on the board to route and gets around this language limitation.
WA2=Change the model so that there are 16 individual pins (D15,
D14...D0).
- Series blocking capacitors. Usually the simulation model you want
for a capacitor is an open circuit, drive both pins with a 'Z'. In
this case though you need the capacitor to behave as a short circuit
connecting the 'input' to the 'output'.
- Passives sometimes need 'direction'. In the case of series
connected passives, if the models cannot tolerate momentary
transitions to 'X', then you need to make these parts 'one-way' with a
specific input and output pin. Typically this will come up with a
series terminated clock signal. The transition from '0' to 'X' to '1'
will not be a 'rising edge'. WA=Again use configurations for the
specific components that have this issue and use a model that only
propogates signals in one direction. You'll also want the person
entering the schematic to not be flipping the ends of the resistor
around on you a lot, and it would help if they oriented these 'one
way' resistors consistently.
- You need to model *everything*. Whereas with the 'roll your own'
approach, you'll typically only model and connect the 'important'
parts, with the CAD model, you'll get every resistor, capacitor,
diode, transistor, varistor, fuse, blah, blah, blah...and in order to
simulate anything you'll need models for all of those parts. That's
the bad news. The good news is that for many of the parts you can
probably get away with a brain dead model which simply drives all
outputs and I/O to 'Z' and those are really quick to create. The
exception will be some of the cases mentioned above. You'll
definitely need several different models for resistors and have to use
some facility to select the appropriate model to use since the CAD
generated netlist will instantiate the exact same 'res' component.
- A part that does not physically fit on to a single page so it must
be broken up into sections and instantiated on separate physical
pages. WA=This is the only case where I don't have a work around that
doesn't involve editing the CAD generated model. The CAD model will
instantiate XX separate sections with their individual set of I/O
pins. The problem is that from a simulation perspective, these need
to be a single instantiation. What I did here is to re-arrange the
ordering of the instantiations of the individual sections so that they
are one right after another and then join the various sections up so
that they are all one instantation in the PCB model. This process
must be repeated whenever the schematic is updated.

No matter which approach you take, you'll need models for parts. If
you currently have none, start building up your library now. There
are sources. For 'important' parts, you can find models either from
the manufacturer, or web sources such as Free Model Foundry (http://
www.freemodelfoundry.com/). Be careful with memory models, in
particular flash or other large non-volatiles. Using those models
might require more memory than can be allocated for the simulation.
For others, and definitely for the 'not so important' parts, start
with a 'simple parts library' where you hand generate the model for
the part. It's a bit tedious when you have a long list of parts, but
this library can be reused in future designs, and the models for these
parts can improve over time. The initial cut at simply assigning all
outputs and I/O to 'Z' is simply an exercise in cut/paste that must be
done...but it is pretty quick (~1 minute or less) per component once
you get into the swing of it.

For your first project, maybe those 'not so important' parts can live
with no real model, but now you have all of the infrastructure in
place to enhance the model later for some future project where maybe
the part isn't 'not so important'.

Also, the system plan is to route nearly all DSP IO and memory interface
pins to the FPGA, so that the FPGA may be used to reconfigure at any
time what specialty DSP IOs appear to the user via a buffered set of BNC
connectors.  Thus, we will actually use at least >100 FPGA IOs, all
which therefore must be coded into the top level Verilog module.

What is the question? The top level module would always have to have
every I/O pin. That's a one time thing for any design. Creating the
top level entity shouldn't take more than a few minutes. Since it is
the 'top level', the interface will not be changing frequently since
that implies that the circuit board would as well.

How is this managed efficiently?  Employ grunts?  Or should I be looking
at the scripting language in Eagle for ex. to attempt to automate the
SMD pad placements, at least?  Is there a scripting process which can
assist this on the Xilinx/Verilog side?

Much of this seems difficult to envision how to automate because it is
mainly primary data entry, ie., transcribing signal names from the
system design and datasheets to pin names in PCB schematic symbols and
to FPGA constraint files, which can't be automated.

One approach that I've found useful is simply to use Excel. There
will be several different tools that will all need different 'things'
that are all related to the pin names in the design. Creating Excel
formulas so that each column performs some useful calculation will
allow this spreadsheet to be a kind of 'golden reference' of
information. Starting from a spreadsheet that lists design specific
pin names, their direction (in/out/inout) and the appropriate pin
number some examples of things you can put into the various columns
are:
- Timing requirements. Inputs should have setup times, outputs should
have Tco or Tpd requirements. Create a formula that generates the TCL
command that can be copy/pasted into your FPGA tool to define them.
- I/O drive strength. Again, create a formula to create a TCL command
for the FPGA tool
- Map the pin number to the CAD model's pin name. The CAD model for
the FPGA will have the manufacturer's pin name such as "IO1",
"IO2"...etc. At some point, you will need to create a design specific
FPGA model that maps those entity names to your FPGA design. The port
mappings can be computed in the spreadsheet, copy and paste them into
your design specific FPGA model. You'll need a page in your Excel
file that lists the CAD pin names used and their pin numbers. Once
the CAD people have created the symbol and PCB files, you should be
able to suck that into a new page in Excel. Then you can use Excel's
lookup functions to search for the pin number and return the CAD
name. This CAD page in Excel would not be design specific, you can
use it for any new design that uses that same component.

There are others as well, but the basic idea is to have the Excel file
be the reference...although it will be tempting to bypass this at
times, mostly in the timing requirements area after the initial load.
Even if you're not totally religious about keeping the spreadsheet
accurate it gets you off to a big start. On the next project, since
you now have the spreadsheet with all those formulas, all you will
have to do is populate a new spreadsheet with the new design signal
names, signal direction and pin numbers for a new design and you'll
immediately have everything you need since the formulas won't need any
tweaking...well, as long as the format of the input to the tools
doesn't vary over time (but it will...but usually not that much).

If anything, it might be possible to develop a central file of signal
names, pad locations, etc., and have scripts generate the PCB models,
Verilog top level module, and constraint file.  That way the data entry
only needs to be done once.  But will the scripting development be just
as time consuming as typing everything 3 times?

Generating the spreadsheet and then using that to copy/paste into the
tools will likely take just about as long as using the tools directly
or a bit longer...but only the first time you do it this way. The
advantage will be with the *next* design since you'll have all the
pieces in place to simply populate a couple columns of the
spreadsheet. Disadvantages of scripts has to do with the scripting
language and whether you have, and will continue to have in the
future, expertise in the scripting language itself. The learning
curve for Excel formulas should be lower than a scripting language.

Any ideas on how this is done in the real world would be of interest.

Hopefully given you at least a few good ideas.

Kevin Jennings

 

[Nico Coesel]

"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> wrote:

Hi:

I've been developing a DSP+FPGA engine laboratory experiment controller
for some years. This summer I have a EE intern coming to help me with
hardware and logic development to push toward finishing things.


Some things we need to do:

1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle).
2. Make Eagle model for TI TMS320F2812 DSP.
3. Top level Verilog module to represent all FPGA IOs used and routing
them to sub-modules.
4. Begin developing some sub modules for various functionality.


Steps 1, 2, and 3 seem like extremely tedious processes to perform by
hand, especially the PCB models, since there are 176 pins on the DSP and
may be 200-300 pins on the FPGA depending on the packages we choose.

Also, the system plan is to route nearly all DSP IO and memory interface
pins to the FPGA, so that the FPGA may be used to reconfigure at any
time what specialty DSP IOs appear to the user via a buffered set of BNC
connectors. Thus, we will actually use at least >100 FPGA IOs, all
which therefore must be coded into the top level Verilog module.

What's further boggles my mind is that this is still a relatively simple
system, compared to the high end FPGAs and CPUs which may involve >1000
poins each.

How is this managed efficiently? Employ grunts? Or should I be looking
at the scripting language in Eagle for ex. to attempt to automate the
SMD pad placements, at least?

PCB packages often have a pin array generator which helps creating
BGA, QFP and QFN layouts. The opensource Geda/PCB package allow
creating footprints and parts by scripts because those are defined in
simple text files.

Is there a scripting process which can
assist this on the Xilinx/Verilog side?

IIRC Xilinx has Excel sheets which you could convert to text files.

Much of this seems difficult to envision how to automate because it is
mainly primary data entry, ie., transcribing signal names from the
system design and datasheets to pin names in PCB schematic symbols and
to FPGA constraint files, which can't be automated.

If anything, it might be possible to develop a central file of signal
names, pad locations, etc., and have scripts generate the PCB models,
Verilog top level module, and constraint file. That way the data entry
only needs to be done once. But will the scripting development be just
as time consuming as typing everything 3 times?

Developing scripts is an insurance premium against errors. Developing
a script takes a -more or less- predictable amount of time. Finding an
error in the pinout takes a variable amount of time.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Tim Wescott]

On Fri, 08 Apr 2011 09:47:55 -0700, Mr.CRC wrote:

Hi:

I've been developing a DSP+FPGA engine laboratory experiment controller
for some years. This summer I have a EE intern coming to help me with
hardware and logic development to push toward finishing things.


Some things we need to do:

1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle). 2.
Make Eagle model for TI TMS320F2812 DSP. 3. Top level Verilog module to
represent all FPGA IOs used and routing them to sub-modules.
4. Begin developing some sub modules for various functionality.


Steps 1, 2, and 3 seem like extremely tedious processes to perform by
hand, especially the PCB models, since there are 176 pins on the DSP and
may be 200-300 pins on the FPGA depending on the packages we choose.

Also, the system plan is to route nearly all DSP IO and memory interface
pins to the FPGA, so that the FPGA may be used to reconfigure at any
time what specialty DSP IOs appear to the user via a buffered set of BNC
connectors. Thus, we will actually use at least >100 FPGA IOs, all
which therefore must be coded into the top level Verilog module.

What's further boggles my mind is that this is still a relatively simple
system, compared to the high end FPGAs and CPUs which may involve >1000
poins each.

How is this managed efficiently? Employ grunts? Or should I be looking
at the scripting language in Eagle for ex. to attempt to automate the
SMD pad placements, at least? Is there a scripting process which can
assist this on the Xilinx/Verilog side?

Much of this seems difficult to envision how to automate because it is
mainly primary data entry, ie., transcribing signal names from the
system design and datasheets to pin names in PCB schematic symbols and
to FPGA constraint files, which can't be automated.

If anything, it might be possible to develop a central file of signal
names, pad locations, etc., and have scripts generate the PCB models,
Verilog top level module, and constraint file. That way the data entry
only needs to be done once. But will the scripting development be just
as time consuming as typing everything 3 times?


Any ideas on how this is done in the real world would be of interest.

Steps 1 & 2 should only take a day -- two if you can't find package
models in the Eagle libraries already. It'll take you longer than that
to hire someone.

--
http://www.wescottdesign.com

 

[Chris Maryan]

See if you can develop a way to script the whole thing. A lot of tools will let you write a script to build up a pinout for a schematic or PCB symbol from something like a spreadsheet file. You can also typically use the same file as a starting point for the FPGA IO definitions.

Companies that do a lot of this generally have three things going for them: they've taken the time to develop good scripted/automated workflows for tedious tasks; once a part is in their library it gets tons of reuse; any board developed with a particular set of IO constraints will usually get a reasonable lifespan so any changes are infrequent.

Chris

 

[Kim Enkovaara]

On 8.4.2011 19:47, Mr.CRC wrote:

Any ideas on how this is done in the real world would be of interest.

In the high end Schematics/PCB packages there are specific tools to do
pin planning, pin swapping etc. For example Mentor IO-designer is one
such tool. It can for example read in the constraint files from FPGA
tools and produce the symbol from that data, and if pins are swapped it
can export the new constraints etc. (there are also many other ways to
do the symbol in the tools).

There are also tools to check all the PCB design constraints and manage
that data (length rules, differential pair rules etc.)

--Kim

 

[Martin Thompson]

"Mr.CRC" <crobcBOGUS@REMOVETHISsbcglobal.net> writes:

Hi:

I've been developing a DSP+FPGA engine laboratory experiment controller
for some years. This summer I have a EE intern coming to help me with
hardware and logic development to push toward finishing things.


Some things we need to do:

1. Make Xilinx Spartan 3E PCB CAD model (most likely for Eagle).

My PCB tool generates BGA footprints in seconds. Or you can buy a wizard from
PCB Matrix (now owned by Mentor, but AFAIK they still cover lots of PCB tools):
http://www.mentor.com/products/pcb-system-design/pcbmatrix

2. Make Eagle model for TI TMS320F2812 DSP.

Ditto.

3. Top level Verilog module to represent all FPGA IOs used and routing
them to sub-modules.

That can be a bit tedious, although if the signal names map 1:1 (or nearly)
Emacs does a good job of the really tedious bit. If you've already got the
schematics drawn, some tools can export a VHDL wiring file which might help.

4. Begin developing some sub modules for various functionality.

That's the interesting part

Steps 1, 2, and 3 seem like extremely tedious processes to perform by
hand, especially the PCB models, since there are 176 pins on the DSP and
may be 200-300 pins on the FPGA depending on the packages we choose.

Also, the system plan is to route nearly all DSP IO and memory interface
pins to the FPGA, so that the FPGA may be used to reconfigure at any
time what specialty DSP IOs appear to the user via a buffered set of BNC
connectors. Thus, we will actually use at least >100 FPGA IOs, all
which therefore must be coded into the top level Verilog module.

That sounds like a fun challenge, are you really planning to buffer the EMIF
onto BNC connectors?

What's further boggles my mind is that this is still a relatively simple
system, compared to the high end FPGAs and CPUs which may involve >1000
poins each.

How is this managed efficiently? Employ grunts? Or should I be looking
at the scripting language in Eagle for ex. to attempt to automate the
SMD pad placements, at least? Is there a scripting process which can
assist this on the Xilinx/Verilog side?

Last big design I did was a 676 pin BGA to 4 memory chips, 50 or so to other on
board compoments and 150 or so to expansion boards. I used MIG to assign the
memory interfaces, import those to PlanAhead to assign the rest of the pins.
That then exports a CSV, and I have a script which then converts that into a
format that my schematic capture tool can use, so I don't have to manually keep
that in sync. I also export a UCF file for the Xilinx implementation tools.
the pins

Much of this seems difficult to envision how to automate because it is
mainly primary data entry, ie., transcribing signal names from the
system design and datasheets to pin names in PCB schematic symbols and
to FPGA constraint files, which can't be automated.

It can if you have the right tools - I can't comment on whether Eagle can do this.

If anything, it might be possible to develop a central file of signal
names, pad locations, etc., and have scripts generate the PCB models,
Verilog top level module, and constraint file. That way the data entry
only needs to be done once. But will the scripting development be just
as time consuming as typing everything 3 times?

It depends how dynamic your pinout is. If you're sure it's right, and won't
need to to it again, just sitting down and typing it all can be a better way.
But I found it really useful to be able to tweak the pinout of the FPGA late in
the PCB design process to ease the routing and ripple that through the deswign
from one source.

And once you've got a flow that works, your next designs can make good use of
that investment.

HTH!

Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware