Going from CLK1X to CLK2X.. really safe?

Rather than relying on perfect alignment (and risking race conditions if it is not met), I would deliberately offset the two clock domains. Obviously, this lowers the max frequency of operation, but it really makes things safe, if you have the timing margin. Peter Alfke, Xilinx Applications

My understanding was that with an appropriate input clock JITTER constraint given to the Xilinx tools, the timing between the two domains would be guaranteed.

I've maintained the asynchronous handshakes across the odd domains (such as 2x to 3x domains) when I cross the 1X and 2X for safety so I haven't had a chance to find out first hand whether the tools deliver the real deal now that they have hold time analysis internal to the device.

I don't think this situation is any different than a regular 1x clock tree. One always has to check the clock arrival to both flops and the rest of the path etc. There is no need for perfect alignment. The source has its clock tree delay + clk->Q. If one sets the correct clock uncertainty in the timing constraints, this should be very easy to check for all pvt corners and fix by adding some small buffers if needed for clk1x to clk2x crossing flops.

Peter Alfke skrev:

I think I remember Ray saying perfect alignment could not be relied upon especially if the load on the two net were very different

-Lasse

I was burnt with Virtex I on relying on the 1x and 2x clock alignment. Ever since I have been careful to avoid direct transfers from one to the other on the same edge.

In my case, it turned out that a combination of a heavily loaded 2x clock tree, a lightly loaded 1x clock tree, and jitter on the input clock conspired to push the 1x and 2x clocks apart by over 500ps, which was enough to cause the design to fail. In that case, the input clock jitter was not from the clock source either, which made it a real bear to find; it was coming from the input clock buffer thresholds being modulated by outputs switching on the same bank as the clock input.

The bottom line is that jitter on the input to the DLL or DCM can cause the 1x and 2x output edges to become misaligned, even when the loads are perfectly balanced.

In the Virtex-I days, there wasn't proper hold timing analysis in the tools that Xilinx introduced recently. With this added hold timing analysis, the transfers between domains were supposed to be properly analyzed. Even with this help, a properly analyzed input clock would have understated the JITTER constraint needed to have the analysis be

100% and you probably still would have had troubles.

If the internal JITTER value can be properly defined, the tools *may* get the designers to a safe point but I haven't gotten any positive feedback or horror stories since the tool changes came about.

Ray - it's because of your earlier trials that I'm a little more protective of my domain crossings - thanks.

- John_H

I did this recently and it worked fine for me, both in real life and in the simulation (note that in simulation, i generated the clock myself, I didn't simulate the DCM). I'm working on Virtex4 with ISE7.1 & 8.1

When looking at the timing analyzing, I clearly see the path between 1x and 2x being analyzed, taking the skew and clock uncertainty into account.

Note that I still tried to minimize the logic between the 1x reg and the

2x reg, basically I just have a mux so this part can run way faster than the 200 MHz I ask for ;) To be sure, you can add a maxdelay constraint in your vhdl file I think and constraint it to be < x% of your clock period for e.g. that should give you some margin.

Sylvain

Maybe I've gotten overly conservative, but I always treat clock boundaries as asynchronous, no matter how closely they may appear to line up on a scope. For example, I worked on a board where the FPGA had control of a off-chip digital signal generator, which produced the clock for the 4th clock domain. (that clock also fed downstream A/D converters, and the controls to the converters had to be synchronous to that clock)

Even though the system requirements indicated that the logic should only operate when the external PLL clock was locked to the primary clock, and accuracy could be maintained to within +/-500 ps, I still took all the usual precautions for clock boundaries.

Even if I were using to derivative clocks from the same oscillator, I would *STILL* treat them as asynchronous - because they are. Don't count on DCM's to make them "close enough".

There are plenty of tricks for crossing clock domains, but you need to know the relative phase relationship of the clocks, the frequency delta, and the latency tolerance of your application.

Hi -

The original poster was concerned with Spartan 3, so this is slightly OT, but does anyone have experience with the V4 phase-matched clock dividers (PCMDs)? Is is safe to transfer data between domains clocked by two outputs of a PCMD without resorting to resynchronization?

Bob Perlman Cambrian Design Works

Bob,

We designed the PMCD so that the outputs all all matched within tens of picoseconds across P-V-T. From there, you get onto the BUFGs, and you end up with the usual +/-100ps rule for match between BUFgs.

Aust> Hi -

Austin, That is basically what I was told when Virtex I came out too, but it turned out that jitter on the DLL input could cause a spread between the 1x and 2x clocks (IIRC, I had specifically asked both here on the NG and through the hotline about the alignment of the 1x and 2x clocks and whether it was safe to cross clock bounds without extra logic and was told it was fine. I don't think anyone realized then what effect jitter would have on the relative phases of the 1x and 2x outputs.

So my question is, I realize you've designed the PMCDs for tight tolerances, but how well does that stand up to jitter on the clock input?

Ray,

Well, the PMCD is just some custom layout flip flops. Nothing more.

So jitter on the input side of a FF jitters the Q output in a pretty linear through fashion.

Aust> Aust>