Deskew Clock on Synchronous Bus

I am having difficulties in trying to deskew the Clock on a synchronous local bus interface between a Virtex4 FPGA and a PowerPC chip.

The instantiation port map of a DCM to provide 0 phase-shift between the external LCLK_IN and the internal CLK is shown below.

--------------------- port map ( CLK0 => CLK, -- 0 degree DCM CLK ouptput CLK180 => open, -- 180 degree DCM CLK output CLK270 => open, -- 270 degree DCM CLK output CLK2X => open, -- 2X DCM CLK output CLK2X180 => open, -- 2X, 180 degree DCM CLK out CLK90 => open, -- 90 degree DCM CLK output CLKDV => open, -- Divided DCM CLK out (CLKDV_DIVIDE) CLKFX => open, -- DCM CLK synthesis out (M/D) CLKFX180 => open, -- 180 degree CLK synthesis out LOCKED => open, -- DCM LOCK status output CLKFB => CLK, -- DCM clock feedback CLKIN => LCLK_IN, -- Clock input (from IBUFG, BUFG or DCM) RST => RESET -- DCM asynchronous reset input );

---------------------

The timing constraint is shown below; I believe that the OFFSET constraints should be effective since the phase-shift, 0 in this case, due to the DCM on LCLK_IN, is accounted for by the PAR tool.

--------------------- NET "LCLK_IN" TNM_NET = LCLK_IN; TIMESPEC TS_LCLK_IN = PERIOD "LCLK_IN" 10 ns HIGH 50%; OFFSET = IN 8 ns BEFORE "LCLK_IN"; OFFSET = OUT 7 ns AFTER "LCLK_IN";

---------------------

A portion of the timing report (.twr) is shown below: Note the Clock Path Delay of 4.979ns which the DCM usage has failed to eliminate in this attempt. I was expecting that the delay would be 0ns or very close to 0ns.

--------------------- Slack: -5.472ns (requirement - (clock arrival + clock path

  • data path + uncertainty)) Source: READY_CARRIER (FF) Destination: LAD (PAD) Source Clock: CLK rising at 0.000ns Requirement: 7.000ns Data Path Delay: 7.313ns (Levels of Logic = 3) Clock Path Delay: 4.979ns (Levels of Logic = 3) Clock Uncertainty: 0.180ns : : Maximum Clock Path: LCLK_IN to READY_CARRIER Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- D14.I Tiopi 0.963 LCLK_IN LCLK_IN LCLK_IN_IBUFG DCM_ADV_X0Y3.CLKIN net (fanout=1) 1.260 LCLK_IN_IBUFG DCM_ADV_X0Y3.CLK0 Tdmcko_CLK -2.213 DCM_BASE_inst DCM_BASE_inst BUFGCTRL_X0Y23.I0 net (fanout=3) 1.504 CLK1 BUFGCTRL_X0Y23.O Tbgcko_O 0.900 CLK_BUFG CLK_BUFG SLICE_X52Y103.CLK net (fanout=123) 2.565 CLK -------------------------------------------------

--------------------------- Total 4.979ns (-0.350ns logic,

5.329ns route)

---------------------

Can anyone shed light on this problem?

Bill Ngo

Reply to
Bill Ngo
Loading thread data ...

---------------------------

If you want to remove the buffer delay, you need to route the output of the BUFG back to the CLKFB input of the DCM. You have the CLK0 output routed directly (internal feedback) which only removes delay to the CLK0 output itself before the BUFG.

HTH, Gabor

Reply to
Gabor

Thanks Gabor,

I explicitly added an BUFG between the DCM's CLK0 output to CLK before feeding it back as well as an explicit IBUFG from the input pad to CLKIN of the DCM and the delay is nulled out.

It is noteworthy though, that even when there is no BUFG instantiated explicitly, the tool does add a BUFG in the feedback path as well as an IBUFG from the input pad to DCM CLKIN. This can be seen in the .twr report showing details for the CLK path which is shown below:

------------------------------------------------------- Maximum Clock Path: LCLK_IN to READY_CARRIER Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- D14.I Tiopi 0.963 LCLK_IN LCLK_IN LCLK_IN_IBUFG DCM_ADV_X0Y3.CLKIN net (fanout=1) 1.260 LCLK_IN_IBUFG DCM_ADV_X0Y3.CLK0 Tdmcko_CLK -2.213 DCM_BASE_inst DCM_BASE_inst BUFGCTRL_X0Y23.I0 net (fanout=3) 1.504 CLK1 BUFGCTRL_X0Y23.O Tbgcko_O 0.900 CLK_BUFG CLK_BUFG SLICE_X52Y103.CLK net (fanout=123) 2.565 CLK -------------------------------------------------

--------------------------- Total 4.979ns (-0.350ns logic,

5.329ns route)

-------------------------------------------------------

The similar detail for the explicitly instantiated IBUFG and BUGF is shown below - note the much larger 'minus' delay introduced by the DCM:

------------------------------------------------------- Maximum Clock Path: LCLK_IN to ASTATE_FFd2 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- B17.I Tiopi 0.988 LCLK_IN LCLK_IN IBUFG_LCLK_IN DCM_ADV_X0Y3.CLKIN net (fanout=1) 1.191 LCLK_INf DCM_ADV_X0Y3.CLK0 Tdmcko_CLK -7.207 DCM_BASE_inst DCM_BASE_inst BUFGCTRL_X0Y25.I0 net (fanout=1) 1.504 DCM_CLK0 BUFGCTRL_X0Y25.O Tbgcko_O 0.900 BUFG_CLK BUFG_CLK SLICE_X0Y53.CLK net (fanout=174) 2.676 CLK -------------------------------------------------

--------------------------- Total 0.052ns (-5.319ns logic,

5.371ns route)

-------------------------------------------------------

I don't understand the difference - both reports show similar connections for the global buffers.

Bill

Reply to
Bill Ngo

---------------------------

---------------------------

Actually the difference between the two is in the feedback path. When you don't instantiate the BUFG, the synthesis will place one between the DCM CLK0 output and your clock loads, but it doesn't use the output of that BUFG for feedback as indicated by the much smaller 'minus' delay. So the clock paths in the report will only differ by the feedback compensation ('minus') delay. You could verify the connection if you looked at an RTL schematic or use the FPGA editor.

Regards, Gabor

Reply to
Gabor

of

rt

y(ns) =A0Physical Resource

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Logical Resource(s)

--------

=A0 =A0 =A0 0.963 =A0 LCLK_IN

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LCLK_IN

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LCLK_IN_IBUFG

LCLK_IN_IBUFG

=A0 DCM_BASE_inst

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DCM_BASE_inst

=A0 CLK1

00 =A0 CLK_BUFG

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CLK_BUFG

CLK

----------------

=A0 =A0 =A0 =A0 =A04.979ns (-0.350ns logic,

wn

y(ns) =A0Physical Resource

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Logical Resource(s)

--------

=A0 =A0 =A0 0.988 =A0 LCLK_IN

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LCLK_IN

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0IBUFG_LCLK_IN

LCLK_INf

=A0 DCM_BASE_inst

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0DCM_BASE_inst

=A0 DCM_CLK0

00 =A0 BUFG_CLK

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0BUFG_CLK

=A0 CLK

----------------

=A0 =A0 =A0 =A0 =A00.052ns (-5.319ns logic,

s

Just wanted to point out that the User Guide outlines the standard usage of the DCMs, including having the BUFG in the feedback path.

formatting link

It's quite a handy little guide! :-)

Reply to
kkoorndyk

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.