Xilinx Virtex2: Erroneous DCM "Tap" Position after Reset

Hi,

We are seeing evidence that a DCM is intermittently selecting the
wrong tap position after it completes its lock sequence after a DCM
reset pulse. I'd like to know if anyone has experienced this effect,
and if they were able to resolve this problem.

In a 2v6000, I am using a variable phase shift DCM which is driven by
a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks
on its clk0/clk180 output pins. This interface uses IOB DDR regs for a
622 Mhz/16-bit LVDS transmission solution.

The DCM initial value is set to 0. After a DCM reset, the DCM is phase
shifted to its predetermined optimal "error-free" setting. However,
intermittently, the interface experiences a small amount of bit
errors.

To eliminate the errors, the DCM is further phase shifted in one
direction until it actually achieves error-free operation. The
subsequent error-free window of operation in this mode matches very
closely to the original calibration error-free window.

It is as if the DCM locking sequence is corrupted somehow, resulting
in a mis-aligned tap position. We don't have conclusive evidence
because we can't see inside the DCM to see its tap position. We have
found that we can eliminate this error condition by applying another
one or two reset pulses to the DCM.

I realize that voltage fluctuations and switching noise could be
causing this effect. Nonetheless, I'd like to hear from real world
experiences.

Thank you.
John

John,

There have been cases where the frequency, jitter, and duty cycle are 
just on the edge of where the DCM phase detector will operate reliably.

Check the input duty cycle.  It will need to be as close to 50% as you 
can make it.  The spec is 45 to 55%, but at the higher frequencies, it 
may have to be even closer to 50% when you take clock jitter into 
account (as if it is 45%, and it has jitter, then it is sometimes less 
than 45%!).

Hope this helps.

If you can vary the input clock duty cycle, you should be able to make 
it always work, never work, and be in between like it is now.  That will 
show you where it needs to be.

Duty cycle management is a tough thing as it is affected by signal 
integrity, and at 311 MHz, signals get distorted very easily.

Even observing the signal can be tough, as it doesn't look like it does 
on the die at the pins (just simulate it to see that).

In the past, I have seen cases where the 100 ohm LVDS receive 
termination is removed, and the problem goes away (due to the location 
of the 100 ohm resistor, and the stubs causing reflections distorting 
the signal).  The termination for a clock signal input isn't really 
required (would be for a data signal to prevent ISI).

Subsequent versions of the DCM (S3 and V4) have even better phase 
detectors which are more tolerant of the duty cycle.  Always room for 
improvements.

Austin

John Cappello wrote:

> Hi,
> 
> We are seeing evidence that a DCM is intermittently selecting the
> wrong tap position after it completes its lock sequence after a DCM
> reset pulse. I'd like to know if anyone has experienced this effect,
> and if they were able to resolve this problem.
> 
> In a 2v6000, I am using a variable phase shift DCM which is driven by
> a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks
> on its clk0/clk180 output pins. This interface uses IOB DDR regs for a
> 622 Mhz/16-bit LVDS transmission solution.
> 
> The DCM initial value is set to 0. After a DCM reset, the DCM is phase
> shifted to its predetermined optimal "error-free" setting. However,
> intermittently, the interface experiences a small amount of bit
> errors.
> 
> To eliminate the errors, the DCM is further phase shifted in one
> direction until it actually achieves error-free operation. The
> subsequent error-free window of operation in this mode matches very
> closely to the original calibration error-free window.
> 
> It is as if the DCM locking sequence is corrupted somehow, resulting
> in a mis-aligned tap position. We don't have conclusive evidence
> because we can't see inside the DCM to see its tap position. We have
> found that we can eliminate this error condition by applying another
> one or two reset pulses to the DCM.
> 
> I realize that voltage fluctuations and switching noise could be
> causing this effect. Nonetheless, I'd like to hear from real world
> experiences.
> 
> Thank you.
> John

Austin,

Thanks for the insight on the duty cycle. We will check this. One more
thing. What can we expect from the integrity of a DCM in a system
where it is common to switch clock sources or clock frequencies? We
have found that the DCM does not lose lock or indicate "clkin_stopped"
during these sequences.

