CODEWITHSUNDEEP
verilogsystem-verilogdigital-logicregister-transfer-levelvlsi
newbie
newbie

Reputation: 4789

How does clock gating in RTL design work?

I'm trying to understand how clock gating works in RTL design.

I've an example wave here:

enter image description here

Description:

1st signal is gated_clock
2nd signal is clock_enable
3rd signal is ungated_clock

So there are 3 cycles in this wave (let's say cycle 0,1,2). In cycle 0, clock_enable was low and gated_clock was turned off. In cycle 1 clock_enable goes high and in next cycle (cycle 2) gated_clock turns on.

Now, during simulation I see some cases where an incoming data received at cycle 1 is properly being registered into the module that is gated by the clock (using gated_clock). It's kinda odd to me and I don't quite understand how it's possible.

The logic is like this:

always_ff @(posedge gated_clock, negedge reset) begin
   if (~reset) begin
      some_val <= 1'b0;
   end else begin
      if (in_valid==1'b1 && in_ready==1'b1) begin
         some_val <= in_val;
      end else begin
         some_val <= 1'b0;
      end
   end
end

So I'm seeing that if in_valid and in_ready was high in cycle 1 then some_val will register the incoming in_val data and it'll be available in cycle 2. However in cycle 1, gated_clock was zero. So how did the in_val get sampled here? From what I understand, posedge gated_clock must be 1 if we want to flop in_val in cycle 1 .

I might be missing some core circuit level digital design concept. I'll really appreicate any help.

Updated wave: enter image description here

1st signal is gated_clock
2nd signal is clock_enable
3rd signal is ungated_clock
4th signal is in_valid
5th signal is in_ready
6th signal is in_val
7th signal is some_val

So here you will see at cycle 0, gated_clock is off but in_val and in_ready is high. The input data in_val is also high. In next cycle some_val goes high. So it looks like in_val captured in cycle 0 even though gated_clock was off.

Upvotes: 0

Views: 1419

Answers (3)

dbosky
dbosky

Reputation: 1641

Based on the new waveform some_val is generated correctly to the posted RTL. On the very first edge of gated_clock signals in_valid and in_ready are both high, thus some_val is going high too in that cycle. On the next edge it toggles back to low because in_valid goes low (and btw in_val too)

Upvotes: 0

dave
dave

Reputation: 4922

Your understand of what is clocked seemed off. in_val isn't clocked here (actually, from the snippet, I can't see where it is coming from). It is free to change at will (again, from the point of view of this snippet). At the point that gated_clock goes high then whatever the value of in_val at that time will now be captured in some_val and this will be available until such time as gated_clock goes high again (at which point we will sample a new value).

Upvotes: 1

dave_59
dave_59

Reputation: 42658

It's possible there is a glitch on the gated clock that's not showing up on the waveform. You'll need to look at the User Manual of the tool you're using to find out how to record and display glitches. It might also help to see the logic for gating the clock. Is clock_enable assigned using an NBA (<=)?

Upvotes: 1

Related Questions