How to simulate netlist with gated clock?

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

 

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

 

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

 

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

 

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.

 

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 ;-)

 

[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).

 

[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!

 

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

 

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.

 

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