Timing from 1x to 2x and back

[Morten Leikvoll]

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?

 

[Brian Drummond]

On Mon, 6 Oct 2003 09:27:25 +0200, "Morten Leikvoll"
<m-leik@online.nospam> wrote:

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 )

2 (based on the input timing)

3 (based on the lowest delay of input and previous output)

How DOES the placer tool handle this?

How about...

4. 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

 

[Morten Leikvoll]

"Brian Drummond" <brian@shapes.demon.co.uk> skrev i melding
news:87m2ovk1sgk2acqt19s6udrbg8uu57adi4@4ax.com...

How about...

4. 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?

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

 

[Marc Randolph]

Morten Leikvoll wrote:

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?

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

 

[John_H]

"Morten Leikvoll" <m-leik@online.nospam> wrote in message news:<IP8gb.28381$os2.396615@news2.e.nsc.no>...

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?

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).

 

[Ray Andraka]

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.

Since then, I have strongly advocated a safe transfer between 1x and 2x domains that makes sure the 2x clock
is clock enabled so as to sample away from the 1x edges going from 1x to 2x, and going the other way clock
enabled so that the edges on the 2x data occur away from the edges of the 1x clock. To do that, copy the 90
degree 1x clock into the 2x domain and use that to generate a 1x clock enable in the 2x domain. The 90
degree reference makes sure the phase is correct and provides a way to sample the 1x clock without getting on
the edge. You could use the 90 degree clocks directly, but for high speed designs the place and route can be
very tricky. This little trick guarantees safe transfers even with a substantial clock skew.

John_H wrote:

"Morten Leikvoll" <m-leik@online.nospam> wrote in message news:<IP8gb.28381$os2.396615@news2.e.nsc.no>...
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?

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).

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

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