Are we supposed to reset the DCM after such an occurrence? If so, we
are trying to figure out how we will know to do this since the DCM
doesn't unlock or indicate that the input clock has stopped.

The DCM spec states (in the "Input Clock Changes" section) that the
DCM can tolerate pauses or phase shifts in the clock, but later on in
the spec, states "once locked to a frequency, cannot tolerate large
variations of the input frequency." Exactly what is meant by "cannot
tolerate"? Does this mean that it is possible for the DCM to offset
its "phase shift" on the output clock from the optimal setting?

Thanks!
John


Austin Lesea <austin@xilinx.com> wrote in message news:<chprct$73l1@cliff.xsj.xilinx.com>...
> John,
> 
> There have been cases where the frequency, jitter, and duty cycle are 
> just on the edge of where the DCM phase detector will operate reliably.
> 
> Check the input duty cycle.  It will need to be as close to 50% as you 
> can make it.  The spec is 45 to 55%, but at the higher frequencies, it 
> may have to be even closer to 50% when you take clock jitter into 
> account (as if it is 45%, and it has jitter, then it is sometimes less 
> than 45%!).
> 
> Hope this helps.
> 
> If you can vary the input clock duty cycle, you should be able to make 
> it always work, never work, and be in between like it is now.  That will 
> show you where it needs to be.
> 
> Duty cycle management is a tough thing as it is affected by signal 
> integrity, and at 311 MHz, signals get distorted very easily.
> 
> Even observing the signal can be tough, as it doesn't look like it does 
> on the die at the pins (just simulate it to see that).
> 
> In the past, I have seen cases where the 100 ohm LVDS receive 
> termination is removed, and the problem goes away (due to the location 
> of the 100 ohm resistor, and the stubs causing reflections distorting 
> the signal).  The termination for a clock signal input isn't really 
> required (would be for a data signal to prevent ISI).
> 
> Subsequent versions of the DCM (S3 and V4) have even better phase 
> detectors which are more tolerant of the duty cycle.  Always room for 
> improvements.
> 
> Austin
> 
> John Cappello wrote:
> 
> > Hi,
> > 
> > We are seeing evidence that a DCM is intermittently selecting the
> > wrong tap position after it completes its lock sequence after a DCM
> > reset pulse. I'd like to know if anyone has experienced this effect,
> > and if they were able to resolve this problem.
> > 
> > In a 2v6000, I am using a variable phase shift DCM which is driven by
> > a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks
> > on its clk0/clk180 output pins. This interface uses IOB DDR regs for a
> > 622 Mhz/16-bit LVDS transmission solution.
> > 
> > The DCM initial value is set to 0. After a DCM reset, the DCM is phase
> > shifted to its predetermined optimal "error-free" setting. However,
> > intermittently, the interface experiences a small amount of bit
> > errors.
> > 
> > To eliminate the errors, the DCM is further phase shifted in one
> > direction until it actually achieves error-free operation. The
> > subsequent error-free window of operation in this mode matches very
> > closely to the original calibration error-free window.
> > 
> > It is as if the DCM locking sequence is corrupted somehow, resulting
> > in a mis-aligned tap position. We don't have conclusive evidence
> > because we can't see inside the DCM to see its tap position. We have
> > found that we can eliminate this error condition by applying another
> > one or two reset pulses to the DCM.
> > 
> > I realize that voltage fluctuations and switching noise could be
> > causing this effect. Nonetheless, I'd like to hear from real world
> > experiences.
> > 
> > Thank you.
> > John

John,

I replied to you directly on this already this AM, but for the benefit 
of the newsgroup, I will also reply in shorter fashion here.

The DCM is all digital.  If a clock edge is missing, nothing happens. 
But, if the clock edge comes back at exactly the right time later (not 
too much later, as if temperature of voltage changes, then the delay of 
the delay line changes), then the DCM picks up where it left off.  If 
the clock edge comes back while other clock edges are already in the 
delay line, then it has to be in the right phase relationship or the DCM 
will either loose lock, or shift in phase (try to track the new edge 
because it gets confused).

In a clock switch, phase is usually unknown, and often the frequency is 
slewing as well.  Not to mention distorted periods, bad duty cycles, etc.

When switching clocks, always reset the DCM after the clock is stable 
again after the switch.

