It seems that dsim includes in the implicit sensitivity list of always_comb the variables declared within the block .
Consider the following simple code (I know that using nonblocking assignments in always_comb is not recommended, hower it is also not prohibited):
`timescale 1ns/1ps
module test;
logic a,b, y;
always_comb begin : my_proc
logic tmp;
tmp <= #1ps a & b ;
y = ~ tmp;
end
initial begin
$monitor ("Time=%0f, a=%b, b=%b, my_proc.tmp=%b, y=%b",
$realtime, a, b, my_proc.tmp, y);
a= 1'b1; b=1'b1;
#1ns;
a= 1'b0; b=1'b1;
#1ns;
a= 1'b1; b=1'b1;
end
endmodule
Simulation results produced by Altair DSim version: 2025.1.0 (b:R #c:449 h:df8da7d488 os:rocky_8.10) on ubuntu is:
Time=0.000000 | a=1 | b=1 | my_proc.tmp=x | y=x |
|---|
Time=0.001000 | a=1 | b=1 | my_proc.tmp=1 | y=0 |
Time=1.000000 | a=0 | b=1 | my_proc.tmp=1 | y=0 |
Time=1.001000 | a=0 | b=1 | my_proc.tmp=0 | y=1 |
Time=2.000000 | a=1 | b=1 | my_proc.tmp=0 | y=1 |
Time=2.001000 | a=1 | b=1 | my_proc.tmp=1 | y=0 |
At time 1ps, my_proc.tmp is updated and the process is executed again driving y to 0, which should not happen. Similar behaviour at time 1.001 and so on.
Simulations performed with tools on edaplayground give the correct results:
Time=0.000000, a=1, b=1, my_proc.tmp=x, y=x
Time=0.001000, a=1, b=1, my_proc.tmp=1, y=x
Time=1.000000, a=0, b=1, my_proc.tmp=1, y=0
Time=1.001000, a=0, b=1, my_proc.tmp=0, y=0
Time=2.000000, a=1, b=1, my_proc.tmp=0, y=1
Time=2.001000, a=1, b=1, my_proc.tmp=1, y=1
Similar discrepancies are observed also when the explicit delay is removed from the nonblocking assignments (mp <= a & b;).
