FPGA Central

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<30> (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

On Jun 8, 11:22 pm, "Bill Ngo" <bill....@sympatico.ca> wrote:
> 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<30> (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

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

"Gabor" <[email protected]> wrote in message
news:<[email protected]>...

> 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



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

On Jun 9, 9:06 pm, "Bill Ngo" <bill....@sympatico.ca> wrote:
> "Gabor" <ga...@alacron.com> wrote in message
>
> <news:[email protected]>...
>
> > 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
>
> 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

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

On Jun 10, 11:51*am, Gabor <ga...@alacron.com> wrote:
> On Jun 9, 9:06 pm, "Bill Ngo" <bill....@sympatico.ca> wrote:
>
>
>
> > "Gabor" <ga...@alacron.com> wrote in message
>
> > <news:[email protected]>....
>
> > > 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
>
> > 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 CLKINof
> > 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
>
> 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


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

http://www.xilinx.com/support/docume...ides/ug070.pdf

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