UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
8,606 Views
Registered: ‎04-16-2009

BUFG in cascading DCMs

Jump to solution

Here is the figure from the Virtex-II Pro User Guide. I always believed that the idea of clock tree, the net driven by BUFG, is equalize the clock delays to all the FF. This is also known as clock skew minimization between regs. Now, I see that BUFG is used to drive the only one "flip-flop", the second DCM. What is the need to use the low skew? Which skew is minimized?

cascading DCMs.png

0 Kudos
1 Solution

Accepted Solutions
Instructor
Instructor
10,960 Views
Registered: ‎08-14-2007

Re: BUFG in cascading DCMs

Jump to solution

First, you need to know that the routing between DCM's, IBUFG's, and BUFG's is all high-speed

dedicated routing with very low skew and prop delay.  The only time you get in trouble in V2

is when you use components on opposite edges of the chip.  If your input pad (and IBUFG),

DCM, and BUFG's are all on the top edge, for example, then the routing delays will match

well enough to avoid hold time issues.  The clock trees themselves (shown in the simplified

block diagrams as a single BUFG and a large fanout net) have significant delay, several

nanoseconds in V2, but also match eachother quite well.  You should really run some test designs

through the tools and look at the delays in the timing reports to see how this works.

 

So given the low skew, low prop delay routing between clock components, but the much

larger (but again low skew) prop delay of the BUFG's you can see why inserting the

BUFG to match the one in the feedback path is necessary to maintain low skew at

the output.

 

As for 180 degree clocks and clock duty cycle, the DCM by default creates a clock output

with 50% duty cycle.  You can turn off the duty cycle correction using one of the attributes,

but generally you shouldn't need to unless you use both edges of the input clock externally.

In the normal, duty cycle corrected case I find that the usefulness of the 180 degree clock

is limited because its rising edge is coincident with the falling edge of 0 degree clock,

and almost all clocked structures in the V2 have the ability to use falling edge clock

without imposing additional delay.  Further, the case made for driving DDR outputs using

180 clocks vs. both edges of CLK0 doesn't hold water in my view, since the clock tree

rising to falling differential skew is on the same order as clock tree to clock tree skew.

Also the dual clock tree approach uses twice the routing reources at the IOB's and

often leads to unroutable designs if you don't take this into account before selecting

a pinout.

 

Just my 2 cents,

Gabor

-- Gabor
11 Replies
Teacher rcingham
Teacher
8,602 Views
Registered: ‎09-09-2010

Re: BUFG in cascading DCMs

Jump to solution
Does it break the design when you do it like the diagram tells you to?

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Xilinx Employee
Xilinx Employee
8,602 Views
Registered: ‎02-09-2011

Re: BUFG in cascading DCMs

Jump to solution

The figure you have pasted here is just to show how to cascade DCMs. It just uses shift register to for cascading.

0 Kudos
Explorer
Explorer
8,595 Views
Registered: ‎04-16-2009

Re: BUFG in cascading DCMs

Jump to solution

I see that people prefere stupid rules and unnecessary overcompications/waste to the extent that they draw in empty talk those who try to optimize/understand the good design.

0 Kudos
Scholar austin
Scholar
8,581 Views
Registered: ‎02-27-2008

Re: BUFG in cascading DCMs

Jump to solution

v,

 

The BUFG resource is used because the clock signal will always arrive before a data signal.  The clock tree is faster, by design, than any/all possible interconnect.  So, it is important that the clock signal arrives everywhere it is needed, before the data has changed on another element on the same clock domain, a BUFG is used.

 

This is called proper synchronous design.  In an ASIC the clock tree is often the trickiest part to add, after the logic is synthesized.  In the FPGA, we do that hard work for you, in advance, by designing a general purpose clock tree that can reach every element with gauranteed timing behavior.


BUFG's are also matched resources:  they all behave identically, within 100ps of one another.  So using the BUFG in the feedback path for Clkinfb (the feedback pin) aligns the output of the BUFG within 100 ps of the Clkin.

 

