I have a basic systemverilog question regarding the use of “int” and “integer” data types. I understand that both are 32-bit signed integer with “int” being 2 state (0,1) and “integer” being 4-state (0,1,x and z). Apart from the clear distinction of states which gives when to use what, are there any specific situations or cases where we MUST use “int” but not “integer” and similarly for “integer”.
My second question is which of these to use for loop variables. Is it the choice ? I wonder given these are “signed”, the recommended way of using them is with “unsigned” ?
My suggestion is that you stick with 2 state data types in your testbench unless you have a specific need to generate or propagate X or Z states. This eliminates any chance of introducing these extra states when your code has not been designed to deal with it. Performance of 2-state versus 4-state simulation is debatable, but is certainly takes more memory to represent 4-state values.
Whether a loop variable is signed or unsigned should not really matter, unless of course, you need to loop through values that only one of those choices can represent. A place you do need to be cautious about using signed types is in constraints and assertions. It is very easy for unintended negative values to pass through (e.g. you wrote “a < 3” expecting only the values 0,1, and 2 to succeed).
SystemVerilog is very relaxed (some will say too relaxed) when it comes to operations requiring 2 or 4 state types. Only when passing arguments by reference are you required to match a 2 or 4 state type.
Another place you should use int is when using the DPI-C. It is much more efficient for the DPI to pass C-compatible data types like int across the language boundary.
My suggestion is that you stick with 2 state data types in your testbench unless you have a specific need to generate or propagate X or Z states.
What about detecting the ‘x’ driven from the design. We will have logic defined in the interface to catch these. But, if we define 2-state types are we not missing on checking those x’s in the testbench.
Performance of 2-state versus 4-state simulation is debatable
Could you explain why the performance improvement is debatable. I read somewhere that 2-states do have performance benefit over the 4-state.
SystemVerilog is very relaxed (some will say too relaxed) when it comes to operations requiring 2 or 4 state types. Only when passing arguments by reference are you required to match a 2 or 4 state type
I am not sure I understood this. Could you explain why do you need to match the types when passing by ref. What problems do you have if not matched ?
Detecting X driven from the design is considered propagation, so you need 4-state variables for that.
Experiments that I have done, as well as other people, have shown little or no performance improvements when substituting bit for logic. The majority of activity in a simulation is the evaluation and propagation of single bit or byte signals, and for that it make little difference if the signals are 2 or 4 state. You will see some performance improvements with larger data widths using 2-state be cause of fewer memory accesses top perform certain operations.
When passing arguments by reference, you will get a compiler error if the types do not match.
I have a question about handling the 2-state and 4-state variables by the “inside” operator.
let’s say the LHS expression of the inside operator is a 2-state variable and the value set on the RHS is a 4-state which includes ‘X’ or ‘Z’
Now the LRM says that if the RHS contains ‘X’ or ‘Z’, it should be treated as don’t care.
But some simulators convert the RHS value set to 2-state and then do the comparison. is this the right behaviour?
example:
bit a[2:0] = 3;
logic [2:0] arr = { 0, 1, 3'b01? };
if ( a inside {arr} )
$display("true");
else
$display("false");
It would help if you provided minimal, complete reproducible example. The following code produces the same results on all 4 SystemVerilog simulators on EDAPlayground. (True)
module top;
bit [2:0] a = 3;
logic [2:0] arr[3] = { 0, 1, 3'b01? };
initial if ( a inside {arr} )
$display("true");
else
$display("false");
endmodule