Skip to content
Learnings · RTL Design Patterns

RTL Design Patterns tutorials & labs.

From describing hardware to engineering it. Reusable, verifiable RTL structures — registers, FSMs, FIFOs, handshakes, arbiters, and clock-domain crossings — with the judgment to choose, parameterize, and verify them.

Structured curriculum

Tutorials

Learn RTL Design Patterns from beginner to advanced through structured tutorials.

79 of 79 topics liveOpen tutorials
Hands-on practice

Labs

Practice RTL Design Patterns using progressively challenging hands-on labs.

0 of 0 labs liveOpen labs

What RTL Design Patterns is

This track is about the structures real digital designs are assembled from: state machines, FIFOs, arbiters, pipelines, ready/valid handshakes, synchronisers and clock-domain crossings. Each is a recurring answer to a recurring problem — how to sequence behaviour, buffer between producers and consumers, share a resource fairly, absorb backpressure, or move data safely between clocks. The focus is on the reasoning behind each pattern: what it guarantees, what it costs in area and latency, and how it fails when applied carelessly.

Why it exists

Knowing the language is not the same as knowing how to build hardware with it. Most real design work is choosing and composing these structures correctly — deciding where to buffer, how to handle a full FIFO, whether a crossing needs a synchroniser or a full asynchronous FIFO, and who owns a piece of state. These decisions determine timing closure, verification effort and whether a block can be reused, long before any syntax question arises.

The part engineers get wrong

The same SystemVerilog can describe hardware that is robust, fragile, timing-hostile or impossible to verify — the difference is architectural, not syntactic. What separates a good pattern from a working one is that it makes the hard things explicit: who owns each piece of state, where backpressure is absorbed, what the latency actually is, and exactly where a clock-domain boundary sits. A design that leaves those implicit usually simulates fine and then fails in timing closure, at integration, or intermittently in silicon — because the assumptions were never written down anywhere a tool or a reviewer could check them.

Before you start

  • Working RTL in Verilog, SystemVerilog or VHDL
  • Combinational and sequential logic, and clocked design
  • Helpful: some exposure to timing closure or integration problems

What you will be able to do

  • Choose an FSM coding style and state encoding, and justify the choice
  • Design a synchronous FIFO with correct full and empty behaviour
  • Size a FIFO against real producer and consumer rates
  • Build a ready/valid interface that handles backpressure without losing data
  • Select and apply the right structure for a clock-domain crossing
  • Choose an arbitration scheme and reason about fairness and starvation

The learning path

  1. State machinesCoding styles, encoding and separating output logic
  2. FIFOsFull and empty flags, depth sizing and first-word fall-through
  3. HandshakesReady/valid, backpressure and the bugs that hide in them
  4. PipelinesAdding stages without breaking flow control
  5. ArbitrationSharing a resource, and what fairness costs
  6. Clock-domain crossingSynchronisers, asynchronous FIFOs and CDC rules
  7. VerificationChecking these structures behave under stress

Core concepts

New to RTL Design Patterns? Work through the curriculum in order — each lesson assumes the one before it, and the sequence is what turns the roadmap above into working knowledge.

Already working with it? Use the core-concept links above to jump straight to the topic you need; each one opens the lesson that covers it in most depth.

Follow the full curriculum

Where this leads