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
Support for DFT requires adding or multiplexing pins. This is followed by the ASIC’s physical design. Subsequently, a post-layout static timing analysis and simulation/formal verification should be performed as a final check. Lastly, the ASIC design files (OASIS/GDSII) are sent to a fabrication plant, followed by packaging and a final round of testing.
VERIFY IP MIGRATION
Intellectual property came by its name because, well, it belongs to somebody who expects to be paid for its use. Mistakes happen in IP selection when designers assume it can be legally migrated, it won’t cost more than the FPGA vendor is charging, and it’s able to be easily modified.
Suppose your FPGA includes a microprocessor core from company XYZ (or the FPGA vendor), and you paid a nominal fee to use it. You get your product working and it’s an overnight success, and it’s time to pull the trigger on an ASIC migration. If the FPGA vendor owns the rights to the IP, you would be forced to design a new core from scratch. If the core is licensable, you’re likely looking at a very significant licensing fee and could even face royalty fees.
As such, it’s highly recommended that you work with the IP vendors for the IP you plan to use in advance, because a deal often can be struck that could save significant money downstream. This early research could even affect your choice of FPGA vendors, if the downstream savings have a significant enough delta between IP vendors.
If you plan to work with an external migration vendor and you wind up tweaking the IP, be sure to include a bountiful supply of design notes (and HDL code comments). These vendors typically offer a plethora of IP that’s already been ported for ASIC use on hand, and tweaks can be difficult to follow (for more on this subject, see “The True Cost Of Free FPGA IP” at www.electronicdesign.com).
SYSTEM-RELATED ISSUES
Several potential system-level “gotchas” may arise if there’s no advanced migration plans. While some may be overcome with a few jumper wires on the printed-circuit board (PCB), others could potentially require your system to be redesigned from scratch.
If no initialization is found, FPGAs tend to initialize memory, register, and I/O states for you, whereas the ASIC will require explicit initialization of these elements via a global reset signal. Speaking of memory, be sure the size and features of the FPGA’s RAM will map to something that’s provided by the ASIC vendor. And, be sure to avoid the “a” words (asymmetric and asynchronous), as duplication of this type of logic will be arduous and prone to error during migration.
FPGAs also tend to offer a slew of I/O standards at various voltage levels. Be certain that the target ASIC library supports the I/O standards you plan to use. Finally, if your ASIC will be running at a faster speed than the FPGA prototype, you may need to reconsider I/O signal assignments for better system noise immunity.
FPGAs tend to force I/O signals to be grouped within banks based on I/O standard and associated voltage compatibility. Grouping fast signals leads to potential simultaneous switching output noise (SSO or SSN).
