ASIC Technology

Verification, not design, is the real bottleneck in today's development cycle. As devices become more complex, it becomes more difficult. Many design teams overcome this bottleneck by incorporating into their methodology a renewed emphasis on system verification through prototype analysis.

After spending months on an accelerated ASIC design schedule, many engineers spend even more months building up confidence in the design by simulating the ASIC and surrounding system. When the first ASIC prototypes arrive from the foundry, however, the prototype may exhibit unexpected behavior that will cause a loss of functionality or require a schedule slip.

ASIC trends are straining verification tools in two dimensions. First, ASIC vendors offer hundreds of thousands of usable gates on a single die, and designers are taking advantage of this increased capability by doubling their average gate count every two years. Each HDL construct and gate in these high complexity designs must be verified. Second, for traditional verification tools, the push to deep-sub micron processes places novel complexities in delay modeling and interactions between design and layout. Design teams encounter added verification burdens as the system around the ASIC becomes more difficult to verify.

Off-the-shelf components such as powerful processors and complex bus controllers are becoming more difficult to model in their entirety. The analog characteristics of high-speed digital signals make PC board verification challenging. New designs may contain one or more megabytes of code that must also be verified. These advances in design complexity exceed the significant, albeit lesser, advances in simulation technology. The result is that verification has become the bottleneck in today's product development.

Engineers initially achieve ASIC verification confidence through simulation, which is the preferred medium. Simulation excels in a number of ways. For example, engineers can hierarchically debug module by module long before the entire design is complete. A defect can be fixed in the source and quickly re-verified by the simulator. Simulation verifies that the ASIC design will operate as desired, while providing nearly limitless debugging visibility.

Because simulation consumes great amounts of time, broad verification coverage is normally not realistic. Some system specifications may initially be unknown or misinterpreted. Test vectors, inherently biased by an incomplete system understanding, provide focused coverage of only part of the design. The difficult task of conceptualizing and simulating all the vectors the physical system could produce challenges the engineers. In fact, even if this comprehensive vector generation were possible, an extraordinary number of test vectors would have to be generated from each team member, based on the different perspectives on how the system will exercise the ASIC. Simulating this exhaustive set of test vectors could easily consume many years.

As shown in Figure 1, simulating a mere second of a 40MHz system can take days or weeks for a system-level simulation. With finite resources and critical schedules to meet, writing and simulating an exhaustive test vector set simply is not and will never be possible.

Figure 1. Required time to simulate one full second of a 40MHz system.

Because simulating an exhaustive set of test vectors is not feasible for the vast majority of systems, verification through simulation offers no formal exit point. After examining simulation results, engineers can take one of two actions. First, if simulation results implicate a bug, they can change the design and re-simulate. Second, if simulation of the individual test vector does not result in discovery of a bug, an engineer will pick another test vector to verify the operation of additional functions. In either case an engineer simulates again with no clear exit point. The sovereignty of schedules nearly always forces ASIC designs to be sent to the foundry before the desired degree of confidence has been achieved. Simulators continue to churn even while the design is being fabricated.

System verification ultimately means ensuring that the entire suite of hardware and software performs properly when the end-user employs the product. Therefore, designers continue synthesis to expand their verification coverage until the first prototypes are delivered. This increase in both software and hardware content compounds the coverage problem, and is exacerbated by the need to meet critical schedules.

Will the verification bottleneck decrease with time? No. More computational power from workstation and PC advances will not solve the verification constraint. Design teams will simply add more system complexity proportional to increases in computation performance. In fact, with the advent of HDL methods and tools, the gap may be widening. Design teams will continue to push tools to the limits, placing an ever-increasing challenge on verification.

The continued existence of verification through prototype analysis demonstrates that system simulation has its shortfalls. Prototype analysis is still--and will continue to be--a critical part of system verification. Many design teams are adjusting the balance between simulation and prototype analysis by placing renewed emphasis on the complementary capacities of prototype analysis. Prototype analysis has been largely ignored as an area that can have a huge positive impact on product quality and time to market. A great opportunity for development improvements through prototype analysis remains untapped and unexploited.

