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
  • Top-Level Verification and Bring-up21
    • SoC Verification Strategy
    • Integration and Connectivity Tests
    • Firmware Co-Simulation
      • Running Boot Code Against RTL
      • Bench Checkpoints and the ROM Self-Test
      • Cost, Speed and What to Log
    • Performance Verification
    • Gate-Level and Power-Aware Simulation
    • Emulation and FPGA Prototyping
    • Bring-Up Readiness
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←Firmware Co-Simulation
  1. Topics
  2. SoC Design
  3. Top-Level Verification and Bring-up
  4. Firmware Co-Simulation
  5. Cost, Speed and What to Log
On this page

    Part 10 of 14, lesson 9 of 21Part 10 of 14/Top-Level Verification and Bring-up/Lesson 9 of 21All levels

    Cost, Speed and What to Log

    Pricing the firmware run, logging that debugs without drowning, and when to stop simulating boot.

    Why it matters

    The boot run is the slowest test on the nightly plan and the noisiest: every APB access, every AXI beat and every UART character can be logged, and logging all of them turns a 12.581 ms run into gigabytes nobody reads. Its one job is the logging and cost discipline: what is always on, what is armed for failure, what a ROM-side print would cost, and when the run moves to a faster platform.

    The core idea

    Cost first. The boot is 12.581 ms of simulated time, which is 1,207,768 clk_sys-equivalent cycles (12,580.917 us at 96 cycles per us; about 1.2 million). At an illustrative whole-chip RTL simulation speed of 5,000 such cycles per wall-clock second, with firmware running and no waveform dump, one boot costs about 241.6 s, four minutes of wall clock per iteration; the speed falls further with logging and rises or falls with design size. Twenty boots a night is the plan from the strategy topic; a developer iterating on the loader pays one boot per change. Anything that shortens the run without touching its proof pays directly: a smaller test image for loader iterations, with the full 8 KB image reserved for the nightly run, and bench checkpoints that stop the run early instead of running the whole SPI load after the DMA already failed.

    Logging follows three levels. Always on: the bench monitor events (about a dozen timestamped lines) and the captured UART output, which is the 16-character banner and nothing else, kept with every regression result. Armed for failure: per-access APB and AXI traces, enabled by a monitor event — when the DMA self-test fails, the rerun enables the fabric trace from the last event, not from reset. Never in the nightly run: full waveform dumps of the whole chip, which are reserved for the failing window around a reproduced bug. The script below prices the log so the choice is arithmetic, and prices the alternative the same way. A character the ROM prints costs 10 bits at 115,384.6 baud, 86.7 us each, so a code per self-test step printed over the UART would add hundreds of microseconds and move every later event; a GPIO write costs one clk_per register access, 281.25 ns. The monitor events cost the ROM nothing. Checkpoints and UART output stay under a kilobyte, an armed trace of the self-test and checksum accesses stays under a megabyte, and a full-signal dump of the boot, with illustrative signal counts, runs to gigabytes per run.

    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
    25
    26
    # Cost and log-volume budget. Simulated time is from the boot flow; the
    # speed, trace record size and signal counts are ILLUSTRATIVE teaching values.
    BOOT_US = 12580.917
    SYS_CYCLES = round(BOOT_US * 96) # clk_sys-equivalent cycles in one boot
    SPEED = 5000 # simulated cycles per wall-clock second, whole chip, no dump
    wall_s = SYS_CYCLES / SPEED
    uart_bytes = 16 # the ROM prints only the banner
    monitor_events = 12 # bench monitor lines, about 40 bytes each (illustrative)
    always_on_kb = (uart_bytes + monitor_events * 40) / 1024
    # what a ROM-side checkpoint would cost: a UART character against a GPIO write
    char_us = 10 / 115384.6 * 1e6 # 10 bits per character
    gpio_ns = 281.25 # one clk_per register access
    trace_bytes = 16 # one fabric access: address, data, strobes, response
    fabric_accesses = 5 + 7 + 64 + 2048 # self-test reads and writes, read-back, checksum reads
    armed_mb = fabric_accesses * trace_bytes / 1024 / 1024
    SIGNALS, ACTIVITY, BYTES_PER_CHANGE = 20000, 0.02, 6 # full dump from reset
    dump_mb = SIGNALS * ACTIVITY * BYTES_PER_CHANGE * SYS_CYCLES / 1e6
    print(f"boot: {SYS_CYCLES} cycles, {wall_s:.0f} s wall clock")
    print(f"always-on {always_on_kb:.2f} KB; armed trace {armed_mb:.3f} MB; full dump {dump_mb:.0f} MB")
    assert SYS_CYCLES == 1207768, SYS_CYCLES
    assert 240 < wall_s < 243
    assert always_on_kb < 1.0 and armed_mb < 1.0
    assert dump_mb > 100 * armed_mb # the check can fail: a dump is not a regression artefact
    assert abs(char_us - 86.67) < 0.01 and 64 * char_us > 5000 # 64 printed characters: 5.55 ms
    assert 5 * char_us > 400 and 5 * gpio_ns < 2000 # five step codes: 433 us on the UART, 1.4 us on GPIO
    print("PASS: 4 min per boot, log under 1 KB, armed trace under 1 MB, full dump in the GB range; a UART code costs 87 us, a GPIO write 281 ns")

    What the review looks for

    • The regression stores the bench monitor log and the captured banner with every result; a pass without its log is not a pass.

    • Armed tracing is reproducible from the checkpoint: the rerun command is documented, not improvised.

    • The nightly count of full-image boots is justified against the simulated-time budget, with short-image runs named.

    Verify and debug

    When a boot fails only in the nightly run and never locally, compare the images first: the short developer image skips exactly the stages that fail at night. When the log shows the failure but the trace window missed it, move the arming checkpoint one stage earlier rather than widening the trace. And when boot dominates the nightly budget, the answer is the faster platform of the emulation topic — not fewer boots.

    Verbose logging that hides the bug: full traces slow the run so much that timing-sensitive failures vanish, and the volume means nobody reads them. The three-level scheme above is the fix — checkpoints always, traces armed, dumps by exception.

    If asked how to debug a failing boot in simulation, answer checkpoints first, then armed traces from the last checkpoint, then a waveform window around the failure. Full-chip dumps from reset are the answer that fails the interview.

    Check yourself How many clk_sys cycles does one full boot simulate, and why does the number matter?

    1,207,768 (12,580.917 us at 96 cycles per us). It converts the 12.581 ms of simulated time into simulator work: at the illustrative 5,000 cycles per second it is about four minutes per boot, which prices the nightly budget and the move to emulation.

    Related topics

    • Bench Checkpoints and the ROM Self-Test

    • Hardware Debug: Emulation and FPGA Prototyping

    • Verification First Principles: Choosing the Platform

    Previous

    201 / 289

    Next: Performance Verification

    Up next

    Up nextPerformance Verification

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Running Boot Code Against RTL