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
  • Clock and Reset Architecture24
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • IP Integration and Handoff21
    • IP Collateral and Versioning
    • Wrappers and Adapters
    • Integration Lint and Connectivity Checks
    • Top-Level SDC and Constraint Merge
    • DFT Integration
    • Debug Infrastructure
    • Safety and Fault Architecture
      • What a Safety Goal Asks of the SoC
      • Fault Detection, Reaction and Reporting
      • Lockstep, Parity and Redundancy
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←Safety and Fault Architecture
  1. Topics
  2. SoC Design
  3. IP Integration and Handoff
  4. Safety and Fault Architecture
  5. Lockstep, Parity and Redundancy
On this page

    Part 9 of 14, lesson 21 of 21Part 9 of 14/IP Integration and Handoff/Lesson 21 of 21All levels

    Lockstep, Parity and Redundancy

    Paying for certainty: what is duplicated, what is coded, what is compared, and what each costs.

    Extension topic: NanoSoC v1 has no fault controller or redundancy hardware. This lesson uses the NanoSoC safety extension described in the Safety and Fault Architecture overview; numbers marked illustrative belong to that extension only.

    Why it matters

    Detection catches the faults the designer predicted; redundancy catches the ones nobody predicted, the flipped flop in a control state machine, a double flip in different bytes of an SRAM word, the clock glitch that no checker modelled. But duplication doubles area and power on everything it touches, and a poorly placed checker flags correct behaviour as faulty. The task is choosing one pattern per structure and doing the cost arithmetic that justifies it.

    The core idea

    Two patterns cover the extension, each matched to the structure it protects. Parity protects storage and transport: one parity bit per byte on the SRAM read path detects an odd number of flips in that byte at the receiver with single-cycle latency, and one bit per 32-bit word (33 wires) protects each stream bus. Lockstep duplicates small control logic with the same inputs and compares outputs, with a delay between the copies so that a fault striking both identically does not slip through: here the reset and power sequencers in nano_rstpwr are duplicated as one pair. Other structures get no extra pattern: the sequencer's own steps need none beyond the lockstep pair, and the DMA datapath and the fabric are not duplicated because that would double the largest blocks; they are covered by error responses and end-to-end checks. Parity has a residual risk the review must write down: two flips in the same byte cancel and go undetected, and the teaching design accepts that.

    Diagram
    # not-run: NanoSoC safety extension, one pattern per structure, illustrative costs
    sram0, sram1:           parity per byte, 36-bit macros (one extra bit per byte = 12.5 percent)
    stream buses:           one parity bit per 32-bit word (33 wires), negligible area
    reset and power logic:  lockstep pair of nano_rstpwr sequencers, delayed compare (100 percent of 0.015 mm2)
    fabric, DMA datapath:   no duplication; error responses and end-to-end checks
    residual risk:          two flips in the same byte are not detected by per-byte parity
    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    # Cost audit: one pattern per structure, cost derived from the area budget.
    SRAM_MM2, RSTPWR_MM2, BLOCK_SUBTOTAL_MM2 = 0.100, 0.015, 0.585   # NanoSoC budget
    STRUCTURES = [   # (structure, pattern, protected area mm2, area fraction added)
        ("sram0", "parity", SRAM_MM2, 0.125),
        ("sram1", "parity", SRAM_MM2, 0.125),
        ("stream_buses", "parity", 0.0, 0.0),           # 33 wires, negligible area
        ("rstpwr_sequencers", "lockstep", RSTPWR_MM2, 1.0),
    ]
    
    def audit(structs):
        problems = []
        names = [s[0] for s in structs]
        problems += ["two patterns: " + n for n in set(names) if names.count(n) > 1]
        problems += ["unknown pattern: " + s[0] for s in structs
                     if s[1] not in ("parity", "lockstep")]
        return problems
    
    assert audit(STRUCTURES) == []
    overhead = sum(a * f for _n, _p, a, f in STRUCTURES)
    assert abs(overhead - 0.040) < 0.0001, overhead
    assert overhead / BLOCK_SUBTOTAL_MM2 < 0.07                      # 6.8 percent
    # the old contradiction (sequencer both lockstep and temporal) is now rejected
    assert audit(STRUCTURES + [("rstpwr_sequencers", "temporal", 0.015, 0.05)]) != []
    print(f"PASS: 4 structures, one pattern each; overhead {overhead:.3f} mm2 = {overhead / BLOCK_SUBTOTAL_MM2:.1%} of block area")

    What the review looks for

    • The pattern choice per structure with the fault class it catches, the residual risk it leaves and the cost beside it, matching the table above in text and in code.

    • The comparator and parity outputs routed to the fault controller as held levels, not to log files or LEDs.

    • The common-cause argument for each lockstep pair: delay, diversity or independence stated, not assumed.

    • Every fault flag that leaves PD_SW into the always-on fault controller clamped, counted on top of the 114 isolation cells.

    Verify and debug

    Inject the faults redundancy should catch: flip one bit in a protected SRAM word and confirm the parity flag, force one lockstep copy to disagree and confirm the compare fires, and flip two bits in different bytes of one word to confirm both parity bits fire. Each injection must end at the fault controller input from the previous lesson; redundancy that flags locally but never reports is the silence the whole topic refuses.

    Missing isolation on fault flags: the power topic's 114 clamps cover the APB, SRAM0, ROM and the two interrupt lines. Every fault flag that leaves PD_SW into the always-on fault controller needs its own clamp on top of those; with the three detector flags used here (stream-bridge error, DMA error, SRAM1 parity) the count becomes 117, and a missed one floats high and reports a fault that is not there. Clamp-to-zero reads as no fault while the domain is off, which is correct only because the detectors are off too. The SRAM0 parity checker sits on the always-on side of the macro, so its flag does not cross.

    If asked when you duplicate versus when you code, answer: code storage and transport where errors are bit-local and parity is cheap, duplicate small control where any wrong output is dangerous, and leave the large datapath to error responses and end-to-end checks. Then price each on the spot as a fraction of what it protects, and name the residual risk of parity.

    Check yourself Lockstep compares the two copies and they agree, but both are wrong. What defeated it?

    A common-cause fault that struck both copies identically: same glitch, same bad input, same misconfigured mode. The delay between copies and input diversity exist exactly to defeat this, which is why the review demands the common-cause argument per pair.

    Related topics

    • Fault Detection, Reaction and Reporting

    • RTL: Failure Model and Protection Choice

    • Protocol First Principles: Error Responses

    Previous

    195 / 289

    Next: Integration and Connectivity Tests

    Up next

    Up nextIntegration and Connectivity Tests

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • What a Safety Goal Asks of the SoC