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
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
    • SRAM and ROM
    • Register Files
    • Valid/Ready Handshake
    • AXI-Lite
    • AXI-Stream
    • Bus Integration
      • Address Decode
      • Mux Trees and Read Paths
      • Error Paths and Timeouts
      • Arbitration
      • Integration Checklist
      • An End-to-End Bus Example
    • Synchronous FIFO
    • Register-Map and CSR RTL
    • Memory Reliability
    • Peripheral RTL Integration
    • Full AXI4: RTL Roadmap
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

‹Memory & Buses
  1. Topics
  2. RTL Design
  3. Memory & Buses
  4. Bus Integration

Part 7 · Memory & Buses · Intermediate

Bus Integration

How several masters and slaves become one working bus: decode, muxing, errors, arbitration and signoff.

  • 6topics
  • 6lessons

Topics in this section

  1. 1Address Decode1 lesson
  2. 2Mux Trees and Read Paths1 lesson
  3. 3Error Paths and Timeouts1 lesson
  4. 4Arbitration1 lesson
  5. 5Integration Checklist1 lesson
  6. 6An End-to-End Bus Example1 lesson
On this page

    A bus connects several masters to several slaves through shared address, data and control wires. Integration is the work that makes the sharing correct: decoding each address to one slave, multiplexing the replies, answering illegal accesses with errors, arbitrating between masters and proving all of it.

    Masters, arbiter, decode, slaves and the read mux in one fabric.
    Masters take turns through the arbiter. Decode steers each address to one slave, and the read mux returns the reply to the master that holds the grant.

    Decode works from an address map: each slave owns one range, and every address outside them goes to the default slave.

    The address map used in this topic: UART owns 0x0000_1000 to 0x0000_1FFF, SPI owns 0x0000_2000 to 0x0000_2FFF, and every other address is answered by the default slave with an error

    Read the ladder from the bottom up. The shaded regions are the only addresses a real slave answers.

    • Adjacent regions: the UART limit 0x0000_1FFF is one below the SPI base 0x0000_2000, so the boundary needs its own test.

    • Gaps: both dashed regions go to the default slave, which returns an error response, never floated data or a false OKAY.

    Lessons in this topic

    6 lessons, about 30 min

    1. 1Address DecodeYou can write base and limit address decode with a one-hot select and a default error path, and choose the addresses that expose off-by-one errors.3 min
    2. 2Mux Trees and Read PathsYou can build an AND-OR read mux qualified by a one-hot select, register it, and keep data, status and owner together under a stall.5 min
    3. 3Error Paths and TimeoutsYou can map bad accesses to SLVERR or DECERR, and build a timeout monitor while saying what the monitor does not do.4 min
    4. 4ArbitrationYou can choose between fixed priority and round-robin, hold a registered grant until acceptance, and state the fairness bound.5 min
    5. 5Integration ChecklistYou can list the five integration items with the evidence that proves each, and design a test that tells a wrong decode from wrong target wiring.4 min
    6. 6An End-to-End Bus ExampleYou can connect two masters, a round-robin arbiter, address decode, three slaves, a default slave and a timeout into one bus, and check it with random traffic against a reference model.9 min
    Check yourself An unmapped address returns data with an OKAY response. Why is that a defect?

    The data is garbage, but OKAY tells software it is valid. The default slave must answer unmapped addresses with an error response, and read data must never float.

    Interview

    Bus integration questions test system thinking: how decode, errors and arbitration interact, and what evidence proves the map matches the software headers.

    Revision sheet

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

    Address Decode

    • Keep the base and limit pairs in one place so the map can be checked against the software headers.

    • Exactly one select is high for a mapped address. An overlap is a map bug.

    • An AND-OR read mux returns zero when nothing is selected. That is not a valid completion, so a default slave must return an error.

    Rule of thumb: test the limit, the base and one address past the limit, not just the middle of each range.

    Mux Trees and Read Paths

    • AND each slave word with its select replicated across the width, then OR the terms. The one-hot select belongs in an assertion.

    • Capture the {data, status, owner} tuple only when the response slot is free, and hold it while the receiver stalls.

    • Byte lanes must keep their order, and both sides must agree on endianness. Do not infer a lane swap from CPU endianness alone.

    Error Paths and Timeouts

    • DECERR means no slave matched the address. SLVERR means a slave detected the error.

    • The timeout counter runs while req && !ack, fires at LIMIT, and drops when ack arrives or req falls.

    • A monitor is a detector, not a transaction engine: it sends no error and does not quarantine late replies.

    Rule of thumb: an error response is data too, so the default slave must produce it.

    Arbitration

    • Fixed priority is a priority encoder and cheap, but it can starve a master, so document that.

    • Round-robin searches after the last owner. With persistent requests, each master is served within N accepted ownership intervals.

    • A grant stays until accept_i is high, then clears for one arbitration cycle before the next owner is chosen.

    Integration Checklist

    • Each item pairs a check with the evidence that proves it: which test, which bound, which log.

    • Re-run the map check whenever a header changes, because maps drift one register at a time.

    • Load, starvation and debug-path fairness are system properties, so prove them at the top, with complete ordered tuples rather than counts.

    An End-to-End Bus Example

    • The grant names the owner until the reply. End the ownership interval on the response, never on the request handshake.

    • Register the slave select at issue and steer the reply by it. Unmapped addresses get DECERR from a default slave that always answers.

    • A timeout ends a hung access with SLVERR and must also stop the slave from replying late. Every bus bench needs watchdogs.

    Rule of thumb: route each reply by who owns the transaction, never by who is asking now.

    Practise it

    • Practice question: AXI4-Lite slave with invalid address protection

    • Practice question: Waveform debug: write transaction timeout

    • Practice question: Memory arbiter for two masters

    • Code lab: Round-robin arbiter

    • Interview: run a mock interview on this topic

    PreviousNext: Address Decode

    Up next

    Up nextAddress Decode

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • SRAM and ROM
    • Register Files
    • Valid/Ready Handshake