Just like Emacs, multiple packages are available for VIM that enable use of code snippets within VIM. Of these I used a package named SnipMate for the purpose of exploring VMM snippets in VIM. If you have not used SnipMate before, the following YouTube video provides a wonderful introduction to the package and its use.

http://www.youtube.com/watch?v=_galFWwSDt0

Prerequisites

1. The snipMate package requires VIM 7 or higher.
2. SystemVerilog mode for VIM from this link.

Download and Install

1. Download the snippets from here.
2. Install the package by unzipping it inside the ~/.vim directory.

To test the installation, open a systemverilog file in GVIM and and press the key sequence . This should pop-up a list of available snippets. You can also try ovm snippets by keying in ovm and following it with a TAB press. VMM snippets can be accessed similarly by keying in vmm followed by a TAB press. Most SystemVerilog constructs like while, for, if, class etc too invoke a snippet. Another interesting snippet to try out is once.

To ease up coding effort, VMM provides vmmgen utility (which seems broken in the recently announced 1.2 release). OVM on the other hand has a couple of utilities available in the contrib area of the OVM World.

Being an Emacs addict, I always craved to have these capabilities as part of Emacs. Over the past year I made some effort in this direction and I think at this point the code templates have matured enough for a public release. Additionally my package (which is built over YASnippet package for Emacs) supports common SystemVerilog constructs like class, case, always etc.

Prerequisites

GNU Emacs (version 22 or later) -- If you are still using XEmacs, I suggest that you have another look at GNU Emacs. The past decade has seen quite a few new developments with GNU Emacs. And a lot of new elisp packages are now supported only for the GNU flavor.

Verilog Mode -- Let me know if there is any other verilog mode for Emacs worth its name, and I will add support for that too.

Installation

Download the package from the following link yasnippet-bundle.el.gz

Uncompress the downloaded file in a directory where you keep your other emacs packages. Make sure that the directory you kept the uncompressed file in, is in your Emacs load path.

Load the downloaded package. You can do this by adding the following lines in your emacs init file.

;; Add the directory to Emacs load path
(setq load-path (cons "/path/to/directory" load-path))

