09-30-2016 06:22 AM
Events (e.g. resetting of a counter) that occur at a particular clock edge in post-implementation functional simulation occurs at the following edge in the post-implementation timing simulation. Request comments around the possible reasons.
10-02-2016 05:18 PM
Almost certainly this is due to the input stimulus.
In a zero time simulation, the rising edge of the clock at the pin of the FPGA is the same time as the rising edge of the clock at every flip-flop inside the design (unless you are using an MMCM/PLL which is intentionally creating some time delay). This includes the flip-flops that first sample incoming inputs and the flip-flops that generate outputs.
In a back-annotated timing simulation, the propagation of the clock inside the FPGA is significant. Depending on your clocking scheme (if you are using an MMCM/PLL to deskew the clock), the rising edge of the clock at the internal flip-flops can be significantly after the rising edge of the clock at the pin, or even before the rising edge of the clock at the pin (due to clock deskewing by the MMCM/PLL). In addition, the insertion delay of the data (through input buffers and any possible combinatorial logic) are also non zero. The timing of these paths, along with the application time of your inputs, determine which edge of the clock will sample which set of input data.
If your input signals (at the pins) change right at or very near the rising edge of the clock at the pin, then the behavior of the system can easily be different in the zero time and full timing simulation.
If you really want to do this right, you need to ensure that the input stimulus at the pins of the FPGA is the same as what it will be in the real system. This, of course, assumes that you have designed your input interfaces properly
- chosen a proper clocking scheme
- constrained your inputs with proper set_input_delay and set_output_delay commands
- ensured that the design meets timing with these constraints
If you do all of this, then the behavior of your timing simulation will be "correct" - consistent with what it is in the "real system".
Even with all this, though, the behavioral simulation may not match - you may need to modify the timing of your input signals and the sampling of your output signals to be consistent with the "cycle accurate" simulation you are performing.
10-03-2016 03:43 AM
It was an observation mistake. The event corresponding to the previous edge was occurring so close (but prior) to the current edge that I mistook it as occurring at the current edge. Thanks a lot.