Xilinx Virtex-II: DCM int & ext feedback

Hi, I've tried to understand exactly which clocks a DCM will phase align when I do external or internal feedback by the book. I've read every bit of documentation I could find, but came out empty-handed. So maybe someone out there can help me out... This is the structure I have for internal feedback: module int_fb(clki, clko);   input clki;   output clko;   wire clki_buf, clk_fb, clk_2x;   assign clko = clk_fb;   IBUFG ibufg0(.I(clki), .o(clki_buf));   DCM dcm0(.CLKIN(clki_buf), .CLKFB(clk_fb), .CLK2X(clk_2x));   BUFG bufg0(.I(clk_2x), .O(clk_fb)); endmodule Which wires are phase-aligned clocks here? External feedback: module ext_fb(clki, clkfb, clko);   input clki, clkfb;   output clko;   wire clki_buf, clk2x, clkfb_buf;   IBUFG ibufg0(.I(clki), .O(clki_buf));   IBUFG ibufg1(.I(clkfb), .O(clkfb_buf));   DCM dcm0(.CLKIN(clki_buf), .CLKFB(clkfb_buf), .CLK2X(clk2x));   OBUF obuf0(.I(clk2x), .O(clko)); endmodule clko is connected to clkfb outside the FPGA. I've omitted reset and locks for simplicity. Again, which wires are phase-aligned clocks here? Also related: what does the DESKEW_ADJUST attribute do? The documentation I found says only how you set it, but not what it does... Thanks, Gernot

Reply to
Gernot Koch
Loading thread data ...

documentation

me

The output of the BUFG (clk_fb) will be phase aligned with your input clock (clki). By connecting to the CLKFB input, the DCM removes the phase offset introduced by routing, the BUFG, and the DCM itself.

This results in the rising edge internal to the FPGA occurring at nearly the same time as the rising edge of the clock feeding the FPGA... hence you maintain a completely synchronous system.

clko, at the point on the trace that it enters the FPGA, will be phased aligned with your input clock (clki). If the trace continues on for another six inches past the FPGA pin, the end of the trace will of course have an additional small phase offset due to flight time.

HOWEVER, Xilinx is considering changing the rules so that you can't do what you've coded up in your two examples, at least in a V2-Pro. The restriction they are considering is that CLKFB can't come from a CLK2X output anymore. For off-chip deskew, this really throws a monkey wrench into things. I don't know if it is too late (or useful) to complain to your FAE about this or not.

The first two hits when typing in DESKEW_ADJUST in the Xilinx search page seem to explain it pretty well:

formatting link
formatting link

Marc

Reply to
Marc Randolph

So it makes the board clock synchrounous to the internal clock. Can I use the CLK0 output of the DCM at the same time if I need both clock speeds inside the FPGA. Will both CLK0 and CLK2X then be phase aligned with clki?

formatting link

Well, I had seen those. However, they are quite vague about the effect of the DESKEW_ADJUST setting. I did not understand what precisely happens if you set that to SOURCE_SYNC vs. SYSTEM_SYNC. Nor is there any information what the other possible settings will result in. E.g. what would happen in the example above (internal feedback) if I choose one setting vs. the other?

Reply to
""g1er3not.k5och88"

Yes, all outputs of the DCM that are multiples of the input clock will be phase aligned.

formatting link

Perhaps this will help more:

formatting link

From what I've seen in the past, it is quite rare to need DESKEW_ADJUST, and in fact, FIXED or VARIABLE PHASE SHIFT usually provides more flexibility if you need something along these lines.

Marc

Reply to
Marc Randolph

documentation I

see also: - pages 4-5 of XAPP259, which describe the DCM feedback delay taps - Answer Record 15350 : What does the DESKEW_ADJUST constraint do?

In particular, the default SYSTEM_SYNCHRONOUS setting will cause the external feedback clock input pin (your 'clkfb') to lead the external clock input pin (your 'clki') by ~1.5 ns.

If your design requires zero offset between the external input clock and the generated external clocks, you may want to set that DCM to SOURCE_SYNCHRONOUS instead.

Brian

Reply to
Brian Davis

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.