Synopsys ZeBu fast emulators come equipped with a comprehensive suite of debugging features, which enable you to quickly find and correct bugs in your ASIC design. However, simply having this technology is not sufficient to track down complex bugs that lie billions of cycles deep in the state space. You also need an effective "Smart" Debug methodology in order to efficiently achieve debug convergence as you reproduce tests and filter billions of cycles of raw data into relevant debug information.ZeBu Smart Debug Methodology:
Datasheet: Next Gen System Validation Using Transactors
Traditional Emulator Debugging Techniques
Traditional emulator debugging is based on the use of Logic Analyzers (LAs) and triggers, and is typically used in an In-Circuit Emulation (ICE) environment. Signals are routed to an on-board trace memory, and the signal capture is initiated via the LA. This technique has the advantage of performing at full emulation speeds, but also has the disadvantage of being limited to a fixed trace window. The limited trace window means that selecting your trigger is critical to the success of your debugging, particularly in ICE environments where the test may not be deterministic, meaning that the failure point or trigger may occur at a different cycle in subsequent runs.
ZeBu transaction-based emulation provides a cycle-accurate, fully reproducible environment which is the enabler for the Smart Debug methodology. Transactors can even be used to provide Smart Debug capabilities for non-deterministic ICE environments as well.
Leveraging Multiple Levels of Abstraction
The ZeBu debug technology offers the user multiple forms of design access, which trade-off between accessibility and run-time performance. The ZeBu Smart Debug methodology leverages this concept, first using the highest speed probes and tracers to initially isolate the time and location of the failure, and then using a wider range of assertions, checkers, and probes to specifically identify the trigger and sub-system in question. Finally, complete waveforms can be generated for the sub-system, and the designer can perform a detailed analysis.
Multi-Phase, Multi-Pass Methodology
The ZeBu Smart Debug Methodology is a Multi-Pass methodology that can be broken up into three phases:
- Preparation Phase - Before emulating your design, compile Static Probes, Flexible Probes, and SystemVerilog Assertions into the design. Add ZEMI-3 tracer transactors and LA triggers to the Reconfigurable Testbench (RTB).
- Investigation Phase - After a test failure, reproduce the test, and use the ZeBu run-time environment, the SW debugger, and the pre-compiled probes, assertions and tracers/checkers to isolate the exact trigger/cycle of failure, as well and the suspect sub-system(s).
- Detailed Debug Phase - Reproduce failing test or leverage save/restore to reach trigger/failure point very quickly, and then enable complete waveform generation for the sub-system(s) using Dynamic Probes. Perform detailed debugging with your favourite waveform viewer.
ZeBu Smart Debug Methodology: Preparation Phase
The first step in the ZeBu Smart Debug Methodology is the Preparation Phase. This phase occurs before you run even a single test, during the initial bring-up and compilation of the design. During this phase, Static Probes, Flexible Probes, SystemVerilog Assertions, ZEMI-3 transactors, and LA triggers are compiled into the system. These pre-compiled options remain dormant during regressions, and can be enabled at run-time, once a failure has been discovered.
Selecting the appropriate signals for probes and triggers requires careful planning. The verification plan for your design is a valuable resource to help you decide which register and signals to choose. Changes to the pre-compiled probe and trigger set will require an incremental compilation, but remember that any registers and signal in the design can later be accessed at run-time via Dynamic Probes, without any re-compilation.
Selecting Static Probes
Static Probes enable access to critical signals at full emulation speed (up to 12MHz). Static Probes can generate waveforms using ZeBu's on-board trace memory, and can also be used as logic analyzer triggers, or as inputs to custom transactors using ZEMI-3. Use Static Probes on critical busses and registers that may be accessed frequently by the testbench or monitors. Common locations for Static Probes include: the processor program counter, transactor I/O, and small design I/Os (e.g. the JTAG/UART interface).
Selecting Flexible Probes
Flexible Probes can be added to the design in greater numbers than Static Probes - approximately 30k/FPGA. They only impact run-time performance when enabled for tracing — capturing signals in the low megahertz (MHz). Flexible Probes are compiled and enabled by group, to minimize the potential run-time performance impact. Use Flexible Probes on design interface signals and for major functional blocks. Common locations for Flexible Probes include: the memory controller, PCIe sub-system, and all design I/O for the first 2-3 levels of hierarchy.
Flexible probes can also be accessed via a software testbench, and can be used to implement software-based logic analyzers and checkers. New logic analyzer functions can be written without any need for re-compilation.
ZeBu hardware-assisted verification products support SystemVerilog Assertions (SVAs) in emulation. Synthesizable SVAs are supported in ZeBu through the use of zFAST, ZeBu Fast Synthesis.
ZEMI-3 is a SCE-MI 2.0 compatible behavioral SystemVerilog compiler that makes it extremely easy to write transactors and Synthesizable Testbench (STB) components. Use ZEMI-3 to create complex HW logic analyzer components, or to perform high speed monitoring of critical signals (e.g. those selected as Static Probes). ZEMI-3 can also be used to create sniffer and frame generator transactors, which can be used to reproduce ICE and non-deterministic application level tests.
ZeBu Smart Debug Methodology: Investigation Phase
Once a failure has occurred in one of your emulation regression or software validation tests, the goal is to isolate and identify the bug in the hardware (or software) as quickly and efficiently as possible. Simply dumping full-chip waveforms for the complete testcase is no longer realistic, since software tests can easily reach over a billion cycles, and ZeBu emulators support designs up to 1 billion ASIC gates. Capturing that much data without advanced thought would produce file sizes that are unmanageable. The goal of the Smart Debug Methodology Investigation Phase is to provide relevant debug information, not just tons of raw data.
Starting at the highest level of abstraction, and using the fastest probes, triggers and monitors in a reproducible transactor environment, investigate the design in order to achieve debug convergence on both the time and location of the actual bug. The result of the investigation phase should be a clock cycle or trigger point, as well as a module or sub-system to which the failure has been isolated, where detailed debugging can occur.
SW Debuggers and the ZeBu Testbench/Run-time Environment
There is often a great deal of debug information available to the user via the ZeBu Run-time Environment (zRun) and the Software (SW) Debugger. SW Debuggers can be used to help isolate the functional block of the failure, and/or the trigger point based on the value of the program counter and SW register values. zRun can be used to dump memory contents, for setting/using the HW logic analyzer triggers for Static Probes, and initiating save/restore to enable faster testcase reproduction. zRun is also scriptable and configurable to extend its debugging power. For example, you can map program counter values to the system map and have zRun output the active function name during run-time.
ZEMI-3 transactor monitors stream data to the testbench, potentially highlighting the time and location of failures within the design.
Enabling Static Probes
Static Probes can be captured using an on-board trace memory, and then flushed out to a VCD, VPD or FSDB file. Tracing of Static Probes can be initiated by HW triggers, manually, or scripted via zRun and/or a software testbench. This information is used to determine which Flexible Probe groups and SVAs to enable in subsequent runs.
Enabling Flexible Probes and SVAs
Both Flexible Probe groups and SVAs are run-time selectable. Information from the SW Debugger, Testbench and Static Probes is used to determine which assertions and probe groups to activate. If necessary, write software based checkers for the Flexible Probes, to augment the monitoring and logic analysis.
Flexible Probe waveform data is captured directly to the hard disk, and has virtually no limit to the number of cycles that can be captured. This data, along with the output of the SVA reporting, is used to further isolate the time/trigger and module exhibiting the problem, and move on to the Detailed Debug Phase
ZeBu Smart Debug Methodology: Detailed Debug Phase
The final phase of the ZeBu Smart Debug Methodology is the most straight forward. Once the time and location of the failure has been isolated into a realistically usable set, simply re-run the test up to the identified clock cycle or trigger point, and then generate waveforms for the entire module or sub-system in question. Then use your favorite waveform and source code viewer to perform a detailed analysis of the problem.
Enabling Dynamic Probes
Dynamic Probes are easily enabled via zRun or the testbench, and provide access to every register in the design, without the need for any re-compilation. Dynamic Probes and ZeBu combinational signals accessibility (CSA) can be used togenerate waveforms for every register and signal within the module or sub-system being investigated.
When reproducing a test for Dynamic Probe waveform generation, ZeBu's Save & Restore feature can be used to jump ahead in the cycle count and state space, saving valuable time in the Detailed Debug Phase.
Fixed Timing and Application-Level Tests
There are some emulation environments for which Dynamic Probes and Save & Restore capabilities may not be initially usable. These include cases where the timing is fixed (e.g. ICE environments not tolerant to clock stalling) or where the test is running in an application mode (e.g. transactor running in non-blocking/untimed operation). For situations such as these, we first need to create a reproducible environment, before the Smart Debug Methodology can be applied.
Product: ZeBu Debug Features
Solutions: Transaction-Based Verification