Never miss a story from Verification. Subscribe for in-depth analysis and articles.
In 2011, UVM1.0 was introduced to the industry. It has already been more than a decade that UVM has been used for testbench creation. The benefits of UVM are very clear. It’s a standardized methodology that helps multiple teams and companies to use the same methodology to verify designs. Using the same methodology, of course, helps to increase the verification efficiency. It also benefits EDA companies to standardize the verification methodology on UVM so that we don’t need to argue about VMM, OVM, and UVM. Everyone just follows the standard.
Although UVM is being used for testbench creation for more than a decade, it is still very challenging to debug problems that are inside of UVM testbench. The following are some examples of the challenges users may encounter when using UVM:
Lack of visibility: One of the biggest challenges in debugging UVM testbench is the lack of visibility into the inner workings of the UVM infrastructure. UVM provides a lot of abstraction layers that can make it difficult to understand what’s happening inside of the testbench. Without enough visibility inside of UVM, this can make it challenging to pinpoint the source of a problem.
Complex debugging environment: The structure of the UVM testbench can be very complex, especially when dealing with larger designs or multiple verification components. Because of the scale of the UVM testbench and the complexity of the functions that need to be verified for different design blocks, debugging such an environment can be challenging, and it’s easy to get lost in the complexity.
Time-consuming: Debugging UVM testbench can be a very time-consuming process, especially when the testbench is complex. You may have to run multiple simulations to reproduce the problem or to verify a fix has solved the problem. As mentioned in the first bullet, because of the visibility, understanding and troubleshooting problems can be very time-consuming.
Dynamic constructs: Testbenches that are using SystemVerilog UVM are very similar to C programming. Constructs and structures are generated or happen dynamically during simulation runtime. The dynamic constructs cannot use the same debug approach as traditional HDL simulations. Dumping waveform and debug after simulation might not be practical or have enough visibility of what happened throughout the simulation.
So, what will be the debugging strategy to debug UVM testbench? Here are some suggestions to debug UVM testbench:
Break down the debugging process into stages to tackle the problem systematically. Begin by isolating the issue to a specific module, component, or transaction. Then, gradually expand the scope to include other related components to understand the interactions and dependencies
Enable debug messages and assertions strategically throughout your testbench code. Use the ‘uvm_info()’ and ‘uvm_error()’ functions to print out relevant debug messages at key points in your code. These messages provide valuable insights into the behaviors of your testbench, aiding in the identification of issues.
Leverage waveform viewers to visualize the behavior of signals, transactions, and other relevant data in your testbench. Create waveform views that highlight the specific signals and transactions related to the issues at hand. Analyze the waveform to identify any anomalies, timing issues, or unexpected issues.
Make use of debugging tools available in your simulation environment. These tools may include interactive debuggers. Familiarize yourself with the features and capabilities of these tools to efficiently trace and pinpoint the root cause of issues.
Modern debug tools are now providing various features to enhance visibility and capabilities to help verification engineers understand what’s happening inside of the testbench and help trace problems within UVM testbench. To achieve this, integration between the debug tool and logic simulator is required.
Why is integrating with a simulator a requirement? As mentioned in the beginning, UVM testbench has many dynamic constructs. Because of that, even the hierarchy of the testbench is dynamically changing over the simulation time. Traversing and getting the information of dynamic constructs, will need a simulator to provide access to the simulation engine kernel to get access the data. And his usually needs intensive communications across simulation and debug product teams before the implementation is in place. That is also the reason if you want to debug testbench, you will need to choose the debug tool that comes from the same EDA vendor.
Ok, let’s come back to what debug tool can help you debug testbench. If you’re using Cadence’s Xcelium simulator to simulate your design and testbench, it is for sure using Cadence’s Verisium Debug is the best choice that you can use for debug. Verisium Debug is tightly integrated with Xcelium and provides all kinds of unique features that enable engineers to visualize and debug testbench. For example, the UVM testbench prints various messages to help engineers understand the simulation status with uvm_info and uvm_error functions. Log messages are usually the starting points to debug a problem. Verisium Debug’s SmartLog feature helps to generate a dedicated message database, which allows users to directly read log messages into Verisium Debug’ GUI. SmartLog makes it very easy for the user to filter or select messages to observe. Simply use click on it, and will jump to the location where the source code is.
Figure 1: Verisium Debug SmartLog
Even more, Verisium Debug can also hook up with Xcelium to interact with the Xcelium engine for stepping source code, setting breakpoints that can help engineers to pause a running simulation and understand the value and state of elements.
Figure 2: Verisium Debug for UVM Testbench
Not only interactive simulation, UVM debug also requires different views to help engineers to understand what’s happening in the UVM testbench. Verisium Debug also provides many different views to help understand the constructs of UVM.
Figure 3: UVM Views
Another challenge for users to debug is the randomization. We all know the beauty of SystemVerilog Testbench is the constraint-random capability. It helps verification engineers to write a testbench that can automatically generate desired test vectors/patterns to verify designs. However, with the increasing complexity of design functions and protocols, verification engineers may write many constraints in testbench in order to get proper vectors to be generated to test the design. This increases the complexity of the constraint as well. When the vector or values are not properly generated, engineers will need to debug constraints to see where might go wrong. Verisium Debug accesses the Xcelium kernel and helps to traverse all the constraint solver steps to help engineers to debug their randomization problem.
Figure 4: Verisium Debug Randomization Debug
Debug UVM testbench is very different from debugging RTL design. There’s no way for users to dump all the transactions from UVM testbench into a waveform file and debug after simulation. The dynamic nature of the UVM testbench requires user to debug UVM testbench interactively during simulation runs. Only the debug tool that is integrated with simulator can do the works.
Cadence offers a complete solution for UVM testbench simulation and debug. With Xcelium, you can simulate designs with UVM testbench at very high performance. To debug with UVM testbench, Cadence Verisium Debug is the only solution today that has tight integration with Xcelium and is able to traverse all the needed data for UVM debug. Verisium Debug has SmartLog to help view log messages and understand problematic points in the simulation. Waveform, source code, and all the different UVM views help to understand necessary data within UVM testbench. By using these features, it boosts the UVM testbench debug efficiency!
Learn more about Cadence's Xcelium Logic Simulator and Verisium Debug.