fpgadesign.io #3 — Asynchronous Assertion, Synchronous De-assertion
👋 Welcome back.
The previous issue: the shift that's free until the amount stops being a constant. A few of you replied with the palindrome detector — nice work on the ones that scaled cleanly to 32 bits.
This time, let's take a look at some nuances related to reset.
The signal every design has, and the one almost nobody designs carefully. 🤔
Ask most engineers how they handle reset and you'll hear "tie it to every flip-flop." Technically true. Also the fastest way to ship a bug that only shows up in the lab, under load, months later.
⚡ Concept of the Week: Asynchronous Assertion, Synchronous De-assertion
Start with what a flip-flop's reset actually controls. While reset is asserted, it holds the output at a known value — 0 or 1, depending on the flip-flop. The moment it de-asserts, control hands back to the clock edge.
That handoff is the whole problem.
If de-assertion lands too close to a clock edge, the flip-flop can go metastable — same failure mode as any other timing violation, except this one shows up once, at power-up or after a reset pulse, and is brutal to reproduce.
Two timing checks govern that handoff:
1️⃣Recovery time — reset must de-assert with enough margin before the next active clock edge.
2️⃣Removal time — reset must stay asserted long enough after a clock edge, if it happens to land near one.
Neither is setup or hold. They're reset's own version of the same problem, and most timing reports bury them.
Here's the asymmetry that actually matters.
Assertion has no timing requirement — it needs to happen immediately, irrespective of the clock edge, any time, because the thing forcing a reset (power glitch, external button, watchdog) doesn't wait for a convenient clock edge.
De-assertion is the opposite: it needs to be clean and synchronous, or you've just traded a known problem (something needs resetting) for an unknown one (metastability, maybe, somewhere, eventually).
So: assert asynchronously, de-assert synchronously. Always.
The standard way to build that is a reset bridge — a short chain of flip-flops using FDPE (async preset) and FDRE (sync reset) primitives. The async input presets the whole chain to 1 instantly. Once the async reset releases, the 1s ripple out one per clock, and the last flip-flop's transition to 0 is what releases your logic — fully synchronous to that domain's clock. Chain length sets your reset pulse width; two or three flip-flops is typical.
The part people miss: in a multi-clock design, that's one reset bridge per clock domain, not one global reset trying to serve all of them. A reset synchronized to clock A tells you nothing about metastability risk on clock B's flip-flops. (Book: Ch6 §6.13, pp.295–299.)
🎯 Interview Question of the Week
Q: "Why do you assert a reset asynchronously but de-assert it synchronously? Isn't a fully synchronous reset simpler?"
Here's how you should approach this question: don't just recite the rule. Explain the asymmetry.
Assertion has to react instantly to something that isn't clock-aligned (power glitch, external reset pin). De-assertion has to be clock-aligned or you risk metastability on release.
A fully synchronous reset can miss a narrow async assertion pulse entirely if it doesn't line up with a clock edge — that's the failure mode interviewers are checking you know.
🧩 Design Question of the Week
Design n module to generate an interrupt based on the information provided.
AXI-Stream interface.
Packets arrive at any rate, any size, TLAST marks the boundary.
Generate an interrupt if an incoming packet exactly matches — same size, same contents — any of the last 10 packets seen.
What do you store? What do you compare it against? And when — mid-packet, or only once TLAST arrives?
Give it a shot. If anything about the problem statement is unclear, or you want to talk through your approach, just reply — I read every email and I'm happy to help.
📌 Latest from fpgadesign.io
✍️ On the site: the free question banks — Digital Logic, SystemVerilog, FPGA Architecture, and Design Questions — just got a big update with a lot more material, sorted basic to advanced.
No signup required → fpgadesign.io/design-questions
🔄 ICYMI on LinkedIn:
⚡ Floorplanning — why the placement decisions nobody made on day one are the ones that block timing closure months later.
⚡ RTL code reviews in the age of AI — concurrency already made RTL reviews harder than software reviews. AI-generated code at multiples of the pace doesn't fix that; it makes it more urgent.
⚡ "How fast does it run?" — a personal story on why that's the wrong first question, and what actually matters: meeting the spec.
💬 Reader Mailbag
Last issue I asked what piece of RTL you rewrote once you understood what it actually synthesized to. Replies are still coming in — if you haven't sent yours, there's still time. 🙏
This issue's question: have you ever chased a bug that turned out to be a reset issue wearing a disguise? What did it look like before you found the real cause?
Hit reply. The best ones show up in a future issue. 🙋
📡 On the Radar
🟠 DAC 2026 is on this week — July 26–29, Long Beach. The 63rd Design Automation Conference is reporting record growth this year, with AI-driven chip design as the dominant theme across sessions. If you're near Long Beach this week, it's worth a look at the program even for a day pass.
🔺 Altera introduces the Agilex 9 Direct RF-Series SoC FPGA — engineering samples now available, claiming a 40% jump in compute density and 45% more logic/DSP density than the prior generation, with DDR5/LPDDR5 support aimed at aerospace, defense, and comms. Worth watching if your roadmap touches high-bandwidth RF.
🔷 Altera's turnaround: FPGAs positioned as GPU companions, not competitors — CEO Raghib Hussain points to ~20% annual growth and more than doubled operating income, driven largely by robotics and edge AI, where the FPGA handles real-time sensor processing alongside a GPU rather than replacing one. The "FPGA as the nervous system" framing is worth remembering next time someone asks why FPGAs still matter in an AI-first roadmap.
📘 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.