Improving Constrained Random Testing - Second Place Paper at DVCon 2017

Improving Constrained Random Testing - Second Place Paper at DVCon 2017

I am excited to share my latest paper which was recently published at DVCon 2017 in San Jose, California. The full title is:

"Improving Constrained Random Testing by Achieving Simulation Verification Goals through Objective Functions, Rewinding and Dynamic Seed Manipulation"

Abstract
Constrained Random simulation is so critical to modern verification environments that it is a major component of the SystemVerilog language itself. This paper proposes a method that improves how UVM Constrained Random simulations are run. By abstracting the purpose of a simulation to be achieving “Objective Functions” (nominally coverage goals), it is possible to have the simulation autonomously explore deep possibilities from multiple points in time of a standard UVM testbench governed by feedback. This method has a number of benefits including: faster automated coverage closure, an efficient final stimulus solution and proposed higher quality of coverage.

One Parameterized Bind to Bind Them All

One Parameterized Bind to Bind Them All

The SystemVerilog bind command allows for adding new functionality to a module.  Typically, it is used to add new checking to a RTL block.

I wrote the example code (available on GitHub here) below to demonstrate a feature of bind that allows the binded module to parameterize itself based on where it is being used.  When you think about what bind is actually doing it starts to make sense.

Implicit Port Connections Summary

I was working on a testbench and made a mistake. I saw a SystemVerilog code construct I wasn't used to and "corrected" it. I ended up disconnecting a port that was implicitly connected. There is already an authorative paper on this subject "SystemVerilog Implicit Port Connections by Cliff Cummings" which is very good.

I'd like to share a one page example that shows the differences. In the code posted on Github here I create a simple dut that uses the two different ways of using SystemVerilog implicit port connection. The one I made the mistake on was called ".name implicit port connections".

mul ex3 (.mult, .mop1, .data);
mul ex1 (.mult, .mop1, .data());

The two lines above are very different. The top line will use the .name implict port connection to connect all three ports. The second line will use the .name implicit port connection to connect only two ports and explicitly leave floating the .data port.

The example code when seen as a schematic in Mentor Visualizer is below. We can see that instance ex3 and ex4 get connected to the "data" input port. But ex1 and ex2 do not - because we are not allowing the implicit port connections to happen for two different reasons.

implicit

uvm_report_object Feature Examples

UVM has a powerful display capability baked into it from the uvm_report_object. Using it allows for capabilities such as:

  • getting the debug info you want out of components without being blinded by everything
  • silencing messages you don't want to see
  • breaking out detailed logs into seperate files to not clutter up the simulation logs for everyone else

I put together a reference environment on GitHub that goes through exercises using the uvm_report_object here. Included is also the text output of the simulaton so you can print the code as well as the output and follow along.

SystemVerilog Constraint Layering Examples from John Dickol

DVCon 2015 had a paper by John Dickol titled "SystemVerilog Constraint Layering via Reusable Randomization Policy Classes" that described how SystemVerilog constraints could be layered onto an object. The previous method was to do a factory override or extend the class to get this type of behavior.

I loved the idea. It solves a lot of problems such as having to create and manage extended classes who only exist to further constrain an object. Plus you get the ability to recombine constraints during the sim - which is amazing. In order to make sure I understood his approach and to do the examples myself, I have written out the complete code from his paper. I have made this code available with the author's permission on my Github account here.

The code in the paper builds upon itself with each additive iteration. This means that classes are getting overwritten with new versions of itself and sometimes classes go away as the paper moves on. If you would like to follow along with his paper it might be helpful to have the full source code for each Figure available to experiment with or to reference in the future. The paper sometimes groups many figures into one example. The list below shows what figure from the Dickol paper is represented in which folder. Each folder has a Mentor Questa .do file that can launch the simulation and then print out five example randomizations.

I added a few non-referenced items to the code that are not explicitly described in the paper like: class addr_range and type addr_t. And added a testbench to try out the code examples, but all of the ideas are credited to John Dickol and his excellent paper!

Folder and Figures from paper:

  • A
    • Figure 1
    • Figure 2
    • Figure 3
  • B
    • Figure 4
  • C
    • Figure 5
  • D
    • Figure 6
  • E
    • Figure 7
    • Figure 8
  • F
    • Figure 9
    • Figure 10
  • G
    • Figure 11

Example Command to Simulate with Mentor Questa

cd A
vsim -c -do compile.do

DVCon 2015 Paper and Presentation

I have a paper and a presentation session slot at DVCon 2015 (Design and Verification Conference) in San Jose, California. The title of the paper is "Method for Generating Unique Coverage Classes to Enable Meaningful Covergroup Merges Across Testbenches" and I am excited to share it with the verification community.

It will be presented on Wednesday, March 4th in the Monterey/Carmel hall in the afternoon Coverage sessions.

My Session Number is 13.3 for more information click here.

If you are attending the conference and liked my presentation / paper please vote at www.dvcon.org/2015/vote.

The paper and the slides used in the presentation are now available at this link on the DVCon website.

Verilog Flip-Flop Macros by Chris Drake

Verilog Flip-Flop Macros by Chris Drake

