fpgadesign.io #4 - Clocks should be Handled with Extreme Care
👋 Welcome back.
Last issue: reset. Assert asynchronously, de-assert synchronously — and one reset bridge per clock domain, not one global reset trying to serve them all. A few of you wrote back with reset bugs that had been hiding in the lab for months. Keep them coming.
This time: clocks. Specifically, what happens when you try to switch one at runtime and treat it like ordinary logic. 🤔
⚡ Concept of the Week: A clock is not a signal you can just mux.
Here's a scenario that shows up in real systems. Your design runs at 100 MHz in normal mode. A high-throughput mode needs 122.88 MHz. Both clocks are free-running and always present. At runtime, software writes a control register and the whole datapath has to move from one clock to the other — live. No reset, no reconfiguration. A clean, hot-swap change.
The instinct is a 2:1 mux:
assign clk_out = sel ? clk_122 : clk_100;
A control bit picks the clock. Done.
Except that's two bugs in one line.
First, sel comes from the software domain — asynchronous to both clocks. Flip it in the middle of a high phase and you truncate a pulse. A runt edge, narrower than the minimum pulse width the flip-flops need. That's a glitch, and every flop on that clock can potentially go metastable — at the exact moment you were trying to switch cleanly.
Second, clk_out is now the output of a LUT being used as a clock. It rides general routing, not the global clock backbone. The timing tools won't characterize it as a proper clock — you get uncharacterized skew and jitter, and STA throws warnings rather than a clean report.
A mux selects a value. A clock is a waveform. Different problem, different hardware.
And this is the part worth calling out: it's an FPGA-specific answer. On an ASIC you'd reach for a glitch-free clock-mux cell from the standard-cell library, characterized for exactly this handoff. On an FPGA you don't design that cell — and you don't have to, because the vendor already built it into the global clock network as a dedicated primitive.
In the Xilinx/AMD world, that primitive is BUFGMUX — a global clock buffer with a select input. Feed it both clocks and the control bit. It synchronizes the select to each clock, does a break-before-make handoff with the output held low across the switch, and drives the result onto the global network. Glitch-free by construction.
BUFGCTRL is the superset — the same switch with full control exposed (clock enables, dual selects, edge handling). BUFGMUX is just the convenient wrapper around it.
One honest caveat: the glitch-free switch waits for a safe condition on the outgoing clock before it hands over. If that clock has stopped, the condition never arrives and the switch never completes. BUFGCTRL's IGNORE0/IGNORE1 force it through immediately — but you give up the glitch-free guarantee to do it. (Book: Ch3 §3.9 makes the same case for clock gating — clock logic in the fabric glitches. The clock mux is the same trap, one level up.)
🎯 Interview Question of the Week
Q: "You need to switch between two clock sources at runtime. Why not just use a 2:1 mux? And what would you use instead?"
How to approach it: don't stop at "it might glitch." Explain why — the select is asynchronous to both clocks, so a mid-phase toggle truncates a pulse and risks metastability downstream. Then the second half most candidates miss: the mux output becomes a clock on general routing, not the global backbone, so it's never properly timed. Land it by naming the dedicated primitive (BUFGMUX / BUFGCTRL) and what it does — synchronized select, break-before-make, on the global network. And flag that this is an FPGA-specific answer: on an ASIC you'd use a standard-cell clock mux; on an FPGA you reach for the vendor primitive. (This is Ch3 §3.9 territory.)
🧩 Design Question of the Week
Design: A single-cycle pulse fires in a 200 MHz clock domain. You need to catch it — exactly once, no misses, no duplicates — in a 50 MHz domain.
A two-flop synchronizer on the pulse isn't enough. Why not? And what do you build instead?
Think about what happens to a one-cycle-wide pulse when the receiving clock is 4× slower. If anything's unclear or you want to talk through your approach, just reply — I read every email. 🙋
🛠 Author's Note
The fabric is for logic. The moment you find yourself doing something to a clock — switching it, gating it, dividing it — stop and look for the dedicated primitive first. FPGAs give you a whole global clocking network and purpose-built buffers precisely because clocks routed through ordinary logic don't behave. Almost every "works in sim, flaky in hardware" clock bug I've seen started with a clock that went somewhere it shouldn't have.
📌 Latest from fpgadesign.io
✍️ On the site: The Complete FPGA & RTL Interview Preparation Roadmap — the full map of what digital design interviews actually test, broken into 8 modules and tagged by how often each comes up (core / common / senior), with a printable checklist and a four-week plan. No signup required → Read the roadmap
🔄 ICYMI on LinkedIn
⚡ Hardware interviews have a LeetCode problem — a personal story about being marked down for not reciting a bus signal list from memory, and an appeal to fellow interviewers: whatever can be referenced has no reason to be memorized. A good interviewer takes the simplest concept and goes deep.
💬 Reader Mailbag
Last issue I asked whether you'd ever chased a bug that turned out to be a reset issue in disguise. Great replies — a few are going into a future issue.
This issue's question: have you ever been bitten by treating a clock like ordinary logic — gating it, dividing it, or muxing it in the fabric? What broke, and how did you find it?
Hit reply. The best ones show up in a future issue. 🙋
📡 On the Radar
🟠 Altera extends FPGA product lifecycles out to 2045 — a long-support commitment aimed squarely at industrial, aerospace, and comms customers who design in an FPGA and need it available for decades. If you build systems with 10–20 year field lives, guaranteed silicon availability is as much a design input as any spec sheet.
🔷 The state of the FPGA union is uncertain — a broad industry read on where FPGAs sit as AI reshapes the accelerator landscape: still essential for real-time and adaptable edge work, but under pressure to justify their place next to GPUs and custom silicon. Worth a skim for the strategic picture behind the product announcements.
📘 Before you go
If these issues are useful, the book — Demystifying the Digital Design Interview — is the full map: 200+ questions worked through the same way, chapter and section referenced every time. → Get the book
Until next time, Milind
📘 Get the book · 🔗 LinkedIn · ✉️ Email
Forward this to one engineer prepping for interviews — that's how this grows.