Monthly Archive: February 2017

Feb 27

Register testing made simple – Go2UVM app!

Categories:

EDA, SystemVerilog, UVM

by

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!

 

This post has no tag

Leave comment

Feb 14

Waves2UVM – a Go2UVM app

Categories:

EDA, SystemVerilog, Uncategorized, UVM

by

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.

 

 

 

This post has no tag

Leave comment

Feb 03

Simplifying UVM messaging – `g2u_display()

Categories:

SystemVerilog, UVM, UVM1.2

by

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!

 

This post has no tag

Leave comment