Author's details

Name: UnleashingUVM Site Admin
Date registered: March 4, 2014
URL: http://www.cvcblr.com

Latest posts

  1. Register testing made simple – Go2UVM app! — February 27, 2017
  2. Waves2UVM – a Go2UVM app — February 14, 2017
  3. Simplifying UVM messaging – `g2u_display() — February 3, 2017
  4. UVM Registers – first step to Portable Stimulus, free training — December 7, 2016
  5. Handling variable delays in SystemVerilog Assertions — November 11, 2016

Most commented posts

  1. Free resource – SystemVerilog interfaces, step-by-step guide — 2 comments
  2. SystemVerilog-UVM, Verification “Hackathon” — 2 comments
  3. Sorting Associative Array by contents in SystemVerilog — 1 comment
  4. Run UVM Hello World in 10 Seconds — The Fastest Way to Get Started with UVM — 1 comment
  5. UVM 1.2 Day event – archive of presentations — 1 comment

Author's posts listings

Feb 27

Register testing made simple – Go2UVM app!

Go2UVM has a major update on the eve of DVCon USA 2017. We added several new features including:

  • Simplified messaging via new macros
  • Support for arbitrary signal access to enable force/deposit/release on DUT signals
  • Waves2UVM – a handy way to convert timing diagrams to UVM tests
  • Register layer app – the BIG one!

While UVM Register layer has been around for few years, an average UVM-aware engineer finds it hard to adopt quickly (compared to rest of UVM). This gets even more tough for RTL Designers looking to do some quick sanity tests on their RTL before handing it off to full-fledged DV teams. As part of our mission to “Go to UVM – the fastest way”, we have added a new app to assist in this process.

Generating UVM registers from an IP-XACT/SystemRDL/XML/YAML files has been around for many years. A limited edition of this capability exists as part of VerifWorks’s DVCreate-PSS tool as well.

However using the UVM register model to create quality tests requires more work form the user side. Part of the problem is to do with the various DUT protocols used to configure the registers as part of the designs. Go2uVM’s new register app targets exactly this problem, i.e. it builds on top of a generated UVM register model and makes it a push-button solution for simple designs to use register layer. When deployed correctly, this can lead to productive results in less than 30 minutes flat for an average RTL Designer (enabling him/her with many UVM capabilities). So how does it work? Below are the pieces needed to perform early register testing for a new RTL.

  • Register spec (IP-XACT and the likes)
  • Protocol specification to write and read from the registers
  • Some use case scenarios

A first step would be to create a UVM register model from the IP-XACT through available tools. The second step involves writing a small BFM (Bus Functional Model) to capture bus write-read protocol. With Go2UVM’s latest register app, we pushed this to a SystemVerilog interface named g2u_reg_if. A skeleton code looks as below:

interface g2u_reg_if (input logic clk);

// Relevant signal declarations

task g2u_write (uvm_reg_addr_t wr_addr, uvm_reg_data_t wr_data);

// Actual protocol to write to RTL
endtask : g2u_write

task g2u_read (uvm_reg_addr_t rd_addr, output uvm_reg_data_t rd_data);
// Actual protocol to read from RTL

endtask : g2u_read

endinterface : g2u_reg_if


Once a basic BFM inside a g2u_reg_if is created, our latest app does the remaining work and creates a thin UVM environment with:

  • Register model instance, creation & build
  • Built-in Go2UVM register agent (g2u_reg_agent) instance and connections
  • Necessary UVM register adaptors (bus2reg() and reg2bus())
  • A thin UVM driver-sequencer-agent-monitor hierarchy

For any new design with a different protocol, only the interface requires updates.Typical tests that are readily available with Go2UVM app includes:

  • Hardware reset and post reset value checking
  • Bit-bashing of all registers and fields (as defined in the IP-XACT spec for the given design)
  • Register access policy checks
  • Aliasing tests (On need basis)

A typical test using the Go2uMV register app looks like below:

We will soon be adding more examples including sample designs from OpenCores, typical protocols such as AHB-Lite, AXI, WishBone etc. to our GitHub repository. Meanwhile the latest release of Go2UVM is 2017.01 and is available under LGPL license from the link below:

Go2UVM on GitHub

We will be showing this in detail at DVCon USA 2017 as part of a UVM tutorial as well.

Let’s Go-to-UVM!


Feb 14

Waves2UVM – a Go2UVM app

For long, engineers needed an easy and scalable way to capture timing diagrams as part of their design specifications. There have been few commercial tools to help in this task. A relatively new tool named WaveDrom has been developed as an open-source JSON based solution for this. Quoting WaveDrom.com site:

WaveDrom draws your Timing Diagram or Waveform from simple textual description.
It comes with description language, rendering engine and the editor.
WaveDrom editor works in the browser or can be installed on your system.
Rendering engine can be embeded into any webpage.

So essentially when you are creating a new design specification and want to capture the timing relationship as a waveform, this utility can be very handy. For instance, below is a screenshot of ARM APB 2.0 specification (for Figure 3-4 in ARM specification):

The above diagram is very easy to create using JSON like syntax with WaveDrom editor – we will offer a download of the JSON file soon here for APB 2.0 specification. For many seasoned digital designers, a diagram such as above is a great source of reference to create:

  • Stimulus (i.e. apply the signal transitions as found in the specification to DUT – Design Under Test)
  • Checks – assertions in the form of SystemVerilog Assertions (SVA) for instance.

As part of our mission to widen UVM adoption across teams, we developed a tiny “app” that reads WaveDrom file and creates a UVM Test through Go2UVM Test API. With this app (Soon to be released along with latest Go2UVM 2017.01 release), one can input this waves.wd file and get a SystemVerilog-UVM test that can be run on a compliant DUT (RTL model for instance). The usage is quite straightforward:

perl $VW_GO2UVM_HOME/bin/vw_dvc_wd_apps.pl

The above app creates the following infrastructure necessary to reproduce the same timing diagram in a typical UVM simulation:

  • SystemVerilog interface file
  • Go2UVM Test that toggles wires as per the specification in the WaveDrom file
  • Top file that instantiates the test, connects the interface etc.
  • Makefile to run on all popular EDA tools.


Some of the screenshots from the app when ran on an APB 2.0 waves is below:


Go2UVM Test:

So as we are about to roll-out our latest Go2UVM library 2017.01 during DVCon USA 2017, there is a lot to look forward to! Stay tuned for more updates.




Feb 03

Simplifying UVM messaging – `g2u_display()

