> 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
> > >>>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
Reply by John Cappello●September 13, 20042004-09-13
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
Reply by Austin Lesea●September 10, 20042004-09-10
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.
>>>
>
>
>
Reply by Symon●September 10, 20042004-09-10
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.
> >
Reply by Austin Lesea●September 10, 20042004-09-10
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
Reply by John Cappello●September 9, 20042004-09-09
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
Reply by Austin Lesea●September 9, 20042004-09-09
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
Reply by John Cappello●September 8, 20042004-09-08
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