Timing from 1x to 2x and back

My collegue and I discussed how our placer (xilinx's) handled going from 1x clocks to 2x clocks and back. (These have of course common rising edge)

For this example I use a 100Mhz clock and a 200Mhz clock:

There are 3 ways of doing this:

1 (based on the timing of the previous ff's output ) Signals coming from 1x to 2x will be routed with max 10ns delay. This means that you can not tell wether the signal will appear at the 2x at the 5ns or 10ns rising 2x clock.

2 (based on the input timing) Signals coming from 2x to 1x will be routed with max 10ns delay. This means that the output can sometimes skip the first

1x edge.

3 (based on the lowest delay of input and previous output) This works, but my collegue claims this tool doesn't do it this way. Can anyone confirm this is the case?

How DOES the placer tool handle this?

Reply to
Morten Leikvoll
Loading thread data ...

How about...

  1. Based on your own explicit timing constraints, defined in the UCF file, applied to TIMEGRPs defined by you, to include all the domain-crossing signals?

- Brian

Reply to
Brian Drummond

"Brian Drummond" skrev i melding news: snipped-for-privacy@4ax.com...

That was the solution, but still I'd like to know how it's done without manually placing the constraint.

Reply to
Morten Leikvoll

Howdy Morten,

Ask your colleague how would he would be able to guarantee the design to work under all conditions if you have the situations described in options 1 and 2. Especially if there is more than the bus taking part in the domain crossing.

The answer, of course, is option 3. But you don't have to take my word, or the word of anyone else. It is easy to set this up yourself in a couple lines of code, run it through PAR, and then run timing analyzer on it.

Have fun,

Marc

Reply to
Marc Randolph

If you check your source and destination clocks for the timing in your timing analyzer, you'll see that the timing is based on 5 ns, not 10 ns. Unless you tell it otherwise with your timing constraints, the tools assume that something generated in one domain will be used in the other domain on the earliest rising edge. The logic will require the 5 ns times unless you have explicit enables in the 200MHz domain and specific logic to keep the 200 MHz outputs steady for 2 clocks going back to the 100 MHz domain. Everything ends up being timed to the faster clock. Can you explain how a 10 ns delay either direction would work properly given the data changes 5 ns before the clock edge (at least for *a* rising edge for the 100 MHz to 200 MHz transition).

Reply to
John_H

A caveat applies to crossing between the 1x and 2x domains. Although there is a specification for skew between the 1x and 2x outputs of a DLL/DCM, that spec is predicated on no jitter in the input clock and balanced loads on the 1x and 2x domains. In practice you wont get that, and you can wind up with a sizable skew between the 1x and 2x clocks. We saw an instance a while back with a customer where there was nearly 1 ns clock skew between the 1x and 2x clock that caused all sorts of problems with transferring data across the domains. The skew was mostly due to clock jitter, and most of that clock jitter was due to outputs switching on the same bank as the clock input, not from outside the FPGA.

S> > My collegue and I discussed how our placer (xilinx's) handled going from 1x

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

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.