As part of our goal to making UVM easy-to-use, we keep adding more features to the Go2UVM library. One of the recent additions is “Simplified messaging in UVM”. Intention is to bring the benefits of UVM messaging to all Verilog-aware engineers in the easiest way. Looking back at Verilog’s native $display(), it is the most used debug techniques in simulation based verification. It is easy to use, concise and almost every Verilog aware engineer is used to this tiny feature. However it does have its deficiencies, especially when it comes to debugging someone else’s code and when the project is large. Some of the most common issues with plain old $display() are:

  • Lack of $time in-built – i.e. since Verilog is mostly dealing with timed models, it is very useful to have the simulation time available with every message. One can add it manually to every $display() – but that’s work!
  • No FILE & LINE number information from $display() – as SystemVerilog added 2 handy macros `__FILE__ to get the file name, and `__LINE__ macro to retrieve the line number. This has been a standard debug technique in software for ages especially when the code is expected to change hands often.

UVM has added several APIs and macros to resolve the above issues and the popular macros are:

  • `uvm_info (ID, MSG, VERBOSITY)
  • `uvm_error (ID, MSG)

However, a uninitiated Verilog like engineer finds the above bit strange, especially the ID part of the macros. With no strict guidelines from UVM documentation on what to use as ID, teams tend to misuse this quite a bit. Seasoned engineers tend to use built-in uvm_object::get_name() as ID as that tends to make the log file comprehendible and correlates quickly to the objects in UVM. And the VERBOSITY – many a times engineers use UVM_MEDIUM. Given that SystemVerilog allows default values for macro arguments, one would hope and expect that the UVM library would add a default value for this argument. – but as of now it does NOT – forcing users to add this to every display message by hand! Let’s look at few sample UVM message code:

`uvm_info (get_name(), “Hello World”, UVM_MEDIUM)

`uvm_info (get_name(), “Generated a packet”, UVM_HIGH)

`uvm_info (get_name(), $sformatf (“Writing to addr: 0x%x data: 0x%x”,

x0.addr, x0.data), UVM_MEDIUM)


That’s bit of a code for first time UVM engineers. How about we simplify the same as below:


`g2u_display (“Hello World!”)

`g2u_display (“Generated a packet”, UVM_HIGH)

`g2u_display ($sformatf (“Writing to addr: 0x%x data: 0x%x”,

x0.addr, x0.data))


That is handy and neat! Under-the-hood we still call the same UVM API (uvm_report_info() for instance). So what happens?

  1. ID : we use get_name() automatically (And a nice, built-in workaround to handle scopes outside uvm_object, don’t worry!)
  2. VERBOSITY – we use default argument to the macro to use UVM_MEDIUM


