Generating Device Clocks That Start at 400kHz and Stop Mid-Transaction

Your SD card interface clock has to start at 400kHz, then negotiate its way up to 200MHz – and it must be able to stop mid-stream when your CPU can't drain the receive buffer. That's the kind of real-world constraint Dan Gisselquist's ZipCPU blog tackles in a deep dive on device clock generation for FPGAs and ASICs.

Why Clock Division Is Harder Than You Think

An FPGA can be rebuilt if the board won't support a particular frequency. An ASIC cannot – that's a cost-prohibitive failure. So the clock generator for an ASIC must handle runtime frequency changes, no exceptions. The NAND flash controller starts slow and only after bring-up can it switch to full speed. The SDIO/eMMC controller needs to go from 400kHz to 25, 50, 100, or 200MHz depending on the card, PCB, and controller capabilities.

And you can't just divide a master clock down and call it done. Some protocols require the clock to be paused – not just gated off when idle, but held in a specific state for a cycle after chip select drops (NOR flash) or for multiple cycles after a transaction ends. The SD card case is even hairier: if the CPU is slow draining buffers, you must stop the interface clock before the card sends a third block into a full FIFO.

The 90-Degree Offset Problem for DDR

Dual Data Rate (DDR) protocols demand data transitions on both clock edges. That requires a clock that is 90 degrees out of phase with the data – so each clock edge lands in the middle of the data valid window, not on the edge. This offset guarantees setup and hold times at the slave peripheral. The blog post includes a clear diagram: SDR clock aligns with data edges; DDR clock is shifted to center the sampling point.

Getting that 90-degree offset while also supporting frequency changes and pauses is not trivial. It's why many hardware engineers end up with complex clock management blocks that handle everything from SPI masters to DDR memory controllers and Ethernet PHYs (10/100/1000 Mbps).

Pausing the Clock Without Breaking the Protocol

The NOR flash controller taught the author early: the clock must be off when nothing is happening, off for one cycle after activating chip select, and off for a couple cycles after the transaction completes before deasserting chip select. Then the HyperRAM controller failed because the return clock wasn't handled properly – a topic promised for a follow-up article.

I2C is too slow to care. I3C might benefit from these techniques, but the author admits limited familiarity. SPI slaves handle clocks differently from masters. The focus here is on the master-side clock generation: an output signal that drives the external device, with the ability to start, stop, and change frequency on the fly.

The upshot: if you're building a controller for SDIO, NAND flash, or any peripheral that negotiates speed and expects idle clock states, you need a clock generator that does more than just divide down a PLL output – it must be a state machine that respects protocol timing at every step. The next piece in this series will tackle the return clock problem, which is where DDR memories and eMMC really earn their keep.

Source: Device Clock Generation (2025)
Domain: zipcpu.com