In reply to dave_59:
I have seen that there was a problem with the sum (WWW.TESTBENCH.IN - Systemverilog Randomization) and to be safe you had to use:
“with (item+32b’b0)”. That is to say, you had to sum a zero value of 32 bits to force a casting with the intern item in the sum loop. See below
rand int arr[];
constraint c_arr{
arr.size() < 10;
arr.sum with (item+32b'b0) inside {[1:1000]); // if you want a positive result
foreach(arr[i]) arr[i] inside ([0:1000]};
}
Now, i see that in your example you will not have problems because the type of arr is int arr; which is already 32bits, and the sum will not be saturated.
Cut/Saturating means that, when the sum overflows the bitwidth for your local sum constraint variable (in your example arr) then this is not seen by the sum constraint because the sum in the internal constraint will be cut and will only compare with the constraint the “bits cut”/bitwidth defined by your local variable,
e.g.
rand logic [1:0] arr[];
constraint c_arr{
arr.size() < 10;
arr.sum inside {[1:1000]); // WRONG SUM constraint in case
//This is wrong because if constraint solver tries a combination that sums e.g. 16='b10000, then constraint solver will see only the LSB 2 bits due to the logic[1:0] arr[] type 16='b100**00**=>2'b00=0 and will think that was a valid combination for your constraints since "0" meets constraint: arr.size() < 10;
//arr.sum with (32'(item)) inside {[1:1000]); // if you want a CORRECT constraint
foreach(arr[i]) arr[i] inside ([0:1000]};
}
converting the item variable in 32bits (or more) ensure that all sum possible combinations tried by the constraint solver will be seen correctly by the constraint solver (<10) ).
Lastly, if you are interested on dynamic array constraints you can see the following post.
https://verificationacademy.com/forums/systemverilog/constraints-dynamic-array#answer-58425