This document discusses best practices for efficiently migrating Verilog testbenches to the Universal Verilog Verification Methodology (UVM) while keeping functionality intact. It covers converting always blocks, assignments, forces and releases, inout ports, user interfaces, and monitor events. Timing diagrams are used to explain how Verilog and SystemVerilog code flows are handled. The benefits of migration include reduced cycle times, increased reuse, randomization, and coverage-driven verification capabilities provided by UVM.

1. TM
Efficient Migration ofEfficient Migration of VerilogVerilog
TestbenchesTestbenches to ‘UVM’ keepingto ‘UVM’ keeping
the functionality intact:the functionality intact:
Do’s andDo’s and Dont’sDont’s
Mehul Kumar & Nitin Goel
Date – 22 Dec 2011

2. Agenda
• Need for Migration
• Conversion of Sequential, Combinatorial and Continous assignments
• Conversion of forces & releases
•Conversion of Inout ports
•Conversion of UI from APIs
•Conversion of monitor events
TM 2
•Conversion of monitor events
•Establishing coherency between converted code with verilog counterpart
•Conclusion

3. Why is this migration needed?
• Increase in design complexity
• More than 100 IPs per SoC
• Reuse of legacy IP
• Avoid hybrid testbenches
• Newer components in the latest methodology
TM 3
• Newer components in the latest methodology
• Environment bring up
• Complex to scale
• Maintain

4. Verilog Testbench and its equivalent UVM
Testbench
TM 4

5. Converting always sequential logic, always
combinatorial logic and Continuous assignments
TM 5
• Combinatorial and sequential blocks are converted to 'task‘
• Sequential block non-blocking assignments are changed to blocking
• Continuous assignments mapped to functions returning values.
•A simple script is utilized to perform the conversion
•'naming 'of tasks could be edited later on.

6. How the Verilog event behavior is compensated when
all assignment types have been transformed to
blocking?
•Events executed in order:
• Active events
• Inactive events (#0 delay
assignments)
• Non Blocking assignments
• Monitor events
•In one time step all events are
TM 6
handled by Simulator

7. apb_interface :
apb_master class:
Dynamics of SystemVerilog code in terms of the
events and functional mapping of Verilog behavior
TM 7
•Two events are declared inside the APB interface
• 'master_nba_evt' (non-blocking event)
• 'master_act_evt' (Active event).
•Active event blocks the execution of the following:
• Waiting for posedge of clock
• Generation of Non-Blocking event.
•A 'main' task is used to synchronize code flow for APB master class
Note the "->>" being different from active event
trigger "->"

8. Event synchronization between code execution and region
execution
TM 8
Step 1: Active Event execution of line " ->apb_if.master_act_evnt; “
Generate trigger “master_nba_evnt”
All the combinatorial converted tasks executed
The code jumps to the wait of the sequential block trigger.
#Step2: NBA event "master_nba_evt" is triggered in the NBA region
"assign_current_state" task is executed
Blocking assignment of "present_state" variable is scheduled for #Step3.
#Step3: Blocking assignment for “present_state” is done . Repeat #Step1.
Verilog code transitions in following manner:
#Step1: Change in wire triggers 'always' block and 'next_state' is assigned.
#Step2: NBA assignment of 'present_state' is done
#Step3: Repeat #Step1

9. Timing Diagram to explain Verilog and System Verilog
code flow
TM 9
•In Verilog at simulator timestep 4 'pending_transaction' wire has a change in value
• Triggers the 'always' block to decide the 'next_state‘ handled in active region of timestep5.
• Assigned to 'present_state' variable in NBA region of timestep6 falling after the posedge of PCLK.
• In SystemVerilog 'act_evt' gets triggers in active region of timestep5 before the posedge of the PCLK.
• 'next_state' assignment is done in the same timestep in active region
• 'nba_evt' gets triggered in the NBA region of timestep6 falling after the posedge of PCLK
• 'present_state' assignment is scheduled to be done in active region of time step7.
• At timestep7 both code shows value of 'next_state' deposited on 'present_state' variable

10. Conversion of Force & Releases
TM 10
• A mux based logic is implemented inside the interface
• output signal 'a_o‘
• A mux select signal 'force_a_at_x‘
• force value at the wire 'a' when the select is '1' else actual 'a_o' value
•Functionality is similar to Verilog

11. Conversion of Inout Ports
TM 11
•A Verilog inout pin bifurcated :
• 'output_enable‘
• 'output‘
• 'input’
•UVM driver class implements these three ports instead of one' inout' pin.
•When the output is not selected a high'z' is driven

12. Conversion of User Interface from APIs
•API of Verilog driver
• 'addr', 'data' , 'strb' and 'write as
arguments
•API removed
•Sequence item class is utilized
• Testcase only needs to randomize one sequence
item instead of calling separate APIs for each
functionality to be executed by the driver
TM 12
functionality to be executed by the driver

13. Monitor :: Event Base -> Object Base reporting via
Analysis Ports
TM 13
• 'event' data type is triggered on occurrence of a particular condition.
• UVM monitor class an analysis port of type of 'apb_transaction' is created
• ‘write’ method of the analysis port is called to publish the event information.
• All events are stored inside TLM fifo to be processed by subscriber (scoreboard).
• Conversion mapping is direct
• triggering 'event‘ modified to a 'write' method call

14. How to establish that the ported UVM testbench is
conforming with Verilog testbench?
•No LEC kind of tool to check the conformity between two different
forms of same testbench.
• A Verilog proven assertion/protocol checker plugged in UVM converted
testbench
• Testcases were run to achieve 100% DUT code coverage
TM 14

15. Benefits of the approach
• Cycle time reduction.
• a reduction in cycle time of 30%-50%(approx.),
•UVM provides additional benefits
• Layered testbench enabling reuse
• Randomization
• Coverage driven Verification.
•UVM RAL provides the automated register check testcases
TM 15

16. Some Facts from a Typical IP Testbench environment
porting
S.No. Data Points Verilog Testbench UVM Testbench
1. Number Of Tests 550 35
2 Randomization No Yes
3 Reusability of Stimulus No Yes
TM 16
3 Reusability of Stimulus No Yes
4 Scalability of Testbench No Yes
5
Approximate Lines Of Code
per testcase
>225 <40

17. THANK YOU!!
TM 17