Are clock and divided clock synchronous?

Valentin,

For all but the simplest of designs divided clocks should be treated as asynchronous and avoided if possible. There are several reasons for this.

1) Your divided clock will have a small delay relative to the real clock. If you use this to clock a register which takes in a signal clocked from the original clock domain it may be possible for the setup/hold to be violated or data to be taken when it shouldn't have been (i.e a clock early). I think you were implying this above.

2) If you have logic which works accross the two clock domains e.g. data clocked from main clock domain goes through logic and is registed on divided clock domain or vice-versa then the synthesis tool may have a hard time performing optimization on logic in that part of the design.

3) Unless you have spare high-speed global resources in your design and the target technology allows the connection of a register output onto these nets (most modern fpga's are okay with this!) then the divided clock may get routed on the normal routing nets. If you have lots of registers driven from the divided clock the fanout may start to become significant and hence the skew between the clock domains will get larger. If the skew starts to become significant it then becomes more difficult to ensure that the design will work over all temperature/voltage conditions as this will introduce skew between registers on the divided domain aswell as between the divided and main clock domain. To overcome this the synthesis/place&route tools may try to insert buffers to split down the net. This may in turn introduce more skew between some registers on your divided net.

So to overcome these issues I would suggest trying alternative method of coding to reduce this problem to a minimum. The way I do things if I want a slower clock is as follows:

For example, say I want a clock that is 1/3 the system clock, I would create a 2-bit counter that counts 0 to 2 and rolls over. When the counter equals 2 a signal EnableDiv3 is asserted to '1' (and is '0' for all other values). I then use this signal as a synchronous enable to the registers I want to run a 1/3 speed but still clock the registers off the system clock.

EnableGen : process (nReset, Clock) begin if (nReset = '0') then EnableCount

Are you referring to a divided clock that you're generating or a divided clock from a dedicated FPGA clocking resource?

If you're generating the clock yourself, I'd suggest generating a one-pulse-wide enable signal every n cycles rather than a divide-by-n clock and use the enable for all the reduced-speed logic that would otherwise use the divided clock. The timing tools should be able to easily apply a multi-cycle constraint that you assiciate with the enable signal. The only logic that needs to have short propagation delays is the enable signal.

Just spotted the typo! Should be (EnableDiv3 = '1').

I have always used a counter clocked on the global clk, and then used one of the signals that make up the counter's vector as my divided clk signal.

e.g. signal cnt: std_logic_vector(7 downto 0);

process(...) .... if rising_edge(clk) then cnt edage. On the other hand, synchronous signals should switch simultaneusly

Stupid OE shows only your last message. Which newsreader do you use?

Newsreader has nothing to do with this, it's the news server that you are connected to. You might try talking to your IP about the issue or use one of the free servers. A very good one is news.individual.net (someone recommended it to me earlier on this group). The only problem with it is that you have to register and it seems that they actually have a live person who does the registrations, so it may take 1-2 days. Their site is

/Mikhail

Hi, Did you try to press the button "headers"? It has worked for all the people complaining at my office.!! I am not sure why the OE does not download all messages.. But I guess it has to do something with max headers and waste of space settings.

Anyway, hope it helps..

of

person

Matt,

In the two examples you provide below you are generating divided clocks on dclk and then using this to clock registers in the design. This will mean that there will be skew introduced between registers on the main clock domain and registers on the dclk domain. This skew may become quite large and cause problems. Also the synthesis tool will not be able to properly optimize any logic that crosses between the two clock domains.

In the example I gave, all registers are clocked using the main global clock. I achive the lower "clock" rate at the registers by using the EnableDiv3 signal as a synchronous enable to the registers. This means that there is not any excessive skew between register as they will all be on the same low-skew clock net. The synthesis tool will be happy about optimizing between registers passing between the fast and slow parts of the design and to ensure the synthesis/place&route tools only optimize as much as is required you can specify register-register paths in the low speed parts of the design as multi cycle paths.

Cheers,

Pete.

I agree with the other Peter, but I might add: If you use the Digital Clock Manager in Virtex-II or Spartan3, you have four outputs with practically zero skew (

Just to make sure I understand, this is NOT the case with the Spartan-2 DLL is it, i.e. the skew is not so well behaved in the DLL.

Jeff

Pressing headers does not help. I know that i need sometimes to reset (clear all messages) and redownload headers in OE. That is why I've considered missing messages as another bug. Actually, the problem is bad newserver as mikhail mentioned.

DLLs ain't misbehavin' !

The DLL >

Peter -

I don't want to put words in Ray Andraka's mouth, but I distinctly remember him posting about the dangers of using the supposedly low-skew outputs from the DLLs of Virtex parts. As I recall, the problem he experienced was that jitter on the clock coming into the part resulted in jitter on the DCM output clocks, in a way that didn't track from clock to clock. (Such jitter could be caused by the clock generator itself, or by SSO noise from nearby FPGA outputs.) So while the spec for output-to-output skew is indeed low, the effects of input clock jitter could increase these numbers. (If this is wrong, Ray, please jump in and correct me.)

For that reason, I've always treated transfers between f and Nf domains carefully, and I assume that rising-edge-to-rising edge transfers won't work reliably in all cases.

So, my questions:

1) To what extent does jitter on the input clock affect DLL/DCM output-to-output skew?

2) Is there some amount of input clock jitter below which the skew published in the data sheets dominates? For example, for a Virtex II part, how much jitter can I tolerate on the DCM clock input before the DCM output-to-output phase offset exceeds the +/-140ps number in the data sheet? (The Virtex II data sheet says that the input clock period jitter can be as high as +/-1ns; is this just the amount of jitter we can tolerate before losing lock, or do I get the +/-140ps clock-to-clock output skew with this much jitter?)

