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
    • NoC Basics
    • Coherent Interconnect View
      • What Changes with Coherent Masters
      • I/O Coherence Options for DMA
      • Migration Path from NanoSoC
    • 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

←Coherent Interconnect View
  1. Topics
  2. SoC Design
  3. Interconnect and Bus Fabrics
  4. Coherent Interconnect View
  5. Migration Path from NanoSoC
On this page

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

    Migration Path from NanoSoC

    Adding one coherent master: the fabric, verification and software delta, priced before it is promised. Illustrative numbers.

    Why it matters

    Coherence arrives as a one-line requirement, support a caching accelerator, and lands as a chip-wide change touching the fabric, the verification plan and every driver. Pricing it before promising it is the integrator's job, and NanoSoC is small enough that the whole delta fits in one lesson.

    The core idea

    The delta has four parts. The fabric gains snoop connectivity to the new master and to every cache it may share with, plus the bandwidth rows and the deadlock re-review for the new traffic class. The map gains a coherency attribute per region, because the same address is treated differently depending on whether the access coherently snoops. Verification gains overlapping-address tests with hot caches, snoop-rate counters, and error-exit maintenance checks. Software gains the maintenance sequences or the port configuration, plus ownership of which buffers are shared. None of this is deep protocol work; all of it is integration surface that must be staffed.

    Diagram
    # not-run: coherence migration checklist, NanoSoC teaching values
    1. Fabric: snoop paths to the new master; snoop bandwidth rows; deadlock
       re-review with three traffic classes; QoS class for snoop traffic.
    2. Map: coherency attribute per region; shared regions marked and bounded.
    3. Verification: overlapping-address tests, cache-state randomisation,
       snoop counters against budget, error-exit maintenance coverage.
    4. Software: maintenance sequences with barriers, or port setup; buffer
       allocation rules that auditors can check.
    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    # Illustrative: the snoop budget row for a coherent accelerator added to NanoSoC.
    LINE = 16 # bytes per cache line
    QUERY_BYTES = 8 # illustrative: one snoop request plus one answer per line
    LINK = 361.4 # MB/s sustained on a 16-beat link
    def snoop_row(data_mbs, shared_fraction):
        # only the shared part of the traffic needs snoops
        return data_mbs * shared_fraction / LINE * QUERY_BYTES
    
    assert abs(snoop_row(361.4, 1.0) - 180.7) < 0.1 # worst case: everything shared
    assert abs(snoop_row(361.4, 0.25) - 45.2) < 0.1 # a placement rule keeps most traffic private
    # the budget check: data plus snoop traffic must still fit the link it shares
    assert 361.4 + snoop_row(361.4, 1.0) > LINK # over budget if all traffic is shared
    assert 361.4 * 0.75 + snoop_row(361.4, 0.25) < LINK # fits when only a quarter of it is shared
    print("PASS: snoop row 180.7 MB/s fully shared, 45.2 MB/s at a quarter, only the placement rule fits the link")

    What the review looks for

    • The migration proposal carries all four parts with owners, not just the port wiring.

    • The snoop bandwidth row exists before the master is added, with the sharing fraction it assumes (above, 25 percent keeps the link within budget; 100 percent does not).

    • A non-coherent fallback is named: which buffers stay placed and maintained if the port slips.

    Verify and debug

    Sequence the migration: first mark the shared regions and run the maintenance tests against them while everything is still non-coherent, then enable the port and compare snoop counters against the budget. If snoop traffic exceeds the row, the sharing pattern is wider than assumed and the fix is placement, not more bandwidth.

    Promising coherence as a port: wiring the coherent interface while forgetting the map attribute, the snoop budget, the deadlock re-review and the driver sequences. The port works in the demo and fails under sharing, and each missing piece is found by a different team months apart.

    If asked to add coherence to a small chip, list the four-part delta before discussing protocols: fabric, map, verification, software. Interviewers asking integration questions score the surface covered, not the states recited.

    Check yourself The coherent master is delayed but the shared regions are already marked. What still works?

    Everything non-coherent: placement plus maintenance covers the marked regions, which is exactly the fallback the review demanded. The port accelerates later without changing the contract.

    Related topics

    • I/O Coherence Options for DMA

    • Cache Coherency: Software Maintenance for DMA

    • Next: Firewalls and Protection

    Previous

    84 / 289

    Next: Clock Sources and PLLs

    Up next

    Up nextClock Sources and PLLs

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • What Changes with Coherent Masters