| Authors: Rich Edelman - Mentor, A Siemens BusinessRaghu Ardeishar - Mentor, A Siemens Business Introduction: Modern SystemVerilog [1] UVM [2] testbenches have grown to be large, complex systems in themselves. They can be equally as hard to debug as the underlying hardware being verified. By instrumenting your testbench in a few places with a few “hooks” your testbench will be more debuggable, more transparent, and easier to manage. This paper will illustrate a few such hooks – you can imagine many more. The basic philosophy is to keep the hooks as simple as possible – as few lines as possible. Architectural Decisions: The solutions presented in this paper require change – instrumentation. Either changing the testbench, the UVM source code or some combination. From this instrumentation an analysis database will be created which can answer questions like – “How many sequences are running on agentX?” Instrumenting the testbench The testbench instrumentation will naturally require that the testbench be changed. Lines of code will change – for example from start_item(t) to `S_START_ITEM(t). New lines may be added to track interesting places. Extra `uvm_info() lines may be added. Instrumenting the UVM The UVM can be changed so that base classes get all the new functionality, and the testbench doesn’t know anything has changed. The base classes can call into the analysis database. Changing the UVM is a convenient solution for the testbench creator – the UVM is changed one time, and all testbenches get the benefit automatically. The problem with this solution is that the UVM does change over time, and worse, some vendors provide custom UVM implementations. Changing the UVM also removes some of the debug transparency. When the testbench is changed to help improve debug, it is obvious what is being instrumented, and what it information will be available. Analysis Database An analysis database is created which can answer questions. This analysis database will keep track of what’s going on in the testbench. An implementation could create a database of all the handles – sequences and sequence_items that are generated in the testbench. As simulation proceeds, analysis can be performed. The problem with this solution is that the database would be retaining handles to objects that could possibly have been garbage collected. The function of the garbage collector is beyond the scope of this paper, but it is not a good idea to change the way objects are garbage collected. It may cause debug situations to change from non-debug situations. Another implementation could build a database which does not use handles, but rather uses information about the objects. This solution – change the testbench, create a stand-alone analysis database, do not retain object handles In the solution presented in this paper, there is no requirement to change the UVM, and there is no storing of handles. The testbench will be changed, and the analysis database will be built without holding on to any object handles. The stand-alone database is created which represents the sequences and sequence_items executions. For example, when a sequence is started, the sequence type_name and instance name are put into a table for later type and name matching. View & Download: Read the entire Are You Smarter Than Your Testbench? With a Little Work You Can Be technical paper. | |