Since in this example, we are concerned with the locked out of the DCM which is operating in its clock domain, and the reset in of the second DCM is operating in its clock domain (I presume the Clock outputs are different frequencies, or phases, as if they were the same, then there is no reason to cascade), the DFF is used to synchronize the LOCKED output to the RESET input of the second stage.  The BUFG is needed on the second DCM for the feedback, and the BUFG is needed on the first DCM for the feedback AND to capture the LOCKED signal properly.

 

If you don't care about the phase relationship of a DCM output, you may drive the Clkin from a regular interconnect (no IBUFG is required, unless you are trying to match the incoming phase with the outgoing phase of te DCM).

 

But, if you use the outputs, at all, from a DCM, the use of a BUFG for every output used means that clocks will always get where they need to go at the right time.


Using regular interconnect for clocks is just wrong, and the tools don't support it:  do not do it.

 

You may skip use of the IBUFG if you don't care about phase in == phase out.

 

Warnings will tell you you did not use an optimal path, but if that is OK, ignore that warning,

 

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
Explorer
Explorer
8,576 Views
Registered: ‎04-16-2009

Re: BUFG in cascading DCMs

Jump to solution

Thanks, There are lots of BUFGs in the figure. And, you have explained all of them besides the one I wanted. Do you see the one that connects DCM1 DV_out to DCM2 in? That is the major cascading line - we take the clock generated by first DCM to another. What is the need for BUFG inbetween? Keeping two domains "in-phase"?

 

BTW, Xilinx provides BUFG to keep regs in-phase. But, DCM is allowed to produce shifted phases. How do you keep the difference? You definitely need to use another BUFG for another phase. That is another clock tree with arbitrary skew from the first!

0 Kudos
Scholar austin
Scholar
8,568 Views
Registered: ‎02-27-2008

Re: BUFG in cascading DCMs

Jump to solution
v,

The one from CLKDV can be left out, as it really doesn't matter that the phase and delay is unknown (unconstrained). This will mean that the clock out off the second DCM will not be aligned in phase on any input clock edge, and that the delay from a clock edge is unknown. Using that BUFG means that depending on the D value, and M/D of the second DCM, some output clock edges would be aligned exactly with the input clock to the first DCM )+/- 200 ps, as each stage is +/- 100ps).

If you are synchronizing between the two clock domains (from DCM 1, and from DCM2), the BUFG insures you avoid really bad states where metastability is likely, as opposed to places where metastability is less likely.


Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
Instructor
Instructor
8,564 Views
Registered: ‎08-14-2007

Re: BUFG in cascading DCMs

Jump to solution

Just to clarify Austin's remark, the BUFG in question matches the delay on the BUFG in the

feedback path of the first DCM.  On the output of the DCM, CLK0 and CLKDV are aligned

on the rising edges of CLKDV, at least for integer divide ratios.  The BUFG in the feedback

path adds a delay to the CLK0 output which is then subtracted out because the input phase

comparitor is on the output side of this BUFG.  So the output of the BUFG on CLKDV will line

up with the input clock rising edges.  You can leave it out if you don't need this alignment,

for example if the external clock is just an oscillator and not connected to any external

devices that communicate with the FPGA.  However note that leaving it out will result in

an effective negative delay of one BUFG prop delay from the input clock to the output.

You could theoretically leave out both BUFG's and get the same results, but I think in

Virtex 2 you need the one in the feedback path for routability.  Newer devices like Virtex 5

have internal feedback in the DCM.  You can certainly try to remove the feedback BUFG,

and the tools will let you know if the result is not routable.

 

-- Gabor

 

-- Gabor
Explorer
Explorer
8,554 Views
Registered: ‎04-16-2009

Re: BUFG in cascading DCMs

Jump to solution

> So the output of the BUFG on CLKDV will line up with the input clock rising edges.

 

