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 show-stopping 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 on
the order 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, go with 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, ED Online 12987.
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 third-party
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. So, 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 is 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 test-bench 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
design-for-test (DFT) concerns.
Support for DFT requires adding or multiplexing pins. This is followed by the
ASIC's physical design. Next, 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.