registers

Registers: What to Emulate

Analysis of which CSRs and tile control/debug registers the emulator actually needs, based on what firmware accesses in practice.

Must Emulate (firmware breaks without these)

CSR: cfg0 (0x7C0)

Every firmware binary (BRISC, NCRISC, all TRISCs) writes this at startup via csrrs/csrrc. Always write-only in current firmware (rd=zero), so read-back value doesn’t matter today, but store it correctly anyway.

Firmware sequence (configure_csr()):

csrrs zero, 0x7c0, 2       # set bit 1 (DisBp)
csrrs zero, 0x7c0, 1<<18   # set bit 18 (DisTrisCache)
csrrc zero, 0x7c0, 2       # clear bit 1
csrrs zero, 0x7c0, 8       # set bit 3 (DisLowCash)

Bit fields:

For the emulator, only bits 30-31 have observable effects (they change FPU behavior). The rest control caches and branch prediction that don’t exist in the emulator.

SOFT_RESET_0 (0xFFB121B0)

Core launch sequencer. This must actually control which cores execute.

Boot sequence:

1. Host writes 0x47800 (all cores in reset)
2. Host writes 0x47000 (release BRISC only)
3. BRISC firmware writes 0x00000 (release all cores)

Bit assignments:

Key values:

• SOFT_RESET_ALL = 0x47800 — all 5 RISC-V cores held in reset
• SOFT_RESET_BRISC_ONLY_RUN = 0x47000 — TRISCs + NCRISC in reset, BRISC released
• SOFT_RESET_NONE = 0x00000 — all cores running

For the emulator, bits 11-14 and 18 (the five RISC-V cores) are the ones that matter. Bits 0-10 and 15-23 control coprocessor blocks and can be tracked but don’t need to gate execution.

RESET_PC Registers

Written by host during firmware upload to set each core’s boot address.

The OVERRIDE registers are 1-bit (NCRISC) or 3-bit (TRISCs) enables. When set, the core uses the programmed RESET_PC instead of the default reset vector.

Implementation: when a core is released from reset (SOFT_RESET_0 bit cleared) and its override bit is set, start execution at the corresponding RESET_PC value.

WALL_CLOCK (0xFFB121F0 / 0xFFB121F8)

TRISC firmware spins in riscv_wait(600) reading these at startup. If they return 0, TRISCs hang forever. Must be monotonically increasing.

There is also an alias at 0xFFB11024 (WALL_CLOCK_L in the TDMA region) which BRISC writes with value 63 during device_setup. The write likely initializes or configures the clock.

Implementation: track a global cycle counter. On read of WALL_CLOCK_0, return low 32 bits and snapshot high 32 bits into WALL_CLOCK_1_AT. WALL_CLOCK_1 returns live high bits. The counter should increment with instruction execution (doesn’t need to be cycle-accurate, just monotonically increasing).

Write-Sink No-ops (firmware writes, never reads)

These registers are written during BRISC device_setup() but control clock gating which is meaningless in an emulator. Accept writes, discard them.

Return-Zero Stubs (specified, not used by current firmware)

These are defined in the spec or in ckernel.h but no firmware binary in the current disassemblies reads them. Implement as simple registers that return 0 (or a sensible default). User kernels or LLK code may eventually use them.

Standard RISC-V counters

Worth implementing properly since user kernels might use them for profiling. Returning the wall clock counter for mcycle and an instruction counter for minstret would be faithful.

Tensix custom CSRs

For tt_cfg_qstatus and tt_cfg_bstatus, returning 0 means “not busy” which is correct for an emulator that executes coprocessor ops synchronously.

The tt_cfg_sstatus registers are scratch space for BRISC/NCRISC. For TRISCs they reflect stream state which would need real stream emulation to be useful.

Defer Entirely (profiler/debug only)

Not needed for functional emulation. Implement only if adding profiling or debug tool support.

Summary