CVCBLR's VoW blog - Verification on the Web!

SystemVerilog adds $urandom – a simple random number generator that returns a 32-bit UNSIGNED integer. Contrast it to good old $random – returns a 32-bit SIGNED integer. Consider the below code snippet: integer address; initial begin : b1   address = $urandom;   $display (“%m address: %d”, address); end : b1 When you run the above code in Questa, one in a while you get: # address = 90095195; # address = -949724053; First sight it looks strange, why is $urandom generating a negative number? Bug in the tool? Crazy? (See a real user post at: http://goo.gl/yp0WZ ) A bit of thinking, taking eyes away from monitor screen would help – follow your basics on digital arithmetic: integer – a signed 32-bit number (in Verilog) i.e. holds−2 ( n −1) through 2 ( n −1) −1. (2’s complement representation) So if you assign even a 32-bit UNSIGNED number with the MSB set to 1 – it will be treated as “signed 31-bits” Hence –> $urandom does generate 32-bit UNS...

Sparse arrays in general (in many computer languages) exhibit ‘allocate-on-the-go” behavior. System Verilog is no exception. During today’s VSV training at CVC we had some interesting discussion on this topic. SV assoc-arrays get allocated on-the-go, while it is well known and talked about fact – it is clear for the “write” to array. What about “read”? For some early stage users it is not so obvious that a $display is a reader as well. Consider the following piece of code (full code later): logic [7:0] logic_aa [int]; initial   logic_aa[20] = 121; In the above code the 21st location gets allocated OTG, clear. What about the following? logic [7:0] logic_aa [int]; initial   $display (“%m CVC: read AA: “, logic_aa[20] ); What would you expect? Error? Or allocate OTG? Hold your answer, let’s see full code: Any guess? Well, the $display on an un-allocated assoc-array element is a reader too, hence gets allocated OTG (On-The-Go), default val...