Electronic Design

Avoid The Bird Flu With Proper FPGA Migration

Prepare in advance for FPGA-to-ASIC migration, or you may wind up flying in the wrong direction.

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.

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.

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.

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 can 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 (see "The True Cost Of Free FPGA IP").

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). But the migration process poses the perfect time to spread I/O signals out to reduce SSO and make for a more routable PCB. That's because ASICs have no concept of banking or regions (see "Digital Design Tip: Avoid Clusters Of High-Frequency Outputs" at ED Online 13089 and "Digital Design Tip: FPGA Escape Planning" at ED Online 12970).

FPGA place-and-route tools generally let you get away with poor coding practices that can bog down ASIC performance and even lead to unexpected results. Examples include ORed/ANDed clocks, latches being synthesized from incomplete if/then statements, and other asynchronous-related issues that cause, for instance, race conditions post-migration.

Next, make sure your logic doesn't depend on FPGA-specific signals, such as "Done." You'll also have to give your power-on reset circuitry some thought. With an ASIC, you tend to need one good system-level reset, ideally from an IC that generates one. Or, the ASIC can be used to drive the reset of the rest of the system. Test-benches are nice if you have them, since they can be reused at the ASIC design phase. Timing information is critical for proper ASIC layout.

When designing an FPGA, you can often get away with a minimal dose of constraints, as many will be assumed. This isn't the case with ASIC design, though. Timing constraints for skew, setup/hold times, and delays must be specified—ideally in Synopsys' Design Constraint (SDC) language in the standard delay format (SDF).

Other potential "gotchas" to avoid include the use of tri-state buffers and manual instantiations of basic logic elements. Moreover, be particularly careful to avoid associating (via the underlying macrocell that feeds a would-be pin) unused or future signals with no-connect (NC) pins. For more on what not to do to keep your code portable, see "Digital Design Tip: A Few HDL ‘No-Nos'" at ED Online 13369.

Many companies and online resources are available to aid in the migration process, or actually do it for you. When working with a third party, be sure to get in explicit writing what will be included as part of the overall NRE, as well as any potential "gotchas."

A statement of work quote may include 95% fault coverage, so find out how much it will cost to increase the fault coverage later if you require that flexibility. Also, after the third party reviews your project, be sure to find out what functionality will be difficult to migrate (like phase-lock and delay-lock loop elements) and what could cause project delays.

Find out the "rules of engagement" to understand what will be expected of you and when. And, have a dedicated person who is willing and able to resolve issues quickly. Third-party companies will typically take what they can get with respect to constraint, pinout, and report files.

Synplicity's Certify helps in the multiple FPGA-to-ASIC conversion process. The main benefit of using Certify is its RTL partitioning capability, known as Quick Partitioning Technology (QPT). QPT is an automated partitioning tool that targets both experienced practitioners and rookies. Synplicity also offers Identify Pro, which provides a connection between FPGA prototypes and simulation software for analyzing and debugging RTL.

In addition, Synplicity recently acquired Swedish company Hardi, which sells ASIC prototyping mother/daughterboards that can be connected like Legos to meet functionality needs. The company wrote up a nice white paper on using multiple FPGAs to prototype a complex ASIC: "ASIC Prototyping Using Off-the-Shelf FPGA Boards: How to Save Months of Verification Time and Tens of Thousands of Dollars."

The Dini Group, a California-based company, sells ASIC prototyping boards capable of emulating up to 24 million ASIC gates. Meanwhile, ChipX offers migration services capable of converting FPGA RTL code or netlists to structured ASICs, embedded arrays, and standard-cell ASICs. Also, eASIC Corp. offers migration to its structured ASIC devices as well.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.