> ## Content Index > Fetch the complete content index at: https://fpgadesign.io/llms.txt > Use this file to discover other available public pages before exploring further. # fpgadesign.io #3 β€” Asynchronous Assertion, Synchronous De-assertion - URL: https://fpgadesign.io/blog/fpgadesign-io-issue-3-resets/ - Published: 2026-07-26T15:00:33.000Z - Updated: 2026-07-26T15:00:32.000Z - Author: Milind Parelkar - Tags: newsletter πŸ‘‹ Welcome back. [The previous issue](https://fpgadesign.io/blog/2-the-shift-that-costs-zero-logic/): 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.) ![](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2026/07/book_fig6.15_reset_bridge.png) ## 🎯 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](https://fpgadesign.io/design-questions/) ## πŸ”„ ICYMI on LinkedIn: ⚑ [Floorplanning](https://www.linkedin.com/posts/milind-parelkar%5Ffpga-rtl-digitaldesign-share-7481789983511740416-0dr9/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) β€” 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](https://www.linkedin.com/posts/milind-parelkar%5Ffpga-rtl-hardwareengineering-share-7484853880951078912-Z%5FWr/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) β€” 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?"](https://www.linkedin.com/posts/milind-parelkar%5Fengineeringcareers-techinterviews-fpga-share-7485355007396212737-ocHD/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) β€” 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](https://dac.com/2026/press-release/the-2026-dac-chips-to-systems-conference-comes-to-long-beach-for-the-first-time-with-record-growth-as-ai-reshapes-chip-and-system-design?ref=fpgadesign.io) β€” 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](https://www.altera.com/newsroom/agilex-9-agrw039?ref=fpgadesign.io) β€” 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](https://techtime.news/2026/07/14/altera-2/?ref=fpgadesign.io) β€” 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](https://fpgadesign.io/book-details/) Until next time, **Milind** πŸ“˜ [Get the book](https://fpgadesign.io/book-details/) Β· πŸ”— [LinkedIn](https://www.linkedin.com/in/milind-parelkar?ref=fpgadesign.io) Β· βœ‰οΈ [Email](mailto:milind@fpgadesign.io) *Forward this to one engineer prepping for interviews β€” that's how this grows.* πŸ“° [Missed an issue? All previous newsletters live here](https://fpgadesign.io/tag/newsletter/).