IOPLL simulation model pitfall: delta cycle delays vary between clock outputs

[roeekalinsky]

The following pertains to the IOPLL simulation models for the Arria 10, Cyclone 10 GX, and Stratix 10, at a minimum (and possibly others I've not yet tested).

I've noticed that the number of delta cycles of delay to the rising edge of a given clock output varies as a function of the configuration of the frequency divider counter of that clock output and other configuration parameters. The fact that the models exhibit some delay of a few delta cycles is expected and is not a problem, but the fact that it varies is problematic.

The problem arises when we use a PLL to generate multiple clocks (perhaps of different frequency ratios and/or duty cycles) that are phase-aligned with each other, i.e. with rising edges occurring at the same time, with the intent of treating them as a group of synchronously related clock domains. As a result of the variation in delta cycle delays in the IOPLL simulation model, different clock outputs can end up having different amounts of delta cycle delays, which puts them out of alignment with each other in simulation. And this misalignment, even if only by mere delta cycles, can then alter the simulated functionality of RTL logic downstream where there are synchronous clock domain crossings between these clocks.

As a specific example, say we have two clock domains A and B generated by an IOPLL, and due to the variability in the IOPLL simulation model, clock domain B ends up with a longer delta cycle delay than clock domain A. Now in RTL logic, a signal originating at a register in clock domain A is re-registered into clock domain B, a simple synchronous clock domain crossing. But as a result of the delta cycle mismatch, in simulation the signal may get registered in clock domain B one clock cycle earlier than it would if the clocks were properly phase-aligned. In other words, the signal will go from reg A to reg B in just those few delta cycles and zero time, instead of taking a clock period as it should. This of course is just a simulation artifact, and will not occur on the hardware. And that makes it a particularly insidious issue, as it opens the door to mismatch between simulation and hardware reality.

This subtle yet insidious issue could be completely avoided if the IOPLL simulation model was designed more carefully to ensure that all clock outputs exhibit the same number of delta cycles of delay.

For now, with the IOPLL simulation models as they are, I have devised a quick and dirty workaround on the user end, though I don't particularly like it. One can take the clock outputs from the IOPLL and further delay them by a small increment of actual time, e.g. 1 ps, before passing them along to the RTL logic downstream. By adding an actual time delay (i.e. not a delta cycle delay!), one can effectively mask the differences in delta cycle delays, as all clock edges will then be delayed to the first delta cycle of the later instant of time. Now, adding a 1 ps delay in RTL is of course not a synthesizable construct, and will simply be ignored in synthesis, which does yield the "correct" desired result... Though embedding stuff like that in synthesizable RTL is highly cringe-worthy, as it too opens the door to mismatches between simulation and hardware reality if not extremely careful. And of course one must also ensure that adding this 1 ps delay won't cause any other ill effects in simulation. So.... a workaround, yes, but ugly, far from ideal, and itself fraught with potential pitfalls.

I would strongly encourage Intel/Altera to correct this issue in the IOPLL simulation models by making the simple improvement such that the models produce their clock outputs with a consistent non-varying number of delta cycles of delay. That way, the IOPLL simulation models won't induce potentially misleading simulation artifacts, and won't make it necessary for us users to pollute our own RTL with ugly workarounds to avoid this pitfall.

Thanks,
-Roee

[Ash_R_Intel]

We have received your valuable input for future enhances. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.