Part 9: Phase-Locked Loop (PLL) and Glitches

What this lecture covers

This lecture answers two related questions: how do you get a faster clock than the iCEstick's 12 MHz oscillator, and what goes wrong in digital logic once clock speeds increase? It configures the iCE40's on-chip phase-locked loop (PLL) as a clock multiplier producing 120 MHz, verifies the result on an oscilloscope, then uses a simulated four-bit ripple counter to show how propagation delay causes glitches - momentary incorrect values - that become a real problem only at high clock speeds.

By the end you can calculate PLL divider settings with the icepll tool, instantiate the SB_PLL40_CORE primitive in Verilog, and explain why a ripple counter's un-registered output can briefly show wrong values, and why that usually doesn't matter for a registered output at normal clock speeds.

Key ideas

• Phase-locked loop (PLL): a circuit that produces an output whose frequency and phase are locked to a reference signal, built from a voltage-controlled oscillator, phase detector, and low-pass filter.
• Clock multiplication: inserting a divider between the oscillator and phase detector forces the VCO to run at a multiple of the reference frequency, letting a PLL turn a slow reference clock into a much faster output clock.
• icepll tool: calculates the reference, feedback, and VCO dividers needed to hit a target output frequency from a given input frequency, sparing you the manual math from the Lattice PLL design guide.
• SB_PLL40_CORE: the iCE40-specific primitive used to instantiate the on-chip PLL in Verilog, configured with the divider values from icepll, a simple feedback path, and the GENCLK output select for no phase shift.
• Propagation delay: the small but nonzero time it takes a signal change to move through a wire or lookup table, which becomes significant relative to a clock period as clock speed increases.
• Glitch: a brief, incorrect intermediate value that appears while a multi-bit signal (like a ripple counter's un-registered output) settles, caused by different bits updating after different propagation delays.
• Registered output safety: because the counter's actual output is captured on a clock edge, glitches on the combinational path usually don't matter at normal clock speeds - only if the clock is fast enough that a glitch occurs right at the sampling edge does it become a real bug.

Walkthrough

What a PLL does (0:29)

The lecture explains the PLL's components - VCO, phase detector, low-pass filter - and how adding a divider in the feedback path turns the circuit into a clock multiplier, using a 36 MHz-to-12 MHz example to illustrate the idea.

Calculating PLL settings with icepll (1:40)

Referencing the Lattice PLL design and usage guide's constraints (reference clock 10-133 MHz, VCO output 533-1066 MHz, final output 16-275 MHz), the lecture runs icepll -i 12 -o 120 to get the reference, feedback, and VCO divider values (and filter range) needed to turn the iCEstick's 12 MHz clock into 120 MHz.

Implementing the PLL in Verilog (6:03)

The lecture instantiates SB_PLL40_CORE with the calculated divider parameters, a simple feedback path, GENCLK output select, and an always-enabled active-low reset, connecting the reference clock to pin 21 and routing the multiplied output to a Pmod pin for measurement. Uploading the design and probing the output pin with an oscilloscope confirms a 120 MHz signal, though the waveform is visibly distorted at that frequency.

Propagation delay (10:16)

The lecture introduces propagation delay - the time for a signal change to appear at a gate or lookup table's output - and notes that the iCE40 datasheet only specifies pin-to-pin delay through a LUT, leaving internal delays for the place-and-route tool to manage.

Ripple counter and glitches (12:09)

Using a four-bit ripple counter built from half adders with simulated one-nanosecond gate delays in a test bench, the lecture shows that each bit updates sequentially rather than all at once, so the un-registered sum output briefly passes through incorrect intermediate values before settling.

Observing glitches in GTKWave (19:08)

Simulation waveforms show the un-registered output briefly reading 0 when it should read 2, and similar momentary errors elsewhere, while the registered count value updates correctly each clock cycle. The lecture explains that this only becomes a real bug if the clock is fast enough that a sampling edge lands during a glitch, and closes with a challenge to design a counter that reduces or eliminates this glitching.

Before you watch

• Complete Part 8 ("Memory and Block RAM"); this lecture assumes familiarity with writing test benches and using GTKWave from earlier episodes.
• Recall the full adder / half adder logic from Part 3, since the ripple counter example is built from half adders.

Check your understanding

1. How does adding a divider in a PLL's feedback path turn it into a clock multiplier?
2. What values does icepll calculate, and why is manual computation from the datasheet impractical?
3. Why does the iCE40 datasheet only specify propagation delay from pin to pin through a lookup table?
4. In the ripple counter example, why does the un-registered out value glitch but the registered count value normally does not?
5. Under what condition would a glitch in the ripple counter actually corrupt the counter's stored value?