Austin

John Cappello wrote:
> Austin,
> 
> Thanks for the insight on the duty cycle. We will check this. One more
> thing. What can we expect from the integrity of a DCM in a system
> where it is common to switch clock sources or clock frequencies? We
> have found that the DCM does not lose lock or indicate "clkin_stopped"
> during these sequences.
> 
> Are we supposed to reset the DCM after such an occurrence? If so, we
> are trying to figure out how we will know to do this since the DCM
> doesn't unlock or indicate that the input clock has stopped.
> 
> The DCM spec states (in the "Input Clock Changes" section) that the
> DCM can tolerate pauses or phase shifts in the clock, but later on in
> the spec, states "once locked to a frequency, cannot tolerate large
> variations of the input frequency." Exactly what is meant by "cannot
> tolerate"? Does this mean that it is possible for the DCM to offset
> its "phase shift" on the output clock from the optimal setting?
> 
> Thanks!
> John
> 
> 
> Austin Lesea <austin@xilinx.com> wrote in message news:<chprct$73l1@cliff.xsj.xilinx.com>...
> 
>>John,
>>
>>There have been cases where the frequency, jitter, and duty cycle are 
>>just on the edge of where the DCM phase detector will operate reliably.
>>
>>Check the input duty cycle.  It will need to be as close to 50% as you 
>>can make it.  The spec is 45 to 55%, but at the higher frequencies, it 
>>may have to be even closer to 50% when you take clock jitter into 
>>account (as if it is 45%, and it has jitter, then it is sometimes less 
>>than 45%!).
>>
>>Hope this helps.
>>
>>If you can vary the input clock duty cycle, you should be able to make 
>>it always work, never work, and be in between like it is now.  That will 
>>show you where it needs to be.
>>
>>Duty cycle management is a tough thing as it is affected by signal 
>>integrity, and at 311 MHz, signals get distorted very easily.
>>
>>Even observing the signal can be tough, as it doesn't look like it does 
>>on the die at the pins (just simulate it to see that).
>>
>>In the past, I have seen cases where the 100 ohm LVDS receive 
>>termination is removed, and the problem goes away (due to the location 
>>of the 100 ohm resistor, and the stubs causing reflections distorting 
>>the signal).  The termination for a clock signal input isn't really 
>>required (would be for a data signal to prevent ISI).
>>
>>Subsequent versions of the DCM (S3 and V4) have even better phase 
>>detectors which are more tolerant of the duty cycle.  Always room for 
>>improvements.
>>
>>Austin
>>
>>John Cappello wrote:
>>
>>
>>>Hi,
>>>
>>>We are seeing evidence that a DCM is intermittently selecting the
>>>wrong tap position after it completes its lock sequence after a DCM
>>>reset pulse. I'd like to know if anyone has experienced this effect,
>>>and if they were able to resolve this problem.
>>>
>>>In a 2v6000, I am using a variable phase shift DCM which is driven by
>>>a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks
>>>on its clk0/clk180 output pins. This interface uses IOB DDR regs for a
>>>622 Mhz/16-bit LVDS transmission solution.
>>>
>>>The DCM initial value is set to 0. After a DCM reset, the DCM is phase
>>>shifted to its predetermined optimal "error-free" setting. However,
>>>intermittently, the interface experiences a small amount of bit
>>>errors.
>>>
>>>To eliminate the errors, the DCM is further phase shifted in one
>>>direction until it actually achieves error-free operation. The
>>>subsequent error-free window of operation in this mode matches very
>>>closely to the original calibration error-free window.
>>>
>>>It is as if the DCM locking sequence is corrupted somehow, resulting
>>>in a mis-aligned tap position. We don't have conclusive evidence
>>>because we can't see inside the DCM to see its tap position. We have
>>>found that we can eliminate this error condition by applying another
>>>one or two reset pulses to the DCM.
>>>
>>>I realize that voltage fluctuations and switching noise could be
>>>causing this effect. Nonetheless, I'd like to hear from real world
>>>experiences.
>>>
>>>Thank you.
>>>John

