The interviewer describes a combinational enable that glitches for a nanosecond mid-cycle, then asks whether the design fails and what changes if the glitch lands on a clock line.
The question tests hazard placement. The same glitch is harmless in one place and fatal in another.
On a synchronous clock-enable sampled at the edge, a mid-cycle glitch that settles before setup changes nothing. On a clock line or a latch enable, the same glitch is an extra edge or a transparent window.
A direct synchronous CE is valid when enable and data meet setup/hold at the receiving register. If control is deliberately pipelined, pipeline its data too or require the producer to hold the associated data through the later accepting edge. Clock gating instead uses a library ICG: its low-phase latch or specified capture element holds the gating decision during the active clock phase. An extra rising-edge enable register is not universally required.
Glitch lands on | Effect |
|---|---|
Synchronous enable, settled before setup | No effect; sampled once at the edge |
Gated clock ( | Extra edge; state corrupts |
Latch enable | Transparent window; data slips through |
Each slot is a quarter of a clock period, so a rising clock edge falls between slots 1 and 2 and again between slots 5 and 6.
Slot 1: d changes to c3 with en_comb low. Nothing should load it.
Slot 2: en_comb glitches high while clk is high. The rising edge just before it saw en_comb = 0, so q_ce keeps a1.
Slot 2, gated clock: gclk = clk & en_comb rises with the glitch. That is an extra edge, and q_g wrongly loads c3.
Slot 6: a real enabled edge; both flops load d5, so only the glitch separates them.
How is it proven? A testbench drives a mid-cycle pulse that returns low before the edge, then checks that nothing loaded. The solution below does exactly that.
Is a gated clock ever acceptable? Use a library ICG with its specified capture mechanism, test override and gating checks. The always-on controller must still be able to reopen a stopped domain; follow the clock-gating contract.
What about the enable timing? A registered enable still needs setup at its sampling flop. Registration moves the constraint to a clean single-cycle path.
“Glitches do not matter in synchronous design” is half true. It holds for sampled enables and fails for clocks and latches.
“Add delay to filter the glitch” is fragile across PVT. For CE, close the sampling window; for a clock, use the approved ICG. Adding control latency without aligning data changes behavior.
// bad-example
module gated_clk_bad (
input logic clk, en,
output logic gated_clk
);
assign gated_clk = clk & en;
endmoduleNo. The flop samples the enable only at the edge, where it reads 0. The testbench below checks this case explicitly.
The direct CE below captures A1 on an enabled edge, holds A1 when the next edge offers C3 disabled, ignores a settled mid-cycle pulse, then captures D5. Changing the data every cycle exposes the old en_q/current-data misalignment.
module ce_reg #(parameter int W = 8) (
input logic clk,
input logic en_comb,
input logic [W-1:0] d,
output logic [W-1:0] q
);
always_ff @(posedge clk) begin
if (en_comb) q <= d;
end
endmodule
The digital enable check, run with Icarus Verilog 13.0 (2026-10-16): prints PASS. It does not measure setup/hold or ICG timing.