Once upon a time, designers could throw FPGA migration over the fence and wash their hands of it. Sure, they may have worked out a few details like optimal pinout along the way. But chances are they didn’t lose any sleep over the process. Nowadays, heads might roll if the migration caused downstream board spins and product delays, especially if the migration was planned from the beginning.

Planned or not, migrating FPGAs to structured ASICs, ASICs, or ASSPs can be smooth sailing—if the process is well thought-out and executed based on some sound guidelines. For example, it can reduce package size, power, and part counts. Yet this also could lead to showstopping issues with timing, noise, and so on.

MIGRATE TO SAVE COST, POWER, AND SPACE

Configured with active elements, FPGAs are designed with maximum flexibility and feature count in mind. As a result, they aren’t very good with power usage per pin/gate ratios for a given process technology size (e.g., 45 nm). They also tend to be bulky and need a heatsink. An external memory for the FPGA configuration code may be required. And, many have other features that weren’t being used or won’t be required going forward.

Even with all of these problems, many companies use FPGAs to prototype their systems. Why? The answer is simple: According to Collett International Research, many companies (43%) prototype to remove functional logic errors. That’s followed by issues regarding reducing analog, signal integrity (SI), and clock scheme (20%, 17%, and 14%, respectively). Also, the software development can be prototyped and the infrastructure validated.

So, post-migration, you can normally expect (sometimes quite significant) cost reductions, typical power savings of between three and five to one or better, reduced pin count (if drop-in replacement isn’t required), package size reduction, and fewer parts. The main variant will be based on your decision to try and maximize performance by using the latest process technology. Or, use a much cheaper older one and gain more of these benefits. Typically, you can get away with a process technology that’s two, three, or even four generations back.

Regardless of the motivation, if you believe there’s even the slightest chance you will be migrating your FPGA, you should plan for it and keep this potential in mind throughout the “napkin to dock” process—starting with the intellectual property (IP) you plan to use. For some guidelines on choosing between structured ASIC and ASIC technology, see “SIC Of Figuring Out The Best ASIC Solution?” at www.electronicdesign.com.

MIGRATION FLOW

If you plan from the get-go to prototype your system using one or more FPGAs and see an ASIC in your near future (assuming you’re working with a thirdparty vendor), you can arrange for a parallel FPGA/ASIC path to production. You can also get up-front advice about each step of the design process, especially the planning phase.

Going to cost-reduce your system, but didn’t necessarily plan for an ASIC conversion? Migration paths tend to follow a flow. Starting from netlist rather than RTL requires a rather significant extra translation and optimization step. Therefore, start with RTL whenever possible (see the figure). During design assessment, I/O standards and other pin requirements are identified, the clocking is evaluated, and the RAM then gets mapped. This is followed by IP migration, which requires extreme precaution.

Next, translation and logic optimization for netlist migration mostly involve removing the logic elements that won’t be required by the ASIC. Lookup tables (LUTs) within the FPGA must be converted to standard logic (NAND, NOR, etc.). Since FPGA netlists are optimized for LUTs, significant opportunity exists to remove unneeded clutter and generate a clean netlist.

Synthesis is then executed with the logic library for the desired process technology, resulting in a technology-mapped netlist. If a testbench is available, simulations can be performed and compared to past FPGA simulations to ensure the results match. Otherwise, a formal verification process should be applied.

After simulation or formal verification, an ASIC-mapped netlist is generated. Scan chain, JTAG, and built-in self test (BIST) elements then are typically inserted for ASIC fault coverage and ASIC/system testability to address the various design-fortest (DFT) concerns.

Continue to next page