Siemens Questa simulation

[jishnuv33]

module tb;
reg phy_reset;
initial begin
  phy_reset = 1'b1;
  #10000;
  phy_reset = 1'b0;
end

initial begin
 forever
    begin
     @(posedge phy_reset);
         $display("posedge of reset");
     @(negedge phy_reset);
     $display("negedge of reset");
    $finish;
    end
end

endmodule

Hi all,I have one test bench ,the above code is just one snippet of it.The issue is that the siemens questa is not taking the event for posedge and negedge but in synopsys vcs its printing both display commands .Is there any compiler directive or any specific command to run the above test bench in siemens questa without editing the test bench(without adding explicit delta delay in test bench).Thanks in Advance!!!!

 

[dave_59]

This is a basic Verilog race condition. The two initial block processes can be started in any order. Using a nonblocking assignment eliminates the race.

 

[jishnuv33]

yes i understood.The above code just a snippet,the original is different ,the fact is that shouldn't change the file.Thanks for your reply.

 

[brucesilver]

module tb;
reg phy_reset;
initial begin
  phy_reset = 1'b1;
  #10000;
  phy_reset = 1'b0;
end

initial begin
 forever
    begin
     @(posedge phy_reset);
         $display("posedge of reset");
     @(negedge phy_reset);
     $display("negedge of reset");
    $finish;
    end
end

endmodule

Hi all,I have one test bench ,the above code is just one snippet of it.The issue is that the siemens questa is not taking the event for posedge and negedge but in synopsys vcs its printing both display commands .Is there any compiler directive or any specific command to run the above test bench in siemens questa without editing the test bench(without adding explicit delta delay in test bench).Thanks in Advance!!!!

This is likely due to zero-delay scheduling differences between Questa and VCS. In Questa, the @(posedge phy_reset); might not trigger because the event happens in the same timestep as initialization.

Try running Questa with:

nginx
Copy
Edit
vsim -novopt tb
or

nginx
Copy
Edit
vsim -suppress 12110 tb
These options disable optimizations that might be skipping the event.

If that doesn't work, you may need to introduce a tiny delay (e.g., #1 in the reset sequence, but that would modify the testbench.

 

[sky_siliconthink]

begin @(posedge phy_reset); $display("posedge of reset"); @(negedge phy_reset); $display("negedge of reset"); $finish; end

I think it may just miss the first posedge, how can the sim tool miss the second negedge?
Have you test this code in Questasim?

 

[jishnuv33]

I think it may just miss the first posedge, how can the sim tool miss the second negedge?
Have you test this code in Questasim?

yes both events are missing.

--- Updated Feb 19, 2025 ---

This is likely due to zero-delay scheduling differences between Questa and VCS. In Questa, the @(posedge phy_reset); might not trigger because the event happens in the same timestep as initialization.

Try running Questa with:

nginx
Copy
Edit
vsim -novopt tb
or

nginx
Copy
Edit
vsim -suppress 12110 tb
These options disable optimizations that might be skipping the event.

If that doesn't work, you may need to introduce a tiny delay (e.g., #1 in the reset sequence, but that would modify the testbench.

i have tried already with adding #0 delay it seems to be working but the editing is not possinble.The vsim commands are not giving expected results.Thanks

 

[SynthWorks]

@jishnuv33 Understand that @dave_59 is a Verilog Wizard. You might want to try what he suggested.

Paraphrasing what Dave already told you:
The order a simulator runs the initial blocks is different for different simulators.
phy_reset updates instantly because you are using a blocking assignment.
Hence if the first initial block is selected to run first, the posedge will be gone before the second initial block runs.
OTOH, if the second initial block runs first, it is waiting for the posedge when the first initial block changes and it sees the posedge.
Hence it runs differently on different simulators.

If you instead use a non-blocking assignment for phy_reset, it will work properly.
Alternately insert a #1 at the beginning of the initial block with phy_reset.

You can avoid issues like this by using VHDL instead. While this sort of non-determinism exists in VHDL, it is very rare.

 

[dave_59]

i have tried already with adding #0 delay it seems to be working but the editing is not possinble.The vsim commands are not giving expected results.Thanks

The code you wrote works differently from the way you expected to. The fact that VCS chose an ordering that seems to work in your case is just lucky. There might be switches that randomly change the ordering of events when they are race conditions but it will just be luck if it works out.

You might be unable to edit a particular file, but you can certainly copy it and edit that file. Then feed it to the compilation command line instead.

It irks me that people expect switches to fix buggy code instead of correcting the code at the source.

 

[ThisIsNotSam]

The code you wrote works differently from the way you expected to. The fact that VCS chose an ordering that seems to work in your case is just lucky. There might be switches that randomly change the ordering of events when they are race conditions but it will just be luck if it works out.

You might be unable to edit a particular file, but you can certainly copy it and edit that file. Then feed it to the compilation command line instead.

It irks me that people expect switches to fix buggy code instead of correcting the code at the source.

Agreed. Relying on simulator's random choice for race conditions is poor practice, instrumenting the simulator to avoid the race still is bad practice.