How to simulate netlist with gated clock?

Discussion in 'Cadence' started by Davy, Nov 7, 2006.

  1. Davy

    Davy Guest

    Hi all,

    When I simulate netlist with gated clock, I found the output is very
    different with what I see in RTL level.

    So I add tfile in NCSim to forbidden the delay and timing check in
    global scope (Because the design have no memory like RAM/FIFO).

    The netlist waveform seems to be better, but there are also some
    trivial differences between RTL and netlist waveforms (e.g. some signal
    have one clock advance and some signal have one clock delay). I guess
    gated clock does not behavior like original clock and introduce race.

    But how to understand gated clock simulation behavior? Any
    comments/reference will be appreciated!
    Thanks!

    Best regards,
    Davy
     
    Davy, Nov 7, 2006
    #1
  2. Davy

    backhus Guest

    Hi Davy,
    When you say netlist simulation do you mean a timing simulation?
    And when you say RTL level simulation Do you mean a behavioral simulation?
    If my assumtions are correct think about the following:

    If you are using gated clocks, the gate has no delay in behavioral
    simulation, so your circuit works as expected. But in Timing simulation
    the gate and the associated routing creates a delay to the clock signal
    of the connected registers. The effects depend on the desired clock
    speed, and may be significant as you already observed.

    To overcome this you should consider using Clock Enable inputs rather
    than gating the critical clock net.

    And, yes you guessed right. A gated clock doesn't behave like the
    original clock because it's a totally different signal.
    You can compare it to trains. One on rails (clock net), the other not
    (normal routing ressources). Guess wich one misses it's schedule at the
    next station. :)

    Have a nice simulation
    Eilert
     
    backhus, Nov 7, 2006
    #2
  3. Davy

    Davy Guest

    Hi backhus

    Thanks a lot!

    I heard latch is only used in gated clock in ASIC design. Is it right?

    I think it must be gated clock cause the problem. I see the waveform.
    And I found though data and clock change at the same time i.e at the
    same delta time (I forbidden timing delay at global scope), clock
    change is follow the data change.

    As we all know data change must follow the clock change. So I guess
    there must be gated clock cause some logic sequence chaos in simulator.

    Best regards,
    Davy
     
    Davy, Nov 8, 2006
    #3
  4. Davy

    backhus Guest

    Hi Davy,
    I`m more familiar with FPGA design than ASIC design, but I think for
    both targets latches should be avoided. They are not sensitive to clock
    edges, and data changes while they are enabled pass the latch causing
    trouble in the circuit that follows.

    I'm not sure if there are still designs which have to use latches
    instead of FFs for some reason. But to my knowledge Clock gating for
    latches is a design technique from way back when, when there were no
    real FFs available and the clock frequencies were about 1 MHz.

    From the groups you are posting to, I guess that you are using NC-Sim,
    dont'you?
    If you say that you wonder about the seqence of changes (Clock
    before/after Data or vice versa) what time scale are you talking about?
    Do you change Data within the setup/hold time of your FFs? This may lead
    to strange results in your simulator.
    Besides simulation, have you made a static timing analysis for your design?

    Have a nice simulation
    Eilert
     
    backhus, Nov 8, 2006
    #4
  5. Davy

    sharp Guest

    A gated clock will be delayed relative to the original clock, by the
    delay of the gate used to gate it. In a timing simulation, this will
    be a positive time delay. In a zero-delay simulation, this will be
    more like a delta cycle delay. In either case, this can introduce a
    race condition.

    If you have flip-flops A and B, where A is clocked by the original
    clock, and B is clocked by the gated clock, and the input of B is
    driven by A, then you have a potential race condition. The output of A
    can change before B is clocked by the delayed gated clock. It only
    works if the propagation delay from the clock through A to the input of
    B is greater than the propagation delay from the clock to the gated
    clock (actually, it has to exceed it by the hold time of B). This is
    true even in zero-delay, except that the delays are essentially delta
    cycles (and Verilog makes no guarantees about delta cycle ordering, so
    you cannot rely on anything here).

    This kind of problem is why some design methodologies forbid gated
    clocks, and require the use of clock enabled flip-flops instead.
     
    sharp, Nov 8, 2006
    #5
  6. Davy

    daytripper Guest

    Or you build the moral equivalent with a feedback mux fronting the flip-flop.

    Adding skew to the equation for a gated clock just increases the intensity of
    the headache. Gated clocks are forbidden in the Reality-based Community ;-)
     
    daytripper, Nov 8, 2006
    #6
  7. Davy

    Davy Guest

    [snip]
    Hi backhus,

    Thanks for the help!
    Yes, I use NC-Sim. My knowledge of gated clock is from a SNUG paper
    "How to successfully use gated clocking in an ASIC design".
    Do you think timescale is a relative matter (corresponding to delay)?
    I forbidden all the delay and timing check (i.e. setup/hold timeing
    check of FFs). Will it lead to strange results?
    I want to do functional simulation of gate level and don't care
    delay(and they are not accurate).
     
    Davy, Nov 9, 2006
    #7
  8. Davy

    Davy Guest

    [snip]
    Yes, I agree.
    Do you mean both ASIC and FPGA have methodology forbid gated clocks (I
    know that FPGA forbid gated clock and use clock enabled D-FF). Thanks!
     
    Davy, Nov 9, 2006
    #8
  9. Do you change Data within the setup/hold time of your FFs? This may lead
    If the checks are enabled you will see at least the violations, and that might give
    clues what goes wrong.
    With gated clocks the SDF usually has to be almost timing clean, otherwise
    strange things can happen. Gated clocks are harder to simulate, and make
    X chasing much harder, it can come trough the clock pin also ;)

    --Kim
     
    Kim Enkovaara, Nov 9, 2006
    #9
  10. Davy

    sharp Guest

    I am not talking about the rules enforced by particular tools. I am
    talking about general good digital design practices, independent of the
    implementation technology. Gated clocks create bugs in designs, due to
    timing problems from extra clock skew, and the potential for glitches
    on the clocks being created by the gating logic.

    When I was an undergraduate student 20 years ago, we were taught never
    to gate a clock. There are some design methodologies that do it, but I
    expect that the successful ones have very strict rules about when and
    how to do it. That is why you found a paper that was written about a
    way to do it correctly. If you don't have the skill and discipline to
    do it exactly right, you should avoid it entirely.
     
    sharp, Nov 9, 2006
    #10
  11. Davy

    gerry Guest

    Forbidding Gated clocks kind of misses the point.

    Proper simulation should pick up all race conditions.

    When you Gate clocks, you are introducing an interesting situation that
    can be very difficult to get right. Clocks, by their nature, typically
    need
    to have a minimum pulse width. If the gating is not sync'ed to the
    clock properly
    then you could violate the setup or hold requirements of the FF or
    latch.

    When you have a non-gated clock, you typically do not need to worry as
    much
    about the (unexpected ) width of an individual clock pulse width as all
    will be close
    to the same duty cycle. Once you add gating of clocks, this adds
    another dimension
    to the already tricky job of ensuring that the DATA to CLOCK setup and
    hold times
    are not violated.

    Any well set up digital simulator can be set up to generate X states
    whenever you are
    violating the setup or hold requirements of the DATA relative to CLOCK.
    You now have to
    also ensure that artificially short CLOCK pulses are also properly
    verified.

    ( Often simplistic setup & hold checking could miss narrow clock pulses
    as this case
    is not always tested )

    YMMV

    -- Gerry
     
    gerry, Nov 9, 2006
    #11
Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.