Advice for board designers...

[eteam00]

Feel free to reply in this thread with additional advice for board designers...  I will link to this thread in the New Users Forum README thread.

1.  Do not consider the board layout settled until the FPGA design is more or less proven to work (timing and fit) with a settled FPGA pinout.  Some timing margin problems are solved only with somewhat specific pinout re-arrangements.  Some logic density problems (running out of logic resources) are solved only with drastic feature reductions or larger FPGAs (and larger packages).

2.  Do not consider the board layout settled until a proper design review has been successfully completed.  A design review is only as effective as the skills and attention provided by the reviewers, so make sure you select reviewers with broader and different talents than your own.  A talented designer can save one board at a time as a designer, and can save many boards as a reviewer of other designers' boards.

3.  Include the testing and manufacturing (assembly) folks in the board design reviews.  You ignore their expertise and advice at your own peril.

4.  Do not overlook review checklist items which are so simple and basic that they are "laughable".  Some of these items are almost always performed manually, such as:

• checks (and signoff) for single-pin nets in the netlist, and unconnected pins
• checks for new schematic symbols against the package pinout in the datasheet
• checks for new component layout footprints ("dollies") against the manufacturer's mechanical drawings
• checks for proper handling of all high-current nets
• checks for optimal placement and connection of decoupling capacitors
• checks for optimal placement of signal termination components
• checks for proper layout of all clock signals
• checks for signal stubs which will affect timing and signal integrity
• checks that the automated checks (netlist consistency, DRCs, etc.) have been run and resolved
• checks that the design reviewers have received the design material AND have diligently reviewed them
• checks that the board layout designer is using the latest version of the board netlist
• checks that the board layout designer understands and has implemented each "design note" you have provided
• checks for "kelvin" voltage sensing connections
• checks for supply plane layout and signals crossing supply planes
• checks for mechanical clearance around connectors (including "overhang")
• checks that any "pin-swapping" rules used in layout are correct and proper, and schematics have been back-annotated

Some (but not all) layout software packages will automatically enforce interesting layout requirements such as trace skews (e.g. DRAM byte lanes, ethernet PHY interfaces), differential pair trace design, etc.  These signal attributes must be properly imported and the design rules must be properly applied to be effective.

Do any of the items in this list sound familiar?

It only takes one silly oversight to ruin your day when it comes time to debug your shiny new prototype board.

-- Bob Elkind

[gszakacs · Accepted solution]

I'll add some Xilinx-specific recommendations:

• Make sure you're working with the very latest versions of the chip documents.  Sign up for e-mail notification for any products you currently use or intend to use.
• Try to use more than one source to verify device pinouts.  Data sheets, ascii pinout files, and above all the design tools.  If there are discrepancies, the design tools are most likely to be the final word.
• Especially for new devices, check for errata or other product notifications that may impact board layout.
• Consult the package user's guide for recommendations on pad sizes and breakout patterns as well as thermal management.
• Find an eval board or kit that uses your part, and look through its schematics.  Especially for configuration-related circuitry make sure you understand how the eval board works before you decide if you can live without certain parts.
• Bundle up all the app notes for high-speed design components like MIG or Rocket I/O and make sure that the layout designer is aware of the board routing requirements (impedance, length matching, pair routing, ...).
• Have a debugging plan.  If necessary, route unused IO's to a connector for a logic analyzer.  And you'll never regret adding more LED's on IO's for simple debugging. 
• Especially for small items that are typically sealed in a box, think about how you would go about re-programming an FPGA.  Can you use an existing interface or do you need to add a dedicated programming port?  Is that SPI flash capable of indirect programming via Impact?
• Use the power estimator before starting a power-supply design.  Try to be conservative when estimating power for a device whose code is not final.

-- Gabor

[austin]

My additions:

1.  All signals simulated for signal integrity (overshoot, undershoot, ringing, impedance matching...)

2.  Bypassing (decoupling) checked against user's guide.  If the guide is not met, have the proper power integrity simulations been performed to validate the choices of the bypass capacitors and their layout and locations?

3.  Has the issue of simultaneous switching IO pins (and internal signals) been considered?  Too many SSO cause excessive system jitter due to ground bounce and may lead to timing closure problems (half the p-p jitter subtracts from the slack).

My three are the three most common really bad mistakes that I see made.  Any of these requires a board redesign (respin).  The software needed to do it right costs less that having to respin the board.

And, finally,

4.  Are the power suppliesd capable of supplying at least 1.5X the required power on each power rail?

The last item is sometimes modified for the industry you are in, and how good you think your power estimate is.  In no case shoud a power supply have less than 20% over-capacity, as the error in power estimation is +/- 20%!  Is used 2X for telecom systems as the "rule."  Fixing this last problem is often not a complete re-spin, but is none the less annoying, and takes time and money to resolve (larger heatsink, adding a fan, etc).

Great list! (with additions)

http://www.xilinx.com/products/design_resources/signal_integrity/si_pcbcheck.htm

I do not know how many of yours are new, or not on our list already.  In fact, I don't know if mine (above) are on the Xilinx list, either....

[barriet]

Good idea and inputs.

I'll add a link to this one:

http://www.xilinx.com/products/quality/fpga_best_practices.htm (FPGA Design Best Practices)
   ->  http://www.xilinx.com/support/documentation/tutorials/xtp031_FPGA_System_Design_Checklist.pdf (FPGA System Design Checklist)

And some others:

http://klabs.org/mapld04/tutorials/vhdl/presentations/design_checklist.pdf

http://web.archive.org/web/20050223021701/http://www.brunham.net/kalen/fdesign.html

http://web.archive.org/web/20050223223109/http://www.brunham.net/kalen/fspeed.html

http://www.dinigroup.com/product/common/6k10_faq.pdf (DINI Group DN6000K10 Series General Reference/FAQ)

http://www.enterpoint.co.uk/techitips/Previous_TechiTips/techitips_checklist.html (FPGA Design Checklist)
http://www.enterpoint.co.uk/techitips/techitips_build_first_fpga.html (TechiTips - Building Your First FPGA or CPLD Design)

http://www.xilinx.com/support/documentation/application_notes/xapp104.pdf (A Quick JTAG ISP Checklist)

My list of things I'v'e seen at one time or another:

http://forums.xilinx.com/t5/Synthesis/XST-producing-seemingly-random-results/m-p/126000/highlight/false (XST producing seemingly random results)

Cheers,

bt

[joe4702]

Don't deviate from the reference (eval) board design unless there is good reason to.

Keep track of deviations which affect software.

Give that list of changes to your embedded software folks.

Saves having to compare schematics and/or trying to guess what the board designer changed such that working eval board code is now broken.

[nima_taie]

Just few to add:

1. Before the review, divide up the work among team members if the design is too big and complex. 

2. Make sure on high speed serial lines: the TX from one device is connected to RX on another, and vice versa

3. Pay attention to cable shield connection on the board - It could create ground loop if connected at both ends

4. Always ask for DFM from the board manufacturer. 

[evgenis1]

@eteam00 ,

>> 1.  Do not consider the board layout settled until the FPGA design is more or less proven to work (timing and fit) with a settled FPGA pinout...

This is not practical for the industry I'm in. I'd relax this to: FPGA design is prototyped to the extent that it compiles with no place and route errors or critical warnings. All I/Os are connected to some logic. Clocks are properly constrained, connected to PLLs if needed, and drive some logic. All complex IP cores - memory controllers, transceivers, PCIe - are instantiated.

Thanks,

Evgeni