Six Automated Steps to Design Partitioning for Multi-FPGA Prototyping Boards

Before starting your next FPGA Prototyping Project you should catch the next SemiWiki webinar – “Six Automated Steps to Design Partitioning for Multi-FPGA Prototyping Boards”, in partnership with Aldec.

A significant portion of my  30+ years in the EDA industry has revolved around design verification with some form of FPGA prototyping, and the verification challenges facing SoC developers haven’t changed much in concept.

However, in today’s world, the cost of failure is much higher and the verification complexity has skyrocketed.  Today’s SoC designers have a plethora of available verification options from formal to simulation to emulation and FPGA prototyping, and most advanced design teams employ some amount of each of these techniques to get designs right before tapeout.  When verification speed is critical you are pretty much forced to include FPGA prototyping.  Emulation is the right choice for high speed debug up to about 1 MHz, but if you need to run at 20 MHz or 100+ MHz to cover your verification space, confirm video streams, or early hardware-dependent software verification, you should seriously look into to adding FPGA prototyping to your verification hierarchy.

This SemiWiki webinar is an excellent overview of the issues facing SoC designers who need to build FPGA prototypes that must be partitioned across multiple FPGAs. Once it is decided to use multiple FPGAs, whether for a single large design, or for multiple instances of the same design talking together, the top-level challenges are well documented: Partitioning, I/O interconnect between FPGAs, and clocking.

Partitioning, or deciding which parts of your design to put in each FPGA, is straight forward in concept, but the devil is in the details.  Simultaneously organizing the FPGA partitions to optimize FPGA utilization, minimize FPGA interconnect, and achieve the target performance is similar in some respects to the “Whac-A-Mole” game, you optimize one metric, and you knock one of the other metrics out of spec.  Oh, and to make your partition challenge more interesting, there’s Rents Rule.  This Rule says you can only put so much logic inside of so many pins, so figuring out how to “cut” your design across multiple FPGAs has limits beyond your control.

Then there’s the I/O interconnect between FPGAs.  The difficulty of this task will be design dependent, but if your design is “highly interconnected”, you may not have enough physical pins to accommodate your logical pins between the FPGAs.  But, don’t despair, pin-multiplexing techniques between FPGAs are available and well understood.  Ah, but, pin-multiplexing comes with a performance penalty, remember the Whac-A-Mole analogy?

Lastly, system clocks and resets must be carefully managed for FPGAs, and there are physical implementation differences between SoCs and FPGAs.  Keep in mind that the FPGA prototype is not the design, but it must “behave” like the design to be an effective design verification platform.  Getting your FPGA clocks to behave like your SoC clocks without introducing design anomalies can be a challenge, and doing a good job with clocks will determine whether or not you hit your FPGA performance targets.

FPGA prototyping is not for the faint of heart, but it can save a design respin or two.  In the early days of emulation, we used to say, “Emulation is hard, but its damn well worth the effort”.  So, my recommendation is to do everything you can to prepare for the project.  Like watching the SemiWiki webinar on this very subject.  And, similar to those familiar warnings: “don’t try this at home”, get someone on your team who has done this before, absolutely.

The Q&A should be especially interesting for this one. If you want to include your questions to my list add them in the comments section.

About Aldec
Aldec Inc., headquartered in Henderson, Nevada, is an industry leader in Electronic Design Verification. Established in 1984, Aldec offers patented technology in the areas of mixed-language RTL simulation, FPGA acceleration and emulation, SoC/ASIC prototyping, design rule checking, clock domain crossing analysis, requirements traceability and functional verification for military, aerospace, avionics, automotive and industrial applications. www.aldec.com