Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
    • Controller and Datapath
    • Moore vs Mealy
    • State Encoding
    • Multi-Cycle Sequencers
    • UART Transmitter
    • Memory Controller
      • Objective and Interface
      • State Machine and Bus Behavior
      • Request Latching
      • Design Closure Checklist
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹FSM & Control
  1. Topics
  2. RTL Design
  3. FSM & Control
  4. Memory Controller

Part 4 · FSM & Control · Intermediate

Memory Controller

A controller FSM between a requester and synchronous RAM with latching and latency handling.

  • 4topics
  • 4lessons

Topics in this section

  1. 1Objective and Interface1 lesson
  2. 2State Machine and Bus Behavior1 lesson
  3. 3Request Latching1 lesson
  4. 4Design Closure Checklist1 lesson
On this page

    A memory controller hides RAM timing behind a simple request interface. It latches each request, waits out the read latency, and returns read data.

    Block diagram of requester, memory controller and synchronous RAM.
    The controller accepts one request at a time, runs the RAM protocol, and returns read data.

    Lessons in this topic

    4 lessons, about 16 min

    1. 1Objective and InterfaceYou can state the interface of a one-request-at-a-time memory controller, its ordering and throughput, and when a write counts as complete.4 min
    2. 2State Machine and Bus BehaviorYou can draw the four-state controller (IDLE, ACCESS, WAIT, RESP), follow a write and a read on the waveform, and say when rsp_rdata is valid.4 min
    3. 3Request LatchingYou can latch the request fields at the accept edge, drive the RAM from the copies, and write an adversarial driver that exposes a missing latch.4 min
    4. 4Design Closure ChecklistYou can answer the closure questions for the controller, list coverage and assertions for it, and say which properties formal tools can prove and under what assumptions.4 min
    Check yourself Why is the controller's interface split into a request channel and a response channel?

    A read returns after acceptance; writes have no response. The response is a one-cycle pulse with no rsp_ready: the consumer must always capture it at the edge where rsp_valid is high. Later pickup needs a holding register/FIFO or a response ready/valid extension.

    Interview

    Variants of this question come up often: “Design a controller for a RAM with 2-cycle read latency”, “How would you add burst support?”, “What if the requester changes its inputs after the handshake?”.

    Revision sheet

    The whole topic on one page, taken from each lesson's Remember box. Read it before an interview, or print it.

    Objective and Interface

    • One request at a time, through valid/ready. A write drives the RAM for one cycle. A read waits for the RAM latency and then gives a one-cycle rsp_valid.

    • req_ready is a pure function of the state register, so it is safe to connect to any requester.

    • Writes give no response. The return of req_ready is their completion.

    Rule of thumb: more throughput means a pipelined controller with a queue, not a faster single-request FSM.

    State Machine and Bus Behavior

    • Writes finish in ACCESS. Reads go on through WAIT and end with one RESP cycle.

    • rsp_rdata is a plain wire from mem_rdata. It is valid only in the RESP cycle, so capture it on rsp_valid.

    • Only an enabled read (mem_en and not mem_we) launches data into the RAM's output pipeline.

    Rule of thumb: use rsp_rdata only when rsp_valid is high.

    Request Latching

    • Copy req_we, req_addr and req_wdata into we_r, addr_r and wdata_r at the accept edge, and use only the copies.

    • A driver that holds the old request until the controller is idle hides all three latch bugs. Change the inputs as soon as that is legal.

    • A correct but slower design can pass a value-only scoreboard, so also check the response edge.

    Rule of thumb: the accept edge is the last moment the requester has to hold its request.

    Design Closure Checklist

    • Cover all four states and transitions, write then read on the same address, and request changes on the cycle after accept.

    • Assert: rsp_valid follows only a read, exactly one rsp_valid per read, and mem_en only in ACCESS.

    • A formal proof covers the specified model under assumptions: progressing clock, stable offers, legal parameters and a fixed-latency RAM.

    Rule of thumb: define in the interface that a reset cancels all outstanding requests.

    Practise it

    • Mini project: an SPI master, controller and datapath

    • Practice question: Design a burst access controller with a ready/valid handshake

    • Practice question: FSM verification strategy: coverage and assertions for corner cases

    • Interview: run a mock interview on this topic

    PreviousNext: Objective and Interface

    Up next

    Up nextObjective and Interface

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Controller and Datapath
    • Moore vs Mealy
    • State Encoding