Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /home2/aefody/public_html/specman-verification.com/scripts/sb_utility.php:873) in /home2/aefody/public_html/specman-verification.com/index.php on line 11

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home2/aefody/public_html/specman-verification.com/scripts/sb_utility.php:873) in /home2/aefody/public_html/specman-verification.com/index.php on line 11

Warning: strpos(): needle is not a string or an integer in /home2/aefody/public_html/specman-verification.com/index.php on line 71
Tips for HVL and HDL users with special emphasis on Specman-e, SystemVerilog and Questa
Specman Verification
Verification engineer? Verifigen has the right project for you!
"We've always been at war with Eastasia" 
Thursday, August 16, 2007, 02:01 PM - The verification hood
We all thought Mentor and Cadence were bitter rivals, but that was all just a brilliant trick to outsmart Synopsys and put it offguard. Read the latest dispatch on the subject from the Ministry of Truth...

When you're done you might feel like shooting the breeze and discussing the winners and losers from this deal. Here's what went through my head in the first few seconds:

Mentor : the big winner. They made a very smart move with their open source AVM and now they are picking up the fruits. The AVM is a good start, but is not yet mature enough to convince customers to migrate. With Cadence's stamp on it, it will look much more tempting.

Cadence : are risking their Specman market share, for a better position in the SystemVerilog race.

Me : Not too bad as well. With Cadence inside I'm sure OVM is going to become more Specman-like then the AVM, which is good, because I do believe that when it comes to methodology, nobody has managed to do as good as Specman so far. Hopefully, with joint forces, they will...

Feel free to add your unqualified remarks and wild guesses to mine. It will make a good laugh one year from now...
  |  permalink
SV enumerated types riddle 
Thursday, August 9, 2007, 12:56 PM - The verification hood
The SV standardization committee awards 50 bucks to anyone who can predict the output of the code snippet below:

typedef enum int {c=2, b=1, a=0} upside_down_t;

module x;

   initial begin

      upside_down_t upside_down;

//$display("upside_down.first() = %d",upside_down.first());

//$display("upside_down.last() = %d",upside_down.last());


      for (upside_down = upside_down.first(); upside_down <= upside_down.last(); upside_down = upside_down.next())




output :

No, I haven't forgot it. This code will print nothing. Why? basically because the highest value of the enumerated type is defined first. Confused? uncomment the $display statements and things will become clearer:

output :

upside_down.first() = 2
upside_down.last() = 0

So, here's what happens: The first value of the enumerated type is not the one with the lowest integer value, but the leftmost one in the definition. Accordingly, the last value is the rightmost in the definition, and not the one with the highest integer value. The following expression, calculated according to the integer values, is therefore false:

upside_down.first() <= upside_down.last()

und the loop is not executed...

And of course the standardization committee gets to keep its 50 bucks :-)

  |  permalink
Bit slicing in SV 
Monday, August 6, 2007, 04:12 PM - Hardcore verification
Is done using the creative syntax shown below:

module x;

  initial begin

      int a = 7777;

      int i = 3;

      int j = 5;



      $display(a[i+:3]); // That's the way to do it

      $display(a[j-:3]); // will work as well

      //$display(a[i:j]); // compilation error because i and j must be constants



so a[i:j] which anyone in his right mind would expect to work, does not. The only way to get a slice that (partially!) depends on a variable is using the a[i+:c] or a[i-:c] syntax, where c is a constant expression. For more details read the section titled "indexing and slicing of arrays" in the SV standard (5.4).

If, just like me, you're not happy with any solution that doesn't give you a complete run-time freedom to determine the bounderies of your bit slice, than feel free to copy and paste the two functions below wherever you want (compiled and checked with Questa 6.3a - a bit longer then you'd expect because I had to work around some small bugs):

parameter max_vector_size=32;

function automatic bit[max_vector_size-1:0] get_bit_slice (bit[max_vector_size-1:0] vector, int lower, int upper);   

   get_bit_slice = vector << (max_vector_size-1-upper);

   get_bit_slice >>= (max_vector_size-1-upper);

   get_bit_slice >>= lower;


function automatic void set_bit_slice (ref bit[max_vector_size-1:0] rh_vector, input int lower, int upper, bit[max_vector_size-1:0] lh_vector);

   bit[max_vector_size-1:0] result;

   result |= get_bit_slice(rh_vector, 0, lower-1);

   result |= (get_bit_slice(lh_vector, 0, upper-lower) << lower);

   result |= (get_bit_slice(rh_vector, upper+1, 31) << (upper+1));

   rh_vector = result;


module test;

   initial begin

      bit[31:0] x = 32'hdeadbeaf;

      bit[31:0] y = 32'h1234567; 

      int upper = 7;

      int lower = 4;

      bit[31:0] slice;

      $display("%h", get_bit_slice(x, lower, upper));

      slice = get_bit_slice(y, lower, upper);

      set_bit_slice(x, lower, upper, slice);

      $display("%h", x);



Thanks to Dave Rich for his help with the code, and to James Keithan for his help with the debug on Questa.

Update: Thanks to Qiang from the comments below for his bug fix
  |  permalink

Back Next