fpgadesign.io #7 - Control Sets
A design blows past its resource budget and nothing in the RTL looks wrong. No obvious duplication, no runaway logic. The usual suspects are clean. The actual cause is almost always smaller than that, and it's rarely where anyone thinks to look first.
⚡ Concept of the Week: Control sets
Ask ten engineers what to learn first about FPGA design, and control sets rarely make the list. Ask again after a utilization report comes back over budget for no visible reason, and they usually make the list of things wished they'd known sooner.
A control set is the combination of clock, reset, and enable driving a register. Two registers running identical logic aren't the same control set the moment one uses an active-low reset and the other active-high, or one has a clock enable and the other doesn't. The logic is irrelevant. The synthesis tool only cares about the three control signals.
Why that matters: an FPGA slice only holds multiple registers together if they share one control set. On 7-Series devices, a slice packs 8 registers around a single shared clock, reset, and enable. UltraScale relaxes that to two control sets per 8-register half-CLB, more headroom, still not unlimited.
Split those control signals instead of matching them, and the tool can't pack the registers together anymore. Logic that should have shared one slice now claims several. Utilization climbs. Routing gets harder to close, and timing gets harder to close right behind it. None of it shows up labeled "control set problem." It shows up as a slice count or a congestion number that doesn't match what the RTL looks like on paper, and by the time someone traces it back, the mismatched reset polarity is three files and two design reviews away from where anyone's looking.
The fix has one shape: keep the clock, reset, and enable the same wherever the design allows it. That's the whole rule. Not fewer registers, not less logic, the same control signals.
Ch5 §5.4 (p.207) covers the mechanics in the book. The fuller architectural breakdown, with the 7-Series vs. UltraScale comparison and the actual packing numbers, is on the blog: Control Sets, Demystified.
🎯 Interview Question of the Week
Q: "You're designing a 16-bit microprocessor SoC. Your package pin budget can't exceed 20 pins. How would you approach it?"
How to approach it: resist naming a peripheral list first. Start with what can't be negotiated away, power, ground, clock, reset, then price the biggest fixed cost before adding anything: a plain 16-bit external address and data bus is 32 pins by itself, more than the entire budget. Even multiplexing address and data onto one bus the classic way still costs most of what's left. The real question isn't how to fit that bus into 20 pins, it's whether the bus needs to leave the package at all. Putting memory on-chip removes it entirely, at the cost of a fixed memory size instead of one you can expand later. That trade, not the pin count, is what the question is actually testing.
🧩 Design Question of the Week
An 8-register status bank sits behind a bus interface. Six registers are plain data captures: synchronous clear, one shared enable. Two are fault flags that a downstream safety monitor requires to clear within one clock edge of a hardware fault input, asynchronous clear, by spec.
Left as written, that's two control sets on one bank. Six registers share one (sync clear, shared enable), two carry a different one (async clear). On a 7-Series device, that's two slices minimum for logic that could otherwise fit in one, and the mismatch tends to resurface as a utilization surprise well after the RTL is signed off, not during review.
Restructure the bank so all eight registers can share a single control set, without weakening the two fault flags' async-clear requirement. State exactly what you'd give up, if anything, to get there, and how you'd convince a safety reviewer the requirement still holds with no gap where a fault could be missed.
Reply with your approach. Every email gets read, and every one gets an answer. 🙋
🔄 ICYMI on LinkedIn
🚨 The 20-pin SoC question. The one behind this issue's Interview Question, in full, including the part left open for readers to answer: what would you cut first with only 13 pins left for peripherals?
🔥 "Think in Hardware" has become a buzzword. The case where it's backwards, FSM state assignment has no clean formula, and that's exactly where letting the synthesis tool search beats hand-deriving it.
🍕 No free lunch. "Always use differential clocks" is half the story. The noise immunity is real. So is the pin count, the routing, and the termination power it costs to get there.
🔗 Worth Reading
- AMD Vivado: Report Control Sets (UG906) — the
report_control_setscommand from this issue's Author's Note, worth running on a design you already think is clean. - AMD Vivado: Control Signals and Control Sets (UG949) — the vendor's own definition and packing guidance, a good second read once the report above names a problem.
📡 On the Radar
🟣 Lattice launches Lattice Prompt, an AI-driven FPGA development tool — natural-language access to simulation, synthesis, placement, routing, and timing analysis, grounded in Lattice's own documentation rather than a general model guessing. The real test isn't the demo, it's whether it flags a control-set or packing problem before a report does.
🔵 Altera and Riverlane partner to bring quantum error correction to Agilex FPGAs — real-time decode for quantum error correction running on classical FPGA fabric, a genuinely new workload category for these devices rather than a spec bump. Worth watching for anyone near the quantum-classical interface.
Until next time, Milind
📘 Get the book · 🔗 LinkedIn · ✉️ Email