With ASIC complexity on the increase and unrelenting time-to-market pressure, many silicon design teams still face serious schedule risk from unplanned spins and long post-silicon debug cycles. However, there are opportunities on both the pre-silicon and post-silicon sides that can be systematically improved using on-chip debug solutions. In the pre-silicon world, there exists a great opportunity for a solution that can provide more cycles of execution than what is possible today with simulation and emulation. But in the past, functions like power management span HW, FW, BIOS, virtualization and OS levels and are difficult to cover until silicon hardware is available. The most recent industry tape-out data shows that despite the use of state-of-the art pre-silicon verification techniques, the number of spins to get to market is not only higher than planned, but is not improving over time. On the post-silicon side, the black-box complexity of today's designs calls for enhanced internal observation. Many design teams could benefit by enhanced debug logic. A more intuitive debug GUI can enable higher productivity through quicker adoption. The Certus™ on-chip logic analyzer solution addresses much of this in a systematic manner as an off-the-shelf solution. Certus can be deployed in FPGA or in ASIC silicon, with an easy-to-use GUI for instrumenting the debug logic and interacting with the instruments in silicon. After a decades-long legacy of EDA improvements in test, verification and physical design, Mentor is bridging the gap into the post-silicon realm. This makes cross-functional teams significantly more productive and reduces schedule risk, while allowing teams to focus more on their core business.
PERSPECTIVE: PRE- AND POST-SILICON
The goals of pre-silicon verification are similar to that of post-silicon validation. In both cases the goals are to find and root-cause all the bugs in as little time as possible. Success relates directly back to basic control and observe, which has become more challenging over time as design size and complexity expand in step with "Moore's Law."
In the half century history of chip design the EDA industry has evolved around increasing specialization. Important areas of chip design that were once done by chip design teams are standardized and automated. Design teams benefit through productivity gains. Their teams stay more focused on their core business and tackle designs of more complexity without as much staffing. Noteworthy areas where this has happened include test, physical design and pre-silicon verification. The test world adopted scan insertion and ATPG software for high push-button coverage and low test times. The physical design world was revolutionized by synthesis and place and route software tools. The area of pre-silicon verification benefitted from coverage tools, directed random stimulus, assertion-based verification, code & functional coverage and more. But the area of post-silicon validation/debug has largely been left as a black art that still falls on the shoulders of the design teams with home-grown, pragmatic but incomplete and difficult to use solutions.
On the pre-silicon side, the observability is very good; everything is observable in simulation and emulation. But due to performance requirements, it is difficult to apply adequate stimulus to fully validate full chip and system-level functionality. There just are not enough cycles to run sufficient verification content, especially when testing & validation incorporate application, driver or even test software. Although emulation has helped significantly, the drive for more verification cycles in less time continues leaving silicon as the only option for faster dynamic verification. These challenges are due to many factors. The sheer size of the state-space resulting from the consolidation of functionality on a single die dictates a very limited number of SoC-level pre-silicon simulation cycles before tape-out. Increasingly complex security and power management schemes have added to the mix as well. Significant interactions between hardware/firmware/BIOS/virtualization/drivers/OS cannot be fully proven until real hardware. Power management algorithms are distributed across many of these layers, yet are a significant source of bugs.
On the post-silicon side it is possible to run lots of content. But, observation is a significant challenge as designs are too complex. For example, if the SoC power is coming in over budget, where do you start to look to narrow-down the problem?
THE STAKES ARE GETTING HIGHER AS WELL
With society's increased reliance on computer systems in a broader range of applications, there's less room for error. In the past, only the military-aerospace sector had safety critical systems. Today, we now have automated medical devices, self-driving cars, autonomous drones and control of large commercial mission-critical infrastructure. A malfunction due to a critical bug escaping to the field could result in serious injury, or death.
THERE IS A PATH FORWARD
With the advent of FPGAs above the 10 million "equivalent ASIC" logic gate size, large ASIC designs can now be partitioned across multiple FPGAs and prototyped to run at speeds of ~10 MHz or faster. At these speeds it starts to get quite interesting for running meaningful software content before tape-out. But without the native observability present in simulation or on an emulator, the validation and debug story remains the missing piece.
An on-chip logic analyzer solution allows teams to root-cause complex issues in a much shorter time than is possible using any other practical means. We refer to on-chip logic analyzers as "debug engines" in this article. This applies both in an FPGA prototyping environment as well as on the actual post-silicon space.
WHAT ARE THE KEY CAPABILITIES REQUIRED IN SUCH A SOLUTION?
Debug engines have become a powerful tool for large, modern ASICs and their corresponding FPGA-based prototypes. They allow for extensible solutions that solve the black-box problem created by the high consolidation of functionality in today's chips. They allow for full-speed observability of arbitrary state buried deeply in chip designs. They are typically deployed in a distributed manner within IP blocks across a chip. A subset of signals from an IP block is fed to its local debug engine. They support an ability to trigger on anything they can observe. They can filter and trace the observed data with the traces extracted after the run for analysis.
Debug engines can range significantly in capability. A basic debug engine can cover use cases such as:
- Trigger on an event
- Trace an event
- Count occurrences of an event
Events could be a single bit going high or could be a decode of multiple signals indicating a specific bus cycle, for example. Triggering includes both level-based as well as edge-based modes. Tracing can be to dedicated on-chip storage, shared storage or even to off-chip storage for more depth. The ability to count clock cycles, as well as a number of event occurrences is another key capability of a basic debug engine.
The capabilities above, while relatively simple, cover what's needed for a significant percentage of debug issues. However, there are less frequent but more challenging issues that beg for more capability.
In order to maximize validation and debug effectiveness at an affordable area cost, it is important to be selective about what to observe with an on-chip logic analyzer.
Categories of items to connect to debug engines include:
- Errors/machine checks
- Performance monitors
- State machines
- Flow control signals
- Queue depths
- Power state
Note that a significant number of assertions from the pre-silicon verification environment can be included in an FPGA prototyping implementation, depending upon area constraints. For ASICs the number and complexity of assertions is typically more limited. One category of challenging bugs is what has been referred to in the industry as "long-latency detect" bugs. These are bugs where the time from when something went wrong to the time when it is observed is large. In these cases, much of the state characterizing the sequence of events leading up to the original fault is long-gone. Coherency bugs frequently fall into this category.
In order to root-cause these more difficult bugs, more debug sophistication is needed. This includes features such as:
- Deep trace
- Sequential state decode
- Cross-triggering between blocks
Deeper trace is always valuable, but it is not free. In order to save on both trace bandwidth, as well as trace depth, a lossless data compression scheme is very valuable. Off-chip trace options are sometimes limited on actual ASICs due to pin constraints.
The sequential state decode feature of a debug engine allows for use cases such as: look for N occurrences of pattern A, followed by pattern B, then trigger.
Another key feature is the ability to cross trigger between debug engines in different IP blocks in order to debug over the context of the entire system. In the case of an FPGA prototype that includes multiple chips, hence cross triggering should span all the FPGAs. The cross triggering must work robustly across arbitrary clock-domain boundaries and optimally, support reasonably low latency. The key use-cases enabled by this triggering include the ability for:
- Any debug engine in the system to trigger
- One debug engine observe an event and arm another debug engine to begin looking for another event.
This is very valuable when debugging across IPs. These cases are not uncommon, where different IPs are constantly being combined to make up an SoC
Issues that straddle hardware and software are very commonplace today. These interactions can span the entire stack including application, OS, hypervisor, BIOS, firmware and hardware. For this reason it is important to have a solid hardware/software co-debug story. Being able to correlate events between hardware and software is very powerful.
These features can also be used as coverage points in validation, allowing more direct observe of items that may be difficult to infer using other techniques.
In order to achieve the promise of significant productivity enhancements, it is very important to make all these capabilities as easy as possible to use. Rather than end up with a small number of expert users, the need is to enable a broad range of users across disciplines. Users can span diverse groups including hardware, driver, BIOS and software.
One area for ease-of-use is adding the debug infrastructure to the design, aka instrumenting the design. The other big area for ease-of-use is interacting with the debug logic at run-time. Typically, there is a much larger set of users interacting with the debug logic at run-time than there are in the instrumentation part.
Mentor's Certus debug solution offers an industry-leading set of features and can be deployed on FPGAs and ASICs. This allows users to benefit from the convenience of the same infrastructure in their FPGA prototyping environment, as well as their post-silicon environment.
Certus offers an easy to use GUI for instrumenting a design, the "Implementor". When a user is adding debug engines and observation points to a design, debug resource utilization is reported real-time. Signal selection is also very flexible and intuitive. Users can easily navigate the design hierarchy and use filters to quickly identify the signals to make observable. Implementor operates on source RTL and generates readable, instrumented RTL. A TCL script facilitates the verification of instrumented RTL.
The Certus run-time GUI tool is called "Analyzer" and has also been tailored for ease-of-use. Since Certus separates the instrumentation of signals for observability from the selection for active tracing, it provides for fully flexible, intuitive selection of instrumented signals. Each debug engine in the system is then programmed by the Analyzer based on the active trace set selection and the desired triggering and conditional capture expressions for a specific run. After a run, Analyzer pulls trace data from the trace buffers and creates a waveform file viewable by users just like a pre-silicon simulation. RTL signal names are applied and waveforms are time-correlated, removing all tedium from the user experience.
The overall ease-of-use of the Certus tool makes user adoption fast, quickly increasing the overall productivity of teams working on root-causing issues.
By employing an easy-to-use and full-featured on-chip debug solution, FPGA and ASIC designs can benefit from reduced schedule risk, reduced number of chip spins, improved quality, reduced time-to-market, and higher levels of customer trust. Mentor is committed to continually enhancing the Certus tool capabilities for customer productivity spanning both pre and post-silicon. Additionally, by using the off-the-shelf and industry leading Certus solution, design teams can have enterprise-level support and focus significantly more on their core business, all at an affordable cost.
Back to Top