English
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".
|
E-mail This Article | 
|
|
Printer-Friendly Page |
|
||||||
Related Articles
- Borrowing from software to use SystemVerilog test bench debug & analysis
- Advanced Topics in FinFET Back-End Layout, Analog Techniques, and Design Tools
- Transitioning to Advanced Verification Techniques for FPGAs - Catch-22?
- Communication centric test and debug infrastructure for multi core SoC
- Using Multi-Gigabit Transceivers to Test and Debug FPGA
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
- PCIe error logging and handling on a typical SoC