General Description: When I use DDR for Data, glitches appear on the output. When I use DDR to forward the clock, the clock will arrive outside the device before the Data. Both of these errors in the simulation are a result of a bug that affects the way the delays are annotated for the MUXDDR.
Consider an example in which TRCE reports a delay of 1.875 ns (Tiockp) from the register to the output using DDR.
The data goes through the following components: X_SFF X_MUXDDR X_BUF_PP X_OBUFTDS
This delay is modeled as follows: Clock-to-out of X_SFF -> .493 Input port delay on X_MUXDDR -> .267 Delay through X_MUXDDR -> 0 Input port delay on X_BUF_PP -> 0 Delay through X_BUF_PP -> 0 Input port delay on X_OBUFTDS -> .209 Delay through X_OBUFTDS to pad -> .905 = 1.874 (Expected delay)
However, in order to model the MUXDDR, the MUXDDR must also have clock inputs. To synchronize the delays, the clock-to-out delay (.493 ns) of the register is placed on the clock input port of the MUXDDR. By doing this, the data from the register should arrive at the MUXDDR with the clock. However, .267 ns is also on the data input port of the MUXDDR. This causes the data to lag behind the clock by .267 ns. When the clock arrives at the MUXDDR, it switches the output, and a .267 ns glitch can appear on the output.
When a clock is forwarded, the register outputs are constant, so the clock-to-out delay of the register and the port delay on the data input of the MUXDDR do not delay the clock. The clock is only delayed by the port delay on the clock input of the MUXDDR and the delays on the OBUFTDS. This means that the clock arrives at the output .267 ns early.