SEE ALSO
- Prev: Smart Debug Methodology: Preparation Phase
- Next: Smart Debug Methodology: Detailed Debug Phase
- Product: ZEMI-3
- Product: ZeBu Debug Features
- Product: ZeBu Probes
- Product: SystemVerilog Assertion Support
- Solutions: Transaction-Based Verification
- Datasheet: Next Gen System Validation Using Transactors
ZeBu Smart Debug Methodology: Investigation Phase
Once a failure has occured 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. A waveform viewer couldn't even open that file! The goal of the Smart Debug Methodology Investigation Phase is to provide the user with relevant debug information, not just tons of raw data.
Starting at the highest level of abstraction, and then 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. Use this information 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. Use the information from the SW Debugger, Testbench and Static Probes 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. Use this data, along with the output of the SVA reporting, to further isolate the time/trigger and module exhibiting the problem, and move on to the Detailed Debug Phase