Re: Aligned PLL clocks in RTL simulation

Discussion in 'VHDL' started by Mike Treseler, Nov 17, 2008.

  1. 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
     
    Mike Treseler, Nov 17, 2008
    #1
    1. Advertising

  2. Mike Treseler

    Andy Guest

    On Nov 17, 3:38 pm, Mike Treseler <> 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
     
    Andy, Nov 18, 2008
    #2
    1. Advertising

  3. Mike Treseler

    Symon Guest

    "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, Nov 18, 2008
    #3
  4. Mike Treseler

    Brian Davis Guest

    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.arch.fpga/msg/6e5b0b6da92b4ad1

    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
     
    Brian Davis, Nov 19, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anand P Paralkar

    ASIC RTL and FPGA RTL

    Anand P Paralkar, Apr 26, 2004, in forum: VHDL
    Replies:
    1
    Views:
    4,990
    Alexander Gnusin
    Apr 26, 2004
  2. Uwe Bonnes
    Replies:
    0
    Views:
    505
    Uwe Bonnes
    Nov 17, 2008
  3. Mark McDougall

    Re: Aligned PLL clocks in RTL simulation

    Mark McDougall, Nov 17, 2008, in forum: VHDL
    Replies:
    0
    Views:
    492
    Mark McDougall
    Nov 17, 2008
  4. Allan Herriman

    Re: Aligned PLL clocks in RTL simulation

    Allan Herriman, Nov 18, 2008, in forum: VHDL
    Replies:
    0
    Views:
    811
    Allan Herriman
    Nov 18, 2008
  5. Kim Enkovaara
    Replies:
    0
    Views:
    524
    Kim Enkovaara
    Nov 19, 2008
Loading...

Share This Page