Chris Drake's blog Fuzzy Logic had a particular post titled Verilog Flip-Flop Macros which I thought was really good. It deals with creating an abstraction of a flip-flop in SystemVerilog.  I had to try out his example code myself to verify the performance differences he experienced.

The Strategy Pattern in SystemVerilog

The Strategy Pattern in SystemVerilog

I had watched a wonderful video series of Object Oriented Design Patterns on Lynda.com called "Foundations of Programming: Design Patterns" by Elisabeth Robinson and Eric Freeman.  In their series, they go through some of the ideas in "Design Patterns" and have very concise code examples that illustrate specific Design Patterns.

I highly recommend checking out "Foundations of Programming: Design Patterns" and checking out Lynda.com - if you haven't heard of them before.

The example code from the video series is, of course, not written in SystemVerilog.  It is written in Java.  From the Lynda.com site you can download for free the Java example code.  As an interested student, I took their example code and rewrote it in SystemVerilog, staying as close as possible to the original and published the result on GitHub below.

Merging SystemVerilog Covergroups by Example Article in Mentor's Verification Horizons

Merging SystemVerilog Covergroups by Example Article in Mentor's Verification Horizons

There were two early articles on this blog that I wrote dealing with merging SystemVerilog covergroups:

The two posts were rewritten and are now available in Mentor's "Verification Horizons" June 2014 quarterly publication under the title "Merging SystemVerilog Covergroups by Example".  I'm happy with how it turned out.

Display Monitor and Strobe in SystemVerilog

Display Monitor and Strobe in SystemVerilog

I was adding in the ubiquitous "what is this code doing" debug statements to some SystemVerilog to trace what was happening and finally had a chance to consider deeply the application of: $monitor, $display and $strobe.  All three print to the display and all use the same syntax and formatting in their arguments.  The difference in the three is when they actually execute.  I read a pretty good starting article Verilog subtleties – $monitor vs. $display vs. $strobe that gave me a start to creating my own teaching version of their example.

You can check out the code below on github.

Using Squarespace and Embedding Syntax Highlighted Code with Emacs

Using Squarespace and Embedding Syntax Highlighted Code with Emacs

Squarespace has the ability to syntax highlight the following three source types:

  • html
  • css
  • javascript

in a very workable built in code block in their blogging system.  But, if you use another source type like SystemVerilog or Python you will have to figure out something else to get your source code syntax highlighted on Squarespace.

In the following post on Answers Squarespace, it mentions a method using the javascript helper Prism that can syntax highlight a lot of languages out of the box.  It actually looks really cool.  Sadly, SystemVerilog is not in their list of supported languages.

To handle something like SystemVerilog, or nearly every language, the solution I ended up with was using Emacs with the plugin htmlize.  The idea is that since Emacs already has great syntax highlighting for everything, you can export regions or whole files to raw HTML with that syntax highlighting intact.

Mentor Questa do versus source

Mentor Questa do versus source

The standard TCL command "source" is the common way to read in source of one file into the current environment - similar to an `include in Verilog.  Mentor Questa runs a TCL interpreter and adds a few custom features to the environment one of which is the command: "do".  For many uses the "do" and the "source" command will have identical output.  In fact, whatever can be done with "source" can be done with "do" - it is a superset of "source".  The "do" command does add at least two useful or at least interesting features.

SystemVerilog timescale Across Classes Illustrated

SystemVerilog timescale Across Classes Illustrated

Mixing of `timescale(s) causes problems if you are trying to pass delays as realtime types.  The realtime type was never meant to be treated this way.  realtime is actually a standard real type but with only local knowledge of the meaning of the units of time.  When you pass a realtime value into a class in a different package all you get is that real type value and no units.

Software Deprecate Versus Depreciate

Software Deprecate Versus Depreciate

I used to work with a guy who would quite often correct me on my use of the word deprecate in the context of software.  I would say "I think that software function is deprecated and should not be used anymore."  (Deprecated pronounced dep-re-kate-ed).  He would respond "no, that software function is depreciated". (Depreciated pronounced de-pre-she-ate-ed).

 

We have the two words:

  • deprecated
  • depreciated

Just one letter different, but the pronunciation is quite a bit different.  I kept saying the word my way and he would say it his.  His reasoning was that deprecate was a synonym for defecate; which is incorrect.

What is the correct word to use in the context of software?  Read the rest of the post for the full answer.

Using TCL cmdline library with Interactive Tools

Using TCL cmdline library with Interactive Tools

Most tools in EDA (Electronic Design Automation) have an interactive TCL (Tool Command Language) interface.  Some examples are Mentor Questa, Cadence Incisive, Cadence RTL Compiler, and many of the IBM EDA tools.  A common problem is that the TCL language does not come shipped with a command line parser.  TCL assumes you will just use positional arguments or you will come up with your own parsing package.

The Standard TCL Library (TCLLIB) has many routine libraries; including a very useful command line parser.  Unfortunately, it is not always installed by default or included with the EDA implementation of TCL.  For a good intro into the use of the command line parsing library available from TCLLIB, you should check out a post from Hai's Blog on how to use the TCLLIB cmdline library.

I took the the example from Hai's Blog and wrapped it to make it work in a reusable way within EDA tools and show some examples below of its use below.  Since EDA tools already have the TCL interpreter running you would want to have the TCL arguments be wrapped around procedures and not the arguments to program itself.