Improving ASIC Design Verification using FPGAs and Structured ASICs

Pat Mead, Altera Europe
High Wycombe, UK

Abstract :

Structured ASICs require developers to re-program only the top level metal layers when customizing their designs, enabling faster development time and low unit cost. However, many structured ASICs still mandate considerable time and effort for design verification to reduce the risk of any design problems. While existing verification techniques are generally valuable for detecting bugs in an ASIC or SoC design, for medium-to-large device sizes these techniques are more applicable at the lower level metal layers instead of the top level layers where custom programming is done.

Prototyping an ASIC or SoC design using field programmable gate arrays (FPGAs) can relieve the time bottleneck and remove the high caliber compute resources required to verify the functionality of medium-to-large sized designs. A single FPGA prototype, for example, can serve to verify hardware, firmware, and application software design functionality before first silicon is received in-house. This presentation will discuss the benefits of using FPGAs and structured ASICs to improve verification of ASIC or SoC designs in less time, thereby reducing the overall risks of ASIC or SoC development.

The Verification Challenge

While rising mask set costs often dominate the headlines as the challenge that threatens the adoption of new semiconductor technology, this isn’t the full story.  Post-project analysis shows that design and verification account for the majority of development costs.  Furthermore, verification typically takes three times the amount of time that design does.  The increased total cost of chip development, which verification plays a significant part, now influences the way that products are built.  Commercial pressure and return-on-investment concerns mean that a single mask set attempts to serve many different customers or market segments.  An OEM developing a standard cell ASIC may need to amortize their costs across multiple generations or variants of products.  The additional features required by multiple generations and variants add further to the verification challenge.  It’s not uncommon for ASICs to be taped out with only the major variants and modes verified simply because the major market cannot delay tapeout any longer.  The same problems face ASSP companies.  Attempting to serve multiple customers and market segments with a single chip can often be a false economy as verification and design make up the highest proportion of the program cost.  The ultimate challenge for these companies is to reduce their verification budgets whilst minimising the chance of needing to re-spin the design.  Unfortunately, the odds are stacked against this with around 60% of modern ASIC designs requiring some kind of re-spin.   Clearly, the worst possible scenario that a company may face is spending a large amount of time in design and verification then truncating the final stages, only to find that they leave bugs in the design that cripple the device and require them to re-spin the design. 

The amount of verification deployed can often be linked to the risk profile of the company.  For example, a company that has earned its reputation for always being first to market will probably need to take more risks to maintain that position (assuming they have access to the same tools and resources as their competitors).   Conversely, companies that build a reputation for always delivering what they say they will at the time they promised will seek to preserve that reputation by investing time and money in thorough verification cycles.  As complexity of designs increase, the additional functionality included in ASIC and SoC designs mean that computing resources and EDA tools are stretched to the limit.   ASIC development teams can often find they simply run out of time or resources to search for more bugs and as the rate of finding bugs reduces to a low-rate the decision is made to tape out.   It’s not surprising that ASIC design teams will accept help in whatever form it comes and for as many as 40% of ASIC design teams, the solution is FPGA prototyping.

FPGAs in the verification flow

Firstly let’s assume that a designer needs to create a structured ASIC or standard cell ASIC in order to meet one or more of the following design considerations: unit cost, low-power or high-density that they can not find in the FPGA in which they choose to prototype.  FPGAs have been adopted as part of ASIC design methodology as a technology that allows a design to be re-spun until the functionality is correctly verified.  The unique advantage they bring as a verification tool is that FPGAs are able to run closer to system speed than any other verification technology and can interface to a wide variety of stimulus and test equipment.   They also allow the designer to typically run multiple design iterations in a single day which allows rapid solving of many system level design functionality issues.   A wide variety of emulation technologies have evolved to help try to solve the verification problem for the ASIC designer.  Commercially available solutions come in many shapes and sizes.  They range from arrays of FPGAs where each FPGA represents a small part of the whole design to FPGA-based accelerators that work alongside a computer-based simulator to implement key parts of the design in hardware.  Some ASIC developers also create unique hardware, which is again, often FPGA based.  This approach has the advantage of being able to integrate the same external components that will ultimately be used in the system.  These platforms often serve as the most effective way to get “near final” hardware onto the desk of a software engineer.    Most structured ASICs have similar design flows to ASICs and rely on emulation or accelerated simulation to debug functional errors from designs.   Some manufacturers offer development cards with examples of their platforms alongside FPGAs to help designers build part of their system. 

FPGAs offer real value in verification when they are deployed to help build a significant part of the system or used in multiple instances to implement a partitioned system.   Clearly, you can’t build every SoC and ASIC within an FPGA due to the levels of complexity and integration of mixed-signal functions that are sometimes required.  Modern FPGAs, however, are phenomenally different to the FPGAs of five or ten years ago.   For example they are often made on a process node that is either the same as leading-edge ASIC technology or even a process generation ahead.  For example, today, 90nm FPGAs are commonplace and are available in a wide range of families from different manufacturers.  In 2007, the next-generation of 65nm FPGAs will roll-out into production.  Just a few years ago, FPGAs were typically at least 2 process generations behind.   This technology catch-up is due to the two main reasons:  Firstly, the FPGAs vendors desire to drive their densities higher, whilst simultaneously reducing cost, sustained by the ability to ship the same silicon to multiple end markets.  Secondly, the ASIC industry hit a barrier of what their end-customers could sensibly design, verify and market.  In these cases it was possible to make ever larger chips on newer processes, but customers typically wanted lower complexity and the lower NRE charges of the previous generation of technology.   This was frequently the case in all but the highest volume components for cellular phones, and personal consumer electronics.

