CODEWITHSUNDEEP
associative-arraysystem-verilog
IonThruster
IonThruster

Reputation: 33

Associative array element accessing in comb vs sequential

I was trying to write a test-bench code which used an associative array, and was seeing that in one case accessing its values wasn't working as a comb logic, but when moved inside a sequential block it was working fine.

Example code :

Here "value" was getting assigned as "x" always, but once I moved it inside the @posedge block, I was seeing it assigned the right value (1 once "dummy" got assigned).

Can someone explain why this is so ? 

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 - code updated to have else block]

The question is a bit misleading, actually the if(dummy.exist(count)) seems to be failing when used inside comb logic, but passes when inside seq logic (and since "value" is never assigned in this module, it goes to "x" in my simulation - so edited with an else block) - but this result was on VCS simulator.

EDA-playground link : http://www.edaplayground.com/x/6eq - Here it seems to be working as normally expected i.e if(dummy.exists(count)) is passing irrespective of being inside always_comb or always @(posedge)

Result in VCS : [when used as comb logic - value never gets 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 value gets printed as "1" when the if(dummy.exist(count)) and assignment is moved inside seq block.

Upvotes: 3

Views: 1242

Answers (2)

Tim P
Tim P

Reputation: 425

Your first always block contains both blocking and non-blocking assignments, which VCS may be allowing because the always keyword used to be able to specify combinational logic in verilog (via always @(*)). This shouldn't account for the error, but is bad style.

Also the first line of your program is strange, what are you trying to specify? Value is a bit, but dummy is not, so if you try doing dummy[count] = 1'b1, you'll also pop out an error (turn linting on with +lint=all). If you're trying to make dummy an array of 4 bit values, your syntax is off, and then value has the wrong size as well.

Try switching the first always to an explicit always_ff, this should give you a warning/error in VCS. Also, you can always look at the waveform, compile with +define+VPD and use gtkwave (freeware). This should let you see exactly what's happening.

Upvotes: 1

jclin
jclin

Reputation: 2559

Please check your VCS compilation message and see if there is any warning related to SV new always_comb statement. Some simulators might have issues with the construct or do not support that usage when you inferred "dynamic types" in the sensitivity list. I tried with Incisiv (ncverilog) and it is also OK.

Upvotes: 0

Related Questions