An associative array element that accesses the comb through serial
I was trying to write a test bench that used an associative array and saw that in one case accessing its values did not work like comb logic, but when it was traversed within a sequential block it worked fine.
Sample code:
Here "value" was always assigned as "x", but as soon as I moved it inside the @posedge block I saw that it was assigned the correct value (1 time after assigning "dummy").
Can someone explain why this is the case?
logic dummy[logic[3:0]];
logic value;
always @ (posedge clk)
begin
if (reset == 1'b1) begin
count <= 0;
end else if ( enable == 1'b1) begin
count <= count + 1;
end
if(enable) begin
if(!dummy.exists(count))
begin
dummy[count] = 1;
$display (" Setting for count = %d ", count);
end
end
end
always_comb begin
if(dummy.exists(count)) begin
value = dummy[count];
$display("Value = %d",value);
end else begin // [Update : 1]
value = 0;
end
end
[UPDATE: 1 - updated code for blocking else]
The question is a bit misleading, in fact if (dummy.exist (count)) seems to fail when used inside comb logic, but gets through when inside seq logic (and since no value is ever assigned in this module) value ", it goes to" x "in my simulation, so edited with an else block), but this result was on the VCS simulator.
EDA-playground link: http://www.edaplayground.com/x/6eq - Here seems to work fine as expected if (dummy.exists (count)) passes no matter what's inside always_comb or always @ ( posedge)
Result in VCS: [when used as comb logic - value is never printed]
Value = 0
Applying reset Value = 0
Came out of Reset
Setting for count = 0
Setting for count = 1
Setting for count = 2
Setting for count = 3
Setting for count = 4
Terminating simulation
Simulation Result : PASSED
And the value is printed as "1" when if (dummy.exist (count)) and the assignment move inside the seq block.
source to share
Your first always block contains both blocking and non-blocking assignments that VCS can allow, because the always keyword is used to specify combinational logic in verilog (via always @ (*)). This shouldn't account for the error, but that's bad style.
Also the first line of your program is weird, what are you trying to indicate? The meaning is not much, but the dummy is not, so if you try to make the dummy [count] = 1'b1 you will also pop up an error (turn on linting with + lint = all). If you are trying to make a dummy array that is 4 bits long, your syntax is off and then the value will be the wrong size.
Try toggling the first always to explicit always_ff, that should give you a warning / error in VCS. Alternatively, you can always look at the waveform, compile with define + VPD, and use gtkwave (freeware). This should allow you to see exactly what is going on.
source to share
Please check the compile message VCS
and see if there is any warning related to the SV new instruction always_comb
. Some simulators may have design problems or do not support this usage when you deduce "dynamic types" in the sensitivity list. I've tried with Incisiv (ncverilog) and that's ok too.
source to share