# fpgadesign.io > RTL and FPGA design interview prep — concept-first articles, question banks, and a book that explains the why behind design decisions. Public Ghost content for AI and LLM tooling. This file includes a bounded export of public pages first, then recent public posts. Append `.md` to any post or page URL to get the content in Markdown (for example, `/example-post.md`). ## Pages ### About URL: https://fpgadesign.io/about/ Last updated: 2026-05-17T04:06:27.000Z A few years ago, when the tech industry was going through a rough round of cuts and no one felt entirely untouchable, I set out to prepare for hardware engineering interviews. Twenty years of industry experience, and the resources available were, frankly, a mess. Multiple books covering the same ground superficially. Blog posts with no clear structure. And a growing flood of AI-generated content that looked authoritative and was frequently wrong. Nothing consolidated. Nothing that treated the reader like a working engineer. So I started writing. First on Substack — which I quickly abandoned. Weekly email newsletters don't really cater well to the interview prep domain. Then here, on fpgadesign.io. And eventually, in a book. ## **About the Author** I'm Milind Parelkar — Principal Engineer and Manager at Qualcomm, where I lead hardware architecture for advanced research programs. Over twenty years specializing in FPGA and RTL design: timing closure, system architecture, and building the prototyping infrastructure for 5G and 6G development. I've served on interview committees and managed engineering teams across multiple sites. I know what the gap looks like between what universities teach and what the job actually demands. That gap is why this site exists. ## **About the Book** [*Demystifying the Digital Design Interview*](https://fpgadesign.io/) is the resource I wish had existed when I was preparing for my first job interview. It's not a question bank. It's a structured, concept-first guide built on a simple premise: understanding the *why* behind design decisions is what holds up in a real interview. Memorized answers don't. The goal is specific. Walk into your next interview without gaps. No *"I've never heard of this topic."* No *"I know this — I just can't recall it right now."* Those two moments are what cost candidates the most. Both are preventable. [ ![Amazon Logo](https://upload.wikimedia.org/wikipedia/commons/4/4a/Amazon_icon.svg)Get Your Copy of the Book on Amazon ](https://geni.us/D8l7uSh?ref=fpgadesign.io) ## **A Note on the Content** The internet has no shortage of AI-generated hardware content. Some of it sounds plausible and is technically wrong — and this audience will catch it immediately. Every article on this site is written by me, grounded in real design experience, and verified for accuracy. I use AI tools occasionally to tighten phrasing. The engineering judgment is mine. ## Subscribe and Support Subscribing gives you full access to all content on the site. If it's been useful to you, a one-time contribution helps me keep building it. If you’d like to contribute through a **one-time donation**, you can do so by clicking the button below [Support fpgadesign.io](https://fpgadesign.io/#/portal/support) --- For questions, topic suggestions, or professional inquiries: [milind@fpgadesign.io](mailto:milind@fpgadesign.io) --- [ Connect with me on LinkedIn ](https://www.linkedin.com/in/milind-parelkar?ref=fpgadesign.io) ### SystemVerilog Questions URL: https://fpgadesign.io/sv-interview-questions/ Last updated: 2026-04-12T20:22:56.000Z Basic — foundational concepts Advanced — depth & edge cases In most RTL design interviews, you will be asked to write some code, or explain what a snippet does, or what it synthesizes to. Make sure your **SystemVerilog fundamentals are solid** before tackling advanced topics. ## Basic Questions Basic 5 questions 1 What are **blocking** and **non-blocking** assignment statements in SystemVerilog? Assignments [Read Answer →](https://fpgadesign.io/blog/intricacies-of-blocking-vs-non-blocking-assignment-statements-in-systemverilog/) 2 What does Case Sensitivity in a programming language refer to? How do Hardware Description Languages like VHDL and SystemVerilog handle case sensitivity? Syntax [Read Answer →](https://fpgadesign.io/blog/systemverilog-name-and-notations/) 3 What is the difference between **Bitwise Operators** and **Conditional Operators** in SystemVerilog? Operators [Answer in Book →](#) 4 What are the advantages of using the `always_ff` construct over the more generic `always@` Verilog construct? Procedural Blocks [Answer in Book →](#) 5 Write SystemVerilog code for a **Positive Edge Triggered FF** with a **Clock Enable** and an **Asynchronous Preset**. Procedural Blocks [Answer in Book →](#) ## Advanced Questions Advanced 5 questions 1 What are the key differences between **packed** and **unpacked** arrays in SystemVerilog? Arrays [Read Answer →](https://fpgadesign.io/blog/packed-vs-unpacked-arrays-in-systemverilog/) 2 What are the typical use cases for **packed** arrays while describing digital logic? Arrays [Answer in Book →](#) 3 What are the synthesis implications of using packed vs unpacked arrays in SystemVerilog? Arrays [Answer in Book →](#) 4 What are **SystemVerilog Interfaces**? What are the advantages of using Interfaces over other constructs like a "struct" in SystemVerilog? Interfaces [Answer in Book →](#) 5 Can you explain the concept behind the `.name` and `.*` constructs in SystemVerilog? Syntax [Read Answer →](https://fpgadesign.io/blog/systemverilog-name-and-notations/) Want detailed answers with full explanations? ### All questions are covered in depth in the book — with context, design rationale, and follow-up discussion. [View the Book →](https://fpgadesign.io/book-details/) ### Design Questions URL: https://fpgadesign.io/design-questions/ Last updated: 2026-05-17T19:53:36.000Z Basic — single-concept designs Intermediate — multi-cycle & sequential Advanced — interface & system-level RTL design questions test your ability to translate a spec into synthesizable hardware. Focus on getting the **architecture right first** — then think about edge cases, reset behavior, and timing. ## Basic Questions Basic 6 questions 1 Design a module to **generate a pulse** once every 32 clock cycles. Extra credit for a design optimized for Xilinx FPGA architecture. Counters [Read Answer →](https://fpgadesign.io/blog/design-question-pulse-generator/) 2 Design a **divide-by-2** module to divide the input clock. Clock Dividers [Read Answer →](https://fpgadesign.io/blog/design-question-clock-dividers-and-duty-cycle/) 3 Design a **divide-by-3** module to divide the input clock. Clock Dividers [Read Answer →](https://fpgadesign.io/blog/design-question-clock-dividers-and-duty-cycle/) 4 Design a divide-by-3 module to divide the input clock. The generated output signal must have a **50% duty cycle**. Clock Dividers [Read Answer →](https://fpgadesign.io/blog/design-question-clock-dividers-and-duty-cycle/) 5 Design a Binary to **Gray Code** converter. Data Converters [Read Answer →](https://fpgadesign.io/blog/gray-codes-and-their-uses-in-digital-design/) 6 Design a module to detect **Odd Parity**. The module receives a single bit serial input. The output shall be asserted when the number of `1`s received is odd. Sequence Detectors [Read Answer →](https://fpgadesign.io/blog/odd-parity-detector/) ## Intermediate Questions Intermediate 6 questions 1 Design a **sequence detector** to detect the following sequence: 0, 1, 1, 1, 0, 0. Sequence Detectors [Answer in Book →](#) 2 Design a **4-bit Full Adder** based on a 1-bit Full Adder module provided to you. The design must be completely pipelined at the boundaries of the 1-bit Full Adder module. Arithmetic [Answer in Book →](#) 3 Design a **4-bit × 4-bit multiplier** using a memory. Arithmetic [Answer in Book →](#) 4 Design a **4-bit Gray Code counter**. Counters [Answer in Book →](#) 5 Design a counter module that gets initialized to 1 on reset. The counter should count up and **skip every multiple of 3**. Every output value should remain on the output bus for a single clock cycle. Counters [Answer in Book →](#) 6 Design an **UP-DOWN Counter** that counts from 4 to 14, based on a select input `up_down`. Counters [Read Answer →](https://fpgadesign.io/blog/up-down-counter/) ## Advanced Questions Advanced 6 questions 1 Design a **skid buffer** to handle Ready-Valid handshaking. Extra credit for Xilinx FPGA architecture design alternatives. Interface Design [Answer in Book →](#) 2 Design an **8-bit Parallel-to-Serial Converter**. The module receives 8-bits of data per clock cycle, with 16 dead cycles between consecutive data words. The module has a single-bit serial output. Shift Registers [Answer in Book →](#) 3 Design a module that receives a single bit serial input (`dat`) qualified with a `vld` signal. The module should **detect the stream marker sequence** — 1, 1, 1, 0, 0, 0 — and output the 4 bits that preceded the stream marker. Sequence Detectors [Answer in Book →](#) 4 Design a **data distributor** module that receives a single 8-bit data word per clock cycle qualified with a `vld` signal. The module distributes data words to 4 outputs in a circular fashion. Interface Design [Answer in Book →](#) 5 Design a module that will generate the following sequence of decimal numbers — **3, 11, 29, 47, 55, 62** — and then roll over to keep generating the same sequence. Counters [Answer in Book →](#) 6 AXI-Streaming interfaces have a `TLAST` signal to indicate the end of a packet. Design a module to take an incoming AXI-Streaming interface and add **Start-of-Packet (`SOP`) and End-of-Packet (`EOP`)** markers to the interface. AXI [Answer in Book →](#) Want detailed answers with full explanations? ### All questions are covered in depth in the book — with context, design rationale, and follow-up discussion. [View the Book →](https://fpgadesign.io/book-details/) ### FPGA Concepts URL: https://fpgadesign.io/fpga-concepts/ Last updated: 2026-05-17T19:53:30.000Z Basic — FPGA fundamentals Intermediate — architecture & timing Advanced — system-level & optimization FPGA interview questions test both your theoretical knowledge of the architecture and your practical experience with tools and constraints. **Understanding the "why" behind design choices** is what separates good answers from great ones. ## Basic Questions Basic 7 questions 1 What are some of the **primitive elements** inside an FPGA? FPGA Architecture [Answer in Book →](#) 2 What is the difference between an **FPGA**, a **CPLD**, and a **Microcontroller**? What are the typical applications for each of these devices? FPGA Architecture [Answer in Book →](#) 3 What **clocking blocks** are available in a typical Xilinx FPGA? Clocking [Answer in Book →](#) 4 What are the different types of **memory elements** available inside a Xilinx UltraScale+ family of FPGAs? Memory [Read Answer →](https://fpgadesign.io/blog/an-introduction-to-xilinx-fpga-memory-primitives/) 5 What are the most basic types of **design constraints** required for any FPGA design? Constraints [Read Answer →](https://fpgadesign.io/blog/clock-constraints/) 6 What sort of **debugging tools** are available in the Xilinx Toolkit? Debug [Answer in Book →](#) 7 ASIC designs frequently use **clock gating** to turn off the clock to certain sections of the design. How is similar functionality handled on an FPGA? Clocking [Answer in Book →](#) ## Intermediate Questions Intermediate 8 questions 1 What does **Stacked Silicon Interconnect (SSI)** mean? FPGA Architecture [Answer in Book →](#) 2 What are **Super Logic Regions (SLRs)** in some Xilinx devices? FPGA Architecture [Answer in Book →](#) 3 What precautions need to be taken while using **SSI devices** or while handling signals crossing **SLR boundaries**? FPGA Architecture [Answer in Book →](#) 4 What are some of the considerations while using **resets** in Xilinx FPGA designs? Design Practice [Read Answer →](https://fpgadesign.io/blog/rethinking-resets-best-practices-for-fpga-design/) 5 What is **Retiming**? What are the typical scenarios where it might be useful? Timing Closure [Answer in Book →](#) 6 What are **Timing Exceptions**? Why is it important to specify them? Constraints [Read Answer →](https://fpgadesign.io/blog/clock-constraints/) 7 What are **Synthesis Directives**? Explain with some common examples. Synthesis [Answer in Book →](#) 8 What is the difference between the directives **KEEP** and **DONT\_TOUCH**? Synthesis [Read Answer →](https://fpgadesign.io/blog/synthesis-directives/) ## Advanced Questions Advanced 9 questions 1 On a Xilinx UltraScale+ device, there are two differential clock inputs — a **400 MHz clock on a GC pin** and a **312.5 MHz MGTREFCLK**. How would you generate 50 MHz, 200 MHz, and 156.25 MHz clocks for internal use? Clocking [Answer in Book →](#) 2 Two of the most common hindrances in **Timing Closure** are **high-fanout nets** and **excessive levels of logic**. How should either of these problems be handled in the design? Timing Closure [Answer in Book →](#) 3 A register stores an 8-bit value that must be shifted left by 4 bit positions. How many **levels of logic** will be needed to implement this operation? Synthesis [Answer in Book →](#) 4 What are **XPMs** (Xilinx Parameterizable Macros) and where are they typically used? FPGA Architecture [Answer in Book →](#) 5 What is **Floorplanning**? Explain the thought process and the steps involved in floorplanning a design. Floorplanning [Answer in Book →](#) 6 Xilinx IP Library has FIFOs designated as **First Word Fall Through (FWFT)**. Explain the design significance and use cases of these FIFOs. Memory [Answer in Book →](#) 7 Xilinx Dual Port BlockRAMs have two flavors — **Simple Dual Port** and **True Dual Port**. What are the differences between the two types? Memory [Answer in Book →](#) 8 What are **IOSTANDARDs** in FPGA design? Why are they needed and how are they specified? IO Design [Read Answer →](https://fpgadesign.io/blog/iostandards/) 9 A module implemented on a Xilinx FPGA needs to send out **source synchronous data** along with the clock. How should the data and the clock be handled at the FPGA IOs? IO Design [Answer in Book →](#) Want detailed answers with full explanations? ### All questions are covered in depth in the book — with context, design rationale, and follow-up discussion. [View the Book →](https://fpgadesign.io/book-details/) ### Digital Logic URL: https://fpgadesign.io/digital-logic/ Last updated: 2026-04-12T20:32:57.000Z Basic — foundational concepts Intermediate — applied understanding Advanced — depth & edge cases In RTL design interviews, you will often be asked to explain basic digital design concepts. Before diving into advanced sections, make sure your **foundation is strong**. ## Basic Questions Basic 8 questions 1 What are the most commonly used types of Flip-Flops in Digital Design? Elaborate on their Truth Tables and Excitation Tables. Flip-Flops [Answer in Book →](#) 2 What is the difference between a Flip-Flop and a Latch? Flip-Flops [Answer in Book →](#) 3 Design a 4:1 Multiplexer using logic gates. Logic Gates [Answer in Book →](#) 4 Design the following gates using only NAND Gates — Inverter, OR Gate, AND Gate, XOR Gate. Logic Gates [Answer in Book →](#) 5 What are the various types of State Machines used in Digital Design? What are the pros and cons of each type? State Machines [Answer in Book →](#) 6 What are Mealy and Moore Machines? What is the advantage of one over the other? State Machines [Read Answer →](https://fpgadesign.io/blog/mealy-moore-fsm/) 7 What are Tri-State Buffers? Walk through a real-world application. Combinatorial Logic [Read Answer →](https://fpgadesign.io/blog/tri-state-buffers/) 8 What is "endianness" in digital design? What are its implications and potential pitfalls? Data Representation [Read Answer →](https://fpgadesign.io/blog/endianness/) ## Intermediate Questions Intermediate 9 questions 1 Design a T-FF (Toggle Flip-Flop) using a D Flip-Flop. Flip-Flops [Answer in Book →](#) 2 What is the difference between a JK Flip-Flop and an RS Flip-Flop? Flip-Flops [Answer in Book →](#) 3 What are the different types of State Machine Encodings used in Digital Design? What conditions dictate the preferred encoding style? State Machines [Answer in Book →](#) 4 Design a 16:1 Multiplexer using 4:1 Multiplexers. Come up with multiple topologies and explain the pros and cons of each approach. Logic Gates [Answer in Book →](#) 5 What are Static Hazards in Digital Design? How can you avoid them? Combinatorial Logic [Answer in Book →](#) 6 What do the parameters setup time and hold time specify in relation to a Flip-Flop? Timing [Read Answer →](https://fpgadesign.io/blog/the-fundamentals-of-static-timing-analysis-in-digital-circuits/) 7 What is meant by critical path in a digital design? Timing [Read Answer →](https://fpgadesign.io/blog/the-fundamentals-of-static-timing-analysis-in-digital-circuits/) 8 What are pull-up and pull-down resistors used for? Explain with examples. Circuit Design [Answer in Book →](#) 9 What are the basic Error Detection techniques used in digital data transmission? Data Integrity [Read Answer →](https://fpgadesign.io/blog/odd-parity-detector/) ## Advanced Questions Advanced 8 questions 1 What are the advantages of using a JK Flip-Flop over the more commonly used D Flip-Flop? Flip-Flops [Answer in Book →](#) 2 Can you explain the timing equation for a critical path? Timing [Read Answer →](https://fpgadesign.io/blog/the-fundamentals-of-static-timing-analysis-in-digital-circuits/) 3 Some datasheets specify sequential logic components with a negative Hold Time. What is the physical implication of this? Timing [Read Answer →](https://fpgadesign.io/blog/negative-hold-time/) 4 What is clock skew in digital circuits? Does a large clock skew affect the design adversely? Timing [Read Answer →](https://fpgadesign.io/blog/advanced-topics-in-static-timing-analysis/) 5 What is Metastability? How does it affect the behavior of digital circuits? Metastability [Answer in Book →](#) 6 What is a Ring Counter and a Johnson Counter? What are their practical applications? Sequential Logic [Answer in Book →](#) 7 Design a Universal Shift Register capable of both Serial and Parallel loading and unloading. Sequential Logic [Answer in Book →](#) 8 How are numbers represented using Fixed Point arithmetic in digital design? What are the advantages over Floating Point representation? Arithmetic [Read Answer →](https://fpgadesign.io/blog/fixed-point-representation-mastering-precision-in-fpga-design/) Want detailed answers with full explanations? ### All questions are covered in depth in the book — with context, design rationale, and follow-up discussion. [View the Book →](https://fpgadesign.io/book-details/) ### Book Details URL: https://fpgadesign.io/book-details/ Last updated: 2026-04-12T19:15:37.000Z Demystifying the Digital Design Interview # The Missing Guide for Practical RTL and FPGA Interview Preparation 200+ embedded interview questions. Concept-first structure. Real engineering insight from 20 years in the industry — not recycled textbook content. [Order on Amazon →](https://geni.us/D8l7uSh?ref=fpgadesign.io) [Paperback · Hardcover · Kindle ↓](#where-to-buy) ![Demystifying the Digital Design Interview](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2026/04/book-rendering.jpg) Most digital design interview prep material falls into one of two traps: it’s either a dense textbook with no interview focus, or a shallow Q&A list that collapses the moment an interviewer asks a follow-up. **This book is neither.** Each topic is built up as a cohesive narrative — you develop genuine competency first, then validate it with the 200+ questions embedded throughout. The result is the kind of understanding that holds up in a real whiteboarding session, not just a rehearsed answer that falls apart under pressure. It also includes a dedicated chapter on FPGA architecture — a gap that almost every other prep resource ignores entirely. Who Is This Book For ## Built for engineers at every stage ### New & Early-Career Engineers Close the gap between what you learned in school and what companies actually test for in RTL and FPGA interviews. ### Senior Engineers Targeted refresh on advanced topics — CDC, AXI, STA, FPGA architecture — before stepping into a senior or staff-level role. ### Career Switchers Moving from software or verification into hardware design? Build a solid RTL foundation without wading through an entire textbook. What Makes It Different ## Designed around how interviews actually work 📖 ### Context-First Learning Topics are covered as a cohesive narrative, not a random Q&A list. You build competency first — the questions follow to validate it. That’s the order that sticks. ⚙️ ### The “Why” Over the “What” Every design choice is explained in terms of its impact on synthesis, area, and timing. That’s what separates a candidate who memorized an answer from one who understands the tradeoff. 🏭 ### FPGA Architecture — a Dedicated Chapter CLBs, LUTs, BRAM, URAM, clocking resources, SRLs. Most prep books skip this entirely. If you’re interviewing for FPGA roles, this chapter alone is worth it. 💡 ### Author’s Notes Throughout Inline pro-tips and design critiques drawn from 20 years of industry experience. The kind of context you’d only get from someone who’s been on both sides of the interview table. Inside the Book ## Table of Contents Chapter 1 ### Digital Design Fundamentals - ·Number systems & binary arithmetic - ·Fixed-point representation - ·Flip-flops vs. latches - ·Finite state machines (Mealy & Moore) - ·Endianness & memory mapping Chapter 2 ### SystemVerilog for Design - ·Blocking vs. non-blocking assignments - ·always\_comb / always\_ff usage - ·Interfaces & modports - ·Avoiding inadvertent latches - ·Parameterized designs & generate Chapter 3 ### FPGA Architecture & Core Concepts - ·CLBs, LUTs, SRLs - ·BRAM, URAM & memory primitives - ·Clocking resources & clock enables - ·Synthesis directives & ILA - ·FPGA vs. ASIC vs. microcontroller Chapter 4 ### Static Timing Analysis & Timing Closure - ·Setup/hold times & critical paths - ·XDC clock & I/O constraints - ·Pipelining, retiming & high fanout - ·Timing exceptions & Pblocks - ·SLR crossings Chapter 5 ### Advanced Hardware Topics - ·AXI protocol - ·Clock domain crossing (CDC) - ·Metastability & synchronizers - ·FIFO design - ·Tri-state buffers & static hazards Chapter 6 ### Practical RTL Design Questions - ·Pulse generators & clock dividers - ·Barrel shifters - ·ROM-based multipliers - ·Ripple carry adders - ·Fixed-priority & round-robin arbiters ![Milind Parelkar](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2026/04/parelkar-photo.jpeg) About the Author ### Milind Parelkar Principal Engineer & Manager · Qualcomm · 20 years in RTL & FPGA design Milind has spent two decades designing, reviewing, and shipping RTL and FPGA systems at Qualcomm. He has interviewed hundreds of candidates across all levels — from new grads to senior engineers — and built this book around the patterns he’s seen separate strong candidates from unprepared ones. He is the founder of [fpgadesign.io](https://fpgadesign.io/). ## Where to Buy Available in paperback, hardcover, and Kindle e-book. Choose the retailer and format that works best for you. 🇺🇸 United States [Amazon — Paperback, Hardcover & Kindle](https://geni.us/D8l7uSh?ref=fpgadesign.io) [Barnes & Noble Paperback, Hardcover & Nook](https://www.barnesandnoble.com/w/demystifying-the-digital-design-interview-milind-parelkar/1149847459?ean=9798901902851&ref=fpgadesign.io) [Bookshop.org Ebook](https://bookshop.org/p/books/demystifying-the-digital-design-interview-the-missing-guide-for-practical-rtl-and-fpga-interview-preparation-milind-parelkar/594463789ef2c603?ean=9798295754371&next=t&ref=fpgadesign.io) 🇮🇳 India All paperback editions in India are black & white. For a full-color copy, the hardcover on Amazon India is the one to get. [Amazon India — Hardcover (Color), Paperback (B&W) & Kindle](https://a.co/d/0gRg5TnL?ref=fpgadesign.io) [Flipkart B&W Paperback](https://dl.flipkart.com/dl/demystifying-digital-design-interview/p/itmc3b13a42e5b70?pid=9798904310066&affid=editornoti&%5FrefId=&%5FappId=CL&ref=fpgadesign.io) [NotionPress B&W Paperback](https://direct.notionpress.com/in/read/demystifying-the-digital-design-interview/?ref=fpgadesign.io) 🌍 Europe, Australia & Rest of World This link automatically routes you to your local Amazon storefront — UK, Germany, France, Japan, Australia, Canada, and more. [Amazon — Paperback, Hardcover & Kindle](https://geni.us/D8l7uSh?ref=fpgadesign.io) ### Home URL: https://fpgadesign.io/home/ Last updated: 2026-04-12T21:58:58.000Z ![Milind Parelkar](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2026/04/parelkar-photo.jpeg) Milind Parelkar High-Speed FPGA Design · Author Principal Engineer/Manager, Qualcomm Research Demystifying the Digital Design Interview ## The RTL and FPGA Interview Guide Built on 20 Years of Industry Experience 200+ interview questions. Concept-first structure. Real engineering insight — not recycled textbook content. [Order on Amazon → ](https://geni.us/D8l7uSh?ref=fpgadesign.io) [ ![Demystifying the Digital Design Interview](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2026/04/book-rendering.jpg) ](https://fpgadesign.io/book-details/) [Full details, table of contents & preview → ](https://fpgadesign.io/book-details/) ## From the Blog [View all articles →](https://fpgadesign.io/blog/) About This Site fpgadesign.io is a technical resource for engineers preparing for RTL, FPGA, and ASIC design interviews. The articles, question banks, and the book are all built on one premise: understanding the *why* behind design decisions is what holds up in a real interview. Memorized answers don't. Get new articles delivered to your inbox — no fluff, no filler. Subscribe ### Book Preview URL: https://fpgadesign.io/book-preview/ Last updated: 2026-04-13T00:53:02.000Z 📖 Free Preview ## Demystifying the Digital Design Interview Preparing for an RTL or FPGA design interview? This preview gives you a genuine sample of the structured, concept-first guide written from **20 years of industry experience at Qualcomm**. Excerpts from all six chapters, 200+ embedded interview questions, and a taste of the appendices — enough to decide if this is the right resource for your preparation. 6 Chapter Excerpts 200+ Interview Questions Appendix Previews Author's Notes _This page is for subscribers only._ ### Start here URL: https://fpgadesign.io/start-here/ Last updated: 2026-06-22T04:23:53.000Z fpgadesign.io is a concept-first resource for engineers preparing for RTL, ASIC, and FPGA design interviews. The goal isn't to memorize answers — it's to understand the *why* behind design decisions so you can reason through anything an interviewer throws at you. 💡 New to interview prep? Start with the FPGA & RTL Interview Preparation Roadmap — the complete map of what these interviews actually test, with a printable checklist and a 4-week study plan. It's the best place to begin. → [Get the free roadmap](https://fpgadesign.io/blog/the-complete-fpga-rtl-interview-preparation-roadmap/) ## Pick your starting point 🎓 New grad / early career Start with [Digital Logic](https://fpgadesign.io/digital-logic/) to build the foundation, then move to [SystemVerilog](https://fpgadesign.io/sv-interview-questions/). Read the blog articles alongside the question banks — the concepts reinforce each other. 💼 Experienced engineer refreshing Go straight to [FPGA Architecture](https://fpgadesign.io/fpga-concepts/) or [Design Questions](https://fpgadesign.io/design-questions/). The advanced blog articles on CDC, STA, and AXI are worth reading too. 🔄 Switching from software or verification Start with the [SystemVerilog](https://fpgadesign.io/sv-interview-questions/) bank to understand RTL thinking, then use the blog articles to fill gaps in hardware fundamentals. ## The free question banks All four question banks are free. No account needed — just bookmark what's useful. [ Digital Logic Combinational, sequential, arithmetic, FSMs ](https://fpgadesign.io/digital-logic/) [ SystemVerilog RTL design, blocking vs non-blocking, interfaces ](https://fpgadesign.io/sv-interview-questions/) [ FPGA Architecture CLBs, LUTs, BRAM, clocking, timing ](https://fpgadesign.io/fpga-concepts/) [ Design Questions Applied RTL — arbiters, FIFOs, barrel shifters ](https://fpgadesign.io/design-questions/) Want a structured path? Demystifying the Digital Design Interview If you want all of this sequenced for you — with 200+ embedded questions and author's notes from 20 years of industry experience — the book covers it end to end. Available on Amazon in paperback, hardcover, and Kindle. [View book details →](https://fpgadesign.io/book-details/) Questions? Reach out at [milind@fpgadesign.io](mailto:milind@fpgadesign.io) or on [LinkedIn](https://www.linkedin.com/in/milind-parelkar?ref=fpgadesign.io). ### Newsletter URL: https://fpgadesign.io/newsletter/ Last updated: 2026-07-26T05:55:21.000Z fpgadesign.io # The Newsletter RTL & FPGA design, explained the way interviews actually test it. Every other Sunday, one concept interviewers love to probe — taught the **why-over-what** way, with a real interview question, a build-it design problem, and what's worth your attention in the field. Free. No fluff. From 20 years of RTL/FPGA design at Qualcomm. Subscribe Read a few issues first — every one is below. ## Every issue New here? The earliest issue (at the bottom) is a good place to start — each one stands on its own. Loading issues… Don't want to miss the next one? [Subscribe — it's free](#nl-top) ## Posts ### fpgadesign.io #6 - Pipelining and Area vs Speed Trade-offs URL: https://fpgadesign.io/blog/fpgadesign-io-6-pipelining/ Last updated: 2026-09-06T15:00:42.000Z 👋 Welcome back. "Just add a pipeline stage" is the reflex answer to almost any "how would you speed this up" question. Sometimes it's right. Sometimes it does nothing for the problem actually on the table. ### ⚡ Concept of the Week: Area and Speed Optimization A design report can report two different types of failures and they call for two different fixes. One failure mode: the design **doesn't fit.** Too many LUTs, too many DSPs, over 100% utilization on the target device. That's an **area** problem. The other: the design fits fine, but a path from one register to the next takes longer than the clock period allows. That's a **timing** problem — too many levels of logic between flops for the clock you're asking it to run at. Pipelining fixes the second one. It says nothing about the first. Add a register in the middle of a long combinational path, and the logic on either side of that new register is shorter — each half now has fewer levels of logic to get through in one clock period, so the path can run faster. Nothing about the total amount of logic changed. You added a handful of flip-flops; the LUTs and DSPs are the same ones you had before. Fmax goes up. Area barely moves. What you paid for the fix is latency — the result now takes one more clock cycle to appear. Area is a different kind of budget, and it needs a different kind of fix: **resource sharing.** Instead of building four multipliers to compute four products in one cycle, build one multiplier and a small state machine that reuses it across four cycles, storing partial results as it goes. The DSP count drops by 4x. What you paid for that fix isn't latency — it's throughput. The shared multiplier can only start its next job once the current one clears, so the whole datapath now takes four times as long to produce each result. That's the actual shape of the trade-off, and it's not one dial, it's two: - **Pipelining trades a few registers for Fmax**, at the cost of latency per operation. - **Resource sharing trades area for the resource itself**, at the cost of throughput. **Replication is the reverse of sharing** — spend more area (more copies of the hardware) to buy back the throughput that sharing gave away, when the design can afford the die space. The book's ROM-based multiplier walkthrough (Ch6 §6.7.4) makes this concrete with numbers: a small lookup-table multiplier is fast and nearly free in area for narrow operands, and that same approach stops being a bargain once the operand width grows — at which point a shared, time-multiplexed multiply-accumulate structure is often the better trade, not a bigger ROM. The diagnostic that actually matters in an interview: before naming a fix, name which report is red. A utilization report over 100% is an area problem. A timing report with negative slack is a timing problem. Pipelining a design that's over its LUT budget doesn't free a single LUT — it just adds flops around logic that was never the thing failing. ### 🎯 Interview Question of the Week Q: *"Your datapath doesn't meet your 200 MHz target. A colleague says to add a pipeline stage. When is that the wrong fix?"* How to approach it: don't answer with a technique — answer with a diagnosis first. Pipelining shortens the combinational path between registers, so it only helps when the failure is a timing violation on that path. If the real problem is that the design doesn't fit the device — too many DSPs or LUTs used — adding registers doesn't remove a single resource. It can make the area problem worse, not better. Say what you'd check before touching the RTL: the utilization report tells you if you have an area problem, the timing report's worst negative slack and the specific failing path tell you if you have a timing problem. Only then do you reach for pipelining, resource sharing, or replication — the report tells you which one. *(This is Ch4 §4.8 for the pipelining mechanics, and Ch6 §6.7.4 for the area-vs-speed framing on multipliers specifically.)* ### 🧩 Design Question of the Week **Design a 4-tap FIR filter that shares a single multiply-accumulate unit across all four taps — zero bubble cycles between output samples.** One multiplier, one adder. A new input sample arrives once every 4 clock cycles (the input rate is fixed by the ADC feeding it; you don't control that). In the 4-cycle window between samples, your shared MAC must compute all four tap products against the last four samples and produce one filtered output. The requirements that make this more than a state-machine sketch: - **Zero bubble cycles.** The first multiply for output N+1 has to happen on the very next cycle after the last accumulate for output N. Not one cycle later. - The four-sample history has to shift in exactly once per output, and it has to be the *right* four samples every time — no off-by-one on the tap window. - A partial sum from output N must never leak into output N+1's accumulation, even with the shared adder running back-to-back with no idle cycle between groups. And the part that separates a working simulation from a design you'd sign off on: how would you convince a reviewer that the accumulator boundary between two consecutive outputs can never mix samples from two different windows — with no gap cycle to make the reset "obviously" safe? Reply with your approach. Every email gets read, and every one gets an answer. 🙋 ### 🔄 ICYMI on LinkedIn 🔥 [**AI found the bug that wasn't in the code**](https://www.linkedin.com/posts/activity-7496578123942080512-Thn9?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) A timing fix that passed every simulation, every synthesis check — and still didn't work, because the missing piece wasn't logic, it was a synthesis directive. 🚨 [**KEEP vs. DONT\_TOUCH**](https://www.linkedin.com/posts/activity-7500207879715540993-ziIG?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) A debug register has to survive synthesis. Two attributes look interchangeable until you need one and reach for the other. ### 📡 On the Radar 🟠 [AMD introduces Kintex UltraScale+ Gen 2 mid-range FPGAs](https://www.amd.com/en/blogs/2026/announcing-amd-kintex-ultrascale-gen-2-mid-range-fpgas.html?ref=fpgadesign.io) — positioned explicitly to avoid pushing designs into a costlier device class: up to 5x the memory bandwidth and 2x the DSP density of the prior Kintex generation, with availability guaranteed through at least 2045\. The mid-range tier exists because not every area/speed trade should be solved by buying a bigger part. 🔷 [Efinix's Titanium Edge FPGA family targets low-power edge AI and vision](https://www.cnx-software.com/2026/07/20/efinix-titanium-edge-fpga/?ref=fpgadesign.io) — four devices from roughly 39K to 123K logic elements, about 50% lower static power than the prior generation, with a system-in-package variant that cuts board footprint up to 60% by integrating the FPGA, RAM, and boot flash in one package. Area efficiency, sold as the headline feature rather than an afterthought. 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) 📰 [Missed an issue? All previous newsletters live here](https://fpgadesign.io/tag/newsletter/). ### fpgadesign.io #5 - Pulses, CDC and Synchronizers URL: https://fpgadesign.io/blog/fpgadesign-io-5-pulses-cdc-and-synchronizers/ Last updated: 2026-08-23T15:00:02.000Z Two readers sent back complete designs for last issue's pulse question. 🙏 Between them they covered both halves of it — so this issue is the answer, built out of those answers. ### ⚡ Concept of the Week: A synchronizer doesn't make a pulse survive The question was: catch a single-cycle 200 MHz pulse in a 50 MHz domain, exactly once. No misses, no duplicates. Almost everyone starts with a two-flop synchronizer. Reasonable. But look at the numbers first. At 200 MHz, a one-cycle pulse is 5 ns wide. At 50 MHz, the destination looks once every 20 ns. A 5 ns pulse fits inside a 20 ns gap with room to spare. Nothing goes metastable. Nothing is marginal. There is just no destination clock edge while the signal is high, so the destination samples a 0, then another 0, and the event is gone. Five flip-flops on the receive side wouldn't help. The problem happened before the first one. A synchronizer fixes metastability. It does nothing about sampling. 🤔 The fix is width. Hold a signal for at least 1.5 destination clock periods and you're guaranteed to be sampled — 30 ns here, six source cycles. Two structures do that for you. A **toggle synchronizer** turns the pulse into a level, crosses the level, and rebuilds the pulse on the far side: cheap, but open loop, so it can miss if your events bunch up. A **req/ack handshake** makes the source hold `req` until the destination confirms: it can't miss, and you pay for that in latency. ### 🎯 Interview Question of the Week Q: *"You put a two-flop synchronizer on a control signal crossing into a slower domain. It still drops events in hardware. What did you miss?"* How to approach it: don't say "add a third flop." That's the reflex answer, and here it's wrong. Separate the two failure modes out loud. **Metastability** is the flop catching a transition. **Sampling** is the destination never looking while the signal was asserted. A synchronizer only addresses the first, and the question is about the second. Then do the arithmetic in front of the interviewer and name the number: hold it for at least 1.5 destination clock periods. That number is what separates someone who has read about CDC from someone who has debugged it. *(This is Ch5 §5.10 in the book. Q.155 asks it almost word for word.)* ### 🧩 Design Question of the Week This one is harder than usual. That's deliberate — readers keep saying the difficult ones are the good ones. **Design a 4-client round-robin arbiter for a shared bus.** Each client asserts `req[i]`. Once granted, a client holds the bus for a variable number of cycles and asserts `last` on its final cycle. One-hot `grant[i]`, one grant per clock. The requirements are where it gets interesting: - No rotation mid-burst. Once a client is granted, it keeps the bus until `last`. - **Zero bubble cycles.** When the current burst ends and another request is pending, the next client must be granted on the very next cycle. Not one cycle later. - **No starvation, ever.** A client that keeps asking must eventually be granted, no matter what the other three do. - A client that drops `req` before being granted must not cost anyone a cycle. And the part most people skip: a fixed priority encoder that always starts at bit 0 will pass a casual testbench and quietly starve client 3 in the lab. So there are two questions here, not one. How do you *build* it — and how would you *convince a reviewer* it can't starve? Reply with your approach. Every email gets read, and every one gets an answer. 🙋 ### 🛠 Author's Note The CDC bugs that survive simulation and only surface in hardware nearly all come from the same place: treating "it's synchronized" as "it's safe." A synchronizer is a metastability filter, not a delivery guarantee. Before adding flops, ask the cheaper question first — is the signal even wide enough for the receiving clock to see it? Ten seconds of arithmetic, and it saves weeks of lab time. ### 🔄 ICYMI on LinkedIn ⚡ [**Is arbitration even needed?**](https://www.linkedin.com/posts/milind-parelkar%5Ffpga-rtl-systemverilog-share-7488984041866592256-ur1A/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) Detecting whether more than one bit is set, without a population count. `~|x` handles the empty case; `x & (x-1)` handles the rest. Directly relevant to this issue's design question. 🔥 [**This made my day.**](https://www.linkedin.com/posts/milind-parelkar%5Ffpga-rtl-interviewprep-share-7490848052442755072-71Os/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) A reader wrote in about the book, unprompted, asking for nothing. Worth a read if you've ever wondered whether writing a technical book is worth the trouble. → **\[LINK\]** ### 📡 On the Radar 🟠 [AMD moves Vivado to tiered licensing in 2026.1](https://www.amd.com/en/products/software/adaptive-socs-and-fpgas/vivado/vivado-licensing-options.html?ref=fpgadesign.io) — five tiers now: Basic (free, annual renewal), Core and Pro as subscriptions, Enterprise and Gold as perpetual. The part worth knowing is what landed in the free tier: all 7 Series plus low-end UltraScale and UltraScale+, on Windows *and* Linux. If you learn or prototype on your own hardware, the free tier just got more useful than it was. 🔷 [Altera expands DDR5 support across the Agilex portfolio](https://www.altera.com/newsroom/ddr5-memory-support?ref=fpgadesign.io) — Quartus Prime Pro 26.1.1 brings DDR5-6400 and LPDDR5-6400 to Agilex 7 M-Series and LPDDR5 to Agilex 3, up to 204.8 GB/s aggregate on the top configurations. Memory bandwidth is quietly becoming the number that decides FPGA-versus-GPU arguments at the edge, so this is a bigger deal than a tooling release usually is. ### 📘 One small ask If you've read *Demystifying the Digital Design Interview*, please consider leaving a review on Amazon. Reviews are what decide whether the book gets shown to the next engineer searching for interview prep. There's no publisher and no ad budget behind this — it moves on word of mouth and on what readers say about it. A few honest sentences about what you found useful genuinely keeps the whole effort going. → [Leave a review on Amazon](https://www.amazon.com/dp/PLACEHOLDER%5FASIN?ref=fpgadesign.io) 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) 📰 [Missed an issue? All previous newsletters live here](https://fpgadesign.io/tag/newsletter/). ### fpgadesign.io #4 - Clocks should be Handled with Extreme Care URL: https://fpgadesign.io/blog/fpgadesign-io-4-clocks-should-be-handled-with-extreme-care/ Last updated: 2026-08-09T15:00:30.000Z 👋 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](https://fpgadesign.io/blog/the-complete-fpga-rtl-interview-preparation-roadmap/) ### 🔄 ICYMI on LinkedIn ⚡ [Hardware interviews have a LeetCode problem](https://www.linkedin.com/posts/milind-parelkar%5Frtl-fpga-systemverilog-share-7488124840231452672-bBja/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) — 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](https://convergedigest.com/altera-extends-fpga-product-lifecycles-to-2045/?ref=fpgadesign.io) — 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](https://www.eetimes.com/the-state-of-the-fpga-union-is-uncertain/?ref=fpgadesign.io) — 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](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/). ### fpgadesign.io #3 — Asynchronous Assertion, Synchronous De-assertion URL: https://fpgadesign.io/blog/fpgadesign-io-issue-3-resets/ Last updated: 2026-07-26T15:00:32.000Z 👋 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/). ### fpgadesign.io #2 — The Shift that Costs Zero Logic Levels URL: https://fpgadesign.io/blog/2-the-shift-that-costs-zero-logic/ Last updated: 2026-07-12T15:30:19.000Z *fpgadesign.io — Issue #2* *RTL & FPGA design, explained the way interviews actually test it.* 👋 Welcome back. Last issue: timing. Setup, hold, and why a hold violation is the one that should scare you. Several of you replied with your attempts at the skip-3 counter. Exactly what I hoped for. (Haven't tried it? Still worth a shot — just reply.) This time, something that looks much simpler. Shifting. 🤔 Most answers I hear about it are technically correct. And completely miss the point. Shift a value left by a fixed amount, and on an FPGA it can cost nothing. No LUTs. No gates. Not even a logic level. Make that same shift amount a variable? The cost explodes. A network of muxes that eats area and drags down your clock. Same operation. Wildly different hardware. That gap is the whole lesson today. ### ⚡ Concept of the Week: The shift that's free — until it isn't Start with the thing everyone half-remembers. Shifting is scaling by powers of 2\. Left by 1 is ×2. Left by 3 is ×8. Right by 2 is ÷4. No multiplier. No divider. Just a reinterpretation of which bit sits in which position. 🔍Now the part interviews are really probing. When the shift amount is a constant, an FPGA doesn't use any fabric combinatorial logic like LUTs, to implement the shift operation. `data_out = data_in << 1` synthesizes to wires. *Something to think about: Do we even need the `<<` operator or can we just assign a specific bit-slice?* The tool knows at elaboration exactly which input bit feeds which output bit. So it routes bit i to bit i+1 through the interconnect and bypasses the LUTs entirely. Zero logic levels. The book calls this wire-shifting (Chapter 3, p.167) — one of the most elegant "free lunch" moves in FPGA design. ✅ Now change one thing. Make the shift amount a variable (or a signal) instead of a constant. ⚠️ Everything changes. The hardware has to be ready to shift by any amount, on any cycle. That's a barrel shifter — a combinational circuit that shifts by a variable number of positions in a single clock. Fast? Yes, single-cycle. But it's built from log₂(width) layers of muxes. Real LUTs. Routing congestion. A live path in your timing report. The book is blunt about it (§6.2, Q.169, p.255): the barrel shifter's speed comes at the cost of resources, congestion, and clock speed. Its sequential cousin, the shift register, makes the opposite trade. One bit per clock. n clocks to move n positions. Cheap in area, slow in latency. The barrel shifter does in one cycle what the shift register takes n cycles to do. You're trading logic for time. (§6.2, Q.168.) 💡 Here's the main takeaway. The one that separates a textbook answer from an engineer's answer. The cost was never in "shifting." It's in whether the amount is known at compile time. Constant → wires. Free. Variable → barrel shifter. Expensive. Which is exactly why declaring a shift amount as a parameter instead of a register can collapse an entire shifter down to routing. The tool propagates the constant. The "extra" hardware disappears. ### 🎯 Interview Question of the Week **Q:** "`data_out = data_in << 3`. How many logic levels does that add? And what changes if the 3 is a signal instead of a constant?" ✏️ **How to approach it:** Don't just say "it shifts." Lead with the constant case. Zero logic levels — the tool resolves the connection at elaboration and wire-shifts it through routing. Then flip it. Make the amount a runtime signal and you've asked for a barrel shifter. A log₂(width)-deep mux tree. Real LUTs. A real timing cost. The interviewer is watching for one thing: can you connect compile-time vs runtime to actual hardware? That link is the answer. 📖 (This is Q.168–169, Chapter 6.) ### 🧩 Design Question of the Week **Design:** A continuous bit stream, one bit per clock. Generate a single-cycle pulse whenever the last 12 bits form a palindrome — reads the same forwards and backwards. No start bit. No end bit. The window just slides every clock. How would you build it? And how does your approach scale if the window grows to 32 bits? 🤔 Give it a shot. If the problem statement is unclear, or you want to talk through your approach, just reply — I read every email. 🙋 ### 🛠 Author's Note If a shift amount is fixed by your architecture, declare it as a parameter or localparam. Never a register "just in case." Reach for a register to "keep it flexible," and you've paid for a full barrel shifter you'll never use. ❌ In my experience, "flexible" hardware that nobody ever reconfigured has cost more timing than almost anything else I've seen. ### 🎓 From the Field: What the panel is actually scoring When you answer the shift question, the panel isn't checking whether you know the words "barrel shifter." They're watching how you get there. Two candidates. Same knowledge. ✏️ The first says: "I'd use a barrel shifter." ✏️ The second says: "If the shift is constant, it's free — the tool just reroutes. If it's variable, I'd use a barrel shifter, and I'd flag that it costs a mux tree and some fmax." Identical facts. Completely different score. 💡 What a hiring manager screens for on a design question is rarely the final answer. It's whether you reach for the simplest thing first. Whether you know the cost of what you propose. And whether you volunteer the trade-off before you're asked. That last one is the tell. Naming the downside of your own design, unprompted, is what senior engineers do without thinking about it. 🔖 Do that, and you've answered a question the interviewer hadn't even gotten to yet. ### 📌 Latest from fpgadesign.io ✍️ On the blog: [Designing a Skip-3 Counter — count up, never land on a multiple of 3](https://fpgadesign.io/blog/design-skip3-counter/). No divider. No modulo. The trick is reading the sequence, not doing the arithmetic. Three ways to build it, and when you'd pick each. 🔄 ICYMI on LinkedIn: ⚡[ The Skip-3 design challenge](https://www.linkedin.com/posts/milind-parelkar%5Ffpga-rtl-digitaldesign-share-7475189406413328384-l-cU/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) — the interview problem behind that blog post. The pattern-over-arithmetic move shows up everywhere. ⚡ [The 12-bit palindrome detector](https://www.linkedin.com/posts/milind-parelkar%5Ffpga-rtl-systemverilog-share-7477381073824346112-MM1j/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) — this issue's design problem, in its original form. Store the data, test the property. No FSM needed. ⚡ [A long timing report isn't how much is broken](https://www.linkedin.com/posts/milind-parelkar%5Fengineeringcareers-techcareers-fpga-share-7480779331502252033-berC/?utm%5Fsource=share&utm%5Fmedium=member%5Fdesktop&rcm=ACoAABc579gBHIw8IGqP-kF-qK8AGP6UP9VDXKQ) — 4,759 violations rarely means 4,759 problems. They cluster. Group them by root cause. ### 🔗 Worth Reading 📄 [Vivado Design Suite User Guide: Synthesis (UG901)](https://docs.amd.com/r/en-US/ug901-vivado-synthesis?ref=fpgadesign.io) — the free reference for what your RTL operators actually become in hardware. Want to see exactly when a shift stays as routing and when it turns into logic? This is where the tool's behavior is documented. ### 💬 Reader Mailbag Last issue I asked what interview topic you find hardest, and why. Those replies are still coming in — keep them coming. They shape these issues. 🙏 This issue's question: what's a piece of RTL you rewrote once you understood what it actually synthesized to? The "flexible" register that should've been a parameter counts. Hit reply. The best ones will show up in a future issue. 🙋 ### 📡 On the Radar 🔺 [AMD ships Vivado & Vitis 2026.1 with a new tiered licensing model](https://www.amd.com/en/support/downloads/adaptive-socs-and-fpgas/development-tools/2026-1.html?ref=fpgadesign.io) — broad new device support (Versal Gen 2 families, Spartan UltraScale+), and the tools moved to pay-for-what-you-target licensing. Know which tier covers the device family your role actually uses. It now affects what you can even run. 🔷 [Altera's Agilex 3 FPGAs are in production and orderable](https://www.eejournal.com/article/altera-announces-that-agilex-3-fpgas-are-in-production-and-are-ready-for-ordering-immediately/?ref=fpgadesign.io) — small form-factor parts with AI and an integrated MCU on-device. The MCU-plus-fabric packaging keeps blurring the MCU/FPGA line. Expect more embedded and PS-PL partitioning questions, not just fabric. 🤖 [Altera's FPGA AI Suite adds a spatial architecture](https://www.fpgakey.com/technology/details/fpga-industry-trends-news-2025-altera-amd-lattice?ref=fpgadesign.io) that maps AI models directly onto Agilex silicon. "AI on FPGA" is shifting from hand-written HLS toward dedicated flows. Watch this if you're anywhere near ML inference on hardware. ### 📘 Before you go New here? The free SystemVerilog and design-problem question banks on [fpgadesign.io](https://fpgadesign.io/) just got a big update. That's the best place to start. No signup required. 🎁 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/). ### fpgadesign.io #1: Setup & Hold, and Why One is Scarier URL: https://fpgadesign.io/blog/1-setup-and-hold-why-one-is-scarier/ Last updated: 2026-06-28T18:24:22.000Z Welcome to the **first issue** of the fpgadesign.io newsletter — or, for some of you, welcome back. A while ago I ran a newsletter on Substack, but a number of constraints meant I had to put it on hold. Now that the book is finally out, I'm restarting it — this time on my own platform at [**fpgadesign.io**](https://fpgadesign.io/), where I have the room to do it the way I want. Since the book came out, I've been hearing from students and engineers prepping for RTL and FPGA interviews, and the same questions keep coming up. So every two weeks I'll take one concept interviewers love to probe and explain it the way I wish someone had explained it to me when I was starting out — plus a real interview question, a design problem, and what's worth your attention in the field. Let's start with a topic, where a lot of careers get made or broken: *timing closure*. ## ⚡ Concept Focus: Setup and hold, and why one is scarier A flip-flop can't capture data at the exact instant the clock edge arrives — it needs the data stable for a small window *around* the edge. **Setup time** is how long data must be stable *before* the edge; **hold time** is how long it must stay stable *after*. Here's the part that matters in interviews and on the device. A **setup** check is a *longest-path* problem — if your slowest path can't make it in one clock period, you fail setup, and you can always slow the clock down to fix it (or pipeline, reduce logic levels, retime). ``` Setup: T_clk >= t_cq + t_comb(max) + t_su (longest path) Hold: t_cq + t_comb(min) >= t_h (shortest path - no T_clk!) ``` A **hold** check is a *shortest-path* problem. Notice what's missing: the clock period. Hold has nothing to do with frequency. A chip that fails hold is broken at *any* speed — you can't slow your way out. The fix is adding delay to the fast path, and the usual culprit is clock skew. So when someone asks "which is worse?" — hold. A setup failure is a performance limit; a hold failure is a functional one. ## 🎯 Interview question **Q:** "What's the difference between a setup violation and a hold violation — and if you could only have one, which would you rather see in your timing report?" **How to approach it:** define both in terms of the data-stability window, then land the key insight — setup scales with the clock period (slow the clock and it's fixable), hold doesn't (broken at any frequency, usually skew). You'd rather have a setup violation. *(This is explained in detail in Chapter 4 of the book.)* ## 🧩 Design question **Design a sequence generator** that starts at 1 after reset and outputs an incrementing sequence every clock — but never outputs a multiple of 7. So: 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 15, … Each value appears for exactly one cycle. How would you build it? Did you approach this at the gate level, RTL level, structural level or with waveforms? Give it a shot. If anything about the problem statement is unclear — or you'd like to talk through your approach — just reply. I read every email and I'm happy to help. **Hint:** I already have a [blog post](https://fpgadesign.io/blog/design-skip3-counter/) about a counter that skips every multiple of 3. ## 🛠 Author's note ****Logical and routing delays:** A rule of thumb is that the routing delay should generally not consume more than 60% of the clock period for efficient routing and timing closure in FPGA designs. ## 📌 Latest from fpgadesign.io **On the blog — three timing reads to go deeper:** [Reading a Timing Report: Why Your First Instinct Might Be Wrong](https://fpgadesign.io/blog/reading-a-timing-report-why-your-first-instinct-is-wrong/) — most engineers see a violation and reach for pipelining. The report already tells you the fix, once you read the logic-vs-route split. [Negative Hold Time Values in the Datasheet](https://fpgadesign.io/blog/negative-hold-time/) — a perfect companion to today's issue: why hold times can go negative, and what that buys you for timing closure. ["Levels of Logic" in FPGA Timing Reports](https://fpgadesign.io/blog/levels-of-logic/) — what that number really means, and why it's often the first thing to check when a path won't close. ## 📌 **ICYMI on LinkedIn** ### **A 3-part series on using AI for SystemVerilog & RTL:** [Part 1 — Do you use AI to write SystemVerilog?](https://www.linkedin.com/posts/activity-7465054262868336640-60Vg?ref=fpgadesign.io) — the unlock isn't the model; it's feeding it your own golden modules so it writes in your style, not generic RTL. [Part 2 — Not every hour of engineering is engineering](https://www.linkedin.com/posts/activity-7465416590998802432-3dqJ?ref=fpgadesign.io) — where AI shines: the mechanical-but-well-specified work (bus hookups, dead-code sweeps, XDC sync). Prep the field; AI executes. [Part 3 — Where human expertise is still irreplaceable](https://www.linkedin.com/posts/activity-7467953300504731648-xQwe?ref=fpgadesign.io) — the failure modes: false CDC, reinvented components, package vs. localparam, pipeline balance. AI writes code; engineers design systems. ## 🔗 Worth reading [AMD UltraFast Design Methodology Guide (UG949)](https://www.xilinx.com/support/documents/sw%5Fmanuals/xilinx2022%5F2/ug949-vivado-design-methodology.pdf?ref=fpgadesign.io) — the timing-closure chapter is the best free reference on closing timing in Vivado. ## 💬 Reader mailbag New issue, so let's start one: what interview topic do you find hardest, and why? Just hit reply — I read every one, and your answers shape future issues. ## 📡 On the radar [AMD launched Kintex UltraScale+ Gen 2 mid-range FPGAs](https://www.amd.com/en/blogs/2026/announcing-amd-kintex-ultrascale-gen-2-mid-range-fpgas.html?ref=fpgadesign.io) (up to 5x memory bandwidth, 2x PCIe channel density). [AMD's Versal Prime Series Gen 2 added smaller embedded-class devices](https://www.amd.com/en/blogs/2026/announcing-new-amd-versal-prime-series-gen-2-devices.html?ref=fpgadesign.io) — the PS-PL partitioning question keeps getting more important; know where your logic should live. [Altera is now an independent company again](https://www.altera.com/newsroom/news/press-release/altera-silver-lake?ref=fpgadesign.io). ## 📘 Before you go If this was useful, forward it to one engineer who's prepping for interviews — that's how this grows. And if you have a question, or want to talk through this issue's design problem, just reply — it comes straight to my inbox. --- Get the book → [Demystifying the Digital Design Interview](https://fpgadesign.io/book-details/) Connect → [LinkedIn](https://www.linkedin.com/in/milind-parelkar?ref=fpgadesign.io) · [Email](mailto:milind@fpgadesign.io) ### Design Question: Counter that Skips Every Multiple of 3 URL: https://fpgadesign.io/blog/design-skip3-counter/ Last updated: 2026-06-24T20:57:08.000Z **Design a counter that starts at 1 and outputs a new value on every clock cycle, but it must never output a multiple of 3\. The sequence looks like this: 1, 2, 4, 5, 7, 8, 10, 11, 13, 14 … — every third number is skipped.** When most students first see this, they read it as a divisibility problem. The logic seems straightforward: count up by one each cycle, check whether the new value is divisible by 3, and skip it if it is. That check is a modulo-3 operation — and in software, that is exactly how you would write it. In theory, the approach is correct. It produces the right sequence. But correct code and practical hardware are not the same thing, and a modulo operation is where the two part ways. Division is one of the most expensive blocks you can put on a chip. So before writing a single line of RTL, it is worth asking a simpler question: do we actually need to divide at all? ## Hardware Design Thinking This is where hardware design thinking comes in. Instead of asking "is this number divisible by 3?", look at the sequence the problem actually asks for and find the pattern in it. Write out the outputs and look at the step from one value to the next: 1 → 2 is +1 2 → 4 is +2 4 → 5 is +1 5 → 7 is +2 The increment alternates: +1, +2, +1, +2 — and it never breaks. ![](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2026/06/wavedrom-skip3.png) The reason is simple. Multiples of 3 are spaced exactly three apart, so between any two of them sit exactly two non-multiples. A step of +1 walks across those two; a step of +2 jumps over the multiple. Alternate the two, and you generate every value the problem asks for without ever landing on a multiple of 3. Notice what just happened. The divisibility test disappeared. No modulo, no comparison, no division — only addition. The hard part was never the arithmetic. It was reading the sequence instead of reacting to the word "divisible." ## Implementation Details The whole circuit is just three small pieces. Take a look at the block diagram below. ![](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2026/06/skip3-counter.excalidraw.png) **The div-2 counter.** Start with a single flip-flop that toggles on every clock: 0, 1, 0, 1, … This is nothing more than a divide-by-2 of the clock, which is why the diagram labels it the Div-2 Count. Its only job is to remember which increment we owe this cycle — a +1 or a +2. ```verilog // Toggles every clock. Drives the mux select. logic div2; always_ff @(posedge clk) begin if (rst) begin div2 <= 1'b0; end else begin div2 <= ~div2; end end ``` **The mux.** The two increments are constants, 1 and 2, wired to the inputs of a 2:1 mux. The Div-2 Count drives the select line: when it is 0, the mux passes 1; when it is 1, it passes 2\. The mux output is the "number to be added" for this cycle, and it takes a single assignment. ```verilog // div2 = 0 -> add 1; div2 = 1 -> add 2 logic [1:0] add_val; assign add_val = div2 ? 2'd2 : 2'd1; ``` **The counter.** Finally, the counter holds the running value. On reset it loads 1, and on every clock after that it adds whatever the mux handed it. Its output is the sequence the problem asked for. ```verilog logic [15:0] count; always_ff @(posedge clk) begin if (rst) begin count <= 16'd1; end else begin count <= count + add_val; end end assign out = count; ``` That is the entire design. No divider, no divisibility check, no comparison — just a toggle, a mux, and an adder. The critical path is a single addition, the same as an ordinary counter. You met a spec that looked like it demanded division using nothing but an add and a flip-flop that flips. ## Alternate Methods The div-2 counter and mux are the lightest way to generate the alternating increment — but they are not the only way. Two alternatives are worth knowing, because they generalize better when the skip pattern gets more complicated. **A rotating register (ring counter).** Instead of computing the increment, store it. Load a small circular register with the pattern of increments — here just two entries, 1 and 2 — and rotate it one position every clock. The value at the head of the register is the number to add. For skip-3 the register is two deep, so it simply presents 1, 2, 1, 2, … The idea scales, though: if the pattern were longer or irregular, you would make the register deeper and load the right sequence into it. The control logic never changes. ```verilog // Two-entry rotating register: presents 1, 2, 1, 2, ... // inc[0] is the head = the number to add logic [1:0] inc [1:0]; always_ff @(posedge clk) begin if (rst) begin inc[0] <= 2'd1; inc[1] <= 2'd2; end else begin inc[0] <= inc[1]; inc[1] <= inc[0]; end end ``` **A state machine.** The same alternation can be written as a tiny FSM. One state emits +1 and moves on; the next emits +2 and moves back. The state register replaces the div-2 counter, and the output logic replaces the mux. For two steps this is heavier than it needs to be, but it is the most general of the three — an N-step skip pattern is just an N-state machine, and irregular patterns are easy to express. ```verilog // ADD1 -> ADD2 -> ADD1 ... typedef enum logic {ADD1, ADD2} state_t; state_t state; always_ff @(posedge clk) begin if (rst) begin state <= ADD1; end else begin if (state == ADD1) begin state <= ADD2; end else begin state <= ADD1; end end end assign add_val = (state == ADD1) ? 2'd1 : 2'd2; ``` ## Trade-offs Every one of these designs produces the exact same output. The difference is in what they cost, and how well they hold up when the problem changes. **Divider vs. pattern.** The modulo approach is the most general — it works for any modulus, no thought required — but you pay for that generality with a divider: a large block, a long critical path, and timing that fights you as the width grows. The pattern-based designs give up that generality in exchange for almost nothing — a flip-flop or two and a single adder, with a critical path no longer than an ordinary counter. For a fixed, known skip rule, that trade is almost always worth it. Once you commit to reading the pattern, the choice comes down to how complex that pattern is, and whether it might grow: - **Div-2 counter + mux** — smallest and simplest. Best when the increment alternates between just two values, like skip-3. - **Ring counter** — store the increment sequence and rotate it. Pays off when the pattern is longer but still periodic; you just make the register deeper. - **State machine** — the most general. Reach for it when the pattern is irregular, or when you expect it to change. The counter and its single-adder datapath stay the same in all three. Only the logic feeding the "number to be added" changes. ### The Complete FPGA & RTL Interview Preparation Roadmap URL: https://fpgadesign.io/blog/the-complete-fpga-rtl-interview-preparation-roadmap/ Last updated: 2026-06-21T14:48:12.000Z Most candidates walk into an FPGA or RTL design interview unsure of what they will be asked. This roadmap removes that uncertainty: it is the complete map of what digital design interviews actually test, organized into eight modules - from digital logic fundamentals to timing closure and the design problems that separate strong candidates from the rest. Built from two decades of designing high-speed FPGAs and sitting on both sides of the interview table. ## Get the printable roadmap The self-assessment checklist, plus interview-frequency ratings and a 4-week study plan. Free. Subscribe Email sent! Check your inbox to complete your signup. No spam. Unsubscribe anytime. CoreAsked almost every timeDigital Logic · HDLs · Clocking & Timing · Design Problems CommonFrequently askedFPGA Architecture · Communication Protocols · Verification & Debugging SeniorDepth & differentiationAdvanced Topics & Applications 01Digital Logic FundamentalsCore The essential building blocks of digital circuits. Boolean Algebra & Logic Gates - Basic gates (AND, OR, NOT, XOR, XNOR, NAND, NOR) and truth tables - Boolean identities and simplification (K-Maps, Quine-McCluskey) - SOP (Sum of Products) and POS (Product of Sums) forms Combinational Logic Design - Multiplexers (MUX) and Demultiplexers (DEMUX) - Encoders and Decoders - Adders (Half, Full, Ripple-Carry, Carry-Lookahead) - Comparators; Shifters and Rotators Sequential Logic Design - Latches vs. Flip-Flops (SR, D, JK, T) - Setup time, Hold time, Clock-to-Q, Propagation delay - Synchronous vs. Asynchronous circuits - Registers and Shift Registers (SISO, SIPO, PISO, PIPO) - Counters (Synchronous, Asynchronous, Up/Down, Ring, Johnson) Finite State Machines (FSMs) - Mealy vs. Moore machines - State diagrams and transition tables - State encoding (Binary, One-hot, Gray) - Common FSMs (sequence detectors, traffic-light controllers) [Practice free in the Digital Logic question bank →](https://fpgadesign.io/digital-logic/) 02Hardware Description Languages (Verilog / SystemVerilog / VHDL)Core Practical use of HDLs to describe hardware - the cornerstone of RTL design. HDL Basics - Syntax and structure (modules/entities, architectures) - Data types (wire, reg, logic, bit, std\_logic, integer, real, arrays) - Operators (arithmetic, logical, bitwise, relational) - Concurrent vs. sequential statements (assign vs. always/process) SystemVerilog Enhancements - logic data type and its advantages over reg/wire - typedef and enum for readability and type safety - package for grouping common definitions - Interfaces and modport (signal bundling, master/slave directionality) - dot-star (.\*) port mapping - usage, advantages, pitfalls Behavioral & Structural Modeling - always / process blocks and sensitivity lists - Blocking vs. non-blocking assignments - Conditionals (if-else, case/casez/casex) and loops - Functions and Tasks - Module instantiation, port mapping, hierarchical design Common RTL Design Practices - Inferring logic (latches, flip-flops, memories, FSMs) - Parameterization and generics for reusable IP - Reset methodologies (synchronous vs. asynchronous) - Writing synthesizable RTL; FPGA coding-style guidelines [Practice free in the SystemVerilog question bank →](https://fpgadesign.io/sv-interview-questions/) 03FPGA Architecture and Design FlowCommon Understanding the target hardware and the design process. FPGA Architecture - CLBs / Logic Elements: LUTs, flip-flops - LUT-based shift registers (SRL16, SRL32) - Routing resources and programmable interconnects - Dedicated blocks: BRAMs, DSP slices, SerDes, PLLs/DCMs/MMCMs - I/O blocks (IOBs); clocking resources (global clocks, clock trees) Advanced Device Architectures - SSI / multi-SLR devices (Super Logic Regions) and their implications - SoC FPGAs (Zynq, Arria 10 SoC): Processing System vs. Programmable Logic - MPSoC and RFSoC awareness; PS-PL communication (AXI, GPIO) FPGA Design Flow - Specification and design entry - Synthesis: purpose, gate-level netlist, reports - Implementation (Place & Route): mapping, placing, routing - Floorplanning & Pblocks; bitstream generation and programming Context - FPGA vs. ASIC: key differences, advantages, disadvantages - Vendors (Xilinx, Intel/Altera, Lattice, Microchip) and tools [Practice free in the FPGA Architecture question bank →](https://fpgadesign.io/fpga-concepts/) 04Clocking and Timing AnalysisCore A critical area and a frequent interview topic - timing closure is paramount. Clocking Concepts - Frequency, period, duty cycle; clock skew and jitter - Global vs. local clocks; generation/management (PLLs, DCMs, MMCMs) - Clock fanout; inter-SLR clocking and routing Static Timing Analysis (STA) - Timing paths (reg-to-reg, input-to-reg, reg-to-output, input-to-output) - Path delay (logic + routing); setup/hold; critical-path analysis - Slack (positive vs. negative) Timing Constraints (SDC) - create\_clock, create\_generated\_clock - set\_input\_delay, set\_output\_delay - set\_false\_path, set\_max\_delay/set\_min\_delay, set\_multicycle\_path - Interpreting timing reports and exceptions Timing Closure Techniques - RTL: pipelining (and latency trade-offs), retiming, parallelism - Reducing levels of logic; managing high-fanout nets; using BRAMs/DSPs/SRLs - FSM encoding (one-hot for speed, binary for area) - Tool directives (DONT\_TOUCH, MAX\_FANOUT, RAM\_STYLE, ASYNC\_REG) - Physical constraints (floorplanning, Pblocks, LOC); failing-path analysis Clock Domain Crossing (CDC) - Metastability and its implications - Synchronizers (double/multi-flop), async FIFOs, handshake protocols - CDC linting and verification [Read the timing & CDC deep-dives on the blog →](https://fpgadesign.io/blog/) 05Communication ProtocolsCommon On-chip and off-chip protocols for integrating IP and external devices. AXI (Advanced eXtensible Interface) Family - AXI4 (Full): memory-mapped; channels; bursts (INCR, WRAP, FIXED); VALID/READY - AXI4-Lite: simple control/status registers; no burst support - AXI4-Stream: streaming; TVALID/TREADY/TDATA/TLAST/TKEEP/TSTRB; packet-based Serial Buses - I2C: two-wire multi-master; SDA/SCL; start/stop, addressing, ACK/NACK - SPI: four-wire full-duplex; SCLK/MOSI/MISO/SS; CPOL/CPHA modes - Protocol comparison: speed, complexity, pin count, multi-master [Read the AXI & protocol articles on the blog →](https://fpgadesign.io/blog/) 06Verification and DebuggingCommon Methodologies for functional correctness, plus debugging real hardware. Simulation & Testbench Development - Event-driven simulation and simulators (ModelSim, QuestaSim, XSim, VCS) - Testbench structure, stimulus generation, response checking - Self-checking testbenches, file I/O, waveform analysis Verification Methodologies - Functional verification; code coverage (line, branch, FSM, toggle) - Assertion-based verification (SystemVerilog Assertions) - Introduction to UVM (awareness) On-Chip Debugging - Integrated Logic Analyzers (ILAs): concept, resource use, vs. sim - Vendor tools (Vivado ILA, SignalTap): triggering, depth, mark\_debug - Virtual I/O (VIO) cores for interactive control/monitoring Debugging Strategies - Incremental debugging; debug registers, status flags, counters - Observing FSM states; handling FIFO under/overflow - JTAG & boundary scan; when to reach for lab equipment [Read the verification & debug articles on the blog →](https://fpgadesign.io/blog/) 07Advanced Topics & ApplicationsSenior Topics that demonstrate deeper understanding and real experience. Specialized Areas - Memory interfaces: SDRAM, DDR/2/3/4 (controllers and PHY) - DSP on FPGAs: fixed vs. floating point, FIR filters, FFT, DSP slices - High-Level Synthesis (HLS): C/C++ to RTL, pros/cons, applications Engineering Practice - Scripting: Tcl (Vivado, Quartus); Python (testbench gen, ChipScoPy) - Design for Testability: scan chains, boundary scan (JTAG) - Common challenges: resource/power optimization, throughput vs. latency [Read the advanced-topics articles on the blog →](https://fpgadesign.io/blog/) 08Common Design & Coding ProblemsCore The RTL problems used in interviews to test practical coding and judgment. Counters & Data Path - Divide-by-N counter (e.g., divide-by-3 with 50% duty cycle) - Barrel shifter; priority encoder/decoder; generic comparators/adders Converters & Synchronization - Binary-to-Gray and Gray-to-Binary converters; BCD to 7-segment - Button debouncer; edge detectors (rising, falling, both) Memory, FIFOs & Arbitration - Synchronous FIFO controller (pointers, full/empty flags) - Skid buffer for pipelined back-pressure; simple memory controller - Arbiters: round-robin and priority Modules & Algorithms - UART receiver/transmitter (simplified) - FSM applications: traffic-light controller, sequence detector - GCD (Euclidean algorithm); PWM generator [Practice free in the Design Questions bank →](https://fpgadesign.io/design-questions/) ## Want it all sequenced for you? This roadmap shows you what to master. Demystifying the Digital Design Interview shows you why — the design intuition, the trade-offs, and the judgment behind every topic here, with 200+ embedded questions drawn from 20 years in industry. [View the book →](https://fpgadesign.io/book-details/) --- ## Download the free PDF using the link below _This post is for subscribers only._ ### Why Only the D Flip-Flop Exists as an FPGA Primitive URL: https://fpgadesign.io/blog/why-only-the-d-flip-flop-exists-as-an-fpga-primitive/ Last updated: 2026-05-18T17:00:25.000Z *You studied RS, JK, T, and D flip-flops in school. So why is only one of them available as a primitive in modern FPGAs?* This is a question that trips up a surprising number of engineers in interviews — even experienced ones. The knee-jerk answer is usually something vague about "the D flip-flop being simpler." That's not wrong, but it misses the real story. The answer comes down to synthesis predictability, feedback topology, and what Static Timing Analysis actually needs to do its job. ## A Brief History Worth Knowing These flip-flops weren't just academic constructs. The JK flip-flop — the 7476 in the 7400 TTL series — was a real chip. Engineers wired them up on breadboards. They appeared in lab kits for decades. The idea that only the D flip-flop survived into the FPGA era isn't obvious if you only learned about them from a textbook. Each type was once genuinely useful. So what happened? ## The RS Flip-Flop: A Forbidden State Problem The RS (or SR) flip-flop has four input combinations: S=0/R=0, S=1/R=0, S=0/R=1, and S=1/R=1. The first three are fine. S=1/R=1 is the problem — it produces an indeterminate output. Both Q and Q̄ go high, which is already a contradiction (they should be complementary), and the output when the inputs return to 0 is unpredictable. It depends on which signal transitions first. For a synthesis tool, "indeterminate output" is unworkable. The tool needs to map your RTL to hardware and make guarantees about that hardware's behavior. A primitive with a forbidden state — one where the output is undefined — cannot participate in that guarantee. You'd have to add external gating to ensure S=1/R=1 never occurs, and at that point you're no longer describing the RS flip-flop, you're describing something else. The RS flip-flop does have legitimate uses in specific asynchronous applications (debounce circuits, for instance — see Chapter 6 of *Demystifying the Digital Design Interview*), but those use the flip-flop at the gate level, not as an inferred sequential element in RTL synthesis. _This post is for subscribers only._ ### ~ vs ! in SystemVerilog: The Bug the Compiler Won't Catch URL: https://fpgadesign.io/blog/vs-in-systemverilog-the-bug-the-compiler-wont-catch/ Last updated: 2026-05-18T05:43:27.000Z *Will this block execute? Yes or no.* ```systemverilog logic [1:0] status; assign status = 1; if (~status) begin // Does this execute? end ``` Take a moment before answering. If you said "no" — think again. ## The Setup This is a question that separates engineers who understand what their code synthesizes to from engineers who rely on intuition. On a single-bit signal, `~` and `!` give the same result. That makes the distinction easy to miss — until you hit a multi-bit signal and something breaks in a way that's nearly impossible to find in simulation. The code above will execute the if block. Not because of a quirk or a compiler bug. Because of exactly what `~` does, and how `if` evaluates its condition. ## Two Operators, Two Different Questions **`~` — Bitwise NOT** The tilde operator asks: *flip every bit in this vector*. It operates on each bit independently and returns a result with the same width as the input. ```systemverilog logic [3:0] input_vec = 4'b1010; logic [3:0] result; assign result = ~input_vec; // result = 4'b0101 ``` If the operand contains `x` or `z` bits, those become `x` in the output. The result is always multi-bit if the input is multi-bit. **`!` — Logical NOT** The exclamation operator asks: *is this entire expression zero?* It evaluates the operand as a Boolean condition and returns a single bit. ```systemverilog logic [3:0] some_ones = 4'b0101; logic result; assign result = !some_ones; // result = 1'b0 (non-zero → TRUE → !TRUE = FALSE) ``` Output is always 1 bit: `1'b1` if the operand is zero, `1'b0` if non-zero, `1'bx` if indeterminate. For a single-bit signal, `~` and `!` give the same result. For a multi-bit signal, they can give completely different answers. ## Why the Example Executes `status` is 2 bits wide. The value `1` is stored as `2'b01`. **With `~status`:** 1. Bitwise NOT flips every bit: `~(2'b01)` \= `2'b10` 2. The `if` statement receives `2'b10` 3. Any non-zero value in an `if` condition evaluates to TRUE 4. `2'b10` is not zero → **the block executes** **With `!status`:** 1. `2'b01` is non-zero → logically TRUE 2. `!TRUE` \= `1'b0` (FALSE) 3. The condition is FALSE → **the block does not execute** The intent was almost certainly to check "is `status` zero?" That requires `!`. Using `~` gives the *opposite* answer for this value. _This post is for subscribers only._ ### Reading a Timing Report: Why Your First Instinct Might Be Wrong URL: https://fpgadesign.io/blog/reading-a-timing-report-why-your-first-instinct-is-wrong/ Last updated: 2026-05-18T00:11:42.000Z *Most engineers see a timing violation and immediately reach for pipelining. Sometimes that's exactly right. Sometimes the report is telling you something completely different — and if you don't read it carefully, you'll spend hours fixing the wrong thing.* ## The Scenario You're in a design review — or a real interview. The interviewer shows you a timing report snippet from a 250 MHz design: ``` ───────────────────────────────────── Slack (VIOLATED) : -0.482ns ───────────────────────────────────── Source : tx_data_reg[7]/C (FDRE) Destination : rx_proc_reg[7]/D (FDRE) Data Path Delay : 3.847ns Logic Delay : 0.461ns (12%) Route Delay : 3.386ns (88%) Clock Path Skew : -0.142ns Clock Uncertainty : 0.035ns Required Time : 3.823ns Arrival Time : 4.305ns ───────────────────────────────────── ``` *"Where do you start?"* Most candidates say: add pipelining. Reduce LUT depth. Restructure the RTL. Hold on. ## How to Read This Report Before reaching for a fix, understand what the report is actually telling you. **Slack** is the timing margin — the difference between when a signal arrives and when it needs to arrive at the destination flip-flop. Negative slack means the path is failing: the signal is arriving 0.482ns too late. **Data Path Delay** is the total time for the signal to travel from the source flip-flop to the destination. It has two components: - **Logic Delay** — time spent propagating through LUTs, carry chains, DSP slices, and other combinatorial elements between registers. - **Route Delay** — time spent traveling through the physical routing fabric. This is pure wire delay — it has nothing to do with your RTL. **Clock Path Skew** is the difference in clock arrival time between source and destination registers. A negative value means the clock reaches the destination *earlier* than the source — that tightens your setup window. The setup check the tool performs is essentially: ``` Slack = (Clock Period) - (Data Path Delay) - (Clock Uncertainty) + (Clock Skew) = 4.000ns - 3.847ns - 0.035ns + (-0.142ns) = -0.024ns [simplified] ``` The violation is real, and the path is telling you exactly where it comes from. ## The Split That Changes Everything Look at the logic/route breakdown: ``` Logic Delay : 0.461ns (12%) Route Delay : 3.386ns (88%) ``` **This is not a logic problem.** There is almost nothing to optimize in the RTL. If you add a pipeline stage, you split the data path — but the new shorter path is still 88% routing-dominated. The pipeline register moves the problem; it doesn't fix it. If you reduce LUT depth, you shave fractions of a nanosecond off a budget that's already only 0.461ns. The 3.386ns routing delay doesn't move at all. The signal is traveling a long distance across the FPGA fabric. That's a **placement problem**, not a logic problem. ## The Clock Skew Makes It Worse The clock path skew of −0.142ns works directly against setup timing. Positive skew *helps* setup — the destination clock arrives later, giving data more time to propagate. Negative skew does the opposite: the destination clock arrives earlier, shrinking the window. In this case, the placer has already put the registers far apart — and the clock tree has compounded it with unfavorable skew. The routing was already marginal; the clock distribution made it worse. ## The 60% Rule of Thumb > **Routing delay should not consume more than 60% of your clock period.** At 250 MHz, the clock period is 4.000ns. 60% of that is 2.4ns. The route delay here is **3.386ns — 85% of the clock period**. That's nearly 1ns beyond the threshold. When you see a number like this, stop looking at the RTL. The problem is physical. *The twelve common causes of FPGA timing failures are covered in detail in Chapter 4, Section 4.6.6 of Demystifying the Digital Design Interview.* ## The Fix: Guide the Placer The solution is to help the placer co-locate the communicating registers. ### Option 1: Pblock Constraint ```tcl create_pblock pblock_tx_rx_pipe add_cells_to_pblock [get_pblocks pblock_tx_rx_pipe] \ [get_cells -hierarchical -filter {NAME =~ u_tx_pipeline/*}] add_cells_to_pblock [get_pblocks pblock_tx_rx_pipe] \ [get_cells -hierarchical -filter {NAME =~ u_rx_pipeline/*}] resize_pblock [get_pblocks pblock_tx_rx_pipe] \ -add {SLICE_X10Y100:SLICE_X30Y150} ``` > **Note:** Pblocks are a scalpel, not a paintbrush. Constrain only what you understand. Over-constraining removes escape routes and can make other paths worse. ### Option 2: KEEP\_HIERARCHY ```systemverilog (* keep_hierarchy = "yes" *) module tx_pipeline ( input logic clk, input logic [7:0] data_in, output logic [7:0] data_out ); always_ff @(posedge clk) begin data_out <= data_in; end endmodule ``` Or via XDC: `set_property KEEP_HIERARCHY TRUE [get_cells u_tx_pipeline]` ### Option 3: Structural RTL Refactor (Last Resort) If the two registers belong to modules architecturally far apart, consider whether the interface between them can be redesigned to be more local. Sometimes a long routing path is a symptom of an interface that shouldn't exist at that level of the hierarchy. ## What You Are Not Doing To be explicit about what *doesn't* fix this: - **Adding pipeline stages** — you're cutting an already logic-light path. Routing delay still dominates. - **Changing clock constraints** — relaxing by 200ps hides the violation but doesn't change physics. - **Restructuring RTL to reduce LUT count** — logic is 12% of the problem. Even eliminating it entirely only recovers 0.461ns. The violation is 0.482ns. > *"A clock constraint is a declaration of intent — not a fix."* > — Chapter 4, Page 118, Section 4.2 · *Demystifying the Digital Design Interview* ## The Broader Lesson Timing failures have different root causes, and the report tells you which category you're in: | Dominant delay | Root cause | Fix direction | | ---------------------- | ----------------------- | ------------------------------------------------ | | Logic-dominated (>60%) | Too many logic levels | Pipeline, retime, restructure RTL | | Route-dominated (>60%) | Poor placement | Pblocks, KEEP\_HIERARCHY, floorplan review | | Skew-dominated | Clock tree or CDC issue | Review clock buffers, synchronizers, constraints | | Combined | Marginal design | Combination of above; check SLR crossings | Read before you react. There is no one-size-fits-all fix for a timing violation — the path tells you what it needs. --- *This post is based on content from Chapter 4: Static Timing Analysis & Timing Closure in* Demystifying the Digital Design Interview: The Missing Guide for Practical RTL and FPGA Interview Preparation *by Milind Parelkar.* **Practice interview questions on this topic →** [FPGA Architecture Questions](https://fpgadesign.io/fpga-concepts/) ### XPMs: Beyond Instantiation and Inference URL: https://fpgadesign.io/blog/xpm/ Last updated: 2026-05-18T00:11:34.000Z # Xilinx Parameterizable Macros, or **XPMs**, are parameterized design macros provided as synthesizable HDL code within the Vivado Design Suite. They offer customizable building blocks for common FPGA components such as **memories (RAM/ROM), clock domain crossing (CDC) circuits, and FIFO buffers**. XPMs are intended for seamless use with UltraScale and other modern Xilinx architectures. They allow designers to instantiate complex hardware primitives by copying the template code, then setting parameters like data width, depth, and synchronization stages. This method reduces dependency on bulky IP cores, while ensuring efficient integration with Vivado's synthesis and implementation processes. Key XPM categories include: - **XPM\_MEMORY:** Configurable RAM and ROM blocks optimized for various device families. - **XPM\_CDC:** Reliable clock domain crossing modules including synchronizers and gray code encoding. - **XPM\_FIFO:** Synchronous and asynchronous FIFO structures for data buffering and clock domain crossing. Vivado automatically recognizes XPMs when their source files are included in projects. In non-project flow, an `auto_detect_xpm` Tcl command is needed to enable them. Instantiation templates help quickly set up macros with properly parameterized ports and generics. XPMs provide a lightweight and flexible alternative to traditional IP, enabling FPGA developers to optimize resource use and speed up design cycles with well-supported, modular hardware primitives. _This post is for subscribers only._ ### "Levels of Logic" in FPGA Timing Reports and Why It Matters? URL: https://fpgadesign.io/blog/levels-of-logic/ Last updated: 2026-05-18T00:11:35.000Z To build high-performance FPGA designs, you need to understand the underlying hardware. One crucial concept is **"levels of logic."** This term describes the number of combinatorial elements a signal passes through, directly influencing your design's achievable clock frequency, resource utilization, and power consumption. This article will break down what "levels of logic" means in Xilinx FPGAs, including how elements like LUTs, dedicated MUXes, and even special shifting capabilities play a role. ### I. Introduction: Why does this matter? The number of "levels of logic" has a direct impact on the performance of the design, in terms of the maximum clock frequency that it can safely operate at. The maximum clock frequency of your design is inversely proportional to the longest combinatorial delay path (or critical path). More levels of logic directly translate to longer delays, which means a slower maximum clock frequency. Your synthesis and implementation tools (like Vivado) constantly strive to minimize these levels. ### II. The Fundamental Building Block: The Look-Up Table (LUT) At the heart of Xilinx FPGA combinational logic is the **Look-Up Table (LUT)**. In 7-series and UltraScale devices, the primary LUTs are 6-input LUTs (LUT6s). A LUT isn't a collection of individual gates; it's a small memory that stores the output for every possible combination of its inputs. For a 6-input LUT, it can implement *any* Boolean function of its 6 inputs. Regardless of the complexity of the function, as long as it fits within 6 inputs, a single LUT6 constitutes **one level of logic**. **Therefore, when counting combinational depth, one level of logic is typically considered equivalent to one LUT.** For example, an AND gate, an OR gate, an XOR gate, or even a more complex 6-input function, all consume one LUT and thus represent one level of logic. However, if your combinational function requires more than 6 inputs (e.g., an 8-input AND gate), it cannot be implemented by a single LUT6\. It would require multiple LUTs, chained together. For instance, an 8-input AND gate might be implemented by two LUT6s whose outputs feed into a third LUT6\. This would result in **two levels of logic**. ### III. Beyond Basic LUTs: Dedicated Logic and Optimization While LUTs are versatile, using them for everything would be inefficient for common, structured operations. Xilinx FPGAs incorporate dedicated hardware to bypass LUTs for specific functions, significantly reducing logic levels and improving performance. _This post is for subscribers only._ ### Number Systems in Digital Design: Signed Arithmetic, Ones Complement and Twos Complement URL: https://fpgadesign.io/blog/number-systems/ Last updated: 2026-05-18T00:11:43.000Z ## Binary Number Systems in Digital Design **Binary numbers** are at the heart of digital logic, but representing **signed** (positive and negative) numbers requires special encoding. Three systems commonly used in FPGAs, microprocessors, and digital circuits are **signed magnitude**, **ones complement**, and **twos complement**. Each has unique properties impacting arithmetic, hardware complexity, and software compatibility. ## Signed Magnitude **Signed magnitude** is the most intuitive method. Here, the **most significant bit (MSB)** indicates the sign: **0** for positive, **1** for negative. The remaining bits represent the absolute value (magnitude) of the number. **Example (4-bit):** - **+5** \= `0101` - **–5** \= `1101` **Advantages:** - **Simple to understand** for humans. - **Easy to negate** (just flip the sign bit). - **Direct separation** of sign and magnitude. **Disadvantages:** - **Two zeros:** `0000` (+0) and `1000` (–0), which complicates hardware logic and software comparisons. - **Complex arithmetic:** Addition and subtraction require separate logic to handle signs and magnitudes, increasing hardware complexity. - **Range:** For *n* bits, range is **\-2n-1 to +2n-1**. For 4 bits: **–7 to +7**. ## Ones Complement In **ones complement**, positive numbers are represented as in unsigned binary, while negatives are formed by **inverting all bits** (including the sign bit) of the corresponding positive number. **Example (4-bit):** - **+3** \= `0011` - **–3** \= `1100` (flipped `0011`) **Advantages:** - **Easy negation:** Just invert all bits[1](https://www.electronics-tutorials.ws/binary/signed-binary-numbers.html?ref=fpgadesign.io). - **Addition:** Simple circuit using inverters for negation[1](https://www.electronics-tutorials.ws/binary/signed-binary-numbers.html?ref=fpgadesign.io). - **Range:** Same as signed magnitude: **–7 to +7** for 4 bits. **Disadvantages:** - **Still two zeros:** `0000` (+0) and `1111` (–0), leading to similar problems as signed magnitude. - **End-around carry:** Addition may require a carry to loop back, complicating hardware. - **Arithmetic:** Not as streamlined as twos complement. ## Twos Complement **Twos complement** is the **de facto standard** in modern computing. Positive numbers are represented as normal. Negatives are formed by **inverting all bits and adding 1** to the least significant bit (LSB). **Example (4-bit):** - **+3** \= `0011` - **–3**: Invert (`0011` → `1100`), add 1 = `1101` **Advantages:** - **One zero:** Only `0000` represents zero, eliminating ambiguity. - **Efficient arithmetic:** Addition and subtraction use the same hardware, with no need for extra sign logic. - **Simplified hardware:** Circuits are smaller and faster. - **Larger range:** For *n* bits, range is **\-2n-1 to +(2n-1 \- 1)**. For 4 bits: **–8 to +7**. - **Integer overflow:** Wraps naturally, which simplifies boundary conditions. **Disadvantages:** - **Negation:** Slightly more complex due to the “add 1” step. - **Least negative value:** `1000` (for 4 bits) is –8, which does not have a positive counterpart in the same bit width. --- ## Comparison Table | Feature | Signed Magnitude | Ones Complement | Twos Complement | | ----------------------- | ----------------------- | ---------------- | -------------------------- | | **Zero Representation** | Two (+0, –0) | Two (+0, –0) | **One** (0) | | **Negation** | Flip sign bit | Flip all bits | Flip all bits, add 1 | | **Addition Logic** | Complex (sign handling) | End-around carry | Standard, no special steps | | **Range (4-bit)** | –7 to +7 | –7 to +7 | **–8 to +7** | | **Hardware Cost** | High | Moderate | **Low** | | **Use** | Rare | Historical/rare | **Universal** | ## Preference for Twos Complement **Twos complement** is preferred in virtually all modern digital systems, including FPGAs, because it **eliminates redundant zero**, **simplifies arithmetic**, and **reduces hardware complexity**. This makes it faster, smaller, and more reliable—critical for performance and power-sensitive embedded designs. **Signed magnitude** is mostly of historical or educational interest, while **ones complement** survives mainly in legacy systems due to its simple negation logic. ## Practical Implications for FPGA Design When designing digital circuits in VHDL, Verilog, or with FPGA tools: - **Use twos complement** for all arithmetic operations. - **Understand overflow**: In twos complement, adding two large positives can produce a negative, and vice versa—this is intentional and must be accounted for in your logic. - **Conversion**: When interfacing with external systems, be aware of the number system used to avoid misinterpretation. **Practice interview questions on this topic →** [Digital Logic Questions](https://fpgadesign.io/digital-logic/) ### Beyond Basic Gates: How Multiplexers Map to LUTs and the Power of Xilinx F7, F8 MUXes URL: https://fpgadesign.io/blog/f7-mux/ Last updated: 2026-05-18T00:11:36.000Z In the intricate world of FPGA design, some components are so fundamental they become almost invisible. The **multiplexer (MUX)** is one such unsung hero. From selecting data paths in a processor to directing signals in a complex communication protocol, MUXes are everywhere. But have you ever stopped to consider how these critical data selectors are actually implemented within the vast, reconfigurable fabric of a Xilinx FPGA? This article will pull back the curtain, demystifying how MUXes map from your HDL code onto the underlying hardware. We'll start with how simple MUXes fit neatly into Look-Up Tables (LUTs), then explore the challenges of building wider MUXes, and finally, reveal the elegance and power of Xilinx's dedicated **F7 MUX** for high-performance 8:1 multiplexing. ### I. The Basics: Mapping Small MUXes to LUTs At its core, a multiplexer is a data selector. It takes multiple input data lines, a set of select lines, and outputs just one of the input data lines based on the binary value of the select lines. If a MUX has 'N' data inputs, it requires 'M' select lines where 2M=N. In Xilinx 7-series and UltraScale FPGAs, the primary combinational logic element is the **6-input Look-Up Table (LUT6)**. A LUT6 can implement *any* Boolean function of its 6 inputs. #### 💡Implementing a 2:1 MUX in a LUT Let's start with the simplest case: a 2:1 MUX. This MUX has two data inputs (e.g., `I0`, `I1`) and one select line (`S0`). It effectively chooses between `I0` or `I1`. A 2:1 MUX requires only 3 inputs in total (`I0`, `I1`, `S0`). This fits comfortably within a LUT6\. The synthesis tool will configure a `LUT6` to implement this function. This consumes just **one level of LUT logic**. #### 💡Implementing a 4:1 MUX in a LUT Now consider a 4:1 MUX. This requires four data inputs (e.g., `I0` through `I3`) and two select lines (`S0`, `S1`). The total number of inputs for this function is 4+2=6. A 4:1 MUX maps perfectly to a single LUT6, utilizing all its inputs. This still consumes **one level of LUT logic**. This demonstrates the efficiency of the LUT: any combinational function with up to 6 inputs can be implemented in a single LUT, meaning minimal propagation delay (one logic level). ### III. The Challenge: Building Wider MUXes with Only LUTs The efficiency of mapping small MUXes to single LUTs runs into a hard limit: the fixed number of inputs on a LUT (typically 6 for Xilinx). Consider the requirements for an **8:1 MUX**: - 8 data inputs - 3 select lines (since 23=8) - Total inputs required = 8+3=11 inputs. Clearly, an 8:1 MUX cannot be implemented by a single LUT6\. If only general-purpose LUTs were available, the synthesis tool would have to break it down and rely on **LUT chaining**: - You'd typically use two 4:1 MUXes (each implemented by one LUT) to handle the first four inputs and the next four inputs, respectively, based on the lower two select lines. - The outputs of these two 4:1 MUXes would then feed into a third 2:1 MUX (implemented by another LUT), which is controlled by the most significant select line. ![](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2025/07/image-2.png) Image Credit: Xilinx Application Note XAPP522 In this purely LUT-based approach, the 8:1 MUX consumes 3 LUTs. More importantly, the critical data path (from a data input through the MUXes to the output) would traverse **two distinct levels of LUT logic** (e.g., Data Input -> 4:1 LUT -> 2:1 LUT -> Output). This cascading introduces increased propagation delay, directly impacting the maximum clock frequency your design can achieve. For even wider MUXes (e.g., 16:1 or 32:1) built solely with LUTs, the number of cascaded LUT levels would grow further, leading to severe performance bottlenecks. ### IV. Xilinx's Solution: The Dedicated F7 MUX To overcome the performance limitations of LUT-only MUX chaining, Xilinx FPGAs incorporate specialized, dedicated hardware blocks for wide multiplexing. The key dedicated element for 8:1 multiplexing is the **F7 MUX**. The F7 MUX is not a general-purpose LUT; it's a pre-optimized, hardwired logic block specifically engineered to implement an **8:1 multiplexer** with remarkable efficiency. Crucially, the F7 MUX significantly optimizes the path for an 8:1 MUX. While the overall 8:1 MUX structure still involves an initial stage of LUTs (to handle the 4:1 selections), the F7 MUX acts as a highly optimized, extremely fast **single dedicated stage** to combine these results. This effectively collapses what would have been a slower, full LUT-based final stage into a much faster, dedicated MUX element. This dedicated path ensures minimal propagation delay for the 8:1 selection, leading to far superior overall performance compared to a purely LUT-chained approach. ### V. Advantages of Using Dedicated F7 MUXes The inclusion and automatic inference of dedicated F7 MUXes offer profound advantages for FPGA designers: - **Superior Performance:** This is the most significant benefit. By utilizing a highly optimized, dedicated MUXF7 for the critical selection stage, propagation delays are dramatically shortened. This enables much higher achievable clock frequencies for designs involving wide data selection compared to an all-LUT implementation. - **Resource Efficiency:** Utilizing dedicated hardware elements means less reliance on general-purpose LUTs, which are freed up for other complex combinational logic functions. This contributes to more efficient overall resource utilization. - **Predictable Timing:** Dedicated MUX elements have optimized and well-characterized delays, making their timing behavior more consistent and predictable. This simplifies timing closure and debugging in high-performance designs. ### VI. Inferring F7 MUXes in SystemVerilog For designers, the good news is that you typically don't need to explicitly instantiate F7 MUX primitives. Modern synthesis tools, such as Vivado for Xilinx devices, are highly intelligent. When they encounter a standard HDL construct that represents an 8:1 multiplexer, they will automatically recognize the pattern and infer the dedicated F7 MUX. AMD Xilinx's documentation, specifically recommends using `case` statements for clear and efficient MUX inference: ```Verilog module eight_to_one_mux ( input [7:0] data_in, // 8 data inputs input [2:0] sel, // 3 select lines for 8 inputs output reg data_out ); always_comb begin case (sel) 3'b000: data_out = data_in[0]; 3'b001: data_out = data_in[1]; 3'b010: data_out = data_in[2]; 3'b011: data_out = data_in[3]; 3'b100: data_out = data_in[4]; 3'b101: data_out = data_in[5]; 3'b110: data_out = data_in[6]; 3'b111: data_out = data_in[7]; default: data_out = '0; endcase end endmodule ``` It's also worth noting that Xilinx devices offer even wider dedicated MUX blocks like **F8 MUXes** (for 16:1 multiplexing). These are built by cascading lower-level dedicated MUX elements, always striving to minimize combinational depth and maximize performance. ### VII. Conclusion Understanding how multiplexers map to FPGA hardware is a vital piece of architectural knowledge for any serious FPGA designer. While simple MUXes map efficiently to single LUTs, the demands of wider data selection quickly expose the limitations of LUT chaining. Xilinx's dedicated F7 MUX blocks (and their wider counterparts like the F8) provide an elegant and highly optimized solution, allowing for the construction of high-performance MUX trees. --- ### ✒️References 1. Xilinx Application Note - Multiplexer Design Techniques for Datapath Performance with Minimized Routing Resources Application Note (XAPP522) 2. Xilinx User Guide - UltraScale Architecture Libraries Guide (UG974) **Practice interview questions on this topic →** [FPGA Architecture Questions](https://fpgadesign.io/fpga-concepts/) ### Fixed-Point Representation: Mastering Precision in FPGA Design URL: https://fpgadesign.io/blog/fixed-point-representation-mastering-precision-in-fpga-design/ Last updated: 2026-05-18T00:11:46.000Z In digital design, especially when leveraging the power of FPGAs, efficiently representing real numbers with fractional components is a cornerstone challenge. While various methods exist, **fixed-point representation** stands out as a highly effective and frequently preferred approach due to its direct mapping to hardware and its inherent efficiency. This post will dive deep into fixed-point numbers, exploring their structure, how they are represented, the critical distinction between signed and unsigned formats, and why mastering fixed-point is essential for optimal FPGA design. ### What Exactly is Fixed-Point Representation? At its heart, fixed-point representation is a method of representing real numbers where the position of the binary point (analogous to a decimal point in base-10) is *fixed* and predetermined. Unlike floating-point where the point "floats" based on an exponent, in fixed-point, you explicitly define how many bits are for the integer part and how many are for the fractional part. Consider a binary number like `1011.0110`. In a fixed-point system, we would decide beforehand where that binary point sits. If we allocate 4 bits for the integer part and 4 bits for the fractional part, this exact number fits perfectly. The elegance of fixed-point lies in its simplicity for hardware. **Arithmetic operations (addition, subtraction, multiplication) on fixed-point numbers can largely be performed using standard integer arithmetic units, followed by appropriate scaling or shifting to account for the implicit binary point.** --- #### The Qm.n Notation: Defining Your Precision A common and intuitive notation for fixed-point numbers is **Qm.n**. - **'Q'** simply indicates a fixed-point number. - **'m'** represents the number of bits allocated for the **integer part** (including the sign bit for signed numbers). - **'n'** represents the number of bits allocated for the **fractional part**. The total number of bits for the fixed-point number would be m+n. _This post is for subscribers only._ ### Negative Hold Time Values in the Datasheet: Theory and Implications URL: https://fpgadesign.io/blog/negative-hold-time/ Last updated: 2026-05-18T00:11:43.000Z ## **Introduction: The Basics of Setup and Hold Time** Please refer to these two pages for an in-depth explanation of Setup and Hold times and how they feed into the timing closure equation - 1. [Introduction to Static Timing Analysis](https://fpgadesign.io/the-fundamentals-of-static-timing-analysis-in-digital-circuits/) 2. [Advanced Topics in Static Timing Analysis and Timing Closure](https://fpgadesign.io/advanced-topics-in-static-timing-analysis/) ## **What is a Negative Hold Time?** A **negative hold time** means that the data input can change *before* the active clock edge, and the flip-flop will still correctly capture the *old* data. It's counter-intuitive to the standard definition, but it effectively extends the "safe" window for data change *before* the clock edge. ## **Why Do Negative Hold Times Occur?** - **Internal Delays:** This is the primary reason. It's due to the internal propagation delays within the flip-flop itself, specifically the difference in delays between the clock path and the data path to the internal latching element. - If the clock signal takes longer to reach the internal latching element than the data signal does, it creates a "margin" where the external data can change *before* the clock edge and still be correctly sampled by the delayed internal clock. - Think of it as the effective clock edge for the internal latching element being slightly delayed relative to the external clock pin. - **Fabrication Process:** It's a characteristic of the specific flip-flop design and the semiconductor process technology. Designers can intentionally design flip-flops with negative hold times. ## **Implications for Circuit Design** - **Benefits (Design Flexibility):** - **Eases Hold Constraints:** A negative hold time provides more "slack" for the hold check. It means that the data path can be *shorter* (or faster) relative to the clock path without violating hold time. - **Simplifies Routing/Layout:** Designers have more flexibility in placing components and routing signals, especially for short data paths, as they don't need to intentionally add delay to meet a positive hold requirement. - **Critical for High-Speed Designs (e.g., DDR Memory):** In very high-speed interfaces like DDR SDRAM, where data rates are extremely high, negative hold times can be crucial to achieve the required timing margins. It allows data to transition almost immediately after the clock edge without causing a hold violation. - **Potential Drawbacks/Considerations:** - While it helps with hold time, it might sometimes come at the expense of a larger *setup time* requirement for the same flip-flop. (Though not always, and it's a design tradeoff). - Requires careful Static Timing Analysis (STA): Designers must accurately account for these negative values in their timing analysis tools to ensure correct operation across all operating conditions (PVT variations). - Doesn't eliminate the need for *any* hold time check: It simply shifts the "safe window." Data still needs to be stable for a certain *total* aperture, even if part of that is before the clock edge. ## **Conclusion** - Negative hold times are not an error or a problem; they are a legitimate and often beneficial characteristic of modern digital circuits. - They provide valuable flexibility for designers, especially in high-speed applications, by relaxing hold constraints. - Understanding and properly accounting for them in timing analysis is key to robust digital design. --- ## Why are there no Negative Setup Times in the Datasheet? It's important to clarify that while negative hold times are a real and utilized phenomenon in digital design, **negative setup times**, on the other hand, do not practically exist. A negative setup time would mean that data could change after the clock edge and still be captured correctly. It is intuitive to see what kind of chaos that would cause!! **Practice interview questions on this topic →** [Digital Logic Questions](https://fpgadesign.io/digital-logic/) ### Understanding Synthesis Directives URL: https://fpgadesign.io/blog/synthesis-directives/ Last updated: 2026-05-18T00:11:36.000Z As hardware designers, we write RTL (Register-Transfer Level) code in languages like SystemVerilog to describe the behavior of our digital circuits. But between that descriptive code and the final bitstream, there's a crucial step: **synthesis**. Synthesis tools interpret our SystemVerilog RTL and map it to the actual gates and primitives available on our target FPGA or ASIC. This is where **synthesis directives**, also known as **synthesis attributes** or **pragmas**, come into play. They are special constructs embedded directly in your SystemVerilog code that serve as explicit instructions or "hints" to the synthesis tool, guiding its optimization process beyond what it could infer purely from standard HDL. Some of these are "soft" directives, which are used to point the tool in the direction that the designer is leaning towards, but the final decision rests with the tool. "Hard" directives on the other hand override any decisions that the tool might make otherwise. ### What are SystemVerilog Synthesis Directives? SystemVerilog synthesis directives are not part of the core IEEE standard for the language. Instead, they are vendor-specific or tool-specific meta-information that you embed directly into your code. They do not affect the simulation behavior of your RTL, but they significantly influence the output of the synthesis stage. **SystemVerilog Syntax Example:** In SystemVerilog (and Verilog), directives are typically placed as `(* attribute_name = "value" *)` right before the declaration of a `module`, `wire`, `logic` signal, register, or instanced component. Some are also inline comments like `// synthesis translate_off`. _This post is for subscribers only._ ### ASIC-Style Clock Gating in FPGAs URL: https://fpgadesign.io/blog/clock-gating/ Last updated: 2026-05-18T00:11:37.000Z In ASIC design, achieving low power consumption is paramount, driven by factors like battery life in mobile devices, heat dissipation in high-performance systems, and overall energy efficiency. One of the most effective and widely adopted techniques for reducing dynamic power consumption in ASICs is **clock gating**. This method involves selectively disabling the clock signal to portions of the digital circuit when they are not actively performing computations or storing new data. Since the clock network is often the largest consumer of dynamic power within a chip (due to its high switching frequency and large fanout), stopping the clock from toggling in idle blocks can yield significant power savings. When transitioning to FPGA design, many engineers might instinctively try to replicate this approach. Crucially, when using FPGAs for ASIC prototyping or emulation, the goal of implementing "clock gating-like" functionality **isn't always about power saving** within the FPGA itself. Instead, it's often to accurately mimic the functional behavior of the intended ASIC design, where clock gating *will* be used for power optimization. This ensures functional equivalence and helps validate the ASIC's power-aware design methodology. However, due to the unique, pre-defined architecture of FPGAs, directly implementing ASIC-style clock gating in general fabric is almost always a recipe for disaster. This post will elaborate on why direct clock gating in FPGA fabric is problematic and then detail the Xilinx-specific mechanisms—particularly **Clock Enables** and specialized **Global and Regional Clock Buffers**—that provide similar functionality with predictable, reliable results. --- ### Why ASIC-Style Clock Gating Fails in Xilinx FPGA Fabric Xilinx FPGAs, like other vendor devices, are built upon a regular, interconnected array of configurable logic blocks (CLBs), dedicated memory blocks (BRAMs), DSP slices, and highly optimized clock networks. These dedicated clock networks are engineered for incredibly low skew and jitter, ensuring that clock edges arrive at thousands of flip-flops almost simultaneously. When you attempt to "gate" a clock using standard Look-Up Tables (LUTs) and general routing fabric (e.g., `assign gated_clk = clk_in & enable;`), it could lead to some potential problems: 1. **Glitches and Metastability:** Combinational logic (LUTs) can produce transient glitches if inputs don't arrive simultaneously. A glitch on a clock input can cause a flip-flop to misinterpret the clock edge. This can lead to metastability, where the flip-flop's output enters an undefined state, potentially propagating errors throughout the design. **ASIC clock gating cells are purpose-built to be glitch-free.** 2. **Unacceptable Clock Skew:** The general routing fabric is optimized for data paths, not for distributing high-speed, low-skew clock signals. Routing a gated clock through this fabric introduces **highly variable delays and significant clock skew** between different flip-flops that are supposedly driven by the "same" gated clock. High skew drastically eradicates your timing margin, leading to setup and hold violations, especially at higher frequencies. 3. **Increased Jitter:** Routing clocks through general fabric adds noise and variability to the clock period, increasing jitter. High jitter reduces the effective time available for logic computation, limiting the maximum achievable frequency (Fmax) of the design. 4. **Inefficient Power Saving:** While a portion of the clock signal might be stopped, the dominant power consumption in an FPGA often comes from the massive, always-on global clock buffers and their associated distribution networks. The marginal power savings from fabric gating are often outweighed by the reliability and performance penalties. --- ### The Xilinx-Recommended Approach: Clock Enables The primary and robust method for conditionally updating registers and achieving power savings in Xilinx FPGAs is by utilizing the **Clock Enable (CE)** pin, which is an inherent feature of almost every synchronous element (flip-flop, register, Block RAM, DSP slice) in the device. When the CE signal for a flip-flop is asserted (high), the flip-flop updates its state on the next active clock edge. When CE is de-asserted (low), the flip-flop ignores the clock edge and retains its current state. **Advantages of Clock Enables:** - **Integrated into Architecture:** The CE input is an integral part of the flip-flop's internal design, ensuring predictable, glitch-free operation. - **Leverages Dedicated Clock Networks:** The main clock signal continues to propagate through the highly optimized global clock networks, ensuring low skew and high fidelity. Power savings occur at the flip-flop level by preventing internal toggling. - **Synthesis Friendly:** Xilinx's synthesis tools (like Vivado Synthesis) are designed to infer CE pins from standard HDL constructs. For instance, an `if (enable_signal) begin ... end` statement around a register update in Verilog or VHDL will typically be mapped directly to the flip-flop's CE input. #### **Example HDL (Verilog) for Clock Enable:** ```Verilog always_ff @(posedge clk) begin if (!reset_n) begin // Active-low reset data_reg <= 0; end else if (enable_data_path) begin // The 'clock enable' condition data_reg <= data_in; // This register only updates when //enable_data_path is high end end ``` --- ### Xilinx Global and Regional Clock Buffers: Recommended Approach to Clock Gating in FPGAs Xilinx FPGAs feature a sophisticated clock management tile (CMT) infrastructure that includes dedicated global and regional clock buffers. These buffers are placed on specialized, low-skew clock networks, providing options for both wide distribution and localized clock control. ### **`BUFG` (Global Clock Buffer)** - **Purpose:** The workhorse for distributing high-speed, low-skew clocks across the entire FPGA. It takes a clock input (often from an I/O pin or a clock management tile like an MMCM/PLL) and drives it onto a global clock network. - **Functionality:** Simply buffers and distributes a clock. It does not have an enable input for gating. - **Use Case:** Ideal for primary system clocks, MMCM/PLL outputs, or any clock that needs to reach many synchronous elements with minimal skew. - **Inference:** Often inferred automatically by the tools if a clock is driven from a clock-capable pin or MMCM/PLL output. Can be instantiated explicitly for precise control. ### **`BUFGCE` (Global Clock Buffer with Clock Enable)** - **Purpose:** Xilinx's robust solution for controlled global clock gating. It's a `BUFG` with an added, dedicated **enable (CE)** input. When the CE input is logic '0', the clock output is stopped in a glitch-free manner. When CE is '1', the clock passes through. - **Functionality:** Provides glitch-free clock gating on a global clock network. The enable signal is synchronized internally to the clock domain, ensuring safe operation. - **Advantages:** - **Glitch-Free:** Designed specifically to prevent glitches on the clock output when enabled/disabled. - **Low Skew:** The gated clock still utilizes the highly optimized global clock network. - **Significant Power Savings:** When the `BUFGCE` is disabled, the entire clock tree driven by it in that region stops toggling, leading to substantial dynamic power reduction for large blocks or entire clock domains. - **Use Case:** Shutting down clock activity to large, independent functional blocks (e.g., an entire Ethernet MAC block, a video processing pipeline) when they are idle. This is the closest you get to ASIC-style clock gating in an FPGA that is both safe and effective for power. - **Instantiation:** Must be explicitly instantiated in your HDL, as the synthesis tools generally won't infer it automatically from standard gating logic. ```Verilog // Assuming 'sys_clk_200mhz' is a continuous clock from an MMCM/PLL // 'enable_ethernet_block' is a control signal to gate the clock logic clk_eth_gated; BUFGCE ethernet_clk_buf ( .O (clk_eth_gated ), // Gated clock output .I (sys_clk_200mhz ), // Input clock from MMCM/PLL .CE (enable_ethernet_block) // Clock Enable input ); // Now use 'clk_eth_gated' as the clock for your Ethernet block logic always_ff @(posedge clk_eth_gated) begin // ... Ethernet MAC logic ... end ``` ### **`BUFGCEDIV` (Global Clock Buffer with Divider and Clock Enable)** - **Purpose:** A more advanced global clock buffer that combines clock enabling with dynamic clock division. It allows you to generate a divided clock (e.g., clk/2, clk/4, clk/8) from an input clock, and also enable/disable that divided clock. - **Functionality:** Offers glitch-free clock gating and selectable division ratios (often /1, /2, /4, /8) controlled by input signals. - **Use Case:** Useful for blocks that need to operate at a lower frequency for power saving or to accommodate different operational modes, where the division ratio can change on the fly. - **Instantiation:** Explicit instantiation is required. ```Verilog // Assuming 'sys_clk' is the primary clock // 'div_select' controls division (e.g., 00->/1, 01->/2, 10->/4, 11->/8) // 'enable_low_power_block' gates the divided clock logic clk_divided_gated; BUFGCEDIV low_power_clk_buf ( .O (clk_divided_gated ), .I (sys_clk ), .CE (enable_low_power_block), .DIV (div_select ) // e.g., 2-bit input for division ratio ); always_ff @(posedge clk_divided_gated) begin // ... Low power mode logic ... end ``` ### **Regional Clock Buffers (`BUFHCE`, `BUFR`):** - **Purpose:** Besides global buffers, Xilinx FPGAs also offer regional clock buffers like `BUFHCE` (Horizontal Clock Buffer with Clock Enable) and `BUFR` (Regional Clock Buffer). - **Functionality:** These buffers also include clock enable capabilities, providing glitch-free clock gating for logic confined to specific horizontal or general clock regions. `BUFR` can also perform clock division. - **Use Case:** They are ideal for "medium-grained" clock gating, where a functional block is localized within a clock region and does not require global clock distribution, offering power savings more efficiently than a global buffer for such localized control. - **Instantiation:** Explicit instantiation is typically required. --- ### Other Power Optimization Techniques Specific to Xilinx FPGAs Beyond clock enabling and dedicated buffers, Xilinx FPGAs offer several other strategies for power reduction: - **Clock Management Tiles (CMTs - MMCMs/PLLs):** These are hard IP blocks that generate precisely controlled clocks (multiplied, divided, phase-shifted) from input clocks. They are far more power-efficient and reliable for clock generation than implementing similar logic in general fabric. They also allow for fine-grained control over clock frequencies, which directly impacts dynamic power. - **Power Optimization Synthesis/Implementation Strategies:** Vivado design suite offers specific strategies (e.g., `Power_DefaultOpt`, `Power_ExploreWithBalance`, `Power_Explore` for synthesis and implementation) that prioritize power reduction during the compilation process. These strategies use various algorithms to minimize toggling, shorten routes, and utilize lower-power logic elements. - **High-Level Synthesis (HLS):** Tools like Vivado HLS can often produce more optimized and power-efficient RTL from C/C++/SystemC descriptions by exploring different architectures and scheduling options that might reduce activity. - **Partial Reconfiguration (PR):** For advanced designs, PR allows you to reconfigure only a portion of the FPGA while the rest of the device remains operational. This can be used to "power down" unused sections of the device by reconfiguring them with a low-power "blank" bitstream, or by dynamically loading only the logic required for the current operation. - **Dedicated Hard IP Utilization:** Using Xilinx's hardened IP blocks (e.g., PCIe controllers, DDR memory controllers, transceivers) for common functions is almost always more power-efficient than implementing the same functionality in programmable logic. These blocks often have their own internal power management features. - **I/O Standards and Termination:** Selecting appropriate I/O standards and termination schemes to minimize power consumption on the I/O pins, which can be a significant contributor to overall device power. ### Conclusion While **clock gating** is a powerful ASIC technique for power optimization, directly replicating it using standard logic in an FPGA is typically detrimental to timing and reliability. Xilinx FPGAs achieve similar functionality and power savings primarily through **clock enable (CE) signals** on individual synchronous elements, which is a safer and more predictable approach given their architectural constraints. For larger, regional power savings, specialized clock-gating-capable global clock buffers like `BUFGCE` and `BUFGCEDIV`, as well as regional buffers like `BUFHCE` and `BUFR`, are available. Understanding this fundamental difference is key to designing efficient and robust FPGA systems. **Practice interview questions on this topic →** [FPGA Architecture Questions](https://fpgadesign.io/fpga-concepts/) ### Understanding Clock Constrains URL: https://fpgadesign.io/blog/clock-constraints/ Last updated: 2026-05-18T00:11:38.000Z Field-Programmable Gate Arrays (FPGAs) offer an unparalleled blend of hardware flexibility and reconfigurability, empowering the creation of sophisticated digital systems. However, merely translating HDL (Hardware Description Language) into a netlist is insufficient for a successful FPGA implementation. To achieve desired performance, ensure reliable operation, and enable effective utilization of the underlying silicon, precise guidance to the synthesis and place-and-route tools is indispensable. This guidance comes in the form of **design constraints**. **Design constraints are not merely suggestions; they are directives that define the operational environment and performance targets for your digital design within the FPGA fabric.** Omitting or incorrectly applying them is a primary source of timing violations, suboptimal resource utilization, and ultimately, non-functional hardware. While advanced FPGA designs necessitate intricate and highly specific constraints, a core set of fundamental constraints forms the bedrock for *any* functional and performant FPGA project. Let's delve into the basic of clock constraints for FPGA design. Most of this information is generic and applies to generic synthesis tools as well. --- ## Basic Clock Constraints The first step in constraining your FPGA design is defining the primary clocks that drive your logic. These are typically the clocks that enter your FPGA from external pins. ### **Clock Definition (`create_clock`):** - **Purpose:** To define a clock, specifying its period (and thus frequency), a unique name, and the physical pin or port where it enters the FPGA. This is the fundamental timing reference for all synchronous logic driven by this clock. - **Syntax:** `create_clock -period -name ` - `-period `: Clock period in nanoseconds (e.g., `10.000` for 100 MHz). - `-name `: A unique name for the clock. - ``: The specific input port(s) that carry this clock (e.g., `[get_ports sys_clk_p]`). #### **Examples:** ##### **Single Primary Clock (100 MHz)** ```Tcl # Define a 100 MHz clock (10 ns period) on the 'sys_clk_p' port. create_clock -period 10.000 -name sys_clk [get_ports sys_clk_p] ``` ##### **Multiple Primary Clocks (from different oscillators)** ```Tcl # Define a 125 MHz clock (8 ns period) on 'eth_clk_p' create_clock -period 8.000 -name eth_clk [get_ports eth_clk_p] # Define a 50 MHz clock (20 ns period) on 'usb_clk_p' create_clock -period 20.000 -name usb_clk [get_ports usb_clk_p] ``` In this scenario, `sys_clk`, `eth_clk`, and `usb_clk` are independent primary clocks. --- ### Non-Primary Clocks Many FPGA designs include internal clock generation, often using specialized hard IP like Phase-Locked Loops (PLLs) or Mixed-Mode Clock Managers (MMCMs), or even simple logic like dividers. ### **Generated Clocks (`create_generated_clock`):** - **Purpose:** To inform the timing analysis tools about clocks that are derived from an existing, already defined primary clock. This ensures the tools understand the phase and frequency relationship between the master clock and the derived clock, allowing for accurate timing analysis across these domains. - **When to Use It:** For outputs of PLLs, MMCMs, or any clock produced by logic that modifies a primary clock's frequency or phase. - **Syntax:** `create_generated_clock -name -source [options] ` - `-source `: The pin or port of the master clock from which this clock is generated (e.g., `[get_ports sys_clk_p]` or `[get_pins my_pll_inst/CLKIN]`). - `-name `: A unique name for the generated clock. - `[options]`: Can include `-divide_by `, `-multiply_by `, `-invert`, etc., to describe the clock's relationship to its source. - ``: The pin or port where the generated clock appears (e.g., `[get_pins clk_wiz_0_i/inst/mmcm_adv_inst/CLKOUT0]`). #### **Example:** ```Tcl # Assuming clk_wiz_0 is an IP core for a clock wizard (PLL/MMCM) # sys_clk (primary clock) is defined earlier create_generated_clock -name clk_200mhz_int -source [get_ports sys_clk_p] \ [get_pins clk_wiz_0_i/inst/mmcm_adv_inst/CLKOUT0] # Clock 'div_clk' generated by a simple flip-flop divider, half the frequency of its source create_generated_clock -name div_clk -source [get_pins my_divider_reg/Q] \ -divide_by 2 [get_pins my_divider_reg/Q] ``` --- ## Input, Output Delays, Timing Exceptions and Clock Groups In this section we will look into some of the more advanced concepts related to timing constraints in FPGA design. _This post is for subscribers only._ ### IOSTANDARDs in Xilinx FPGAs URL: https://fpgadesign.io/blog/iostandards/ Last updated: 2026-05-18T00:11:39.000Z What are they and Why are they needed in FPGA Design? _This post is for subscribers only._ ### Endianness: The Byte Order You Didn't Know You Needed to Know URL: https://fpgadesign.io/blog/endianness/ Last updated: 2026-05-18T00:11:44.000Z Endianness refers to the order in which bytes are stored in computer memory. There are two main flavors: - **Big-Endian:** The most significant byte (MSB) is stored at the lowest memory address. Think of it like reading a number from left to right – the "big end" comes first. - **Little-Endian:** The least significant byte (LSB) is stored at the lowest memory address. This is more like how we'd write numbers on paper if we were to put the units digit first. _This post is for subscribers only._ ### Design Question - Odd Parity Detector URL: https://fpgadesign.io/blog/odd-parity-detector/ Last updated: 2026-05-18T00:11:52.000Z 💡 Question: Explain the concept of data parity and its applications in digital design. What does ****odd parity** mean? ## Data Parity - Concept In digital systems, ensuring data integrity is critical. One widely used error-detection method is **parity checking**, which helps detect transmission errors by appending a **parity bit** to a data stream. Among parity methods, **odd parity detection** ensures that the total count of 1s in a binary sequence remains odd. This simple yet effective technique finds applications in communication protocols, memory systems, and data reliability mechanisms. Parity refers to a method of error detection where an extra bit (parity bit) is added to a data sequence to enforce a particular sum of 1s. - **Odd Parity:** The parity bit ensures the total number of 1s in the data (including the parity bit) is odd. - **Even Parity:** The parity bit ensures the total number of 1s is even. ## **How Does Odd Parity Work?** Consider a **4-bit data sequence**: - `1010` → Already has two 1s (even count), so the parity bit is `1` → **Final data: `10101`** - `1101` → Already has three 1s (odd count), so the parity bit is `0` → **Final data: `11010`** This mechanism ensures **consistent error detection**, making it useful in scenarios where single-bit errors could compromise data integrity. 💡 Question: Design a module that detects odd an odd number of 1s. The module receives a single bit input, along with a valid qualifier. ## State Transition Diagram The figure below shows the state transition diagram for an odd parity detector. The FSM can essentially be in one of two states, EVEN or ODD, based on the number of `1`s it has received up to that point. _This post is for subscribers only._ ### Design Question - Up-Down Counter with a Twist URL: https://fpgadesign.io/blog/up-down-counter/ Last updated: 2026-05-18T00:11:53.000Z 💡 Question: Design an Up-Down Counter which counts from 4 to 14 and then rolls over. The direction is determined by the input signal `up_down`. # Exploring an Up-Down Counter: RTL Design and Implementation An **up-down counter** is a fundamental digital design component used in various applications requiring sequential counting. In most cases, counters are designed without predefined limits, allowing them to roll over naturally upon reaching their terminal count. However, when specific counting ranges are introduced, the design becomes more intricate, requiring additional logic to handle transitions effectively. # **Understanding the Design** This counter operates based on three primary signals: - **Clock (`clk`)**: Drives the counter operation. - **Reset (`rst`)**: Ensures proper initialization. - **Up-Down Control (`up_down`)**: Determines the counting direction. _This post is for subscribers only._ ### Tri-State Buffers and Their Applications URL: https://fpgadesign.io/blog/tri-state-buffers/ Last updated: 2026-05-18T00:11:45.000Z 💡 Question: What are Tri-State Buffers? What are their applications in Digital Design? ## Understanding Tri-State Buffers A Tri-State Buffer is a digital component that has 3 stable output states - - High (Logic 1) - Low (Logic 0) - High-Impedance (Hi-Z) While the buffer behaves like a standard logic buffer in the **High** and **Low** states, it enters a **Hi-Z** state when deactivated, effectively disconnecting the output from the circuit. ![](https://storage.ghost.io/c/d4/71/d47101ad-5d83-42ec-8a79-e6c7e23e490e/content/images/2025/05/image.png) Tri-State Buffer The diagram above shows a Tri-State Buffer with an Active-High Tri-State Enable (`EN`) signal. The buffer is equivalent to an "open circuit" when the `EN` signal is de-asserted. When `EN` is asserted, the Tri-State buffer behaves like a "normal buffer", passing the input signal to the output. ## Applications of Tri-State Buffers 1. **Arbitration in Computer Systems** Tri-State Buffers are commonly used in systems where multiple devices are connected to the same **shared resource**. For example, in a microprocessor based system, the CPU, the memory modules and the peripherals generally share the same data bus. To ensure that only one device can transmit on the bus at any given time, every device is equipped with a tri-state buffers. In the absence of Tri-State Buffers, multiple devices would transmit data at the same time, thereby causing **bus contention**. 2. **Multiplexing in Digital Circuits** Tri-state buffers help implement **efficient multiplexers**, especially when multiple sources need to drive a single output line. Instead of using complex logic gates, tri-state buffers allow selective activation of inputs, reducing circuit complexity. 3. **Bi-Directional Data Transfers** In **bidirectional buses**, such as those used in microcontrollers and memory interfaces, Tri-State buffers enable **controlled data flow**. For example, in an **I²C or SPI bus**, devices enter a high-impedance state when not transmitting, preventing interference. 4. **Peripheral Device Control** Many **peripheral devices**, such as sensors and external memory modules, use Tri-State buffers to disconnect from the system when not in use. This prevents unnecessary power consumption and ensures only active devices drive the bus. Tri-stating shared lines not in use provide an additional advantage of reducing crosstalk and noise on a bus. ## **Why Can’t a Device Just Drive `0` When Not in Use?** If an idle device drives a `0` instead of going **Hi-Z**, it still actively controls the bus. If another device attempts to transmit a `1`, it creates a **contention scenario**, leading to: - **Erroneous data transfers** - **Signal corruption** - **Potential hardware damage** in extreme cases By using **Tri-State Buffers**, designers ensure **efficient bus arbitration**, **proper data transmission**, and **safe signal handling** across digital systems. **Practice interview questions on this topic →** [Digital Logic Questions](https://fpgadesign.io/digital-logic/) ### Mealy and Moore Finite State Machines (FSMs) URL: https://fpgadesign.io/blog/mealy-moore-fsm/ Last updated: 2026-05-18T00:11:45.000Z Key Differences and Synthesis Implications _This post is for subscribers only._ ### Packed vs Unpacked Arrays in SystemVerilog URL: https://fpgadesign.io/blog/packed-vs-unpacked-arrays-in-systemverilog/ Last updated: 2026-05-18T00:11:48.000Z SystemVerilog provides powerful enhancements over Verilog, particularly in handling arrays. Among these, packed and unpacked arrays play a crucial role in designing efficient hardware descriptions. While both serve distinct purposes, understanding their differences is essential for writing optimized and maintainable RTL code. 💡 Question: What are the key differences between Packed and Unpacked Arrays in SystemVerilog? SystemVerilog refers to the legacy Verilog array declaration style as *unpacked* arrays. **Each element of an unpacked array may be stored independently from other elements**, but grouped under a common name. Vector declarations are referred to as *packed* arrays in SystemVerilog. **The entire packed array must be stored as contiguous bits, without any padding**. ## SystemVerilog Syntax The array dimensions are specified after the signal name for unpacked arrays, and before the signal name for packed arrays. It is also possible to have a mix of packed and unpacked dimensions within the same array declaration. ```verilog logic data_in [31: 0]; // unpacked array logic data_in [32]; // unpacked array (C-style declaration) logic [31: 0] data_in; // packed array ``` SystemVerilog Syntax for Array Declaration ## Use Cases for Array Types 💡 Question: When would you use a packed array vs an unpacked array in your design? ### **Packed Arrays** Packed arrays are ideal for situations where bit manipulations need to be performed or bit-slices need to be referenced. _This post is for subscribers only._ ### Design Question - Barrel Shifter URL: https://fpgadesign.io/blog/design-question-barrel-shifter/ Last updated: 2026-05-18T00:11:50.000Z 💡 ****Question:** **What is a Barrel Shifter and how does it compare to a Shift Register?* A barrel shifter is a ***combinatorial shifter*** that can shift its input data by a specified number of bit positions in a single clock cycle. It is extremely fast, as it can, in theory, perform an n-bit shift operation in a single clock cycle. On the other hand, a shift-register is a ***sequential circuit*** that can perform a one-bit shift per clock cycle. A shift-register requires n clock cycles to perform an n-bit shift operation. 💡 ****Question:** **What are the downsides of a Barrel Shifter in terms of design performance?* The high speed of the barrel shifter comes at a cost of increased resource utilization, additional congestion and reduced clock speeds. A single clock cycle shift requires a large number of multiplexers. The number of inputs to these muxes grow as the number of input bits to be shifted increase. 💡 ****Question:** **Write the RTL code for a 4-bit Left Shift Barrel Shifter?* The complete RTL code for this block can be found [here](https://gist.github.com/milindparelkar/623a30f0459982755b4f30677aafec5c?ref=fpgadesign.io). The main element of the Barrel Shifter is the combinatorial multiplexer which lists out all possible shift combinations. ```Verilog // Use the shift distance (shf_dst) // to left shift the input data always_comb begin case (shf_dst) // No shift 2'b00 : sig_dat_out = dat_in; // 1-bit shift 2'b01 : sig_dat_out = {dat_in[2:0], 1'b0}; // 2-bit shift 2'b10 : sig_dat_out = {dat_in[1:0], 2'b0}; // 3-bit shift 3'b11 : sig_dat_out = {dat_in[ 0], 3'b0}; // default default : sig_dat_out = dat_in; endcase end ``` Barrel Shifter **Additional Questions -** 1. What modifications are needed if the module needs to do Rotation instead of Shifting? 2. Design a Barrel Shifter when has a Left Shift as well as Right Shift functionality based on an additional input signal. 3. In a Xilinx FPGA, how can you implement a barrel shifter using DSP48s? **Practice interview questions on this topic →** [RTL Design Questions](https://fpgadesign.io/design-questions/) ### Advanced Topics in Static Timing Analysis URL: https://fpgadesign.io/blog/advanced-topics-in-static-timing-analysis/ Last updated: 2026-05-18T00:11:47.000Z Before moving on to some of the more in-depth topics about Static Timing Analysis (STA) and Timing Closure, it is important to introduce and intuitively understand two terms related to clock distribution - - Clock Skew, and - Clock Jitter ### Clock Skew Clock skew refers to the difference in the clock arrival time at different sequential elements in the design. Although extreme care is taken to route the clocks over load balanced and length matched low-skew routing, it is impossible to completely eliminate clock skew in any digital circuit. The presence of clock skew impacts STA and affects timing closure (but at times can work in our favor as well). **Positive Clock Skew** is present when the clock reaches the destination flip-flop later than the source flip-flop. This situation helps the setup checks by increasing the amount of time available for the data signal to travel from the source to the destination flip-flop. At the same time, a positive skew conversely affects the hold time constraints, since there is a chance that the data might change too soon with respect to the destination clock edge. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F681764f5-5420-4b8f-b34b-4e87e5bca79f_1950x1117.png) Figure 1: Clock Skew **Negative Clock Skew** works in exactly the opposite way. Intuitively, it can be seen that the data will have a smaller time window to reach the destination flip-flop if the destination edge moves to the *left* (as compared to it's ideal location). Negative clock skew is worse for setup paths but help with hold checks. ### Clock Jitter Clock jitter refers to the variations and deviations in the timing of a clock signal's edges from their ideal positions. In other words, these are small, unpredictable changes in the timing of a clock pulse. As a Digital, RTL designer, one does not too much control on the jitter aspects of the clock. These are generally managed during the board design phase of the project, by choosing the appropriate clock sources, power supplies and reducing EMI (Electromagnetic Interference). At the FPGA design level, using clock conditioning blocks like PLLs or MMCMs, will help clean the clock signal and reduce jitter. Jitter adds uncertainty and the STA tools will have to reduce the available timing window to account for this unpredictability. ### Interview Question One of the most commonly asked interview questions is - > What can you do to achieve timing closure or increase the working clock frequency of your design? 99% of the candidates that I have interviewed, always lead with **Pipelining** as the first thing they would do. In theory, this is not an incorrect answer, but there are a few pre-requisites to adding pipelines in the design. The first step is to figure out the cause of the timing failure. If you have a long route, by all means, add enough pipelines to break the critical path. But, what if the timing closure issues are because of high-fanout nets, or even worse, localized congestion in the FPGA. Adding pipelines would actually be detrimental to the final goal of achieving timing closure. A follow up question is about **design trade-offs**. You gain something, you lose something. What's the thing that you lose when you add pipelines? - Resource usage increases with more pipeline stages. This is especially true for wide data buses. - Adding pipelines increases the overall latency in terms of clock cycles. 💡**Remember** \- Just because the latency increases in terms of number of clocks, does not mean that the latency has increased in terms of absolute time. Let's take a look at an example - Say you have a path running at 100 MHz. A signal takes one clock cycle to traverse a timing path i.e. it takes 10 ns. Now assume that you are running the same path at 200 MHz. You add a pipeline stage, so that you can meet timing at 200 MHz. Every clock cycle is now 5 ns wide. Even if you take 2 clock cycles to get from the same source to the destination, the absolute time it takes is the same (10 ns) in both cases. ### Takeaways Managing clock skew and jitter is essential to avoid timing violations. Implementing pipelining can significantly boost throughput by breaking down operations into sequential stages, despite introducing additional latency. Balancing these factors is key to optimizing the overall efficiency and robustness of digital designs. **Practice interview questions on this topic →** [Digital Logic Questions](https://fpgadesign.io/digital-logic/) ### The Fundamentals of Static Timing Analysis in Digital Circuits URL: https://fpgadesign.io/blog/the-fundamentals-of-static-timing-analysis-in-digital-circuits/ Last updated: 2026-05-18T00:11:46.000Z Static Timing Analysis (STA) is a method of validating the timing performance of a digital circuit by checking all possible paths for timing violations. STA breaks a design down into timing paths, calculates the signal propagation delay along each path, and checks for violations of timing constraints inside the design and at the input/output interface. > ⏱️Static Timing Analysis is a broad field, and the intricate language used in the literature can obscure some of the fundamental ideas. This is an attempt to clarify the concepts and give a conceptual rundown of the procedure. ### Types of STA Paths As shown in the figure below, a design will have different types of timing paths. The *cloud of logic* shown in the diagram might contain multiple combinatorial paths. The STA tool uses the shortest path to compute the **minimum delay** and the longest path to compute the **maximum delay**. We will look at these concepts later to understand why both these computations are important. Let's look at all the paths shown here in detail - - **Path #1**: This is a path from an input port to the data input of a sequential element. - **Path #2**: This is the path from the clock pin of a sequential element to the data pin of the next sequential element, traversing through a cloud of combinatorial logic. *We generally focus on this path during the timing closure process.* - **Path #3**: This path goes from the clock pin of a sequential element to an output port. - **Path #4**: This is a purely combinatorial path from the input to the output port. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1d20e971-1cc1-4a5d-91db-49435a91964c_1180x384.png) Figure 1: Timing Paths In addition to the 4 paths described above, there are a few more path types that need to be accounted for during STA. These are as follows - - **Clock Path**: The clock distribution network from the clock source to the clock pin of sequential elements. This path consists of one or more clock buffers (and optionally, inverters). **Clock path delays (also known as *clock skew*) can result in tightening or loosing the data path timing constraints.** - **Asynchronous Path**: This is a path from an input pin to an asynchronous set or reset pin of a sequential element. This is required for **recovery and removal checks**. ### Timing Path between Sequential Elements (Path #2) It is important to understand all the elements in this path conceptually, and then build upon that knowledge for further discussion. This path can be further broken down into the following elements (for setup checks) - - **Clock-to-Q Delay**: This is the time required for the flip-flop input data (D) to show up at the output (Q) after the active clock edge. - **Propagation Delay**: This is the time required for the data to propagate through the combinatorial logic cloud. The propagation delay can be further broken down into - - **Logical Delay** \- This is the delay through the logical elements in the path. - **Routing Delay** \- This is the delay through the connecting wires. - **Setup Time of the Destination Flip-Flop**: This is the time period before the clock edge, when the data should be stable to be captured correctly by the destination flip-flop. > A rule of thumb is that the routing delay should generally *not consume more than 60%* of the clock period. In addition to the setup checks, there are hold time checks as well. **Hold Time** is the time period after the clock edge, when the input data must be stable, so that it is correctly latched by the flip-flop. ### Critical Path and Slack **Critical Path** in a design is the longest combinatorial path between two sequential elements (such as flip-flops or registers). The maximum time required for the data to propagate from one sequential element to the next is determined by the length of the critical path. This has a direct bearing on the maximum clock frequency that the digital logic can run at. MaximumClockFrequency=1/TimeRequiredtoTraversetheCriticalPath ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fbd548608-43f3-4efd-89ed-66cbef0c8aef_940x450.png) Figure 2: Elements of Critical Path In a real world scenario, we are trying to design modules to meet timing closure at a given target clock frequency. The total time for a signal to travel from the source flip-flop to the destination flip-flop can be given (loosely[\[1\]](https://fpgadigest.substack.com/p/the-fundamentals-of-static-timing#fn-1-670d6570a9947b10)) by the following equation. Ttotal=Tclk−to−q+Tlogic+Trouting+Tsetup Clock-to-Q and setup time of flip-flops are generally known beforehand. Designers have to manage the *routing and logical delays*, so that the total delay is less than the required *clock period*. **Slack** is the difference between the required time period and the actual arrival time of the signal at a particular point in the circuit. When the signal arrives earlier than the required time, the slack is said to be **positive**. This indicates that all setup time requirements are met (along with some extra margin). **Negative** slack is when the signal arrives later than the required time, thereby violating the setup time of the destination flip-flop. ### Setup and Hold Checks A setup check determines whether all setup time constraints are met, while a hold check determines the same for hold time constraints. It is important to introduce the concept of a launch edge and a capture edge. **Launch Edge** is the edge of the clock on which the source flip-flop launches the data. **Capture Edge** is the edge of the clock on which the destination flip-flop captures the data. Since, the data travels from the source to the destination, and has to reach there before the **setup time window** begins, setup checks are performed at the **Capture Edge**. Hold check ensures that the hold time requirements at the source flip-flop are met, i.e. the data does not change during the duration of the Hold window. Hence, hold checks are performed at the **Launch Edge**. > 🚨 A caveat to the above paragraph is the **Hold Checks** are made **one clock edge prior** to the **Capture Edge** (by the STA tools). This checks out with our example because the Launch Edge is always one clock cycle prior to the Capture Edge. > > 💡Potential problems can arise when **multi-cycle paths** are used in the design. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F1c6a6766-9c34-4e3c-b30e-e98825168137_1000x488.png) Figure 3: Setup and Capture Edges in STA ## Minimum and Maximum Delays through Combinatorial Logic **Maximum delays** through combinatorial logic affect setup checks, because the signal might be delayed reaching the destination. **Minimum delays** on the other hand, affect hold checks, because the data might transition too fast and not remain stable through the duration of the hold window. > In most modern FPGAs, sequential elements have zero or even negative hold time requirements. Unless there are some sub-optimal design elements, leading to a large clock skew, it is very hard to see hold time violations. ### Coming up in the Next Edition After laying down the foundational concepts of Static Timing Analysis, we will take a look at some more advanced concepts in the next edition. These include things like *clock skew*, *clock jitter*, *timing exceptions (false paths and multi-cycle paths)* and how to mitigate timing closure issues. --- 1. For completeness, elements like, *clock skew, jitter and clock uncertainty* should also be considered. Adding too many elements at the same time, obfuscates the primary concepts. Therefore, some of these elements have been left out from the explanation at this point. --- **Practice interview questions on this topic →** [Digital Logic Questions](https://fpgadesign.io/digital-logic/) ### Design Question - Clock Dividers and Duty Cycle URL: https://fpgadesign.io/blog/design-question-clock-dividers-and-duty-cycle/ Last updated: 2026-05-18T00:11:51.000Z In RTL Design interviews, it's common to encounter questions about clock divider circuits. While many interviewees might have quick answers ready from a cursory Google search, this topic has much more depth that often goes unexplored. This post aims to delve into practical implementations, going beyond general knowledge. ## Need for a Clock Divider Clock divider circuits reduce clock frequency for slower components, generate multiple clocks, and synchronize data between different clock speeds. They manage power by enabling slower speeds, adjust timing, and are used in PWM and motor control. They aid in serial communication, simplify testing by slowing speeds, and are crucial in digital filters for specific sampling rates. ## Interview Questions - Design a Clock Divider circuit to divide the input clock by a factor of 4 (or any other power of 2) - Design a Clock Divider circuit to divide the input clock by a factor of 3 (or any other odd number) - Modify the design to generate an output clock with 50% duty cycle ## Solution - Divide by 4 Circuit The divide by 4 (or any other power of 2, or for that matter any even number) circuit is a simple counter that runs from `0` to `n-1` (in this case, 3) and then rolls over back to `0`. > If you are dividing the incoming clock by a factor of 4, the output should have **one** rising edge for every set of **four** rising edges of the input clock. The counter cycles through the values `0`, `1`, `2`, `3`. For two consecutive states of the counter, the output should be a `0`, and for the other two states it should be a `1`. A snippet of code for the Divide by 4 counter - ```verilog logic [ 1: 0] sig_div4_cnt; // Divide by 4 counter always_ff @(posedge clk) begin if (rst) begin sig_div4_cnt <= '0; end else begin sig_div4_cnt <= sig_div4_cnt + 1; end end // Generating the divided down version of clk assign clk_div_4 = sig_div4_cnt[1]; ``` Divide by 4 Counter In the above example, the MSB of the 2-bit counter is used to hold the output `LOW` in counter states `0` and `1`, and `HIGH` in the other two states of the counter. **One additional advantage of implementing the output this way, instead of using a** `case` **or an** `if-else` **statement is that the output is sequential, as opposed to combinatorial.** > Can you figure out a way to generate the output clock with a 25% duty cycle? ## Solution - Divide by 3 Circuit Division by odd numbers is where things start getting a little trickier. The design concept is still the same as the earlier example. We have a 2-bit counter that runs from `0` to `2` and then gets reset to `0`. The counter now has 3 states, `0`, `1` and `2`. Assuming we do not have the 50% duty cycle requirement, we can simply design the circuit as follows - ```verilog logic [ 1: 0] sig_div3_cnt; // Divide by 3 counter // No duty-cycle management always_ff @(posedge clk) begin if (rst) begin sig_div3_cnt <= '0; end else if (sig_div3_cnt == 2'd2) // Roll over back to 0 begin sig_div3_cnt <= '0; end else begin sig_div3_cnt <= sig_div3_cnt + 1; end end // Generating the divided down version of clk assign sig_clk_div_3 = (sig_div3_cnt == 2) ? 1'b1 : 1'b0; assign clk_div_3 = sig_clk_div_3; ``` Divide by 3 Counter This generates an output clock with 33% duty cycle. ![Pasted image 20241011164043.png](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fde0896c2-9c96-4071-b16a-c5e5ae954140_970x268.png "Pasted image 20241011164043.png") In order to create an output with 50% duty cycle, we need the output, `clk_div_3` to be asserted for another *half clock cycle*. Referring to the diagram below, the extended output is shown in *orange*. ![Pasted image 20241011164418.png](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff2c9ce7f-a9ee-4242-92be-95696bba85e7_970x148.png "Pasted image 20241011164418.png") In order to drive any signal for half a clock cycle, we have to utilize the negative edge of the clock. Let's take the *Divide by 3* circuit explained earlier and add this additional functionality. ```verilog // For 50% dutycycle, we need the output to be asserted // for half a clock cycle more always_ff @(negedge clk) begin sig_clk_div_3_ne <= sig_clk_div_3; end // Generating the divided down version of clk (50% duty cycle) assign clk_div_3_dc50 = sig_clk_div_3 | sig_clk_div_3_ne; ``` Divide by 3 Counter (with 50% duty cycle) ![Pasted image 20241011165022.png](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff73015bc-d7aa-4ba1-b6f4-90b2fd7a1fa4_774x284.png "Pasted image 20241011165022.png") **The primary downside of this design is that the generated output signal is combinatorial.** ## Practical Considerations for FPGA Design This is an absolutely horrible way to generate *divided down versions* of the master clock in an FPGA design. Clocks in an FPGA have a certain *status* and have their own exclusive, low-jitter distribution routing. Signals from the FPGA fabric cannot easily enter this *special* clock routing network. As can be seen from above examples, the generated clocks are either on the `Q` output of a Flip-Flop or are purely combinatorial. Driving a bunch of sequential logic from a clock generated in this manner will cause a lot of issues in an FPGA. For the 50% duty cycle design, one must realize that the path from `sig_clk_div_3` to `sig_clk_div_3_ne` is **required to be traversed in half a clock cycle**. This puts an extra burden on the synthesis tools. ### Considerations for Clock Dividers in an FPGA Xilinx FPGAs have dedicated clock management resources that can take care of clock division. Users have access to **PLLs** and their superset, **MMCMs** (Mixed Mode Clock Managers). For simple division, the Xilinx primitive **BUFGCE\_DIV** can be used. ## Takeaways While these questions are understandable for interview purposes, it is important to recognize that, in proactive, clock division in FPGAs is typically achieved using dedicated FPGA primitives. Achieving a 50% duty cycle output clock becomes complex when dealing with odd division factors and requires utilizing both clock edges. **Practice interview questions on this topic →** [RTL Design Questions](https://fpgadesign.io/design-questions/) ### SystemVerilog .name and .* Notations URL: https://fpgadesign.io/blog/systemverilog-name-and-notations/ Last updated: 2026-05-18T00:11:50.000Z ## SystemVerilog is Case Sensitive Verilog and SystemVerilog are both *case sensitive* languages. Uppercase and lowercase letters are perceived differently in relation to both identifiers as well as keywords. > VHDL is a case insensitive Hardware Description Language. Keeping case sensitivity in mind while coding is especially important for those transitioning from VHDL to SystemVerilog. ```verilog // !!DO NOT DO THIS!! module CaseExample; reg myVar; // Declare a register variable named "myVar" initial begin myvar = 1'b1; // Error: SystemVerilog does not recognize "myvar" MyVar = 1'b0; // Error: SystemVerilog does not recognize "MyVar" myVar = 1'b0; // Correct: This matches the declared variable end endmodule ``` Case Sensitivity in SystemVerilog In this code snippet, the variable `myVar` is declared. However, attempts to assign values using `myvar` and `MyVar` result in errors because they are not recognized as the same variable. ```verilog // !!DO NOT DO THIS!! // Enumerated Data Type for a State Machine enum logic [1:0] {WAIT, IDLE, READY, SEND} State, NextState; Copy ``` Enumerated Data Type in SystemVerilog In this example of an enum declaration for an FSM, the signals `State` and `NextState` are declared with a mix of uppercase and lower case characters. It is very easy to miss one of the uppercase characters when these identifiers are used in the code at a different place. The compiler will consider `NextState`, `Nextstate` and `nextstate` as different signals and you can imagine the carnage to follow. > It is generally not a good idea to use a mix of lowercase and uppercase characters for SystemVerilog variables and other identifiers. **Can you spot one more slight issue with the enum declaration above?** The statement is syntactically correct, the way it is written. SystemVerilog has an inbuilt keyword, `wait`. The uppercase, enumerated label, `WAIT` is, in theory, not to be confused with the lowercase keyword (and the compiler won't either), but you can see how issues could pop-up if all lowercase characters were used elsewhere to refer to the enumerated label. > The best way to avoid falling into this case sensitivity trap is to adopt good coding guidelines and follow proper naming conventions across teams and the organization as a whole. > > 💡Spend some time while coming up with identifier names. Keep the names concise, but unambiguous. Easier said than done, but in all the rush to get to the more complex part of coding, we tend to sometimes trivialize the process of choosing appropriate names for signals and variables. ## Implicit Net Declaration in SystemVerilog In SystemVerilog, implicit declarations occur when you use a signal name without explicitly declaring it. Take a look at the snippet of code below. ```verilog module implicit_example; logic a, d; // Explicitly declared signals assign a = b & c; // 'b' and 'c' are implicitly declared as logic assign d = a | e; // 'e' is implicitly declared as logic endmodule Copy ``` Implicit Declaration in SystemVerilog Here, `b`, `c`, and `e` are not explicitly declared, but SystemVerilog treats them as `logic` by default. This can lead to unintended errors if a name is used incorrectly. It’s often recommended to declare all signals explicitly to avoid confusion and maintain code clarity. > Countless hours have been spent debugging issues caused by implicit declarations. The compiler is happy with the code, but the synthesis tool typically prunes out a big chunk of logic because of improper connections. There is a method to implicitly enable checking for undeclared instances, by using the `.name` and `.*` notations. ## Using `.name` and `.*` notations for instance mapping #### The `.name` Notation The `.name` notation in SystemVerilog is a shorthand way to connect ports in module instances. When you declare ports with the same name in both the parent module and the instantiated module, `.name` automatically matches them. This can significantly reduce the amount of repetitive code and potential errors. Let's take the case of an `aximaster` module. ```verilog module aximaster ( input logic aclk, input logic aresetn, output logic [31:0] awaddr, output logic awvalid, input logic awready, output logic [31:0] wdata, output logic wvalid, input logic wready, input logic [31:0] rdata, output logic rready, input logic rvalid ); // Module architecture goes here endmodule ``` Example Code for AXI Master Module Let's see how this module can be instantiated in the top-level using the .name convention. ```verilog module top; logic aclk; logic aresetn; logic [31:0] awaddr; logic awvalid; logic awready; logic [31:0] wdata; logic wvalid; logic wready; logic [31:0] rdata; logic rready; logic rvalid; aximaster u_aximaster ( .aclk, .aresetn, .awaddr, .awvalid, .awready, .wdata, .wvalid, .wready, .rdata, .rready, .rvalid ); endmodule ``` Example Code for Instantiation of the AXI Master Module The compiler checks the **names** and the **size** of the signals in the `top` module and connects the corresponding signals to the ones on the `aximaster` interface. > The `.name` instantiation takes care of errors introduced due to typos leading to implicit net declarations. #### The `.*` notation With the `.*` notation, SystemVerilog automatically connects all the instance ports of `aximaster` to the signals with matching names in the `top` module. This notation reduces boilerplate code and the potential for errors by ensuring that signal names are matched and connected correctly, as long as the names are consistent. ```verilog module top; logic aclk; logic aresetn; logic [31:0] awaddr; logic awvalid; logic awready; logic [31:0] wdata; logic wvalid; logic wready; logic [31:0] rdata; logic rready; logic rvalid; aximaster u_aximaster ( .* ); endmodule ``` SystemVerilog .\* Notation ### More Rules to be Aware of - .name and . *implicit ports are not allowed to be mixed in the same instantiation. Instantiating one module with .name implicit ports and another module with .* implicit ports is permitted. - .name or .\* implicit ports are not allowed to be mixed in the same instantiation with positional port connections. (A caveat here - *Positional Port Connections should never ever be used, unless there is a good enough reason to do so*.) - A named port connection is required if the port size does not match the size of the connecting net or bus. For example: a 16-bit data bus connected to an 8-bit data port requires a named port connection to show which of the 16 bits are connected to the 8-bit data port. - A named port connection is required if the port is unconnected. ### Takeaways Understanding the nuances of SystemVerilog's case sensitivity and port connection notations can significantly improve your coding efficiency and reduce errors. Develop a set of guidelines for naming signals and modules and stick to those guidelines. You might not be able to get everyone on board to follow the guidelines, but at least there should be consistency across multiple design modules written by the same designer. **Practice interview questions on this topic →** [SystemVerilog Questions](https://fpgadesign.io/sv-interview-questions/) ### Intricacies of Blocking vs Non-Blocking Assignment Statements in SystemVerilog URL: https://fpgadesign.io/blog/intricacies-of-blocking-vs-non-blocking-assignment-statements-in-systemverilog/ Last updated: 2026-05-18T00:11:49.000Z This is one of the most common questions asked in RTL and FPGA design interviews. To be completely honest, I find this question pretty useless. Anyone and everyone who has prepared even a little bit for an interview and has opened a textbook on SystemVerilog should know what **blocking* and **non-blocking* statements are. If I were to venture a guess, almost 90% of interviewees are able to answer the basic question about this topic. But go one level deeper, and the success rate drops to less than 10%. Again, these are not "official" statistics, but, I am assuming you get the point. ## Let's get the simple stuff out of the way Verilog and SystemVerilog have two types of assignment statements - - Blocking assignments (e.g. `a = b`) - Non-blocking assignments (e.g. `a <= b`)\* Blocking assignments model the behavior of combinatorial logic in hardware. The order of operations is important. Non-blocking assignments model the behavior of sequential elements in hardware, with clock-to-Q propagation delay. An example of combinatorial logic. ```verilog always_comb begin a = b + c; d = a + b; end ``` Combinatorial Logic Block We have two blocking assignments. First, the sum of `b` and `c` is computed and assigned to `a`. Then next statement in the sequence is executed. `d` gets the value of `a` that was computed in the previous statement, plus the value of `b`. So in short, the value of `d` is `2*b+c`. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc625b44b-ce39-4c46-a517-0fc05a335e64_1780x963.png) Figure 1: Waveform for Blocking Assignment Code Example Now let's take a look how things differ when we use non-blocking assignments. ```verilog always_ff @(posedge clk) begin a <= b + c; d <= a + b; end ``` Sequential Logic Block The above snippet of code models two separate adders followed by a flip-flop each. Since non-blocking assignments are used, both statements get executed in parallel. The current values of `b` and `c` are added and assigned to `a`, which will only be updated on the next clock edge (after the clock-to-Q delay). At the same time, the current value of `a` is added to the current value of `b` and assigned to `d` at the next clock edge. In this case, the value of `d` is not equal to `2*b+c`, as in the earlier example. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fb6290c41-8151-4c8e-8890-55e400860488_1781x963.png) Figure 2: Waveform for Non-Blocking Assignment Code Example ## Now for the more tricky stuff > I have asked this question to many candidates, right from recent graduates to some more experienced candidates. "What happens if you use a blocking assignment inside an `always_ff` block?" Here are some of the answers that I have come across. Think through and figure out which one of these is correct. - \[Answer 1\] That's a syntax error. The compiler will not allow it. - \[Answer 2\] Why would you ever want to do that? (By the way, that wasn't the essence of the question) - \[Answer 3\] It makes no difference. I use it all the time. By the way, the answers are either incorrect or trying to skirt the essence of the question completely. > It is not syntactically incorrect to have a blocking statement inside a sequential block. > It will just not produce the output you are looking for. Let's take an example of a simple shift register, written **incorrectly** with blocking assignments. ```verilog always_ff (posedge clk) // This is **NOT** how you write a Shift Register begin ff0_q = d; // Load d into ff0_q without clock-to-Q delay ff1_q = ff0_q; // Load ff0_q into ff1_q without clock-to-Q delay end ``` Shift Register Example (with an error) If we were to describe a shift register properly, what we really want is for `ff0_q` and `ff1_q` to be positive edge triggered flip-flops. On the appropriate clock edge, `d` should get transferred to `ff0_q` and the previous value of `ff0_q` should get transferred to `ff1_q`. Since we have used blocking assignments, the described hardware doesn't quite work like a shift register. The blocking assignment of `d` to `ff0_q` **blocks** the evaluation of the statement that follows, until the value of `ff0_q` has been updated. Thinking through this, you can see that the value of `d` gets passed on to `ff1_q` on the first clock edge, rather than getting shifted through in two clock cycles (like a shift register). > The synthesis tool will recognize that `ff0_q` is just a temporary variable and optimize it out. The question then is, > **Why are blocking statements even allowed inside a sequential block?** The practical reason is to **allow the use of a temporary variable** within the sequential block. Let's say a complex math equation has to be computed and assigned to a sequential output. For code readability purposes, it might be practical to break down the equation into multiple parts. That is when the sequential block should use a blocking assignment to compute intermediate values. In synthesis, the extra assignment will be optimized out and the *blocking feature* will be removed. A secondary and a more obscure, philosophical reason is that a Hardware Description Language used for synthesis and verification purposes must correctly model the hardware and must be able to prove what will work (and not work) correctly in hardware. ## Takeaways Get into good coding habits. In most cases, you should use blocking assignments only to describe combinatorial logic (`always_comb` blocks), and non-blocking assignments to describe sequential logic (`always_ff` blocks). There are always exceptions to the rule, but I have not really ever come across the need to use these somewhat arcane exceptions. **Practice interview questions on this topic →** [SystemVerilog Questions](https://fpgadesign.io/sv-interview-questions/) ### Designing with Xilinx Memory Primitives: Understanding Inference vs Instantiation URL: https://fpgadesign.io/blog/designing-with-xilinx-memory-primitives-understanding-inference-vs-instantiation/ Last updated: 2026-05-18T00:11:41.000Z In our [last newsletter](https://fpgadigest.substack.com/p/an-introduction-to-xilinx-fpga-memory?r=47n24y), we covered the basics of Xilinx memory primitives. Now, let’s dive into some more nuanced topics. How does choosing between synchronous and asynchronous memory access impact your design? When should you infer memory versus instantiating it? This post explores the access characteristics of different Xilinx memory primitives and the pros and cons of each approach. Whether you’re optimizing for low latency or seeking precise control, this guide will help you make informed decisions to enhance your FPGA designs. ## Synchronous vs Asynchronous Access It is important to understand the access characteristics of different Xilinx memory primitives. This is especially important if you plan on *inferring* the memory primitives. Writes to all memory primitives are always **synchronous**. BlockRAMs and UltraRAMs reads **synchronous**, while Distributed RAM reads are **asynchronous**. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F3ee5ae5d-8482-4460-92fe-8ea506696223_610x480.png) Figure 1: Read-Write Options for Memory Types The asynchronous read feature of Distributed RAMs can be crucial for low latency applications, where the data can be read immediately without waiting for a clock edge. If *synchronous read* capability is desired, an additional flip-flop at the output of the Distributed RAM (LUT) is used to register the data. ## Inference vs Instantiation **Instantiation** involves explicitly defining the memory blocks in your HDL code using vendor-specific primitives or IP cores. This method provides precise control over the memory’s configuration and behavior. **Inference** involves writing generic HDL code that the synthesis tool interprets to create the appropriate memory blocks. The tool deduces the intended memory type based on the code structure. *Synthesis attributes are available to suggest the memory type intended, but the Synthesis tools have the freedom to ignore the suggestion for optimization purposes.* > *For critical areas of the design, I always tend to *instantiate* the functionality, rather than infer it. This guarantees that the synthesized netlist will be in line with what you intended.* ### Instantiating Memory Modules There are two primary ways to instantiate memory modules in a Xilinx FPGA: - **Generate the required memory configuration** through the Vivado IP Generator tool. Vivado will generate a .xci (or the core container .xcix) file, which can then be integrated into the design during synthesis. - **Use Xilinx Parameterizable Macros (XPMs)**. XPMs provide a standardized method to instantiate various types of memory, such as BlockRAM, UltraRAM, and distributed RAM, with customizable parameters. #### Advantages of Using XPMs - **Portability**: XPMs facilitate easy portability across Xilinx devices. Memories generated with the Vivado IP Generator tool target a specific Xilinx part, but you can use the `upgrade_ip` command to target a different FPGA part or a different Vivado version. - **Code Management and Integration**: XPMs are instantiated in the HDL code, similar to any other IP module. This keeps the memory instantiation within your code, simplifying code management and version control. It also reduces *makefile dependencies* on other makefile targets and allows for better flexibility since configuration parameters can be managed from the HDL code rather than regenerating the IP core for specific configurations. > *The main downside of XPMs (as of today) is that not all configuration options are available in the XPM instantiation template. You can achieve more complex configurations, such as very wide or deep memories with customizable pipeline stages, through the Vivado IP Generator GUI.* Here's an example of how XPMs are used to instantiate an UltraRAM. ```verilog // XPM memory instantiation xpm_memory_spram #( .ADDR_WIDTH_A (ADDR_WIDTH), .MEMORY_SIZE (1024*DATA_WIDTH), // Memory size in bits .READ_DATA_WIDTH_A (DATA_WIDTH), .WRITE_DATA_WIDTH_A (DATA_WIDTH), .READ_LATENCY_A (1), .WRITE_MODE_A ("read_first") ) xpm_bram_inst ( .clka (clk), .addra (addr), .dina (din), .wea (we), .douta (dout) ); ``` XPM Example ### Inferring Memory Modules Inferring code is all about **portability**. Inferred code can be used across multiple FPGA platforms (vendors). It is also used in instances where specific FPGA modules are ported over to an ASIC implementation at a later time. > *I prefer to *infer* code for small and simple memories, where the overhead of generating a fresh instance through the Vivado IP Generator GUI is too time-consuming.* ```verilog module inferred_uram_example ( input logic clk, input logic [ADDR_WIDTH-1:0] addr, input logic [DATA_WIDTH-1:0] din, input logic we, output logic [DATA_WIDTH-1:0] dout ); parameter ADDR_WIDTH = 12; parameter DATA_WIDTH = 72; // Memory declaration with synthesis attribute for UltraRAM (* ram_style = "ultra" *) logic [DATA_WIDTH-1:0] uram [(2**ADDR_WIDTH)-1:0]; always_ff @(posedge clk) begin if (we) begin uram[addr] <= din; end dout <= uram[addr]; end endmodule ``` Inferring a Memory The memory array `uram` is declared with the `ram_style = "ultra"` synthesis attribute, which instructs the synthesis tool to implement this memory using UltraRAM. ## Takeaways In conclusion, understanding the nuances of inferring versus instantiating memory in FPGA designs is crucial for optimizing performance and resource utilization. By leveraging the strengths of each approach, you can tailor your design to meet specific requirements, whether it’s for portability, simplicity, or advanced performance optimization. As you continue to explore and implement these techniques, you’ll be better equipped to create efficient and effective FPGA solutions that meet the demands of your projects. 💡**Remember** \- When in doubt, always **instantiate** your logic. ## Additional Resources 1. [Vivado Design Suite User Guide: Synthesis (UG901)](https://www.xilinx.com/support/documents/sw%5Fmanuals/xilinx2022%5F2/ug901-vivado-synthesis.pdf?ref=fpgadesign.io) provides more information on inferring memories and XPMs. 2. Xilinx Vivado IDE includes language templates for inferring various types of memories in HDL and also has information about XPMs. **Practice interview questions on this topic →** [FPGA Architecture Questions](https://fpgadesign.io/fpga-concepts/) ### An Introduction to Xilinx FPGA Memory Primitives URL: https://fpgadesign.io/blog/an-introduction-to-xilinx-fpga-memory-primitives/ Last updated: 2026-05-18T00:11:41.000Z When designing FPGA-based systems, choosing the right type of memory is crucial for achieving optimal performance and resource utilization. Xilinx FPGAs offer three primary types of on-chip memory: BlockRAM, Distributed RAM, and UltraRAM. Each has its unique characteristics, advantages, and use cases. In this article, we’ll explore the differences between these memory types, helping you make informed decisions for your FPGA designs. In most cases the Xilinx tools (Vivado Synthesis) will infer the most optimal type of memory based on the user code. Synthesis attributes are available to force the tool to pick a specific memory primitive. ### BlockRAM (BRAM) **BlockRAM** is a dedicated memory resource available in Xilinx FPGAs. It consists of large, configurable memory blocks that can be used for various applications. #### Key Features: - **Size and Configuration**: BlockRAMs are typically 36 Kb in size and can be configured as single-port or dual-port memory. They support various data widths, such as 16Kx1, 8Kx8, and 4Kx4\. These memory blocks can be aggregated together to support arbitrary widths and depths. BlockRAMs can be configures as Simple Dual Port (SDP) memories or True Dual Port (TDP) memories. - **Performance**: BlockRAMs offer high performance with low latency, making them ideal for applications requiring fast data access. - **Use Cases**: Commonly used for implementing FIFOs, large buffers, and memory-intensive algorithms. ### Distributed RAM **Distributed RAM** utilizes the configurable logic blocks (CLBs) in the FPGA to implement small memory structures. It leverages the lookup tables (LUTs) within the CLBs to create memory elements. #### Key Features: - **Size and Configuration**: Distributed RAM is typically smaller than BlockRAM and is implemented using LUTs. Most modern Xilinx FPGAs use 6-input LUTs (LUT6), which can be configured to store 64 bits of data. - **Flexibility**: Highly flexible and can be used to create small, distributed memory structures throughout the FPGA. The access latency for distributed RAM is typically 1 clock cycle for read operations, making it suitable for applications requiring quick access to small amounts of data. - **Use Cases**: Ideal for small buffers, coefficient storage, and state machines. ### UltraRAM (URAM) **UltraRAM** is a large, high-capacity memory resource available in Xilinx UltraScale+ FPGAs. It is designed to provide significant on-chip memory capacity, reducing the need for external memory. #### Key Features: - **Size and Configuration**: UltraRAM blocks are significantly larger than BlockRAM, typically 288 Kb each. They can be cascaded to create very large memory arrays. - **Performance**: UltraRAM offers high performance with configurable pipeline stages to optimize timing. It is designed for applications requiring large, high-speed memory. - **Use Cases**: Ideal for applications needing large data storage, such as video processing, deep learning, and large data buffers. ## Practical Design Considerations ### 1\. Floorplanning BlockRAMs and UltraRAMs are placed on the Xilinx FPGA fabric as **columns** of memory, which are fixed in place. If a certain RTL module requires fast access to a BlockRAM or UltraRAM-based memory block, it must be placed closer to the memory column, or sufficient pipelining must be provided to ensure timely access without causing timing issues. Distributed RAMs consume fabric LUTs, which could otherwise be used for implementing other design logic. However, LUTs are ubiquitous and typically do not encounter the floorplanning issues mentioned above. ### 2\. Initialization BlockRAMs and Distributed RAMs can be initialized with specific values while loading the bitstream onto the FPGA. In contrast, UltraRAMs **do not support initialization** during the bitstream loading process. This design choice keeps UltraRAM smaller per bit and avoids significantly increasing the bitstream size. If you need to initialize UltraRAM with specific data, you must do so manually after the FPGA has been configured, involving writing the desired data to the UltraRAM using your design logic. ### 3\. Clocking UltraRAM has a single clock input and is fully **synchronous**. Unlike BlockRAM, it does not support independent clock interfaces directly. Distributed RAMs can be configured as True Dual Port memories, providing more flexibility in clocking. ### 4\. Pipelining Considerations in BlockRAMs BlockRAMs have optional output registers optimized for Clock-to-Q times. These optional output registers improve design performance by eliminating routing delay to the configurable logic block (CLB) flip-flops for pipelined operation. An independent clock and clock enable input is provided for these output registers. > **💡Recommendation 💡** > Use **two pipeline registers** on the BRAM read side. This allows the tool to use the register inside the BRAM tile, while the second register is implemented in the fabric to provide some elasticity for longer paths. Additional pipeline registers might be needed if the destination logic is placed further away from the BlockRAM tile. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8461a157-1955-40c6-91ad-6c4f1cddf337_1224x686.png) Figure 1: BlockRAM Output Pipelining Recommendation ## 5\. Synthesis Attributes The `ram_style` attribute in Xilinx FPGAs is a synthesis directive to guide the synthesis tool what type of memory to infer during synthesis. This can be used to **override** the default tool behavior or to **document** what memory type is intended to be used by the designer. > It is important to understand that `ram_style `is a **soft attribute**. This needs to be viewed of more as a guidance to the tool rather than strict enforcement. This allows the designer to **express intent**, while allowing the synthesis tool enough freedom to optimize the design. ```verilog // BlockRAM (* ram_style = "block" *) reg [7:0] bram [0:255]; // Distributed RAM (* ram_style = "distributed" *) reg [7:0] dram [0:255]; // UltraRAM (* ram_style = "ultra" *) reg [71:0] uram [0:4095]; ``` Synthesis Attributes for FPGA Memories If strict enforcement of a certain type of memory is required, then it needs to be **instantiated**, not inferred. ### 6\. Other Considerations - UltraRAM can only support a read or a write operation per port, per cycle. - A True Dual Port memory cannot be generated using UltraRAMs. The behavior of an UltraRAM-based memory can be viewed as a superset of a BRAM-based Simple Dual Port memory. - UltraRAM data width is fixed at 72 bits, whereas BlockRAMs offer more flexibility with choices of data widths (1, 2, 4, 9, 18, 36, 72). **Practice interview questions on this topic →** [FPGA Architecture Questions](https://fpgadesign.io/fpga-concepts/) ### Gray Codes and Their Uses in Digital Design URL: https://fpgadesign.io/blog/gray-codes-and-their-uses-in-digital-design/ Last updated: 2026-05-18T00:11:54.000Z ## What are Gray Codes? Gray code is a binary code in which only one bit changes between adjacent values. This property makes it useful in a variety of applications where reliable and accurate data transmission is required. One common application of Gray code is in rotary encoders, which are devices used to convert the angular position of a shaft into an electrical signal. Rotary encoders typically use a binary code to represent the shaft position, but the changing position of the shaft can create glitches or noise in the code. By using Gray code instead of binary code, only one bit changes at a time as the shaft rotates, minimizing the potential for errors or false readings. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9b01250f-b3fa-46f4-9a18-42ee12a13d65_1000x1000.jpeg) Figure 1: Rotary Encoder using Gray Code Another practical usage of Gray code is in digital-to-analog converters (DACs), which convert digital signals into analog voltages or currents. DACs often use resistor networks to generate the analog output, and Gray code can be used to ensure that only one resistor changes value between adjacent digital codes. This can reduce the potential for glitches or non-monotonic behavior in the analog output. Gray code can also be useful in signal processing applications, where it can be used to generate waveforms with minimal harmonic distortion. By ensuring that only one bit changes at a time, Gray code can produce smooth and continuous transitions between adjacent values, reducing the potential for distortion or artifacts in the waveform. Overall, Gray code is a useful encoding scheme in applications where accuracy, reliability, and minimal distortion are important factors. Its unique properties make it a valuable tool in a variety of fields, including electrical engineering, computer science, and signal processing. 💡If you have worked with Karnaugh Maps or K-Maps, you have already seen a practical use of Gray Codes. > During one of my interviews, I was asked to generate 4-bit Gray codes for binary numbers 0 through 15\. Here’s a neat trick using a K-map to do that! ⚡⚡ > We know that each cell in a K-map differs from its adjacent cell by a single bit. So, if you start at the top-left corner and draw a zig-zag line across the K-map, you’ll end up with a sequence of Gray codes. ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff978bb61-83d1-479a-9444-8c62889e9d5c_1275x492.png) Figure 2: Gray Code Encoding in Karnaugh Maps ## Generating a Gray Code Equivalent for Binary Code Generating Gray codes from binary is straightforward and involves a simple bitwise operation. Here’s the technique: 1. **Retain the Most Significant Bit (MSB)**: The MSB of the Gray code is the same as the MSB of the binary code. 2. **XOR Operation**: For each subsequent bit, perform an XOR operation between the current bit and the previous bit of the binary number. ### Example: Convert Binary `1011` to Gray Code 1. **Binary**: `1011` 2. **Gray Code**: - MSB: `1` (same as binary) - Next bit: `0 XOR 1 = 1` - Next bit: `1 XOR 0 = 1` - Next bit: `1 XOR 1 = 0` So, the Gray code equivalent of binary `1011` is `1110`. **Practice interview questions on this topic →** [RTL Design Questions](https://fpgadesign.io/design-questions/) ### Control Sets Demystified URL: https://fpgadesign.io/blog/control-sets-demystified/ Last updated: 2026-05-18T00:11:40.000Z A control set is a group of control signals (set/reset, clock enable, and clock) that drives any given SRL, LUTRAM, or register. Each unique combination of these signals forms a different control set. Let’s break it down with an example: Imagine you have two registers, A and B, both driven by the same clock. If register A needs a clock enable but register B doesn’t, they end up in different control sets. This means they can’t be packed into the same CLB slice. ## How Control Sets Affect Packing The way control sets are packed depends on the FPGA architecture and device family: - **7-Series Devices**: A slice (or half a CLB) has eight registers. All registers in a slice share one clock, one set/reset, and one clock enable. So, only one control set can be used per group of eight registers. - **UltraScale Devices**: Each half-CLB consists of two sets of four registers. Each set has its own clock, set/reset, and clock enable. Ideally, you can use two control sets per eight registers, allowing for tighter resource packing compared to the 7-series architecture. ## Why Does This Matter? Control set restrictions in CLB packing can make the placer shift some registers and their input LUTs around. Sometimes, these registers end up in less ideal spots. This extra distance can mess with utilization, placement quality, and power consumption because of longer net delays and more interconnect usage. This is especially a problem in designs with lots of low fanout control signals, like clock enables that only feed one register. In short, code written without any thought about optimizing for control sets, will usually result in wasted resources and potentially cause localized congestion due to the spread of logic. ## Unused Control Signals and Constants Unused inputs on a primitive don’t create new control sets. For example, if a PRESET on an FDRE primitive isn’t connected, it’s ignored and won’t create a new control set. Undriven reset signals can be tied off internally within a slice and won’t lead to a unique set either. ## Tips for Designing and Coding - **Avoid different clock enables** for logically related registers. For instance, if you have a data and control pipeline flowing in lock-step, don’t use different clock enables for these paths. This allows for more efficient logic packing. - **Avoid different set/reset signals** for logically related registers. - **Don’t code** `always_ff` **blocks** with a constant clock enable signal (set to `1`) or a reset signal set to a constant. It is more optimal to avoid these constants in the `always` block. ## Troubleshooting Control Set Issues in Vivado (Post-Synthesis) - **Check for unnecessary** `MAX_FANOUT` **attributes** on control signals in the RTL and constraints. Replicating control signals can cause the number of control sets to blow up. - **Avoid asynchronous set/reset signals** unless necessary. These can only be routed to dedicated asynchronous pins and can’t be absorbed into the datapath during synthesis. - **Don’t use both active high and active low versions** of the same control signal for different sequential elements. This practice is generally frowned upon. - **Use clock enables and set/resets sparingly**. Often, data paths contain many registers that automatically flush uninitialized values, where set/reset or enable signals are only needed on the first and last stages. ## Related Interview Questions - What is a control set in an FPGA? - What factors affect the number of control sets in a design? - How can the number of control sets in a design be minimized? - What are the benefits of minimizing the number of control sets in a design? - What are the drawbacks of using too many control sets? **Practice interview questions on this topic →** [FPGA Architecture Questions](https://fpgadesign.io/fpga-concepts/) ### Design Question - Pulse Generator URL: https://fpgadesign.io/blog/design-question-pulse-generator/ Last updated: 2026-05-18T00:11:52.000Z ## Design Idea 1 - A 5 bit counter One of the most common approaches is using a 5-bit counter that runs from 0 to 31\. A pulse is generated when the counter rolls over. It’s pretty straightforward. ```verilog module pulse_generator ( input logic clk, // clock input logic rst, // reset output logic pulse_out // output pulse ); //------------------------------------------------------------ // local signal declaration //------------------------------------------------------------ logic [4:0] sig_cnt; logic sig_pulse_out; //------------------------------------------------------------ // start of RTL code //------------------------------------------------------------ // Counter to count to 31 always_ff @(posedge clk) begin if (rst) begin sig_cnt <= '0; end else begin sig_cnt <= sig_cnt + 1'b1; end end // Pulse Generation // The generated pulse is combinatorial assign sig_pulse_out = (sig_cnt == 5'd31) ? 1'b1 : 1'b0; // Sequential output always_ff @(posedge clk) begin pulse_out <= sig_pulse_out; end endmodule ``` Design Idea - Using a Counter ### Key Points to Consider: - **Eliminating the** `rst` **Signal**: In FPGA designs, the `rst` signal can theoretically be eliminated in a majority of cases. Xilinx FPGAs have a Global Set Reset (GSR) line that initializes all registers to a known state, typically zeros. Even if the synthesis tool randomly distributes the 5 bits between a `0` and a `1`, the module will still generate pulses 32 clock cycles apart once it rolls over from all ones to all zeros. - **Combinatorial** `sig_pulse_out`: Using `sig_pulse_out` as the block output isn’t optimal. Typically, the output pulse drives other logic or serves as an input to a state machine. This can introduce long combinatorial paths with multiple levels of logic into the design. - **Using** `5'd31` **Instead of** `5'd0`: The pulse generator uses `5'd31` to generate a pulse to avoid creating a stretched pulse when `sig_cnt` is held at `0` with an asserted `rst` signal spanning multiple clock cycles. ## Design Idea 2 - Shift Register If you could load a 32 bit shift register with a single bit set to a `1` and all other bits set to zeros, and connect the output of the last stage to the input of the first stage, you would get a **Ring Counter** which would generate a pulse once every 32 clocks. Let’s dive into the pros and cons of this approach compared to the previous design: - **Resource Usage**: The shift register implementation requires 32 flip-flops, compared to just 5 flip-flops for the counter-based method. While this might be a drawback in ASIC designs, it fits well with the register-rich fabric of an FPGA. - **Eliminating Combinatorial Logic**: The shift register approach removes the need for an adder and a comparator, which can be part of the critical path in the counter-based method. - **Routing Delay**: With no combinatorial logic between stages, the main component of the critical path is the routing delay between flip-flops. This allows the placer more flexibility in positioning these registers, potentially improving performance. Now, let’s talk about FPGA-specific optimizations. Xilinx UltraScale+ devices offer SRL16s and SRL32s (LUT Shift Registers) that can be used to implement the ring counter logic. An SRL32 can create a 32-bit shift register using a single LUT and a slice flip-flop for sequential output. By initializing the SRL to `32'h80000000`, you insert a single `1` into the shift register. The SRL-based method is particularly advantageous for larger shift registers. Xilinx tools allow cascading SRLs to form longer chains, making this approach more efficient for a 256-bit ring counter compared to an 8-bit counter. ```verilog module pulse_generator_sr ( input logic clk, // clock input logic rst, // reset output logic pulse_out // output pulse ); //------------------------------------------------------------ // local signal declaration //------------------------------------------------------------ (* shreg_extract = "yes" *) logic [4:0] sig_shift_reg = 32'h80000000; logic sig_pulse_out; //------------------------------------------------------------ // start of RTL code //------------------------------------------------------------ // Counter to count to 31 always_ff @(posedge clk) begin sig_shift_reg[30: 0] <= sig_shift_reg[31: 1]; sig_shift_reg[ 31] <= sig_shift_reg[ 0]; end // Pulse Generation // Any bit of the Shift Register can be used as the output pulse assign pulse_out = sig_shift_reg[0]; endmodule ``` Design Idea - Using a Shift Register ### Synthesis Directives Synthesis directives guide the synthesis tool, nudging it in the right direction to achieve the desired implementation. To ensure SRL (Shift Register LUT) inference, you need to provide the appropriate synthesis directives in your RTL code. In the example above, `shreg_extract` is a directive that instructs the synthesis tool to implement the shift register using a LUT. ### Key Points to Consider - **Consistency with Design Idea 1**: The `rst` signal is included in the interface to maintain consistency with Design Idea 1. - **SRL Primitives and Reset**: Notice that `rst` is not used in the `always_ff` construct. SRL primitives do not accept a reset input. Including a reset signal would prevent the tool from using the SRL, even if a synthesis directive is specified. - **Initialization** of the shift register is done by specifying the initial value when the signal is declared. (Yes, this is synthesizable!!) ## Other Design Ideas There are other, more unconventional ideas that might be theoretically possible but not practically viable. One such idea is to use a state machine with 32 states, where one of the states produces the required output pulse. **Practice interview questions on this topic →** [RTL Design Questions](https://fpgadesign.io/design-questions/) ### Rethinking Resets: Best Practices for FPGA Design URL: https://fpgadesign.io/blog/rethinking-resets-best-practices-for-fpga-design/ Last updated: 2026-05-18T00:11:39.000Z While designing an RTL module, most engineers do not even give a second thought to the reset signal. Every textbook on the subject touches upon the pros and cons of synchronous vs asynchronous resets. The texts generally focus on the correct syntax for inferring a synchronous or an asynchronous reset. It is almost drilled into our brains that every sequential element in the design needs to have a reset (and this is almost always true in the ASIC world). The ubiquitous nature of reset signals do warrant that we pause for a moment before we blindly connect a reset signal to every flip-flop in the design, while working with FPGAs. ## Take a Step Back and Consider This What is the true purpose of the reset in your design? 🤔 In general terms, the purpose of a reset signal can be summarized as follows: - **Power-On Reset**: To initialize all sequential elements in your design to a known state at power-up. - **Software Reset**: To initialize specific sequential elements to a known good state during operation, such as resetting a locked-up state machine. - **Hardware Reset**: To use an internally generated signal or an external input to reset all or some portions of your design during operation. ## The Problem with Resetting Everything in the FPGA FPGA fabrics are rich in registers. Simply connecting the reset signal to all registers in the design can place a heavy load on the Place and Route tools during the routing phase. A high fanout signal like reset can significantly impact the maximum clock frequency, area, and power consumption. ## Wouldn’t the Logic Fail Functional Equivalence Without an Initialization Reset? In Xilinx FPGAs, every Flip-flop is connected to the **GSR (Global Set/Reset)** line, which ensures that every Flip-flop will come up in the desired state ('0' or '1'), without the need for an explicit initialization reset. The initial value can be specified in SystemVerilog as follows - ```verilog logic reg1 = 1’b0; // specifying reg1 to initialize to a zero logic reg2 = 1’b1; // specifying reg2 to initialize to a one logic [3:0] reg3 = 4’b1011; // specifying INIT value for 4-bit register ``` Specifying initial values for registers 💡If no initial value is provided, the synthesis tool is at a liberty to assign either a '0' or a '1' to a particular element. Vivado synthesis generally defaults to a '0', with a few exceptions such as one-hot encoded state machines. For Software Resets and external Hardware Resets, it is necessary to code the reset logic explicitly. ## Some other scenarios where the use of Resets can cause issues Inferred synchronous code might be mapped to resources such as - - LUTs - Registers - SRLs - BlockRAM, UltraRAM or Distributed LUT memory - DSP48s The choice and usage of resets, along with the coding style, can significantly impact the selection of optimal resources. Here are a couple of examples: - **Shift Registers**: A 32-bit shift register can be efficiently mapped to a single LUT in a Xilinx UltraScale+ device. However, if the logic includes a reset signal, the synthesis tool might map the same logic into 32 discrete registers, which is less efficient. - **Multipliers**: Using an asynchronous reset on a multiplier might result in the associated registers being placed in the fabric logic instead of the more efficient DSP48s. ## Some Real-Life Observations and Notes **Wide Data Buses**: Wide data buses with multiple pipeline stages typically do not require a reset. This can simplify the design and improve performance. **Synchronous Resets**: Xilinx recommends using synchronous, active-high resets wherever possible. Active-low resets require an inverter, which can sometimes be absorbed into the register but may also necessitate a LUT, adding an extra logic level to the path. **High Fanout Reset Issues**: High fanout reset signals can be problematic. To mitigate this, you can replicate the source of the reset signal to balance the load on the reset net. ![](https://substackcdn.com/image/fetch/w_2400,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F06369574-c004-46fd-bf34-b66bdf7aa7a5_2644x1344.png) Figure 1: Source Replication for Fan-out Reduction on the Reset signal **Global Clock Buffer (BUFG)**: In extreme high-fanout scenarios, a global clock buffer (BUFG) can be used to route the reset signal. However, this approach is generally not recommended due to potential timing issues. **SSI Devices**: In SSI (Stacked Silicon Interconnect) devices, timing closure on reset paths behaves similarly to other paths. Designers should account for additional pipeline stages when crossing SLR (Super Logic Region) boundaries to ensure proper timing closure. **Practice interview questions on this topic →** [FPGA Architecture Questions](https://fpgadesign.io/fpga-concepts/)