Tips for HVL and HDL users with special emphasis on Specman-e, SystemVerilog and Questa

Buzzword of the week: functional qualification

Yaron Ilani, a fellow blogger has posted an interesting interview with Mark Hampton, the CTO of Certess, a company specializing in "functional qualificaion. Functional qualification, I have just learned, is a new technology that introduces artificial bugs into an HDL design, to check how good your testbench is. If this sounds interesting, or if you'd just like to impress the girls in your team with your deep knowledge of the latest trends, go ahead and read some more.

A $ comes for free

It took me a while (about 1.5 year of working with SV), but I�ve just realised that dynamic arrays are just plain useless: Whatever a dynamic array can do, a queue can do much better. A queue could be resized using new[] just like an array, but it would also be resized automatically when you add an element, or a list of elements. You could use two variables to slice a queue, which you can�t do with an array, and this alone is a good enough reason to forget about dynamic arrays for eternity. And, in general, every function or language structure that would work with a dynamic array, would also work with a queue. You could also randomize queues of course.

And why did it take me such a long time to figure this out? Obviously, because no one in his right mind expects a language to have some outright redundant constructs. I was assuming that if dynamic arrays are there, then there must be some raison d'�tre, some hidden super-power that I haven�t come-across yet. Well, I guess I should have read what I�ve written some weeks ago first�Then I would have realised much earlier that the results of committee work, don�t always follow the most basic rules of common-sense.

So, the bottom line is, whenever you write something like that:

int a[];

Just go ahead and place that $ inside:

int a[$]

This dollar comes for free, and it can give back so much.

Cadence wants this website back!

Just learned that Cadence is trying to preform a hostile takeover of Mentor.

Will I soon become Cadence employee? Will "die hard" Specman survive?

Judging by this article (which makes sense for a business ignorant guy like myself), probably not...

Low standards

About a week ago a dramatic announcement has taken the verification world by storm: Accellera has started a new standardization committee dedicated to Verification IP interoperability. This committee should take the OVM, the VMM and any other existing SV methodologies as its inputs, insert some 1-2 years delay, then drive the Absolutely Complete Verification Methodology (ACVM) on its output. The exact specification of this complex committee-DUT is still TBD, but we can already take a wild guess on the output right now: It will be a class library; it will contain base classes for reporting; it will have a configuration interface; it will define ports that can be used by scoreboards; it will have a generation interface. Maybe it will define some naming conventions, directory structure and a way to deploy new versions as well. By the time output valid goes high, however, we will have plenty of OVM based IPs, VMM based IPs, ??? based IPs and many eVCs still there, and all of these would have to be interoperable with the new interoperable ACVM. A brave new world indeed.

You have to be na�ve at best or a (Synopsys) salesperson at worst, to believe that the new standard will result in better interoperability and better quality VIPs. I have a strong deja-vu feeling when I hear these talks about vendor interoperability: wasn�t it only 2 years ago that the exact same promise was used to sell SV to clients? Wouldn�t it be smarter to first make SV live to its interoperability promises, and only then move on to build another layer on top? JL has a very strong point when he puts SV interoperability as a pre-condition for any further discussion of VIP interoperability.

Why is it that SV vendor-interoperability is taking such a long time? The answer to this question hides a very important lesson for the new committee, which has not been acknowledged or learned so far. The main problem with the SV standard is in fact not vendor-interoperability, but the fact that the standard is not even interoperable with itself. Different parts of the language have almost no connection to other parts: assertions and classes, for example, seem to live on two different plants. You can�t have assertions in classes and you can�t have references to class members in assertions. The same goes for the object oriented part and the static hierarchy world � of all three static elements defined in the language (interface, module and program) not even one supports inheritance. There are more such examples but I guess you got the point.

If the SV standard is made out of so many separate non-communicating worlds, this is not because some of the best verification experts in the world got suddenly dumb when they wrote it. It is simply because these �worlds� were each separately designed by a different vendor, than donated to the committee to integrate. Assertions, classes, programs and interfaces all originated in different �donations�. These �donations� have of course nothing to do with kind hearted charity: in fact they are no more than a euphemism for �strong pressure�. Too often, their unique actual contribution is to put another obstacle in the competition�s path: why not let the competition break its head over the implementation of this thing/this crap we already have? And, of course, the first part of the standard each company implements are its own donations, because they�re already there.

