TM

Efficient Migration of Efficient Migration of VerilogVerilog

TestbenchesTestbenches to ‘UVM’ keeping to ‘UVM’ keeping

the functionality intact: the functionality intact:

Do’s and Do’s and Dont’sDont’s

Mehul Kumar & Nitin Goel

Date – 22 Dec 2011

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

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

Verilog Testbench and its equivalent UVM Testbench

TM 4

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.

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

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 "->"

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

Timing Diagram to explain Verilog and System Verilogcode 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

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

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

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

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

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

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

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

5Approximate Lines Of Code

per testcase>225 <40

THANK YOU!!

TM 17