Specman Verification
Verification engineer? Verifigen has the right project for you!
New scoreboard tutorial & personal blog 
Monday, November 20, 2006, 08:49 AM - Hardcore verification
My girlfriend is back to Israel, and you, my dear anonymous readers, are the great winners! Over this weekend I've finally got to rewrite my Specman tutorial outdated chapter on scoreboards. Its not yet complete, but the crucial 80% are there. So hurry up and check it out right here.

Also, you can now venture into my personal blog. Be warned though that this is not for the feint of heart...

enjoy
  |  permalink
A white space is not an option! 
Wednesday, October 25, 2006, 07:24 AM - Hardcore verification
All you macro beginners out there pay attention! This entry is guranteed to save you at least one hour of cursing Specman in front of your screen...

Let's say that you define the following useless macro:

define <abs'action> "abs <x'name> <y'num> " as {
<x'name> = (<y'num>>0)?<y'num>:(-1)*<y'num>;
};

Then Specman will give you the following error:

"The match string can never be matched since there are white spaces at either end of the string"

and if you insist on using your macro: 

extend sys {
   post_generate() is also {
      var x : uint;
      abs x -5;
      print x;
   };
};


Specman will show that it is consistent, and issue the following error:

"unrecognized action: abs x -5"

which will probably be enough to make you delete that trailing space...

So far no surprises...but now lets assume that you have defined another useless macro, this time with an optional parameter:

define <set_max_x_y'action> "set_max <x'name> <y'num> [<z'num>]" as {
<x'name> = max(<y'num>,<z'num|0>);
};

then, if the macro is used with the optional parameter you won't have a trailing space and you will have a match. However, if you decide to use it without the optional parameter, then once again you have a trailing space, and nothing will match. This is in line with the behavior described above, with the major exception that this time Specman won't bother to tell you why your macro call doesn't match. So, unless you've read this entry, you will find yourself wondering why the second macro call in the example below, fails: 


extend sys {
   post_generate() is also {
      var y : int;
      // next line will be matched because there is no trailing space
      set_max y 7 8;
      // next line will give an error because without the optional parameter, you have a trailing space
      set_max y 9; 
      print y;
   };
};


To fix this, and to make your macro match both calls with an optional parameter and without an optional parameter, just change the match string as shown below:

"set_max <x'name> <y'num>[ <z'num>]"

And if I saved you an hour feel free to use it to send me a thanks email...
  |  permalink
Make your “check that” perfect using this simple macro! 
Thursday, October 19, 2006, 01:59 AM - Hardcore verification
Most of you who write scoreboards/checkers are probably acquainted with the “check that” construct. Personally I like this construct a lot. I have found out that it makes scoreboards code more readable, both for others and for me (when I’m back to some code I wrote after several months). When you are using that construct, it’s easy to tell what you’re actually looking for. Everything would have been perfect if it wasn’t for one major shortcoming of the “check that” construct…seems like people who thought it up, never imagined a case where you would like to build a “gradual scoreboard”, in which some checks are executed only if those before them succeed, and are skipped otherwise. For example, when you’re checking that two packets are the same, it makes sense to first check that the structure or the kind of the two is identical, and only if that is the case, proceed to check the data itself. So, the data is checked only if the structure is identical. If you’re planning to use your scoreboard with check-effect set to WARNING and not only to ERROR (and you’d better do, because sometimes people would want to skip a specific bug), then such “gradual checking” becomes mandatory, or otherwise you would get 10 warnings for every single error…To work gradually with check that you need to write something like that: 

check that received_packet.kind == expected_packet.kind else
dut_error("..");

if (received_packet.kind == expected_packet.kind) then {
  // do some further checks
};

Which is definitely annoying because the condition to be checked must be written twice…

To rid you of this nuisance, here is a simple macro that makes it possible to do it all in one line: 

define <check_continue’action> "check that <condition’any> else <error’any> continue <continue’block>" as {
  check that <condition’any> else <error’any>;
  if <condition’any> <continue’block>;
};

And now you can have it all in a better looking way: 

check that received_packet.kind == expected_packet.kind else
dut_error("..");
continue {
  // put further checks here
};

Cool, nes’t-ce pas? (a hommage to my french colleagues here in Sophia)

More hot macro stuff to follow soon…

  |  permalink

Back Next