No substitute adequately replaces real-world testing. Plugging the first prototypes into the target offers the first substantial opportunity to verify system performance. Even after weeks or months of time-consuming simulation, design teams continue to discover a wealth of new critical knowledge about the hardware and how it works when exercised by the software during prototype analysis. Because the prototype is composed of real hardware instead of models, it can represent the full system, both functionally and parametrically. Millions of system-generated test vectors execute each second, ensuring a high verification confidence. As system complexity drives a greater need for checks of hardware and software interaction, design teams should place greater emphasis on system verification through prototype analysis. Prototype analysis forces greater interaction between software and hardware teams because their distinct deliverables function tangibly together. Prototype analysis, shown in Figure 2, provides visibility on how the ASIC interacts with sourced components, with firmware, with operating systems, and with application software.

Figure 2. Prototype analysis spans the domains required for complete systm verification For more information circle56

A number of design bugs will continue to manifest themselves exclusively during prototype analysis. For example, some pathological bugs are data dependent: they may occur when a 1 follows a long stream of 0s. A bug may also occur only when the system operates at a certain frequency. For instance, a 33 MHz system with short rise times may experience crosstalk problems that don't occur at lower speeds when transition times are longer. Other bugs are software dependent, and may occur only when operating systems or application software exercise the hardware in a specific sequence.

An engineer commented that running "Flight Simulator" on computer prototypes produces a class of hardware bugs that are not caught by exercising the hardware with firmware and operating systems. It is unlikely that these would ever be found through simulation.

A couple of prototyping methodologies commonly allow designers to ensure that they will deliver the right product while still meeting schedules. Some teams get to the prototype stage more quickly by planning for multiple silicon cuts from the start and fabricating the ASIC much earlier than they would have otherwise done. First silicon is rarely "brain dead," and can be used for hardware turn-on and initial software/hardware integration. Firmware and parametric test can begin weeks ahead of the date system simulation would have mandated. Running in real time, an engineer can find corner-case bugs in a short period of time. The team can make design changes, re-simulate the modified design, and turn the ASIC quickly. The additional schedule impact can be minimized if planned for ahead of time. The value of early corner-case bug discovery is weeks of market time with the desired performance and feature set.

A few seconds in a functional system can be worth days or weeks of simulation. Many designers choose to use the actual target system as the debug medium, only minimally simulating their FPGA designs. The FPGA intensive designs, on the other hand, may be spun dozens of times in a short period of time using prototype analysis as the primary verification tool. The team builds enormous confidence in the design by testing thoroughly in the real system. Teams can ship the FPGAs in "proto-duction" and can convert to an ASIC if it makes financial sense.

The resurgence in prototyping is also fueled by semiconductor advances. Without heavy turnaround-time and NRE penalties, teams employing FPGAs benefit greatly from early in-circuit debug. High-capacity FPGAs allow designers to prototype critical subsections or whole ASICs. Part of the success experienced by teams building systems with FPGAs comes from prototype analysis tools that allow the software engineers can communicate earlier with the hardware engineers. The increased team communication results in a more complete understanding of system specifications and results in earlier resolution of system integration problems. The net impact is greater confidence in the system's quality earlier than if the hardware were not available.

Prototype analysis tools have silently evolved to serve as powerful complements to simulators. For example, some logic analyzers now utilize dedicated high-powered computational engines to provide insightful visual data. Design teams can apply a variety of filters to captured prototype behavior minimizing time to insight, the time between admitting to a problem and finding its root cause. Teams can export logic analysis screens to networked PCs or workstations via X-Windows. This allows engineers to collect information about the prototype at the same geographic location where the design and simulation data are available. This model lowers the cost per user since multiple team members can use shared prototype analysis equipment.

With new innovations in prototype analysis tools, design teams can isolate asynchronous anomalies which are difficult to model and test in cycle-based simulation. For example, an engineer can capture a setup and hold violation on a data bus by setting a logic analyzer to trigger on a violation of any of the data lines. Nearly all prototype analysis tools include disk storage so that prototype behavior can be permanently achieved and shared with other team members.

The powerful benefits derived from prototype analysis are being rediscovered. Many design teams spend too much time before going to the prototype phase. After a design is stable, teams should consider the extra time spent in simulation against the complementary benefits that would be derived from an equal amount of resources spent on prototyping.

The interest in prototype analysis will grow as more people realize that verification will continue to be the bottleneck to product development. As the use of simulation tools matures, and designers better understand the contributions and limitations simulation tools provide, prototype analysis will become an important design process consideration. *

Joel Woodward is a technical marketing engineer at Hewlett-Packard's Colorado Springs division. He specializes in prototype analysis tools.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design   May 1995