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

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • The NanoSoC Tour
  • Reading Path
  • SoC Glossary10
  • SoC Metrics Reference
  • SoC Cheatsheet
  • What SoC Integration Is12
  • Architecture and Budgets21
  • Memory Maps and Address Decode26
  • Interconnect and Bus Fabrics26
    • Topologies and Bridges
    • AXI Integration Details
    • Ordering and Deadlock at the Top
    • QoS and Arbitration
      • Round-Robin and Its Measured Cost
      • Starvation, Priority and Shaping
      • QoS in Practice on NanoSoC
    • NoC Basics
    • Coherent Interconnect View
    • Firewalls and Protection
    • Bandwidth and Latency Verification
  • Clock and Reset Architecture24
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • IP Integration and Handoff21
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←QoS and Arbitration
  1. Topics
  2. SoC Design
  3. Interconnect and Bus Fabrics
  4. QoS and Arbitration
  5. QoS in Practice on NanoSoC
On this page

    Part 4 of 14, lesson 13 of 26Part 4 of 14/Interconnect and Bus Fabrics/Lesson 13 of 26All levels

    QoS in Practice on NanoSoC

    What NanoSoC guarantees with round-robin alone, what AxQOS would add, and the proposed changes priced in MB/s.

    Why it matters

    A QoS table that nobody checks is decoration, and a QoS table for features the chip does not have is worse. NanoSoC's nano_xbar is round-robin only, with an AxPROT security filter: there is no priority, no rate regulator and no master-ID firewall. This lesson states what round-robin alone guarantees the CPU, checks the budget against it, and prices the changes that would add more, each labelled as a proposal.

    The core idea

    What NanoSoC guarantees today: the CPU's wait behind the SBR on a shared bank is bounded by one SBR burst, 17 cycles, 177 ns. While both are backlogged, the CPU's 4-beat fills get about 69.8 MB/s and the SBR about 279.3 MB/s, 349.1 MB/s in total. The CPU's end-to-end line-fill demand is up to 128 MB/s, so in the shared-bank corner it is slowed to 55 percent of that, but it is never starved. The classes in this lesson (CPU latency-critical, SBR bulk) are therefore a plan for fabric configuration, not signals.

    AXI4 carries a 4-bit AxQOS value on every request; an interconnect may use it to rank requests or to drive regulators, and may limit outstanding transactions per class. NanoSoC's CPU port and the SBR tie AxQOS to 0 and nano_xbar ignores it. A QoS-aware replacement would let the CPU's fills carry a higher value than the SBR's bursts, which would change who starts next but, as the previous lesson showed, not the burst already running.

    Proposed change (not in NanoSoC)

    Effect on the CPU worst wait

    Cost

    Per-master priority, CPU above SBR

    Still 17 cycles (a burst in progress runs to its end); the CPU never queues behind a second SBR burst

    A priority input in the arbiter; a starvation risk for the SBR to be regulated

    Rate limit (token bucket) on the SBR

    Still 17 cycles; guarantees the CPU its share even with SBR priority

    SBR capped at its share, 105.4 MB/s per direction in the shared-bank corner below

    Software rule: the SBR driver splits jobs into 4-beat bursts

    5 cycles, 52.1 ns

    SBR stream falls from 361.4 to 307.2 MB/s

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    # NanoSoC teaching values: the shared-bank corner under round-robin, and the proposed shaping.
    F = 96e6
    CPU_FILL = 128.0 # MB/s the CPU asks for when it runs straight-line code from SRAM
    # round-robin, both backlogged, one 22-cycle period: 4-beat fill + 16-beat SBR burst, 2 bubbles
    period = 22 / F
    cpu_rr = 16 / period / 1e6
    sbr_rr = 64 / period / 1e6
    assert abs(cpu_rr - 69.8) < 0.1 and abs(sbr_rr - 279.3) < 0.1
    assert abs(cpu_rr / CPU_FILL - 0.545) < 0.002 # slowed to 55 percent, bounded, not starved
    # proposed: give the CPU its full 128 MB/s and shape the SBR into what is left of the port
    cpu_port_fraction = CPU_FILL * 1e6 / 16 * 5 / F # 5 cycles per 16-byte fill
    assert abs(cpu_port_fraction - 0.4167) < 0.001
    sbr_total = (1 - cpu_port_fraction) * 384 * 16 / 17 # SBR bursts of 16 in the remaining cycles
    sbr_per_direction = sbr_total / 2 # the SBR's read and write both use this one bank
    assert abs(sbr_total - 210.8) < 0.1 and abs(sbr_per_direction - 105.4) < 0.1
    # split-bank case: SBR reads SRAM0 and writes SRAM1, each bank carries one direction
    assert abs(2 * 361.4 - 722.8) < 0.1 # both banks together at the full SBR rate
    # but a CPU running from SRAM0 still competes with the SBR's read stream on that bank
    assert cpu_rr + sbr_rr < 361.4 # 349.1: the shared bank loses capacity to the extra bubbles
    print("PASS: round-robin gives CPU 69.8 and SBR 279.3, proposed shaping gives SBR 105.4 per direction beside a full-rate CPU")

    What the review looks for

    • The QoS table says which classes exist in the hardware and which are proposals, and no document describes a proposal as built.

    • The shared-bank corner has its own budget row with the round-robin result (69.8 and 279.3 MB/s) and, if shaping is proposed, the shaped rates, not a footnote.

    • Performance counters (testbench or added monitors, NanoSoC has none built in) are assigned per class so the budget is checkable.

    Verify and debug

    Drive the shared-bank corner in performance simulation and read per-class counters: the CPU must see its fill rate near 69.8 MB/s and a worst wait of 17 cycles, the SBR near 279.3. If the wait is longer, something other than one SBR burst holds the port. For a proposed regulator, repeat with it enabled and check the SBR holds its shaped share. The verification topic turns this budget into a simulation and counter plan.

    Port oversubscription: the sum of worst-case master demand exceeds what the shared port delivers once bubbles are counted, so throughput misses and latency tails grow with no error anywhere. Caught by the budget plus traffic-model simulation; fixed by re-budgeting, moving a buffer to the other bank, or shaping concurrent use cases. NanoSoC shows it in miniature on one shared SRAM bank.

    If asked to assign QoS on a new chip, start from deadlines not rates: whose miss is visible first, then reserve that rate and shape the rest. Be explicit about what the hardware has: on NanoSoC round-robin bounds the CPU's wait at one SBR burst, and priority or a regulator would be proposals with a price.

    Check yourself The SBR stream and CPU fills share one bank and nothing is regulated. What do the counters show?

    Round-robin: the CPU fills at about 69.8 MB/s and the SBR at about 279.3 MB/s while both are backlogged, and the worst fill wait is one SBR burst, 16 beats plus one bubble, 17 cycles or 177 ns. The CPU is slowed to about 55 percent of its 128 MB/s demand, not starved.

    Related topics

    • Starvation, Priority and Shaping

    • Bandwidth and Latency Verification

    • Protocol First Principles: Fairness and Starvation

    Previous

    77 / 289

    Next: NoC Basics

    Up next

    Up nextNoC Basics

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Round-Robin and Its Measured Cost