«

Jonathan Bromley wrote:

> We've easily enough got around this for the present
> design, but I'd love to know what all you seasoned
> PLL/DCM users out there do about it. Do you
> introduce small non-zero time delays in all the
> signals crossing the clock domains, so that it all
> works in simulation? Do you treat the various
> clock domains as if they were asynchronous, thereby
> losing one of the nicest benefits of the PLLs? Or
> do you simply accept that it's necessary to do timing
> simulation in order to see what will really happen?

Naturally, I would prefer to fix up the design
to use a single clock or another "known good"
synchronization scheme.

If I were forced to use both clocks,
and to trust that the vendor got the
analog portions of the PLL right, I would
write a simplified rtl model that
just trusted the vendor specs.
I don't think a gate sim would make me feel better.
Maybe a SPICE sim would

This is analogous to the case of a
two flop bit synchronizer. I might simplify
a model that gave me 'U' outputs for
setup violations because I 'believe"
the synchronizer will work well enough.

> ... I swapped-in
> much simpler, but perfectly adequate in-house models and
> got x10 simulation speedup.

Sounds reasonable to me.


-- Mike Treseler

On Nov 17, 3:38*pm, Mike Treseler <mtrese...@gmail.com> wrote:
> Jonathan Bromley wrote:
> > We've easily enough got around this for the present
> > design, but I'd love to know what all you seasoned
> > PLL/DCM users out there do about it. *Do you
> > introduce small non-zero time delays in all the
> > signals crossing the clock domains, so that it all
> > works in simulation? *Do you treat the various
> > clock domains as if they were asynchronous, thereby
> > losing one of the nicest benefits of the PLLs? *Or
> > do you simply accept that it's necessary to do timing
> > simulation in order to see what will really happen?
>
> Naturally, I would prefer to fix up the design
> to use a single clock or another "known good"
> synchronization scheme.
>
> If I were forced to use both clocks,
> and to trust that the vendor got the
> analog portions of the PLL right, I would
> write a simplified rtl model that
> just trusted the vendor specs.
> I don't think a gate sim would make me feel better.
> Maybe a SPICE sim would
>
> This is analogous to the case of a
> two flop bit synchronizer. I might simplify
> a model that gave me 'U' outputs for
> setup violations because I 'believe"
> the synchronizer will work well enough.
>
> > ... I swapped-in
> > much simpler, but perfectly adequate in-house models and
> > got x10 simulation speedup.
>
> Sounds reasonable to me.
>
> * *-- Mike Treseler

Not quite where Jonathan was headed with this, but:

Applying "standard" synchronization techniques to not-quite-
asynchronous interfaces can and has caused problems. With truly
asynchronous interfaces, the probability that an input will fall
within the narrow region that causes metastability lasting long enough
to be a problem (with two flop synchronizers) is extremely rare.
However, if the two clock domains are related, such an event can
happen much more often (or never at all). If they do happen (i.e. the
stars align...) they will happen much more frequently (i.e. the stars
will stay aligned).

If at all possible I would take steps to ensure that either the clocks
are related and a fully synchronous interface is employed, or that
they are not related and asynchronous interface techniques are
employed. Failing that, a three stage synchronizer should be
considered.

I have solved the simulation problem in the past by running the main
clock through the same module where the DCM is, and providing a 1:1
clock output that is delayed (RTL) for the same number of delta cycles
as the DCM delays its output. That delayed 1:1 output is used to drive
the rest of the design. This is not always easy, especially when the
DCM would otherwise best be buried down at an appropriate level of
hierarchy along with it's associated functionality.

Andy

"Jonathan Bromley" <> wrote in message
news:...
>
>>I have solved the simulation problem in the past by running the main
>>clock through the same module where the DCM is, and providing a 1:1
>>clock output that is delayed (RTL) for the same number of delta cycles
>>as the DCM delays its output. That delayed 1:1 output is used to drive
>>the rest of the design. This is not always easy, especially when the
>>DCM would otherwise best be buried down at an appropriate level of
>>hierarchy along with it's associated functionality.
>
> Perfect summary of the issues I was hoping to raise. Thanks.
> --
> Jonathan Bromley, Consultant
>
It also seems that if the design only uses the outputs from the DCM only,
i.e. CLK0, CLKDV, CLK2X, which is the way they are 'meant' to be used, then
they are already aligned. Problems arise when folks subsequently add stuff
to their VHDL like:-

my_clock <= his_clock;

This assignment is optimised away in real life, but in the simulation,
my_clock is now a delta later than his_clock, and maybe no longer aligns
with his_clock_2X.

HTH., Syms.

Symon wrote :
>
> It also seems that if the design only uses the outputs from the DCM only,
> i.e. CLK0, CLKDV, CLK2X, which is the way they are 'meant' to be used, then
> they are already aligned.
>
That's how the DCM model is _supposed_ to work, but I've
encountered problems with delta delay offsets in the Xilinx
DCM models in years past:

http://groups.google.com/group/comp....5b0b6da92b4ad1

Other thoughts:

As suggested elsewhere on the thread, I usually attempt
to bundle all the DCM's into a clock module that can be
replaced by a simpler model for functional sims.

This module also gives a handy spot to take care of any DCM
reset sequencing, unlock logic, and the startup enables needed
to avoid the insidious initialized BRAM corruption feature.
( IIRC, xapp873.zip has an example of this sort of thing )

One additional suggestion: even if one replaces the DCM module
for functional sims, it is very helpful to thoroughly beat up
the actual DCM module in it's own simulation testbench to make
sure all of the required startup and unlock recovery sequencing
is done properly without the simulation model throwing any errors.

Brian