Webinar: Aiding ASIC Design Partitioning for multi-FPGA Prototyping

The advantages of prototyping a hardware design on a FPGA platform are widely recognized, for software development, debug and regression in particular while the ultimate ASIC hardware is still in development. And if your design will fit into a single FPGA, this is not an especially challenging task (as long as you know your way around FPGA design). More commonly your ASIC won’t fit into one FPGA and you’ll have to distribute it across multiple devices. Then this task gets a lot more interesting.

REGISTER HERE for this webinar on September 14[SUP]th[/SUP] at 11am PDT or 3pm CEST

First, you’re going to need a board of FPGAs or even a set of boards into which you can map your design. And second you have to figure out how to optimally split the design across those FPGAs. If you’re not getting worried at this point, you should be. Wherever you split, signals have to cross through board traces and sometimes even between boards. Those signals have to travel through device pins, the board traces and possibly backplane connections so they’re going to switch more slowly than signals within a device. Where you thought you had manageable timing, it just got messed up.

Clock signals pose another timing issue; you’ll discover all kinds of unexpected post-partitioning clock skews as clocks cross between devices. FPGA design tools will help you close timing within an FPGA but closing timing across the whole design is going to be your problem.

You also have to deal with IO resource limits on FPGAs. Aside from timing, however you divide up your design you will probably need more IO signals on a device than there are signal pins. Handling this requires some clever logic to bundle/unbundle signals to meet pin limitations; a lot more work if you’re trying to hand-craft your own mapping.

Or you could join Aldec on September 14[SUP]th[/SUP] to learn how you can avoid most of this pain, using their boards and backplanes along with their guided partitioning software to quickly explore partitioning alternatives and confidently map to an implementation which you can close with predictable and usable timing.