Possible Data Transfer Anomaly
Ammie2 opened this issue · comments
Hello,
I encountered an inconsistency issue during the compilation and simulation process using Iverilog.
I merged some statements representing inertial delays in the stimulus file to simplify the code. Due to simulation characteristics, inertial delays are not detected, and merging them does not affect the results. However, during actual operation, the simulation results after merging inertial delays show inconsistency.
The results are displayed as follows:
Figure 1. Results after merging.
Figure 2. Results before [merging.]
The file "syn_identity.v" in the attachment "project.zip" is the design file, "identity_testbench.v" is the stimulus file after merging inertial delays, and "identity_testbench_mts.v" is the stimulus file before merging.
project.zip
Looking forward to your response.
This appears to be a repeat of #884. Are you the same person, and if so, why are you using a different user name?
In any case, the answer is the same as in #884. Closing as a duplicate.
I'm not the person you mentioned. I've been studying about inertial delays. These delays are defined as follows: when the pulse width of an input signal to a component is less than a certain value ‘p’, the component's output does not respond. Inertial delays are commonly used to simulate such practical situations. If needed, I can provide a simple example.
I've looked at #884, and the situation described there is similar to mine, but there's no solution provided.
Feel free to reopen this issue if you can provide a simple test case that demonstrates a bug in Icarus Verilog.
Thank you for your prompt response. I have prepared a simple test case. This time I've provided a simple example. From the result graphs, it can be observed that the waveform of the value C remains unchanged. However, in Graph 1, there is a waveform change in A at 17ns and it persists for 3ns, which does not affect the value of C. Graph 1 corresponds to the waveform result of the testbench_mts.v stimulus file before merging delays, while Graph 2 corresponds to the waveform result after merging delays using the testbench.v stimulus file. The example.v is the simple design file. The same principle applies to the files I provided earlier, but different results were obtained.
Graph 1: Waveform before merging delays
Graph 2: Waveform after merging delays
I hope the information I provided helps you understand. Looking forward to your response.
example.zip
This is expected behaviour, as defined by the IEEE standard. From IEEE 1364-2005 section 6.1.3
In situations where a right-hand operand changes before a previous change has had time to propagate to the
left-hand side, then the following steps are taken:
a) The value of the right-hand expression is evaluated.
b) If this right-hand side value differs from the value currently scheduled to propagate to the left-hand
side, then the currently scheduled propagation event is descheduled.
c) If the new right-hand side value equals the current left-hand side value, no event is scheduled.
d) If the new right-hand side value differs from the current left-hand side value, a delay is calculated in
the standard way using the current value of the left-hand side, the newly calculated value of the
right-hand side, and the delays indicated on the statement; a new propagation event is then sched-
uled to occur delay time units in the future.
So in your first example, A changes to 0 at t=17ns. This schedules a change to C at t=22ns (due to the 5ns delay in the continuous assignment to C). But A changes to 3 at t=20ns As per rule (b) above, this causes the existing change to C to be descheduled, and a new change to C to be scheduled at t=25ns.
This is an inertial delay. If you want to model a transport delay, you should use a non-blocking assignment like this
always @* C <= #5 A + B;
Thank you for your response. I tried the commands you suggested and observed that in this scenario, the simulator accepts data changes within the delay time frame, where input changes within this window are entirely reflected in the output. This seems to resemble simulated propagation delay: the time it takes for a change in the input signal to result in a corresponding change in the output signal. However, my concern lies in the comparison between two similar operations: in a simple example I provided, merging delays results in an unchanged value for 'C', whereas in the initial case I presented, merging delays lead to changes in 'y'. I'm puzzled by why these seemingly identical operations yield different outcomes. Could it be that there are internal operations within Icarus Verilog (iverilog) that handle delays inappropriately? I'm wondering if you could shed some light on this matter. I hope my inquiry is clear, and I would greatly appreciate your insights.
@martinwhitaker hi here I really appreciate for your support and answer of my questions. But this issue is not discovered and reported by me. I have checked this question and i do not thinks it is a valid operation. So if there cases always exist in Issues branch it will be not my business.
Finally i wana to share my appreciation for your support and wish Iverilog will be more and more Complete