UVM Testbench Structure and Coverage Improvement in a Mixed Signal Verification Environment
by Mihajlo Katona, Head of Functional Verification, Frobas
In recent years a number of different verification methodologies were developed to ease the process of pre-silicon verification of ASIC designs. Usually developed by EDA tool vendors, these methodologies often were not compatible with tools from different vendors. With the appearance of the Open Verification Methodology (OVM), which works best with SystemVerilog testbenches, verification became more and more standardized. OVM gave way to the Universal Verification Methodology (UVM), which is now an official Accellera standard supported by all EDA tool vendors.
Developing UVM-based testbenches from scratch is a time consuming and error-prone process. Engineers have to learn object oriented programming (OOP), a technique with which ASIC developers generally are not familiar. Automatic generation of testbench building blocks, guided by the standard, is a sensible way to speed up the initial setup. Verification engineers can then focus on specific tasks associated with verifying the design.
This article discusses how a UVM verification environment was set up easily for a mixed signal device under test (DUT) using a scripting tool developed in-house and based on a testbench configuration file. The article focuses mostly on presenting two mixed signal DUT examples and the corresponding UVM-based testbench with a digital-ontop structure. Also discussed: how Questa® InFact is used to improve the coverage based on results from nightly regression runs for functional and mixed signal verification, managed with Questa Verification Run Manager.
It is no surprise that directed testing is no longer an efficient way to verify modern designs. Large and complex designs require writing and maintaining large, directed test suites, which can be incredibly tedious. With only a little experience, verification engineers can build constrainedrandom stimulus and a corresponding coverage model that’s equivalent to several directed tests.
UVM verification methodology combined with a System Verilog testbench improves verification of simple and complex ASIC and FPGA designs. Among the potential benefits: high flexibility, randomization, re-usability and higher levels of abstraction. Taking advantage of these benefits requires familiarity with OOP, central to UVM and so essential to properly setting up a verification environment. These prerequisites can be time consuming, and even if engineers are familiar with OOP and UVM, developing from scratch a multi-layer verification environment with lots of connections often gives engineers too many chances to make mistakes. Too often, engineers spend lots of time just on start-up, finding and fixing errors, instead of debugging the design and performing other verification tasks.
Because the UVM verification environment is well structured and testbench building blocks are defined by the standard, there exists the possibility of automatically generating many elements of the verification environment.
The frobas-UVM-GEN scripting tool represents on means of achieving such automation. This in-house tool was combined with Questa InFact to help us achieve our predetermined goals of functional and code coverage. Using Questa InFact, our verification team targeted as much functionality as traditional constrained random testing but managed to achieve coverage goals much faster, even in an analog mixed signal environment.
UVM Environments for Mixed Signal DUTs
Two different mixed signal DUTs and corresponding UVM environments are shown below to illustrate our approach to verifying mixed signal designs with the Questa ADMS simulator.
Mixed signal DUT with VHDL-AMS wrapper The first example of a mixed signal DUT is a result of controlling the analog circuit with the outputs of the digital module. For encapsulating this system of different model types, the VHDL-AMS language is used for TOP_DUT module. All the other modules are instantiated and connected inside the top module as shown in Figure 1.
The digital module works like a control unit that has two pairs of three-bit control outputs. These outputs are connected to six simple switch modules implemented using the VHDL-AMS language. Switch modules (with port list) as shown here have one digital input and two terminal analog connections:
entity switch is port( sw_state : in std_logic; terminal p1, p2 : electrical); end entity switch;
Switch modules are used as a bridge between the digital control unit that calculates the values of the output control signal in regards to the stimulus on the input and the analog part of the design. The analog part of the design consists of a sinusgenerator and analog module that are controlled using the switch. Both of these modules are implemented in VHDL-AMS. After connecting all of these modules and combining them into the final mixed signal DUT that has only digital ports, frobas-UVM-GEN is used to generate the UVM environment.
The UVM environment has all the components necessary to implement drivers that generate random constraint stimulus, protocol and functional checkers in monitors and scoreboards. Because TOP_DUT ports are digital, sequences and tests can be written in the UVM environment to satisfy verification requirements without generating any analog signals from the environment itself. The analog part of the design is controlled through digital outputs of the control unit.
In Figure 2, the example of the input and output signals of the switch can be seen using the Questa ADMS waveform viewer, which can display digital and analog signal values.
This waveform clearly shows how the analog value on the out terminal of the switch (switch_1:p1) can be controlled with different values on the digital input port of the switch (switch_1:sw_state).
Mixed signal DUT with Verilog-AMS wrapper
The next example of the mixed signal DUT is a system of multiple VHDL and VERILOG-AMS modules that has a VERILOG-AMS wrapper on top with digital ports only.
The system consists of two VHDL modules, a transmitter and receiver module, and the model of an analog channel for data transmission between the transcending and receiving units. The analog transmission channel model is embedded within the DUT and not directly connected to the testbench. The digital connection in the first version of the TOP_DUT model was substituted with the VERILOG-AMS model of the transmission line as shown in Figure 3.
In the second version of TOP_DUT the SPICE implementation of the transmission line is integrated in the VHDL-AMS module using Eldo commands to substitute the digital line. (See Eldo commands below and Figure 4 )
attribute Eldo_device of trans : component is Eldo_subckt; attribute Eldo_subckt_name of trans : component is “trans”; attribute Eldo_file_name of trans : component is “trans.ckt”;
Thanks to the fact that the top module instantiated in the testbench does not have any analog ports, the sequences, tests and all the other parts of the UVM environment can be completely generated using the configurationfile- based scripting tool.
The UVM environment generated in this manner does not have to be changed in any way when analog modules are added inside the DUT to replace the digital modules with the same functionality. This means that the effect of adding analog models (the analog values of the added modules) can be seen without any changes to the environment.
The only reason to change the previously generated environment is to change the DUT functionality. Different functionality requires changes to the sequences, monitors, scoreboards and all the other parts of the UVM environment that are linked to the part of functionality that is changed. If new ports are added, analog or digital, the UVM environment has to be regenerated so that interfaces of the agents match the layout of DUT ports.
The structure of generated UVM testbench is shown in Figure 5 above.
There are two UVCs under the top environment, RX and TX. Both UVCs have the same basic construction that encapsulates an environment with a configurable agent. Inside the agent, a sequencer and driver communicate to provide the stimulus for the DUT. Monitors collect the information from the interface that will be used in the scoreboard to check the correct functionality of the DUT. Most of the verification of this DUT is related to register access, so using UVM Register Model was required as well. In this particular case, two register blocks are instantiated within the UVM verification environment.
These register blocks are generated by Questa, but all necessary connections within the environment related to these register blocks are performed by frobas-UVM-GEN tool.
Compared to the link between the digital and analog parts of the design in the previous example (an analog switch model with digital input), in this transmitter receiver DUT A/D and D/A converters are used. The reason for this was the different structure of this receiver DUT transmitter.
The D/A converter used here is the Mentor Graphics model of “unipolar digital to analog converter with voltage or current output.” The A/D converter is the Mentor Graphics model of the “analog to digital converter with a reference resistance and propagation delay.” These converters are configurable and can be adjusted to the needs of particular connected modules. For example, the A/D converter has a list of ports and parameters as shown here:
port (dout, underflow, overflow, encode,ref_plus, ref_minus, ain) parameter real Rref = 10.0e3 from (0:inf); // Reference input resistance parameter real tD_out = 10n from (0:inf); // Propagation delay
In the waveform in Figure 6, the input and the output signals of the A/D converter are shown where ref_plus (the positive reference voltage) is set to 1.3V and the digital output is single bit.
With these two examples, different ways of implementing different types of analog modules in the digital environments are shown. Also it can be seen that having the analog modules inside our DUT-s does not necessarily mean that the way of developing and using the UVM environment has to be changed. That enables use of all the tools that can help in developing more complex environments, and achieving better results of verification.
Improving Coverage Results Using inFact
After generating the testbench environment for the DUT containing analog parts, with a Verilog-AMS wrapper as a top module, inFact was used to efficiently target and improve the defined coverage goal. The graph-based coverage improvement enabled by inFact can be easily achieved thanks to the digital-on-top testbench concept.
For the stimulus class, which in this case is a sequence item, inFact defines the rules. This means that rules define the legal values of fields of a transaction data structure (UVM sequence items), and control their creation and delivery to the driver. When an inFact test component was created, a rules file template was also generated as a starting point for the rules file definition. Then, stimulus data fields were declared. Actually, those data fields are meta_actions in the inFact rules file that correspond to the random fields in the original UVM sequence item. Also in this step: declared constraints in the rules file that mirror the same data field relationships as the original UVM sequence. Rules are compiled into graphs on which the inFact algorithms operate. At this point the graphical view of the coverage strategy derived from the testbench is made (Figure 7, shown below).
Results of the simulation using the generated inFact sequence show that the predefined coverage goal was not achieved. By using inFact to compute the exact number of legal combinations for a set of variables, including the number of bin combinations when bins are defined, the target coverage was reached. This feature is more visible for more complex DUTs. This approach not only significantly accelerated the verification process, but also helped to reach the desired coverage goal.
Coverage was collected from results from nightly regressions. Questa Verification Run Manager (VRM) was used to set up nightly regression runs for functional and mixed-signal verification. As an output result, VRM provides an HTML file with a chart of test results, code and functional coverage percentages, as shown in Figure 8.
The examples presented in this case study show how the complete process of verifying analog mixed signal designs can be improved, from the initial setup of verification environment using a configuration-file-based Perl script, to increasing results of code and functional coverage using a tool for sequence generation based on coverage demands, to automatically running tests with a tool for verification management. This approach helps meet coverage goals faster than is possible with other, more traditional verification methods. The key to our approach: nearly every aspect of the verification environment used for analog mixed signal designs can be implemented with digital-ontop wrapper that greatly simplifies the verification process.