How to simulate netlist with gated clock?

[Davy]

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

 

[backhus]

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

Davy schrieb:

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]

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

backhus wrote:

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

Davy schrieb:
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

 

[backhus]

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


Davy schrieb:

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

backhus wrote:
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

Davy schrieb:
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 wrote:

I guess
gated clock does not behavior like original clock and introduce race.

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.

 

[daytripper]

On 8 Nov 2006 10:30:01 -0800, sharp@cadence.com wrote:

Davy wrote:

I guess
gated clock does not behavior like original clock and introduce race.

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

 

[Davy]

backhus wrote:

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?
[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".

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 think timescale is a relative matter (corresponding to delay)?

Do you change Data within the setup/hold time of your FFs? This may lead
to strange results in your simulator.

I forbidden all the delay and timing check (i.e. setup/hold timeing
check of FFs). Will it lead to strange results?

Besides simulation, have you made a static timing analysis for your design?

I want to do functional simulation of gate level and don't care
delay(and they are not accurate).

Have a nice simulation
Eilert


Davy schrieb:
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

backhus wrote:
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

Davy schrieb:
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]

sharp@cadence.com wrote:

Davy wrote:

I guess
gated clock does not behavior like original clock and introduce race.

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

Yes, I agree.

This kind of problem is why some design methodologies forbid gated
clocks, and require the use of clock enabled flip-flops instead.

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!

 

[Kim Enkovaara]

Do you change Data within the setup/hold time of your FFs? This may lead
to strange results in your simulator.


I forbidden all the delay and timing check (i.e. setup/hold timeing
check of FFs). Will it lead to strange results?

If the checks are enabled you will see at least the violations, and that might give
clues what goes wrong.

Besides simulation, have you made a static timing analysis for your design?


I want to do functional simulation of gate level and don't care
delay(and they are not accurate).

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

 

Davy wrote:

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!

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.