Skew between the output of a DCM ?

  • Thread starter jean-francois hasson
  • Start date
J

jean-francois hasson

Guest
Hi,

I remember reading a few lines on this newsgroup about the fact that a DLL
in a Virtex might not be able to handle a negligible skew between two
outputs (clk0 and clk2X for instance) in some situations like a heavy
loading difference between the two clock trees with maybe an important (but
in the datasheet spec ?) jitter on the input clock. Ever since I read this I
did not consider I could change from one clock domain to the other without
special care. Has anyone something new concerning these potential cases ? If
there is still a possibility does it apply only to Virtex or also to Virtex
II ? The reason I ask is that the designs coming up are running faster and
faster making it more difficult to consider changing clock domains with some
extra precaution.
Thanks,

JF
 
The new version of Xilinx tools (6.1i and on) appear to be doing a more
complete job on this analysis. The biggest problem earlier was the effect
of input jitter on the DCM that couldn't be accounted for. Uneven loading
on the clock nets was also an issue. Now the tools allow an INPUT_JITTER
constraint to go along with your specified period and duty cycle. Also with
the automated elimination of hold-time violations, it looks like the tools
are filling in for the corner cases of design as long as we, the designers,
give the tool the right info.

I'm now happier making the transition between same-edge clock domains
without special treatment though I know where to look first if my design
starts to misbehave.


"jean-francois hasson" <jfhasson@club-internet.fr> wrote in message
news:3fd377da$0$6982$7a628cd7@news.club-internet.fr...
Hi,

I remember reading a few lines on this newsgroup about the fact that a DLL
in a Virtex might not be able to handle a negligible skew between two
outputs (clk0 and clk2X for instance) in some situations like a heavy
loading difference between the two clock trees with maybe an important
(but
in the datasheet spec ?) jitter on the input clock. Ever since I read this
I
did not consider I could change from one clock domain to the other without
special care. Has anyone something new concerning these potential cases ?
If
there is still a possibility does it apply only to Virtex or also to
Virtex
II ? The reason I ask is that the designs coming up are running faster and
faster making it more difficult to consider changing clock domains with
some
extra precaution.
Thanks,

JF
Click to expand...
 
The input_jitter constraint does not factor in jitter caused skew between clock
nets. It only decreases the available cycle time in your period constraint to
account for cycle to cycle variations (jitter) in the clock for that net. I
don't know if the VirtexII suffers to the same degree or not (and I haven't
chanced it) from DLL output spreading due to input jitter.

Safe crossing between related clock domains in not overly difficult, and is
still possible to do with the faster clock speeds. The only work around other
than deliberate safe crossing design is to guarantee the delay between two
flip-flops on different but related clocks is greater than the maximum possible
clock skew between those flip-flops, which is to say you have to depend on LUTs
and routing to delay the data signal. If speed is critical, then adding the
delays can hurt you more than doing a proper safe crossing.

John_H wrote:

The new version of Xilinx tools (6.1i and on) appear to be doing a more
complete job on this analysis. The biggest problem earlier was the effect
of input jitter on the DCM that couldn't be accounted for. Uneven loading
on the clock nets was also an issue. Now the tools allow an INPUT_JITTER
constraint to go along with your specified period and duty cycle. Also with
the automated elimination of hold-time violations, it looks like the tools
are filling in for the corner cases of design as long as we, the designers,
give the tool the right info.

I'm now happier making the transition between same-edge clock domains
without special treatment though I know where to look first if my design
starts to misbehave.

"jean-francois hasson" <jfhasson@club-internet.fr> wrote in message
news:3fd377da$0$6982$7a628cd7@news.club-internet.fr...
Hi,

I remember reading a few lines on this newsgroup about the fact that a DLL
in a Virtex might not be able to handle a negligible skew between two
outputs (clk0 and clk2X for instance) in some situations like a heavy
loading difference between the two clock trees with maybe an important
(but
in the datasheet spec ?) jitter on the input clock. Ever since I read this
I
did not consider I could change from one clock domain to the other without
special care. Has anyone something new concerning these potential cases ?
If
there is still a possibility does it apply only to Virtex or also to
Virtex
II ? The reason I ask is that the designs coming up are running faster and
faster making it more difficult to consider changing clock domains with
some
extra precaution.
Thanks,

JF
Click to expand...
--
--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
 
Hi,

I agree with the fact that crossing clock domains with special care is still
possible even with higher clock frequencies. However, I believe some designs
involving the Virtex II Pro cross clock boundaries (300 MHz to 100 MHz and
the opposite) without concern about skew. Does that mean that the skew is
negligible compared to propagation delay by construction of the Virtex II
Pro ? Would it be the same for Virtex II ?

JF Hasson

"Ray Andraka" <ray@andraka.com> a écrit dans le message de news:
3FD73863.BE23FD47@andraka.com...
The input_jitter constraint does not factor in jitter caused skew between
clock
nets. It only decreases the available cycle time in your period
constraint to
account for cycle to cycle variations (jitter) in the clock for that net.
I
don't know if the VirtexII suffers to the same degree or not (and I
haven't
chanced it) from DLL output spreading due to input jitter.

