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

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)

First DATE with JL

Several days ago I wrote that I will be manning Mentor�s OVM booth, but as all the attractive singles that came looking for me soon found out, this was only a vicious trick to attract them to our stand. In fact, someone in Mentor�s intricate administrative hierarchy made a mistake, which I only found out about yesterday. This means I had all the time in the world to wonder around the relatively empty stands in the relatively small exhibition area, and to collect all sorts of shiny papers and cheap gifts. Most of the sales people behind the stands were eager for some activity so even the shortest eye contact meant high risk of getting a lengthy lecture, most probably about a product that is in no way related to anything I did or will ever do. I got one such talk from the very nice guys at the Cypress desk, who showed me different kinds of cool gadgets that could be implemented with their mixed signal FPGA, among which a smell detector that could tell you the directions to an open bottle of Vodka, and a shoe whose sole fits itself to the terrain. Too bad they had only me as an audience for this quite impressive show�

Johann Notbauer from Siemens in Wien gave a talk that is worth mentioning about a testbench written using the, meanwhile defunct, AVM. On the whole, he was quite positive about it and claimed that at the moment it was a good solution for verification of small-medium size blocks, which are often still verified using directed tests. This could happen even with companies that have access to, say Specman (such as Siemens), only because writing a full blown coverage driven testbench in this �strange� e language for a small block, is regarded as an overkill by many designers. Johann thinks the AVM, written and used with the �designer friendly� SV, and being run using the very same tool, has a big advantage here.

The single thing he didn�t like about the AVM was the complexity of connecting testbench parts. I remember that in my pre-Mentor days I used to not quite like this part as well (but of course I love it now :-)). He found it too complex, and it in fact is � a bit too verbose, a bit too difficult to debug, and quite confusing. Even after a year with AVM I still found it difficult to connect ports, exports, imps and fifos in the right way. I think I�m in the process of figuring it all out, and when I do, I will publish some quick tutorial right here. Those of you who experienced the same problems with AVM will be probably happy to hear that the OVM went a long way in simplifying this part. Still, it is not the easiest in the world and does take some time to grasp. Hopefully later versions will make it even more straight forward. I promise I�ll be pushing for that�

But the highlight of the day, was of course my meeting with JL. We have talked on the phone and emailed a lot before, but we�ve never met face to face. I was quite happy to find out that JL is a very cool and friendly guy, that doesn�t put any airs because he hangs out with the biggest verification hot-shots, and the EDA world stars. We had a long interesting talk about blogging, Verilab and life in general, and he even paid for my coffee at the end. Now, that�s what I call a real successful DATE :-)

VMM vs. OVM on coolverification

JL has got an interesting, somewhat heated discussion regarding the pros and cons of VMM vs. OVM going on at his place. It has attracted considerable amount of attention from various verification celebs and is sure worth a look.

JL makes the claim that the initiative in SV verification is not in the hands of Synopsys anymore: Synopsys got stuck on the proprietery VMM for too long, and therefore lost its cutting edge position to the more advanced and open-source OVM. Personally I think he's right but having no real hands-on experience with VMM I believe my opinion is not very well informed. As I'm going to be wearing an OVM shirt and manning Mentor's OVM booth at the DATE next week (say hello if you're passing by!), there are chances that it is biased as well.

Having nothing clever to say about the present, let me turn my attention to the future. An interesting question for me is whether the OVM will benefit from Synopsys joining in. Obviously, the OVM alliance doesn't mean Mentor and Cadence are not bitter competitors anymore. The competition is also reflected in the OVM, where in some domains, a Cadence flavor and a Mentor flavor exist. Although I believe that sooner or later technical common sense (backed up by powerful cleints) will prevail, and one of the flavors will be dropped, this process could probably go faster if a "responsiple adult" is present in the room as well. In that sense, I think Synopsys presence might be good news. On the other hand, it might also result in having a third "Synopsys" flavor, which might make the OVM an empty shell.

SV tutorial and personal news

Thanks to continental airlines and a six hour delay on my flight to Portland, I've finally got to start my SystemVerilog tutorial. Not a lot there at the moment, but hopefully I'll soon have some other delayed flights...

Full disclosure: Last month I've switched from Verilab to Mentor Graphics. Although I intend to keep this blog as objective as before, and even leave its name and domain intact, readers are warned, so that they take subsequent information, with as many grains of salt as they want.

OVM is finally released

http://www.ovmworld.org/

Didn't have a chance to look at it yet. Feel free to comment if you did.

How to return an array from an SV function?

Here's a code snippet I should have posted already some time ago. It shows you how you can return an array from an SV function. It runs with Questa 6.3c, but not with NC 6.2 that still doesn't support this feature (and many many others, if I may add). Have a look first, and then we can discuss it shortly:

typedef int int_array5[5][5];
typedef int int_array[][];
typedef int int_q[$][$];


module top;
   int a[5][5];
   int b[][];
   int c[$][$];

   // The obvious way doesn't compile
   //function int[5][5] d(int arr5[5][5]);
   //   return arr5;
   //endfunction

   function int_array5 d(int arr5[5][5]);
      return arr5;
   endfunction // d

   function int_array e(int arr[][]); 
      return arr;
   endfunction // d

   function int_q f(int q[$][$]);
      return q;
   endfunction // d

   initial begin
      void'(d(a));
      void'(e(b));
      void'(f(c));
   end
endmodule

The SV standard shows how you can pass an array argument to a function at section 5.8 under "arrays as arguments". Great. However, at least as far as I could tell, it is silent about arrays as return values. The obvious way shown above simply does not compile, which is why it is commented out.

You might ask yourself if this clumsy typedef trick is really the standard way, or just a workaround some SV feature that is still unsupported by Questa. I believe, and please correct me if I'm wrong, that the clumsy way is the standard one. The SV formal syntax BNF at annex A of the standard, which I usually do my best to avoid, says that a function return type is defined as:

data_type_or_implicit ::=
integer_vector_type [ signing ] { packed_dimension }
| integer_atom_type [ signing ]
| non_integer_type
| struct_union [ packed [ signing ] ] { struct_union_member { struct_union_member } }
{ packed_dimension }
| enum [ enum_base_type ] { enum_name_declaration { , enum_name_declaration } }
| string
| chandle
| virtual [ interface ] interface_identifier
| [ class_scope | package_scope ] type_identifier { packed_dimension }
| class_type
| event
| ps_covergroup_identifier
| type_reference

Compare this with the definition of a function argument, and you�ll see that the �variable_dimension� part which exists below, is missing above:

tf_port_item ::=
{ attribute_instance }
[ tf_port_direction ] [ var ] data_type_or_implicit
[ port_identifier { variable_dimension } [ = expression ] ]

So, you can�t put a �variable_dimension� for the return argument, but you can do it for arguments you pass. For the return arguments, therefore, you don�t have a choice but to use a typedef (the option type_reference above).

And now you know why I do my best to avoid this BNF part