Efficient Migration of Verilog Testbenches to 'UVM' Keeping the Functionality Intact
- 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