Safe crossing between related clock domains in not overly difficult, and
is
still possible to do with the faster clock speeds. The only work around
other
than deliberate safe crossing design is to guarantee the delay between two
flip-flops on different but related clocks is greater than the maximum
possible
clock skew between those flip-flops, which is to say you have to depend on
LUTs
and routing to delay the data signal. If speed is critical, then adding
the
delays can hurt you more than doing a proper safe crossing.

John_H wrote:

The new version of Xilinx tools (6.1i and on) appear to be doing a more
complete job on this analysis. The biggest problem earlier was the
effect
of input jitter on the DCM that couldn't be accounted for. Uneven
loading
on the clock nets was also an issue. Now the tools allow an
INPUT_JITTER
constraint to go along with your specified period and duty cycle. Also
with
the automated elimination of hold-time violations, it looks like the
tools
are filling in for the corner cases of design as long as we, the
designers,
give the tool the right info.

I'm now happier making the transition between same-edge clock domains
without special treatment though I know where to look first if my design
starts to misbehave.

"jean-francois hasson" <jfhasson@club-internet.fr> wrote in message
news:3fd377da$0$6982$7a628cd7@news.club-internet.fr...
Hi,

I remember reading a few lines on this newsgroup about the fact that a
DLL
in a Virtex might not be able to handle a negligible skew between two
outputs (clk0 and clk2X for instance) in some situations like a heavy
loading difference between the two clock trees with maybe an important
(but
in the datasheet spec ?) jitter on the input clock. Ever since I read
this
I
did not consider I could change from one clock domain to the other
without
special care. Has anyone something new concerning these potential
cases ?
If
there is still a possibility does it apply only to Virtex or also to
Virtex
II ? The reason I ask is that the designs coming up are running faster
and
faster making it more difficult to consider changing clock domains
with
some
extra precaution.
Thanks,

JF



--
--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
Click to expand...
 
I've come across plenty of designs in the older devices that go between clock
domains without concern about skew as well. It doesn't make it right. Fact is,
the average design that has several layers of logic between flip-flops is going
to be fine, as there is enough delay in the LUTs and routing to outweigh the
skew. It is in the carefully done (and occasional accidental case) where you
have a flip-flop in one domain connected to the direct in input to the flip-flop
in the other domain (skipping the LUT) that is the potential problem. If you
have a LUT in between, you'll need to have a good bit of jitter on the input in
order to have enough skew to break the design, at least in lab conditions. The
cases where I had problems were designs with the arrangement as described above,
that had also been floorplanned. Trouble is, there is no minimum propagation
spec, so it is difficult to determine how much margin a given number of LUTs or
routing delay buys you. The safe design takes very little extra logic, so it is
to me a no-brainer to put it in to avoid the situation altogether.

jean-francois hasson wrote:

Hi,

I agree with the fact that crossing clock domains with special care is still
possible even with higher clock frequencies. However, I believe some designs
involving the Virtex II Pro cross clock boundaries (300 MHz to 100 MHz and
the opposite) without concern about skew. Does that mean that the skew is
negligible compared to propagation delay by construction of the Virtex II
Pro ? Would it be the same for Virtex II ?

JF Hasson

"Ray Andraka" <ray@andraka.com> a écrit dans le message de news:
3FD73863.BE23FD47@andraka.com...
The input_jitter constraint does not factor in jitter caused skew between
clock
nets. It only decreases the available cycle time in your period
constraint to
account for cycle to cycle variations (jitter) in the clock for that net.
I
don't know if the VirtexII suffers to the same degree or not (and I
haven't
chanced it) from DLL output spreading due to input jitter.

Safe crossing between related clock domains in not overly difficult, and
is
still possible to do with the faster clock speeds. The only work around
other
than deliberate safe crossing design is to guarantee the delay between two
flip-flops on different but related clocks is greater than the maximum
possible
clock skew between those flip-flops, which is to say you have to depend on
LUTs
and routing to delay the data signal. If speed is critical, then adding
the
delays can hurt you more than doing a proper safe crossing.

John_H wrote:

The new version of Xilinx tools (6.1i and on) appear to be doing a more
complete job on this analysis. The biggest problem earlier was the
effect
of input jitter on the DCM that couldn't be accounted for. Uneven
loading
on the clock nets was also an issue. Now the tools allow an
INPUT_JITTER
constraint to go along with your specified period and duty cycle. Also
with
the automated elimination of hold-time violations, it looks like the
tools
are filling in for the corner cases of design as long as we, the
designers,
give the tool the right info.

I'm now happier making the transition between same-edge clock domains
without special treatment though I know where to look first if my design
starts to misbehave.

"jean-francois hasson" <jfhasson@club-internet.fr> wrote in message
news:3fd377da$0$6982$7a628cd7@news.club-internet.fr...
Hi,

I remember reading a few lines on this newsgroup about the fact that a
DLL
in a Virtex might not be able to handle a negligible skew between two
outputs (clk0 and clk2X for instance) in some situations like a heavy
loading difference between the two clock trees with maybe an important
(but
in the datasheet spec ?) jitter on the input clock. Ever since I read
this
I
did not consider I could change from one clock domain to the other
without
special care. Has anyone something new concerning these potential
cases ?
If
there is still a possibility does it apply only to Virtex or also to
Virtex
II ? The reason I ask is that the designs coming up are running faster
and
faster making it more difficult to consider changing clock domains
with
some
extra precaution.
Thanks,

JF



--
--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
Click to expand...
--
--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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top