Thanks, Bob Perlman Cambrian Design Works

Bob,

The DCM ICDES expert will weigh in here.

See below,

Aust> Peter -

?? Yes there is added jitter, but it is added to all outputs at the same time.

Not at all. All outputs are generated by matched devices in the clock generator output block state machine that has the delay line (taps) as its inputs.

The latter. You get the +/- 140 offset on top of the 1 ns noise.

One can think of the offset, or skew as DC, and the jitter as AC. On any signal, you have the AC component which varies, and the DC component which is fixed and does not vary for any given part.

That is why the timing budget has to treat offsets different from jitter. They are both measures of time, but one is peak to peak white AC noise (jitter), and the other is + or - DC offset (output skew). Adding offsets is linear (1+1=2) while adding jitter is quadratic (1+1=1.414 or sqr(2)).

Adding RMS jitter would add arithmetically (1+1=2), but the peak to peak to RMS ratio of designs is so hard to evaluate, that the RMS to P-P conversion factor could be guessed to be from 3 to 14 (and still not be right). Easier to keep everything in P-P, and do the calculations that way.

I ever implemented such divided clock design. The derived clock (A) took data from high-speed clock domain at A's falling edge. On the other hand, the high-speed clock put data to derived clock domain at A's rising edge. Besides, the area constraint was needed to limit the inter-domain module. So the routing delay was confined.

Bob, thanks for putting the question forward so well.

Xilinx Insiders, if there is input-jitter related DCM output skew in the 1x,

2x, or DIV clocks, I'd like "reassurance" that the new JITTER constraints in 6.1i will adjust for the input-jitter induced timing skew.

If the caution we've been designing against can be a non-issue with a proper INPUT_JITTER number, I'm a happy guy. Primarily because of this caution, I was ecstatic to see these new constraints. If the caution we've been designing against is a non-issue because it never was a problem (despite apparent empirical evidence otherwise) I'm still happy though a little confused.

I never did find out if the multiple clocks were guaranteed to use the same delay-line tap for the common edge (versus 180 or 360 degrees out of phase).

have

distribute

caused

John_H,

A few comments...

Aust> Bob, thanks for putting the question forward so well.

Skew is a fixed phase offset, or error, from a nominal value. Think of it aas DC.

Jitter is variations around the "significant instant" (ie where a perfect clock would be). Think of it as AC. Don't mix AC and DC. They don't mix well. AC adds RMS or peak to peak root mean square. DC adds linearly (1+1=2).

6.1i has much better software prediction of both skew and jitter (kept separate) so that you do not have to make an Excel spreadsheet to keep track of everything.

If you can state your confusion to me, I will attempt to clarify (can post, or send to me directly).

Clocks fromt he same DCM are spec'd to arrive at their destinations when using the global clock buffers +/- 140 ps (for example) when the destinations are all on the same H clock tree within a few CLBs or IOBs of one another (ie removing clock skew on the global).

Here is something from the other stereo channel (Austin and I often complement each other):

Each DLL or DCM takes the rising input edge and feeds it into a very long chain of cascaded buffers. In the background, we have a complex calculating engine that figures out which tap should feed which output, and it gracefully adjusts the tap setting when temperature or voltage change. (One tap is about 50 picoseconds or less). That's the basic mechanism, quite simple, although the implementation takes tens of thousands of transistors.

Obviously, incoming jitter is passed through to the outputs ( delayed by more than one period), but exactly equally to all outputs. So, there is no added skew caused by the input jitter. If you trust the global clock lines to distribute a clock with simultaneous arrival times at all flip-flops, you should also trust two global lines to distribute two different (e.g. 2:1) clocks in a similar way. No race condition...

This describes the physical acti>

separate)

So when this 'smart tracking' has to adjust a delay step ( due to Temp, or Vcc changes ) you will get a quantized jump in the delay ? (50ps) Some may call that jitter, and it depends on the HW design how often it occurs. With Hyst in the decision, the spectrum of the jitter can be reduced, but note that poor Vcc behaviour can cancell the Hyst. It does not sound like the adjust steps are an issue from Tsu/Th viewpoint, but they _may_ affect a system with a critical jitter budget - such as those where jitter == signal to noise floor.

-jg