Using advanced logging techniques to debug & test SystemVerilog HDL code
By Bindesh Patel and Amanda Hsiao, SpringSoft US.
Embedded.com (05/12/09, 07:08:00 PM EDT)
SystemVerilog provides an advantage in addressing the verification complexity challenge—not simply as a new language for describing complex structures, but as a platform for driving a more efficient, realistic test of the design. It is no surprise then that the adoption of the language for verification purposes has been rapid.
However, there is a gap when it comes to the debug and analysis of SystemVerilog testbench code. The accepted "dumpvars"-based techniques are not practical for the softwarelike object-oriented testbench code, and their benefits in this realm are also questionable.
But, at the end of the day, engineers do need to know what the testbench is doing at any given point in time. Thus far, engineers have been forced to revert to low-level, text-based message logging and subsequent manual analysis of the resulting text log files.
Logging—the process of recording history—has been widely used in systems and software environments. And most SystemVerilog libraries used today provide some built-in utilities for logging information from the testbench to low-level text files that can be analyzed after simulation.
Engineers then manually correlate the testbench data to the design activity along the time axis. This is a painfully low-tech process with inherent disparity in the design and testbench debug flows, in which the visualization "tool" is often "vi" or "emacs".
Embedded.com (05/12/09, 07:08:00 PM EDT)
SystemVerilog provides an advantage in addressing the verification complexity challenge—not simply as a new language for describing complex structures, but as a platform for driving a more efficient, realistic test of the design. It is no surprise then that the adoption of the language for verification purposes has been rapid.
However, there is a gap when it comes to the debug and analysis of SystemVerilog testbench code. The accepted "dumpvars"-based techniques are not practical for the softwarelike object-oriented testbench code, and their benefits in this realm are also questionable.
But, at the end of the day, engineers do need to know what the testbench is doing at any given point in time. Thus far, engineers have been forced to revert to low-level, text-based message logging and subsequent manual analysis of the resulting text log files.
Logging—the process of recording history—has been widely used in systems and software environments. And most SystemVerilog libraries used today provide some built-in utilities for logging information from the testbench to low-level text files that can be analyzed after simulation.
Engineers then manually correlate the testbench data to the design activity along the time axis. This is a painfully low-tech process with inherent disparity in the design and testbench debug flows, in which the visualization "tool" is often "vi" or "emacs".
To read the full article, click here
Related Semiconductor IP
- TSMC 7nm 0V75 / 0V9 ESD Local Clamp – Low Cap
- TSMC 65nm 3V3 ESD Local Clamp – Rad Hard
- TSMC 5nm 1V8, 1.2V and 0.9V ESD Local Protection – Low Cap
- TSMC 3nm 3V3 ESD Local Clamp
- TSMC 3nm 1V2 ESD Local Clamp – Low Capacitance
Related Articles
- Tools for Test and Debug : Dealing with determinism in DSPs with pipelines and caches
- Tools for Test and Debug : Embedded real-time behavior requires "design-in" processes
- Tools for Test and Debug : Specialized net backplanes needed for DSP debug in distributed environments
- Tools for Test and Debug : Adapting traditional embedded debug strategies to SoC designs
Latest Articles
- LACE: Large Language Model Aided Multi-Agent Framework for Agile RISC-V Instruction Extension
- A Process-Aware Hybrid Si/IGO Monolithic-3D 6T SRAM with BEOL Pass-Gates for the 2nm Node
- Automated Estimation of MBIST Area and Test Time in Heterogeneous Memory IPs via Stacked Ensemble Framework
- VIPER: Architecture-Aware Performance Modeling for Processing-in-Memory Design-Space Exploration
- CTTE: An Open Dual-Protocol RISC-V Trace Encoder for N-Trace and E-Trace