The anatomy of a modern FPGA might offer a surprise in terms of its complexity and capabilities.   The features and performance of an FPGA have always determined its suitability as an ASIC prototype and as a system capable device in its own right.   For example, the largest member of Altera’s recently announced Stratix III family, which will be built on 65nm technology, offers a logic gate count of around 3.5M gates, 17Mbits of embedded memory and around 1M gates of complexity in the I/O banks to implement a variety of external system-level interfaces for communications, control and memory.   Some ASIC gate counting methodologies would actually class this as a device that had in excess of 40M ASIC gates!

Can Structured ASICs solve the problem?

The original value-proposition of the structured ASIC is that it can be implemented at a fraction of the cost of modern standard cell ASICs.  This means that custom technology can be developed without needing the end-product to ship in millions of units per year to be viable.  Some of the reduction in development cost comes from the simplified verification of this technology.  From a silicon perspective, the architecture of a structured ASIC is similar to the FPGA.   Pre-fabricated base arrays with pre-defined logic, memory, clock networks, and I/O resources are designed with a range of sizes and features.   These arrays are processed through manufacturing up to a certain level of layers to provide the basic infrastructure.  Custom designs are then implemented on these base arrays using the top few metal layers, thus creating an ASIC.  The common base array means that the majority of the deep sub-micron effects and characterization of the logic, memory and support functions can be taken care of at the time of design of the base array.  Care and attention to the effects of crosstalk, parasitics and voltage drops still need to be checked as the customization layers are added, but if the base array has been designed correctly, any problems found can still be fixed at the top layers.  This means that structured ASICs have rightly gained a reputation for saving verification and design time during the back-end ASIC design flow.   Most structured ASICs, however, offer little to help with the functional verification apart from using pre-defined building blocks which minimize errors in design that might be caused by building memories or macros from compilers or mapping functionality of the design onto the ASIC vendor’s library. 

The choice to use structured ASICs over standard cell ASICs, however, is usually driven by commercial reasons.  It is rarely considered to use Structured ASIC to minimise risk through reduced verification time, especially as an interim solution to standard cell ASIC technology.    The benefit of using a structured ASIC to reduce the verification risk of a standard cell ASIC might not be instantly obvious.   The real benefit comes when a structured ASIC that has equivalent functionality and a pin-compatible FPGA is used to form the first part of the development cycle.

Not all structured ASICs are the same

Choice in the structured ASIC market expanded rapidly to form a wide variety of very different offerings.  These ranged from high-complexity base arrays that looked more like standard cell or ASSPs, with a small amount of user customization, to more fine-grained architectures that look more like modern gate arrays, but with very limited embedded memory or system level features (at least compared to modern FPGAs.   Both of the extremes of this range have ultimately suffered from poor adoption in the marketplace.   The high-complexity offerings suffered from a very complex design flow and overspecified base arrays.  This meant that development costs for the ASIC vendor were unlikely to be returned from the modest NRE charges of structured ASIC.   Conversely, the low-complexity offerings struggled to offer the system level capabilities needed today, such as embedded memory and complex PLLs for board level timing.  Interface standards such as LVDS, DDR2 and QDR2 were also often not possible on the older process nodes that these devices were typically made on.  Ultimately, this part of the market is destined to follow the fate of the gate array and be replaced by cost-optimised FPGAs.

For higher-complexity structured ASICs, the more IP blocks that are placed in the design should, theoretically ease the verification burden.  Consideration, however, needs to be given as to how the blocks will be verified with the rest of the design and whether they include errata that have not been discovered form the base array development.    Their complexity means that their interaction with the rest of the system is complex by nature and needs to be modeled, verified and debugged at a system level.  These blocks will often include a processor or multiple processors that will be running a real time operating system (RTOS) and will require extensive verification throughout the entire boot, software loading, register configuration and operation phases.

Finer grained structured ASICs offer less integrated IP, but due to their similarity with FPGAs, do offer the chance to try out the individual IP within an FPGA.   There are many initiatives and bus interface standards to address this challenge.  The creation of these standards has been driven to help designers integrate and verify IP from multiple sources with minimal time and uncertainty.   Once all the IP is connected together the next challenge is system verification at speeds as close to the final system speed as possible.

Altera’s HardCopy structured ASICs offer an approach that removes significant risk from both the technical and commercial aspects of building complex ASICs.   They offer a bridge from the world of FPGA prototyping to a system that would offer power, cost and performance benefits over FPGA but at lower cost and risk than standard cell ASIC.   If the end-product can take advantage of a fast-track to production while the final standard cell ASIC is being verified then this approach offers the unique ability to lower both commercial and technical risk

Summary and Conclusion

Migrating from FPGA prototyping to structured ASIC production has been simplified via Altera’s HardCopy structured ASIC solution. With three production options – FPGA for low volume, Altera’s HardCopy structured ASIC for medium volume, and standard cell ASIC for high volume, the program manager can select which production path is most suitable for current market conditions. Seamless migration from FPGA to HardCopy structured ASIC addresses low to medium production volumes. Reuse of the RTL, scripts and constraints when migrating from FPGA to HardCopy II is addressed using common Altera tools.  Finally, minimal rework of RTL and scripts are needed to move to a standard cell design environment.   The significant advantage of this approach is that production can already have started in structured ASIC while end-customer demand ramps.  Meanwhile, the verification of the standard cell ASIC (which can focus on the differences between the structured ASIC and the standard cell ASIC) can continue.   At the point the standard cell ASIC is ready for tapeout, at least functionality will have been proven in FPGA, Structured ASIC and end-system products.  These technologies provide designers a clear path for prototyping, and the flexibility for program managers to decide the most appropriate production option.