Archive for June, 2008

Why does the VMM message interface (the vmm_log class) have a start_msg() and a text() method that must be used in this convoluted way:

if (log.start_msg(vmm_log::DEBUG_TYP, vmm_log::TRACE_SEV)) begin
   log.text("This is a trace message");
   log.end_msg();
end

Why not the much simpler one-liner:

log.message(vmm_log::DEBUG_TYP, vmm_log::TRACE_SEV,
            "This is a trace message");

which would then eliminate the need for the macro:

`vmm_trace(log, "This is a trace message");

Given the examples above, there is absolutely no reason. However, this example illustrates why:

`vmm_trace(log, $psprintf("Read 'h%h from 'h%h with status %s",
                           data, addr, status.name()));

which expands to:

if (log.start_msg(vmm_log::DEBUG_TYP, vmm_log::TRACE_SEV)) begin
   log.text($psprintf("Read 'h%h from 'h%h with status %s",
                      data, addr, status.name()));
   log.end_msg();
end

The $psprintf() (and all other formatting system tasks $sformat(), $format(), $write(), $display(), etc…) may be simple to use but they are very run-time expensive. And if you are not going to display a message, why incur the cost of composing its image?

When using a single procedure call, the value of all of its arguments must be determined before it is called. Thus, using this approach:

log.trace($psprintf("Read 'h%h from 'h%h with status %s",
                    data, addr, status.name());

incurs the cost of creating the message image every single time. And most of the time, this debug message will simply be filtered out (think about the thousands and thousands of regression runs where debug is not enabled!).

On the other hand, checking first if messages of a certain type or severity are going to be filtered out or not and only then composing the image of the message improves your run-time performance.

By how much? Of course, it depends on the number of messages that will eventually get filtered out. But just to give you an idea, I ran this experiment using VCS:

program p;

initial
begin
   int i;
   string msg;
   i = $urandom() % 2; // See footnote1
   if (i == 1) i--;
   repeat (100000) begin
`ifdef GUARD
      if (i)
`endif
      msg = $psprintf("%s, line %0d: Message #%0d at %t",
                      `__FILE__, `__LINE__, 0, $time());
   end
end

endprogram

With `GUARD defined, which causes the $psprintf() call to be skipped, I get run-times of approximately 0.025 seconds. With `GUARD undefined, which causes the $psprintf() call to be executed, I get run-times of approximately 0.230 second or 10x slower simulation performance.

Personally, I think the performance gain is worth the little extra bit of code to write. Remember to always optimize the right thing: you’ll write that code once but you’ll run it thousands and thousands of times. So saving a few lines of codes is not always the right decision.

¹ I use a convoluted way to set i to 0 to prevent an optimizing compiler from optimizing the entire if statement away.

Now that VMM is available under an Open Source license, how is it going to be supported?

First of all, any further bug fixes and enhancements we will be making to VMM (such as the newly announced VMM-for-Low-Power functionality) will be added to the Open Source distribution once the usage model and basic functionality will have been proven with one or two lead customers who work with us in specifying and developing the enhancements.

The Apache licensing means that you are free to modify the VMM code in any way you wish. But should you? If you make a modification, that modification exists only in your version of the VMM code.

For bug fixes, that is obviously not a problem (and I’d really like to know about those so I can have them fixed in our distribution (such as the recent non-compliance issues)).

But what about functional changes? If you add functionality that you rely on for implementing your verification IP, those will no longer be portable to other VMM environments.

If you require some new capability or have an idea for some cool new functionality, I suggest talking with Synopsys first about it. If we can implement that new functionality for you, it will automatically be included in the next VMM release and everyone else will get it, ensuring portability once more. It will also ensure that the new functionality is implemented while taking into account other developments concurrently happening or planned. And we will be responsible for its on-going support.

But should you decide to go ahead on your own (for whatever reason), I’m still OK with it.

If you want to share your modifications with the VMM community, you can publish your patch in the VMM MODS forums. Such user-contributed modifications will use the same support model as the one used by phpbb. As the MOD author, you are responsible for all support. The VMM MODS forums on VMM Central can be used as a support and distribution meeting point. Simply request that a MOD-specific forum be created in the VMM MODS forum group. You can then announce new versions and users can request support on that forum.

We only ask (but cannot require) that you publish your MOD under the same Apacahe 2.0 license that VMM is published under. MODs that prove to be popular and stable (and backward compatible!) will eventually be merged into the Synopsys VMM Open Source distribution (with proper credit given to the original author(s) of course).

One of the issues with open-sourcing, is that everyone gets to see the code you write.

So now that you have had the chance to look at the VMM source code, you probably have noticed what a former co-worker once described as “a compulsive use of “this” in method implementations“. Why is it that I indeed compulsively use “this” whenever I refer to a data member in a class? As with every coding guideline, there are pros and cons. This one is no exception.

First of all, a bit of background, for those of you who may not be familiar with “this”… Those of you who are, can skip forward…

When referring to a variable or function/task that is declared as a member of a class from within that same class, you can prefix the reference with “this.”. For example:

class packet;
bit [47:0] da;
function new(bit [47:0] da);
this.da = da;
endfunction
function void display();
$write("DA = %h\n", this.da);
endfunction
endclass

“this” is an implicitly defined handle to the object instance that is executing the procedural code. In the constructor of the above example, “this.da” is an explicit reference to the “packet::da” variable contained in the class. Using the “this.” prefix makes it clear that I am not referring to the “da” argument. In this case, the use of “this.” is not optional as it is needed to differentiate between the constructor argument and the data member. It also avoids having to come up with different names for the constructor argument and data member when in fact they both represent the same thing.

I choose to use the “this.” prefix even in cases where it is clearly optional. For example, in the “packet::display()” method, because there are no other variables named “da” in the scope of the function, it would be clear that a simple reference of “da” would refer to the packet::da variable.

I always use the “this.” prefix to document that the variable or method referred to is a member of the class and not some variable/task/function inherited from some larger scope. In the simple example above, it is easy to see that the “da” variable is a class data member. But what if the procedural code making use of the “packet::da” variable and the declaration of that variable where separated by several dozens — or hundreds — of lines? What if they were in different files? Consider the code below. Using “this.”, despite being option, clearly document the nature of the “stream_id” and “fcs” variables.

class bad_frames_in_stream_0 extends eth_frame;
rand bit is_bad;

constraint some_bad_frames {
if (this.stream_id == 0 && this.is_bad) this.fcs != 0;
}
…
endclass