It is interesting to know - why? I understand that DCM might be good aligning all its outputs, putting them in one phase (and shift 90, 180 and 270 properly). However, I do not understand why you are sure that passing these parallel outputs through independent BUFG instances still keeps them in phase? The DCM-BUFG traces may vary in length. The clock trees produced by BUFG might also be different. I see that to match BUFG output rising edges with ones at DCM input, the following is proposed in the same document

 

clock distribution with DCM.png

 

You see: the same BUFG drives the (not shown) flip-flops and the feedback. This ensures that all clock consumers are "in phase" with the input clock. Clocking another DCM with a similar single BUFG at the output, I could have another clock tree in phase with the first one. However, a different BUFG is used in cascading example. The phase with DCM1 input clock is lost, IMO. This makes the BUFG between two DCMs useless. I do not see what could keep the phases together when fanout branches are driven through the different BUFGs.

 

The same problem I see in BUFGing different phases. For instance, take

 

ddr clock.png

 

This makes CLOCK switching simultaneously with its inverse. But, what about the duty cycle? How much phase 180 is away from 0?

0 Kudos
Instructor
Instructor
10,961 Views
Registered: ‎08-14-2007

Re: BUFG in cascading DCMs

Jump to solution

First, you need to know that the routing between DCM's, IBUFG's, and BUFG's is all high-speed

dedicated routing with very low skew and prop delay.  The only time you get in trouble in V2

is when you use components on opposite edges of the chip.  If your input pad (and IBUFG),

DCM, and BUFG's are all on the top edge, for example, then the routing delays will match

well enough to avoid hold time issues.  The clock trees themselves (shown in the simplified

block diagrams as a single BUFG and a large fanout net) have significant delay, several

nanoseconds in V2, but also match eachother quite well.  You should really run some test designs

through the tools and look at the delays in the timing reports to see how this works.

 

So given the low skew, low prop delay routing between clock components, but the much

larger (but again low skew) prop delay of the BUFG's you can see why inserting the

BUFG to match the one in the feedback path is necessary to maintain low skew at

the output.

 

As for 180 degree clocks and clock duty cycle, the DCM by default creates a clock output

with 50% duty cycle.  You can turn off the duty cycle correction using one of the attributes,

but generally you shouldn't need to unless you use both edges of the input clock externally.

In the normal, duty cycle corrected case I find that the usefulness of the 180 degree clock

is limited because its rising edge is coincident with the falling edge of 0 degree clock,

and almost all clocked structures in the V2 have the ability to use falling edge clock

without imposing additional delay.  Further, the case made for driving DDR outputs using

180 clocks vs. both edges of CLK0 doesn't hold water in my view, since the clock tree

rising to falling differential skew is on the same order as clock tree to clock tree skew.

Also the dual clock tree approach uses twice the routing reources at the IOB's and

often leads to unroutable designs if you don't take this into account before selecting

a pinout.

 

Just my 2 cents,

Gabor

-- Gabor
Explorer
Explorer
2,860 Views
Registered: ‎04-16-2009

Re: BUFG in cascading DCMs

Jump to solution

Gabor, It was a good explanation

0 Kudos
Teacher eteam00
Teacher
2,853 Views
Registered: ‎07-21-2009

Re: BUFG in cascading DCMs

Jump to solution

Gabor, It was a good explanation

Unpaid commercial advertisement on behalf of the forum admins:

 

  • If your question or topic has been fully addressed, please mark the single keenest posting in the thread -- the one post most closely representing a solution -- as the 'solution'.  This will also mark the thread as 'solved'.
  • If you are impressed by the wit or wisdom imparted in any posts (other than your own), feel free to 'reward' or compliment the post's author with a 'kudo' (click on the star near the left margin).  You can kudo many posts, not just one.  And you don't have to be the thread's 'owner' to add your own kudos (compliments) to posts which are worthy.

Thanks!

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos