AbstractConstrained 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.

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.

AbstractConstrained 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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

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.

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.

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.