AR# 15828


5.1isp1 Timing Simulation, NGDAnno - Delays for the MUXDDR are not annotated correctly


Keywords: Timing, Simulation, NGDAnno, SDF, DDR, MUXDDR, Tiockp, glitch, clock, forward

Urgency: Standard

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:

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.


This problem is fixed in the latest 5.1i Service Pack, available at:
The first service pack containing the fix is 5.1i Service Pack 2.

This was fixed by making the .267 ns delay a clock-to-output delay on the MUXDDR rather than an input port delay on the MUXDDR.
AR# 15828
Date 08/11/2005
Status Archive
Type General Article
People Also Viewed