So with Go2UVM, adopting UVM becomes easier and simple.

Stay tuned for more updates in next major release of Go2UVM!


Dec 07

UVM Registers – first step to Portable Stimulus, free training

For those using UVM in live projects and looking to see what’s next in DV – here is an opportunity to learn (for free) UVM Registers -a definitive first step to “Portable Stimulus”. Accellera’s PSS working group is working on defining how a portable test specification can be defined and is expected to be the next big wave in DV space.

CVC, a global leader in VLSI Design-Verification training is pleased to offer a free half-a-day training on UVM RAL/Registers. It is free of cost, but registration is must.

Register at: https://goo.gl/forms/2UQvmI90Lp6dgKwk2

When? Dec 17th, 2016 Saturday, 10 AM – 1 PM (Indian Standard Time)

Address: http://www.fb.com/cvc.uvm/about 

Cost:  FREE

All Attendees will have the option of buying the best selling SVA book at 10% discount, see: http://verifnews.org/publications/books/ 

Hurry, limited seating, first-come-first-serve basis.


• UVM introduction

• Capturing registers in UVM

• Using XL sheet to capture Register Specification

• Brief look at IP-XACT for register specification

• Case studies: popular IPs and their register specifications

• Demo: VerifWorks DVCreate PSS tool to generate UVM-RAL model from IP-XACT

Register via: https://goo.gl/forms/2UQvmI90Lp6dgKwk2




Nov 11

Handling variable delays in SystemVerilog Assertions

Have you got a modern design that has dynamic, variable latency bet’n request and response? Do you want to model that behavior in your verification code using SystemVerilog? Assertions are great way to capture such temporal requirements and verify them in simulations.

A more formal requirement
// After “start_sig” goes high
// within a variable delay of “var_del” clock cycles
// signal “end_sig” should go high

A first-cut SVA implementaion would look like below:

start_sig |-> ##[1:var_del] end_sig

However SVA as in IEEE 1800-2012 does NOT allow variable delays in properties/sequences. That would mean that assuming the var_del is a variable (int/integer/logic vector etc.) the above code won’t compile 🙁

 A work-around is to use local variable and count.

The core code is below:


So what’s happening?

Line-3: Once you see a HIGH on start_sig, save the current value of var_del (Remember it is a variable, could change during the course of checking this transfer) in a local variable (v_cnt)

Line-4: Start decrementing v_cnt value once per clock (Till.. see next line)

Line-5: As soon as you see end_sig make sure your transfer did NOT timeout/expire

For all FSM lovers, here is the logic as a bubble diagram:


In this example we have implemented that logic inside a “checker” (a new construct in SV) and make it easy for end users.

Now how do we “verify” this logic? Well, let’s use UVM trace with Go2UVM. One of the key benefits of Go2UVM is that while testing an assertion/checker for proper functionality, one could predict the errors and report them with SVUnit’s report-mock feature.

See go2uvm_tb_src/vw_var_del_in_sva_uvm.sv and look for expect_error API usage. We use that prediction for an intended fail trace and in the log file you will see the test still passes (as expected) despite the presence of an UVM_ERROR (again note that the test intentionally introduces errors and expects the SVA to flag it appropriately).

You can download the fully ready code as a tar ball below:

[wpfilebase tag=file id=19 /]

Files Description:

UVM Trace –> go2uvm_tb_src/vw_var_del_in_sva_uvm.sv
SVA code –> sva_src/vw_var_del_in_sva.sv

To run;

cd run_dir
make cvc2 (for Questa). Other targets are available for other tools as we use a generic Makefile from: Generic Makefile for UVM

Oct 27

Generic Makefile for UVM simulations

Given the widespread usage of UVM across the globe, many first timers to UVM find it hard to remember all relevant options to their favourite simulator to get going with UVM. Our Go2UVM approach is addressing this very issue via a generic Makefile. Given most of the VLSI engineers are familiar with Makefile use model, we provide a free to use (even for commercial deployment) Makefile here:

[wpfilebase tag=file id=18 /]

So how does this work?

  1. Create a text file named “flist” that contains names (and paths as necessary) of all the design and Testbench files.
  2. Choose your favourite simulator – Synopsys, Cadence, Mentor or Aldec – we support all of them in single Makefile.
  3. On a terminal type: make cvc2_gui TOP=my_chip_uvm_tb_top TEST=my_uvm_test

That’s it!

Here are different EDA tool supported along with our Makefile target names:




Older posts «

Fetch more items