;; Load the package
(require 'yasnippet-bundle)

Now when you launch Emacs, you should see a YASnippet menu in the top menu-bar. Navigating to verilog-mode on this menu-bar will make all the verilog templates visible to you. When editing a file in verilog-mode, you can also access these templates using keyboard shortcuts shown along with the menu-bar entries. All the VMM specific templates can be accessed by typing vmm and following it up with a TAB. Similarly OVM templates can be accessed by typing ovm and then a TAB. SystemVerilog snippets can be invoked by typing the respective keywords followed by a TAB. To know all the package capabilities, just watch the following video tutorial.

http://www.youtube.com/watch?v=76Ygeg9miao

If you face any issues with installation, just leave a message. Bug reports and other feedbacks/suggestions are also welcome. I intend to maintain and further develop this package. Ideas and suggestions are most welcome. Future revisions will be announced on Twitter.

Continuing with our exposition of the parameterized classes, today we will discuss some details of the vmm_channel and how to use these channels for parameterized transactions.

In an earlier blog entry I had discussed parameterized transactions. Ever since VMM 1.1 release, vmm_channel supports parameterized transactions, though this support is not enabled by default.

When I set off blogging, I kind of missed a good syntaxhighlighter for SystemVerilog. Well there are a number of wordpress plugins that do syntax highlighting job for you, but none supports SystemVerilog.

Fortunately, I found that SyntaxHighlighter Evolved Plugin supports extensions. So I went ahead and created an extension in form of an add-on plugin.

So, if you are a SystemVerilog geek, and want to share your code snippets with others, go ahead and use this small plugin. Note that this plugin depends on an active installation of SyntaxHighlighter Evolved Plugin.

Download

SyntaxHighlighter add-on for SystemVerilog

Install

Install and activate SyntaxHighlighter Evolved first.

Upload the systemverilog-syntax.zip on to the plugin interface of your wordpress installation. Activate the plugin.

Usage

When you have a SV code snippet to share, enclose it within

1

tags. As an example, if you wanted to share a code that looks like ....

`ifndef _FOO_SV_
`define _FOO_SV_
class foo extends bar;
   rand int frop;
   
   constraint frop_cst
     {
      // ....
       };

   // More code here
endclass: foo
`endif // _FOO_SV_

You need to just enclose it inside sv tags -- just as illustrated below here.

1

This should result in a beutified snippet on your weblog.

`ifndef _FOO_SV_
`define _FOO_SV_
class foo extends bar;
   rand int frop;
   
   constraint frop_cst
     {
      // ....
       };

   // More code here
endclass: foo
`endif // _FOO_SV_

Facing issues? Just leave out a comment.

So how are parameters useful while implementing generic VIPs? Is it not sufficient to pass a configuration object to the VIP and maneuver the VIP configurability with that object?

Well, configuration objects are dynamic. While they are very useful for the purpose they serve, they can not be used to configure bus bit-widths. This is because SystemVerilog requires you to provide compile time constants for specifying the bit range of the bus. And there are only two viable methods for achieving that -- parameters and pre-processor tick-defines. While, tick-defines are not elegant, earlier we also saw why tick-defines do not provide a viable solution all the times.

Let us look at what it takes to implement a parameterized transaction descriptor class. As an example we take the AMBA AHB master transaction. The specification of the bus protocol says that the data-width may be 8, 16, 32, 64, 128, 256, 512, or 1024. Similarly the address bus too can have any bit-width. The following snippet shows how an AHB Master transaction descriptor class could be coded (in VMM) using parameterized classes.

class ahbm_burst_xactn #(int DW=32, int AW=32) extends ahbm_xactn;

   typedef ahbm_burst_xactn #(DW, AW) transaction_type;
   typedef vmm_channel_typed #(transaction_type) channel_type;

   // Make the parameters available to the xactn object clients
   static const int DATA_WIDTH = DW;
   static const int ADDR_WIDTH = AW;

   // ......
   // ......
endclass: ahbm_burst_xactn

function vmm_data ahbm_burst_xactn::copy(vmm_data to=null);
   transaction_type xactn;
   if (to != null) begin
      if (!$cast(xactn, to)) begin
         `vmm_fatal(log, "Not a ahbm_burst_xactn instance");
         return null;
      end
   end else xactn = new;
   super.copy_data(xactn);

   xactn.kind = this.kind;
   // ......
   // ......
endfunction: copy

Here, I am using ahbm_xactn, which itself is derived from vmm_data, as a base class. On line 3, we have a typedef that defines transaction_type. You will notice that this is nothing but a concrete instance of the parameterized class that we are defining. The idea is to provide an abstraction for use within the transaction descriptor class itself. It makes the code more readable. For example, as you can see on line 15, nested type transaction_type provides a convenient way to declare the type of the transaction while defining the descriptor class methods. And it is a good abstraction, since if you add or remove a parameter to the parameterized class, you will not have to do that at many places. Just modify the typedef definitions, and you are done.

Similarly, on line 4, you see a similar typedef definition for a channel. With non-parameterized transactions, we would have declared the channel type outside the descriptor class definition. And we would have perhaps used the VMM macro `vmm_channel for doing that. That does not work for parameterized transaction types. Again typedef comes to our rescue. The following snippet illustrates how to use this abstraction while coding a transactor. Those with C++ background will notice that STL provides iterator types to the user in a similar fashion.

class ahbm_burst_gen #(int DW=32, int AW=32) extends vmm_xactor;

   typedef ahbm_burst_xactn #(DW, AW) transaction_type;

   // More typedefs -- snipped

   // transaction objects and channel declarations
   transaction_type randomized_obj;
   transaction_type::channel_type exec_chan;
   transaction_type::channel_type obs_chan;

   // snipped
endclass: ahbm_burst_gen

Coming back to the descriptor claas, on line 7 and 8, you would notice definitions of static constants DATA_WIDTH and ADDR_WIDTH. This is a convenient way to make data and address widths available to any code that uses a transaction object but is not aware of the DW and AW parameters. And since these constants are declared static, they do not consume much memory when the simulation runs.

In my next post, I will discuss the intricacies of writing a parameterized transactors. When we do that, we will also see Emacs and ViM snippets coming to our rescue.

In his blog, Adiel concludes that `define macros should be preferred over using parameterized classes. In this blog entry, I will try to focus on some of the virtues of parameterized classes.

Take for example an AMBA AHB Master VIP, that I recently had an opportunity to work on. To make the VIP reusable, the data bus-width and the address bus-width need to be made configurable. There are two approaches ....

The `define method

When you code using `define, you don't hardcode the configurable parameters (eg DATAWIDTH and ADDRWIDTH). Instead you use `define constants. The following SV code snippet shows an attempt to code an AHB master transaction this way.

`define AHB_ADDRWIDTH 32
`define AHB_DATAWIDTH 32

class ahbm_xactn extends vmm_data;

   static vmm_log log = new("ahbm_xactn", "class");

   rand ahb::trans_kind_e kind;

   rand bit [`AHB_ADDRWIDTH-1:0] haddr;
   rand bit [`AHB_DATAWIDTH-1:0] hwdata;
   rand bit [`AHB_DATAWIDTH-1:0] hrdata;

   ....

endclass: ahbm_xactn

Note that the `define macro constants are scoped globally - and that is primarily the reason I have given them a longish name (in an attempt to make them really unique).

Also note that we are really defining a single transaction descriptor class, just that it happens to be configurable.

Using parameterized classes

The following SV code snippet illustrates another attempt to implement the AHB transaction descriptor class — this time using parameterized classes.

class ahbm_xactn #(int DW=32, int AW=32) extends vmm_data;

   static vmm_log log = new("ahbm_xactn", "class");

   rand ahb::trans_kind_e kind;

   rand bit [AW-1:0] haddr;
   rand bit [DW-1:0] hwdata;
   rand bit [DW-1:0] hrdata;

   ....

endclass: ahbm_xactn

Note that the parameters DW and AW are scoped locally — and therefor it is perfectly fine to give them smaller names. When using C++ templates too, it is a standard practice to use small — often single character — names to represent classes and parameterized constants.

Now something that really makes parameterized classes more powerful. When you code a parameterized class, you are really coding a set of classes. A class is in fact an instance of a parameterized class and you could create a multitude of such classes.

Why is that important? When modeling complex systems, there are places where you have multiple subsystems, each having its own AHB bus. And you need to have independent parameters for the address and data widths of these subsystems. If you used `define to implement an AHB bus transaction, you will find yourself in a fix.

In fact there are multiple dimensions to reusability. When you code a reusable VIP, it should be reusable across multiple projects. It is equally important to make it reusable within the same system — meaning thereby, it should be possible to instantiate the same VIP multiple times within the same system. And it should be simultaneously possible to configure each VIP instance in a different way. When you use the `define method, you can still have multiple instances of the VIP, but the `define parameters (being globally scoped) are common for all the VIP instances, and hence not independently configurable.

Support for parameterized classes does open up a lot of coding options. And I will try to explore some of these in my upcoming blog entries. My focus is going to be on how to code efficient VIPs that are really reusable.

The figure below depicts the various abstraction layers in a typical VMM-based verification platform. The concept of a transaction is central to VMM and a transaction transcends through all the different layers. At the top is Test Layer, which abstract the control mechanism of the verification. This is the highest level of abstraction and at this level none of the transaction details are important — often only the count of transactions is important in this layer. Just below are the Scenario and Functional Layers — which present the behavioral abstraction. Since these are the layers responsible for generation of transactions, the functional fields of each transaction object are important at these levels. What is not important is the bit-level timing as well as bit-level sequencing of the fields within the transactions. Finally the Command Layer helps drive the transactions to the bit-level interface of the design-under-test. Since this is also the physical interface of the module/chip, it is often a very different abstraction than what is presented by the Functional Layer. At this level we are more interesting in sequencing and timing of the various transaction bits.

The methods byte_pack and byte_unpack help us achieve these different abstractions of a transaction. Packed transactions offer the right abstraction within the command layer and often at the input of the functional layer. On the other hand unpacked transactions are required within the scenario layer.

For an ATM Cell transaction that we discussed here we can write the byte_pack method as ....

// Byte Pack
function int unsigned atm_cell::byte_pack(ref logic [7:0] bytes[],
                                          input int unsigned offset,
                                          input int kind);
   // Make sure there is enough room in the array
   if(bytes.size() < this.byte_size())
        bytes = new [this.byte_size()] (bytes);
   // Pack the bytes
   bytes[0] = {gfc, vpi[7:4]};
   bytes[1] = {vpi[3:0], vci[15:12]};
   bytes[2] = {vci[11:4]};
   bytes[3] = {vci[3:0], pt, clp};
   bytes[4] = {hec};
   for (int i=0; i < 48; i++)
     bytes[i+5]=payload[i];
   byte_pack = 53;
endfunction

// Byte Unpack
function int unsigned atm_cell::byte_unpack(const ref logic[7:0] bytes[],
                                            input int unsigned offset,
                                            input int len,
                                            input int kind);
   {gfc, vpi, vci, pt, clp, hec} = {bytes[0], bytes[1], bytes[2],
                                     bytes[3], bytes[4]};
   for (int i = 0; i != 48; ++i)
     payload[i] = bytes[i+5];

   return 53;
endfunction

A few points are in order ....

1. The byte_pack (and byte_unpack) function(s) are virtual functions. And therefor the function signatures need to match exactly the signatures of the base function defined in the vmm_data class in the VMM library.
2. It is useful to add some default values to the input arguments of the function, so that it becomes easier to call the function. These default values are often added in function declaration inside the descriptor class.

// method declaration, within the descriptor class definition
extern virtual function int unsigned
               atm_cell::byte_pack(ref logic[7:0] bytes[],
                                   input int unsigned offset = 0,
                                   input int kind = -1);

3. Input parameters offset and kind are usually ignored in the function implementation. While the usage of parameter kind can be user specific, the parameter offset can be used to make the function more generic — so that the byte packing can be done at an offset provided by the user.

function int unsigned atm_cell::byte_pack(ref logic [7:0] bytes[],
                                          input int unsigned offset,
                                          input int kind);
   // Make sure there is enough room in the array
   if(bytes.size() < this.byte_size() + offset)
        bytes = new [this.byte_size() + offset] (bytes);
   // Pack the bytes
   bytes[offset+0] = {gfc, vpi[7:4]};
   bytes[offset+1] = {vpi[3:0], vci[15:12]};
   bytes[offset+2] = {vci[11:4]};
   bytes[offset+3] = {vci[3:0], pt, clp};
   bytes[offset+4] = {hec};
   for (int i=0; i < 48; i++)
     bytes[offset+i+5]=payload[i];
   byte_pack = offset+53;
endfunction

4. Often it is useful to use byte_pack function while sending a transaction to a DPI function. Similarly byte_unpack can be used after receiving a transaction from a DPI function. It is easier to pass dynamic arrays to and from a DPI function.
5. Janick suggests on-the-fly calculation of CRC and other transaction processing be done in the byte_path method.
6. Chris Spears suggests using array slices as a short-hand notation for assigning various fields to the reference variable bytes and vice-versa. Given the fluidity in the SystemVerilog LRM regarding array assignments and the fact that the transaction fields may not be byte aligned, it is much better to use the old verilog trick as shown above, on the lines 24-25 of byte_unpack example for atm_cell.

SystemVerilog provides various ways of achieving this end. Often it is done by copying all the elements ....

foreach( payload[i] )
  cpy.payload[i] = this.payload[i];

Another possibility is to use the for block …

for( i=0; i < $size( this.payload ); i++ )
  cpy.payload[i] = this.payload[i];

But the best way is to just use the array assignment. Works for both fixed-size and dynamic arrays.

cpy.payload = this.payload;

Since in C/C++, assigning an array to another variable would only make a copy of the pointer corresponding to the array, use of assignment operator for copying arrays or queues is not intuitive enough, even when we code in SystemVerilog.

Here is my new weblogger setup …

(require 'weblogger)

(add-hook 'weblogger-start-edit-entry-hook
          (lambda()
            (flyspell-mode 1)
            (flyspell-buffer)   ; spell check the fetched post
            (auto-fill-mode -1)
            (visual-line-mode 1)))
(add-hook 'weblogger-publish-entry-hook
          (lambda()
            (when visual-line-mode
              (visual-line-mode -1))
            ;; tabs might spoil code indentation
            (untabify (point-min) (point-max))))
(add-hook 'weblogger-publish-entry-end-hook
          (lambda()
            (visual-line-mode 1)))

(setq weblogger-config-alist
      '(("PRIVATE"
         ("user" . "puneet")
         ("pass" . "TOPSECRET")
         ("server-url" . "https://systemc.in/wordpress/xmlrpc.php?RSD")
         ("weblog" . "1"))
        ("CoVerification"
         ("user" . "puneet")
         ("pass" . "ANOTHERTOPSECRET")
         ("server-url" . "https://blog.coverification.com/xmlrpc.php?RSD")
         ("weblog" . "1"))))

(require 'tls)
;; since I am now using rsd/ssl for wordpress, I need to make sure
;; that I do not get these redundant hostmismatch errors.
(setq tls-hostmismatch nil)

Also note that I am now using RSD to enable SSL connection with the server.

The Verification Methodology Manual provides several rules and guidelines specific to description of transactions. To understand how these rules apply in practice, we will look at an example — which happens to be the atm_cell descriptor class.

class atm_xactn extends vmm_data ;
   static  vmm_log log = new("atm_xactn", "class");
   rand bit [ 3:0] gfc;
   rand bit [ 7:0] vpi;
   rand bit [15:0] vci;
   rand bit [ 2:0] pt;
   rand bit        clp;
   bit      [ 7:0] hec;
   rand bit [ 7:0] payload[48];

   extern function new();
   // Mandated VMM functions
   extern virtual function string psdisplay(string prefix );
   extern virtual function bit is_valid(bit silent, int kind);
   extern virtual function vmm_data copy(vmm_data to);
   extern virtual function vmm_data allocate();
   extern virtual function bit compare(vmm_data to,
                                       output string diff,
                                       input int kind =-1);
   // Recommended VMM functions
   extern virtual function int unsigned byte_size(int kind=-1 );
   extern virtual function int unsigned
       byte_pack(ref logic [7:0] bytes[],
                 input int unsigned offset=0, input int kind=-1);
   extern virtual function int unsigned
       byte_unpack(ref logic [7:0] bytes[],
                   input int unsigned offset=0,
                   input int len=-1, input int kind=-1);
   // Additonal Methods
   extern  virtual function bit[7:0] atm_hec();
endclass

`vmm_channel(atm_xactn)
`vmm_scenario_gen(atm_xactn, "ATM Cell")

A few things need special mention …

1. On line number two, the vmm_log instance has been declared static. Since static data members are shared by all the instance objects of a class, it avoids unnecessary duplicate instantiations of vmm_log.
2. From line 3 to line 8, various fields of the 5 byte ATM Cell header are declared. While all other header fields have been declared random, the byte corresponding to the hec field has not been. This is because the hec byte depends on the value of the other bytes in the header — it is really not random.
3. From line 13 to line 28, there are various function declarations. Please refer to the VMM Book for a detailed description of these functions.
4. On line 30, function atm_hec has been declared. In the next blog entry, we will see how to implement this function using a C++ library.
5. Another pair of functions pre_randomize and post_randomize are available. These methods can be used as hooks that get called, before and after a transaction gets randomized. For example post_randomize function could be used to fill the hec field, calculated by the atm_hec function.