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

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
> 

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

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.

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

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

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!

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