The next Design pattern I ported to SystemVerilog is the Observer Pattern below. See the Strategy Pattern in SystemVerilog for more background on this mini project.
Observer Pattern in SystemVerilog on GitHub
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.
I'm honored to share that my paper:
"Design Patterns by Example for SystemVerilog Verification Environments Enabled by SystemVerilog 1800-2012"
was awarded Best Paper at the Design and Verification Conference (DVCon) 2016. The link to the final paper is now available.
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.
The next Design pattern I ported to SystemVerilog is the Observer Pattern below. See the Strategy Pattern in SystemVerilog for more background on this mini project.
Observer Pattern in SystemVerilog on GitHub
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.
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.
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.
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.
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.
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.
I had used other programming languages before working with System Verilog. So when I started looking at System Verilog code for the first time, I was perplexed why there were all of these `includes all over - even in purely object oriented verification logic.
There is a problem and proposed solution I would like to share. Using packages instead of `include to store constants. I wrote the example both ways: package and `include; so you can see something that I see typically done with `include done with packages.
Your FlexLM License server might be behind a firewall that makes it unaccessible even if you are VPNed into that network. The FlexLM server could be only listening to machines on a certain subnet of addresses or have some other reason to communicate with only certain machines. That firewall makes things like my post Installing Mentor Questa on Ubuntu much more difficult to complete if you wanted to run something like Mentor Questa on your remote machine.
This is my recipe that will allow you to do the necessary ssh forwarding to be able to communicate with a FlexLM server as if you were at a machine on its native network.
I use Mentor Questa a lot and when I am at work the visual lag of interacting with the GUI is almost imperceptible. But, when I am working remotely that visual lag is, of course, more noticeable. One possible solution that reduces the lag considerably compared to VNC, NX, or Windows Remote Desktop is to run Questa natively on your local computer.
The first problem you will run into is that Questa is only officially supported on Redhat and SUSE Linux. (It is also supported on Microsoft Windows too, but who really does serious engineering work on Windows?) So, if Questa is only supported on two commercial Linux variants are we stuck on installing Redhat at home from the corporate install? Fortunately, no.
You can install Mentor Questa on Ubuntu Linux. I'll go through installing it on Ubuntu 12.04.3 64bit.
In the previous blog post, we were merging covergroups and, in all cases, keeping track of the covergroup instances "INST" (the Mentor Questa notation) data as well. This is perfectly fine if you have only a few repeated instances. But, what if you have thousands of instances in your design - the covergroup data can get bloated.