Austin,
If John's used the input divide-by-2 mode, to make 311MHz from 622MHz
wouldn't that take care of any duty cycle problems?
Cheers, Syms.
"Austin Lesea" <austin@xilinx.com> wrote in message
news:chprct$73l1@cliff.xsj.xilinx.com...
> John,
>
> There have been cases where the frequency, jitter, and duty cycle are
> just on the edge of where the DCM phase detector will operate reliably.
>
> Check the input duty cycle.  It will need to be as close to 50% as you
> can make it.  The spec is 45 to 55%, but at the higher frequencies, it
> may have to be even closer to 50% when you take clock jitter into
> account (as if it is 45%, and it has jitter, then it is sometimes less
> than 45%!).
>
>
> John Cappello wrote:
>
> > Hi,
> >
> > We are seeing evidence that a DCM is intermittently selecting the
> > wrong tap position after it completes its lock sequence after a DCM
> > reset pulse. I'd like to know if anyone has experienced this effect,
> > and if they were able to resolve this problem.
> >
> > In a 2v6000, I am using a variable phase shift DCM which is driven by
> > a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks
> > on its clk0/clk180 output pins. This interface uses IOB DDR regs for a
> > 622 Mhz/16-bit LVDS transmission solution.
> >

Symon,

Yes, it would.  That is a nice trick, but you trade one problem (duty 
cycle) for another, getting a 622 MHz signal into the chip (SI is much 
tougher the higher the frequency).

I think John's problem is more that he has a clock that switches between 
two sources.  If the clock must switch, then you best reset the DCM.

Austin

Symon wrote:
> Austin,
> If John's used the input divide-by-2 mode, to make 311MHz from 622MHz
> wouldn't that take care of any duty cycle problems?
> Cheers, Syms.
> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:chprct$73l1@cliff.xsj.xilinx.com...
> 
>>John,
>>
>>There have been cases where the frequency, jitter, and duty cycle are
>>just on the edge of where the DCM phase detector will operate reliably.
>>
>>Check the input duty cycle.  It will need to be as close to 50% as you
>>can make it.  The spec is 45 to 55%, but at the higher frequencies, it
>>may have to be even closer to 50% when you take clock jitter into
>>account (as if it is 45%, and it has jitter, then it is sometimes less
>>than 45%!).
>>
>>
>>John Cappello wrote:
>>
>>
>>>Hi,
>>>
>>>We are seeing evidence that a DCM is intermittently selecting the
>>>wrong tap position after it completes its lock sequence after a DCM
>>>reset pulse. I'd like to know if anyone has experienced this effect,
>>>and if they were able to resolve this problem.
>>>
>>>In a 2v6000, I am using a variable phase shift DCM which is driven by
>>>a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks
>>>on its clk0/clk180 output pins. This interface uses IOB DDR regs for a
>>>622 Mhz/16-bit LVDS transmission solution.
>>>
> 
> 
> 

Austin Lesea <austin@xilinx.com> wrote in message news:<cht42i$6o86@cliff.xsj.xilinx.com>...
> Symon,
> 
> Yes, it would.  That is a nice trick, but you trade one problem (duty 
> cycle) for another, getting a 622 MHz signal into the chip (SI is much 
> tougher the higher the frequency).
> 
> I think John's problem is more that he has a clock that switches between 
> two sources.  If the clock must switch, then you best reset the DCM.
> 
> Austin
> 
> Symon wrote:
> > Austin,
> > If John's used the input divide-by-2 mode, to make 311MHz from 622MHz
> > wouldn't that take care of any duty cycle problems?
> > Cheers, Syms.
> > "Austin Lesea" <austin@xilinx.com> wrote in message
> > news:chprct$73l1@cliff.xsj.xilinx.com...
> > 
> >>John,
> >>
> >>There have been cases where the frequency, jitter, and duty cycle are
> >>just on the edge of where the DCM phase detector will operate reliably.
> >>
> >>Check the input duty cycle.  It will need to be as close to 50% as you
> >>can make it.  The spec is 45 to 55%, but at the higher frequencies, it
> >>may have to be even closer to 50% when you take clock jitter into
> >>account (as if it is 45%, and it has jitter, then it is sometimes less
> >>than 45%!).
> >>
> >>
> >>John Cappello wrote:
> >>
> >>
> >>>Hi,
> >>>
> >>>We are seeing evidence that a DCM is intermittently selecting the
> >>>wrong tap position after it completes its lock sequence after a DCM
> >>>reset pulse. I'd like to know if anyone has experienced this effect,
> >>>and if they were able to resolve this problem.
> >>>
> >>>In a 2v6000, I am using a variable phase shift DCM which is driven by
> >>>a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz clocks
> >>>on its clk0/clk180 output pins. This interface uses IOB DDR regs for a
> >>>622 Mhz/16-bit LVDS transmission solution.
> >>>
> > 
> > 
> >

