Full-Chip and Post-Silicon Verification - Visibility Issues
Overview
The overall time to reach volume production is growing, driven by the increasing difficulty of determining the root cause of problems found in full-chip, regression simulation, emulation, FPGA prototypes, and first silicon prototypes running in their target systems. For the latter, the size, complexity, and software content of today's SoC designs are making it harder to validate and debug silicon prototypes, bring up system-level test programs, and complete all the tasks required for volume production of quality devices. The time spent debugging full-chip and post-silicon applications is being stretched by the painfully insufficient visibility of internal signal values. Effective debug requires observation and recording of internal signal values over time so that the causes of design behavior can be investigated and understood. [This article reviews the visibility problem and specifies a general methodology to overcome it.]
Observing signal values, while effective and necessary for debug, impacts design and verification. Simulation and emulation run times grow because it takes time to dump and record values. On the other hand, dumping signal values during actual chip operation (also known as in-situ operation) does not affect performance, but usually requires a separate dumping procedure and the addition of special on-chip logic (often termed "Design for Debug" or DFD). Because of the impact on design and engineering resources, the volume of observe signals is usually limited, especially as the design stage progresses from simulation to in-situ system validation (see Figure 1).
Figure 1
Consider the various impact of signal dumping: a typical full-chip simulation decreases performance by 4x to 20x with dumping turned on. Since verification and validation applications are significantly impacted, engineering teams usually resort to workarounds. A summary of the issues for each application follows below.
Full-Chip Simulation
Full-chip simulation usually requires a trade-off between performance and debug. Generally, a greater understanding of the behavior, and therefore quicker debug, is achieved by dumping as much signal data as possible. Unfortunately, a high amount of dumping significantly degrades simulation performance. As a result, many verification teams avoid signal dumping in favor of iterating lengthy simulations with signal dumping only after an error is discovered. The number of total iterations using this approach is not possible to predict and could significantly impact the design schedule.
Emulation and FPGA Prototyping
Emulation and FPGA prototypes present significant visibility challenges due to the expense of observing internal signal data and the unfamiliar gate-level representation of the design. Because these verification systems are hardware-based, engineering teams must run multiple iterations of synthesis and compilation steps to configure or insert debug logic such as internal logic analyzers, and then re-execute the tests. Setup of emulation systems for register dumping impacts performance, and compilation of FPGA prototypes with embedded logic analyzers impacts turn-around time. Although dumping registers or inserting logic analyzers allows observation of user-selected signals, in many cases these techniques fail to include the signals required for debugging a specific problem. As a result, an unpredictable number of compile iterations is likely, and still may not provide visibility of all signals at the desired RTL view.
In-situ Silicon Validation
Validation of a new chip in its target system or a validation board that emulates the target system is often called "in-situ" validation. This type of validation presents challenges for debug because of the limited observability of internal signal data and the difficulty of accessing the data from the system board. For example, signal values may be present at the external pins and monitored with equipment such as logic analyzers, but this information is insufficient to deduce internal device states. As a result of this limited observability, finding and analyzing the problems in silicon is dreadfully tedious and time consuming. What engineers find much more useful for understanding silicon behavior is the status of the internal state machines, data, and status registers. This requires a silicon debug methodology that improves internal signal data visibility. Part of the solution for high-visibility design for in-situ validation is the emerging set of DFD techniques that enhance observability in running silicon. These techniques place structures on the silicon and thus require upfront planning. They can leverage scan chains to improve silicon debug by making it possible to observe internal signals in a manner similar to hooking up logic analyzer probes. Strategic hookup of the scan chains to the test controller allows one to shift values to a test port output while the device is mounted in the system.
Overcoming Limited Observability - High-Visibility Design
As seen across the verification and validation applications, engineering teams must make tradeoff choices between impact (on performance, area, and resources) and observability of internal signals. The optimal tradeoff is a limited or partial dumping with negligible impact on the design. (see Figure 2). What methods and technologies are necessary to achieve this?
Figure 2
Research at Novas has revealed a few required steps to optimizing the ability to debug a chip with minimal observation impact:
- Analyze the design to determine which signals are essential for full visibility
- Dump only the set of essential signals
- Expand the limited data of the essential signals to obtain values for the rest of the design's signals
- Correlate the abstraction from which the signals were dumped back to the familiar RTL representation
Though an analysis of the gate- or RT-level description, a list of signals can be derived such that observation of the values of these signals over time will provide full visibility within a designated portion of the design. This list must be relayed to the simulator, emulator, FPGA or design team implementing DFD. With this list, the corresponding application dumps a limited set of signals, minimally impacting performance. Additional analysis can fill in the unknowns for the signals that were not dumped, such that a full set of values over time is available for debugging. Finally, to easily understand the workings of the design or chip when only the netlist is available, the signals at the gate-level can be mapped to the RTL. Viewing the dumped and filled-in values where the logic description is much more familiar aids comprehension of design behavior.
High-Visibility Design - Roadmap and Conclusion
Limited or expensive observability and unfamiliarity with low-level abstractions stretch design cycles and delay product releases by making it harder for chip designers to comprehend design behavior. By using a methodology that limits the dumping to a small, but critical subset of signals, verification teams can achieve full-chip functional simulation, emulation, prototyping, and in-situ silicon debug with minimal performance and resource impact. High-visibility design can mitigate the expense of obtaining enough signal value information to debug complex problems across various verification and validation tasks. Novas is working with partners - both customers and vendors - to provide technologies to automate the process of implementing high-visibility design. Stay tuned for further updates.