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.