Since the standardization committee is too weak and too divided to tell strong vendors �thanks, but no thanks�, the easiest way out is just to sum everything up. That�s how a bunch of loosely integrated donations ends up becoming a standard, and that�s how you get assertions and classes that can hardly communicate. In fact, even if the committee wanted to do better it probably could not, since it lacks its own independent R&D resources. This means that it simply has to relay on the donations made, and hope for no more than some slight modifications for the sake of integration at best. Even such slight modifications often encounter tough resistance because they force the contributing vendor to modify an already existing piece of code.

Since there is absolutely no reason to assume the new standard will escape the donations kiss of death, there is also no reason to believe it will be more tightly integrated than the 1800-2005. Both OVM and VMM have already been donated, and since it is quite unlikely that either Mentor/Cadence or Synopsys will agree to see their donations thrown away, what we will most probably have at the end is a sum that is less than its individual parts. It is quite likely that we will have a lot of duplicated functionality that will be kept inside only to save face in front of old customers. This duplicated functionality will mean, at the end of the day, that we will have several non-interoperable ways of doing things. Back to square one.

Is there any way out of this situation? I would say the only way out is to give Accellera some real teeth and resources. Then it will be able to delegate such standard creation to a small company of independent experts, who will sit, just like a jury, in a room with no internet connection until white smoke comes out. Since they will be paid by Accellera, they will be able to fearlessly throw away spam donations, and develop missing parts themselves.

It is quite simple: you can�t arbitrate between two competing sides if one of them is paying your salary. That�s why judges, for example, get paid by the state, right?

Randomizing an array of objects in SV

Here's another code snippet I should have added already a while ago. It shows how you can randomize an array of SV objects, without using pre_randomize or post_randomize to do any randomization at all. Why it is so important to avoid doing any randomization in these two functions, will be explained below. Before we go into that philosophical discussion, however, here's the code:

module top;
   class a;
      rand int b;
   endclass

   class b;
      const int unsigned max_array_size = 100;
      rand a obj_array[];

      constraint obj_array_size_c {obj_array.size() < max_array_size;}

      function void pre_randomize();
         obj_array = new[max_array_size];
         foreach(obj_array[j])
           obj_array[j] = new();
      endfunction
                           
   endclass

   initial begin
      b b1 = new;
      b1.randomize();
      $display("done");
   end
   
endmodule

Since SV never instantiates objects as part of the randomization process you have to instantiate an array of the maximal size at pre_randomize. SV will than randomize the size of the array, and because of the constraint that uses the size() method, will cut down your array to the new size. The objects up to the new size will be randomized, and the remaining ones will be removed out of the dynamic array, and left for garbage collection to take care of.

As mentioned above, this code doesn't randomize either the size or any of the elements at pre_randomize or post_randomize. Randomizing stuff in pre_randomize or post_randomize means that you can no longer use constraints of any kind to direct the randomization. For example, had I done this:

   class b;
      const int unsigned max_array_size = 100;
      rand a obj_array[];

      function void pre_randomize();
         int obj_array_size = $urandom_range(max_array_size,0);
         obj_array = new[obj_array_size];
         foreach(obj_array[j])
           obj_array[j] = new();
      endfunction          
   endclass

I wouldn�t have been able later to do this:

   class c extends b;
      constraint obj_array_size_eq_1 {obj_array.size() == 1;}
   endclass

Or this:

   initial begin
      b b1 = new;
      b1.randomize() with {obj_array.size() == 5;};
      $display("done");
   end

In a real life testbench such limitations mean that users won�t be easily able to direct the generator towards interesting cases and coverage holes. From this point it�s a short way to having to patch your testbench with ugly workarounds to allow them to do the stuff they want.

However, with SV, this flexibility and control come at a relatively high price. As you might have noticed, you need to know upfront the maximal size your array will have. Worse, you need to allocate a maximal size array every time you call randomize. There might be tricks to work around that limitation, such as using prtototypes and fixed size arrays instead of dynamic ones but I'll not go into those right now because I still haven�t found the perfect mix. Maybe in a few years time :-)

Many thanks to Ray Salemi From Mentor for his help with this entry.

Soft constraints in SV

For all those e veterans coding in SV and still badly missing their soft constraints, Akiva Michalson from ACE verification has wrote a small macro that would enable you to have soft constraints in SV as well. This is very convenient, and I tend to agree with Akiva when he says that it is a much nicer way than turning constraints on and off, the way some of them SV experts want us to go. Since he has a version of the macro for all the big three simulators (IUS, VCS and Questa), portability is not an issue here. I have just tried it with Questa, and you�re more than welcome to go ahead and give it a try on your simulator of choice for yourselves.

Download it here (short registration required)