Hi Austin,
I wanted to focus more on the DCM reset. As you may recall, we can fix
or break our system with multiple DCM resets. Whether due to bad clock
or fluctuating voltges, why would you suppose the integrity of the
dcm's output is decided only during this reset sequence? I am confused
because it seems that the DCM is constantly updating its tap position
in response to its phase comparators even during the locked state.
Thanks.
John

John Cappello wrote:
> Austin Lesea <austin@xilinx.com> wrote in message
news:<cht42i$6o86@cliff.xsj.xilinx.com>...
> > Symon,
> >
> > Yes, it would.  That is a nice trick, but you trade one problem
(duty
> > cycle) for another, getting a 622 MHz signal into the chip (SI is
much
> > tougher the higher the frequency).
> >
> > I think John's problem is more that he has a clock that switches
between
> > two sources.  If the clock must switch, then you best reset the
DCM.
> >
> > Austin
> >
> > Symon wrote:
> > > Austin,
> > > If John's used the input divide-by-2 mode, to make 311MHz from
622MHz
> > > wouldn't that take care of any duty cycle problems?
> > > Cheers, Syms.
> > > "Austin Lesea" <austin@xilinx.com> wrote in message
> > > news:chprct$73l1@cliff.xsj.xilinx.com...
> > >
> > >>John,
> > >>
> > >>There have been cases where the frequency, jitter, and duty cycle
are
> > >>just on the edge of where the DCM phase detector will operate
reliably.
> > >>
> > >>Check the input duty cycle.  It will need to be as close to 50%
as you
> > >>can make it.  The spec is 45 to 55%, but at the higher
frequencies, it
> > >>may have to be even closer to 50% when you take clock jitter into
> > >>account (as if it is 45%, and it has jitter, then it is sometimes
less
> > >>than 45%!).
> > >>
> > >>
> > >>John Cappello wrote:
> > >>
> > >>
> > >>>Hi,
> > >>>
> > >>>We are seeing evidence that a DCM is intermittently selecting
the
> > >>>wrong tap position after it completes its lock sequence after a
DCM
> > >>>reset pulse. I'd like to know if anyone has experienced this
effect,
> > >>>and if they were able to resolve this problem.
> > >>>
> > >>>In a 2v6000, I am using a variable phase shift DCM which is
driven by
> > >>>a 622 MHz clock (divide-by-2 mode). The DCM generates 311 MHz
clocks
> > >>>on its clk0/clk180 output pins. This interface uses IOB DDR regs
for a
> > >>>622 Mhz/16-bit LVDS transmission solution.
> > >>>
> > >
> > >
> > >
>
> Hi Austin,
> I wanted to focus more on the DCM reset. As you may recall, we can
fix
> or break our system with multiple DCM resets. Whether due to bad
clock
> or fluctuating voltges, why would you suppose the integrity of the
> dcm's output is decided only during this reset sequence? I am
confused
> because it seems that the DCM is constantly updating its tap position
> in response to its phase comparators even during the locked state.
> Thanks.
> John

John Cappello:
I was wondering how you solved your problem. I also have a system that
behaves like yours, I mean that we can fix or break it with multiple
DCM resets. We can even configure DCM for a fixed phase value (not
variable) and even then, the problem shows up. 90% of the resets work
well and of the resets causes a problem. If we do a "bathtub" (DCM
phase shift x BER) using variable DCM phase values and reset at each
increment, we can see clearly the "spikes" in our bathtubs, when things
go wrong. Looks like something funny in the reset sequence. Am I
missing something trivial in the settings of the DCM?
I would appreciate any feedback!
Rgds,
Roberto Mattos