Key Manager (KM)

The Key Manager is configured through its ROM and SRAM sizes, the mailbox FIFO depth, the read-data behaviour of its memories, and the address of the eFuse controller. The main KM SRAM is 32 KB (8192 × 32-bit words), implemented with the scrambler macro scrambler_8192x32. The SRAM macro must return read data (rvalid) at least one cycle after the cycle in which it grants the read, because the SRAM interface descrambles and parity-checks each response with the address and byte strobes it captures at the grant.

The parameters of key_manager are listed in key_manager.

Figure 2 shows how cold and warm reset requests are conditioned for the Key Manager.

Each reset net keeps its own colour. The cold and warm outputs of u_reset_conditioner run in two spines beside the instances, with the port name at each instance edge. A solid warm line drives a reset pin; a dashed warm line is a synchronous clear, which the instance samples on clk_i rather than using as a reset. Junction dots mark fan-out, and a gap in a line marks a crossing without connection. In test mode, test_en_i selects scan_rst_ni in both scan multiplexers.

Cold and warm resets have different scopes. Warm reset restarts the CPU and its control interfaces while retaining cold-domain state and memory contents. Retention across warm reset does not make SRAM or registers non-volatile, and reset must not be treated as a key-data wipe.

Table 1 identifies the two external reset inputs and their SEP connections.

SEP isolates the Key Manager’s AXI paths before asserting the warm reset; see Resetting the Key Manager.

km_reset_conditioner produces two active-low outputs:

scanmode_i selects scan_rst_ni to override both paths for DFT. Table 2 identifies resettable state; it does not imply that key-data flops or memory arrays have reset values.

The internal AXI4-Lite fabric and generated register CPU interfaces reset on warm reset, discarding their in-flight transaction state. This is an internal reset boundary, not a completion or cancellation guarantee for an external accelerator transaction. Mailbox FIFO contents survive warm reset; ROM flushes the mailbox during boot before accepting new commands.

Writing 0x53525354 (ASCII "SRST") to KMCSR SOFT_RST_CODE triggers the warm path. BOOT_STATUS.COLD_BOOT_DONE survives it: ROM sets this flag after cold-boot initialization and reads it on subsequent boots to distinguish warm restart from cold initialization.

The mailbox is a raw 32-bit word transport with two FIFOs: inbound SEP-to-KM and outbound KM-to-SEP, each at least 16 words deep. Hardware does not parse commands, validate CRCs or enforce key policy. Firmware defines the framing in Table 3 and Table 4; use the firmware reference for command legality, sequencing and error responses.

Command/response messages without a data payload (message_length = 0x00) drop the payload CRC32 and only contain the header (Table 4).

Each FIFO word carries a separator bit that the sender sets on the last word of a message. The receiver uses it with the header length to check framing. Reads pop words; writes push words. Status reports fill level and empty/full conditions.

A write to a full FIFO drops the incoming word without changing queued data. An empty read has no data to consume. Both return SLVERR by default, with configuration allowing OKAY, and set the corresponding sticky overflow or underflow status. Each side has write-one-to-trigger flush control: either side flushes both FIFOs and sets the peer’s flushed-by-other status.

Each side independently enables its interrupt sources. Receive-data-available and transmit-space-available are level conditions; overflow, underflow and peer-flush are sticky conditions. Their enabled OR drives one interrupt to each side: directly to the KM CPU for the KM side, and to the SEP interrupt controller for the SEP side. KM firmware validates received words before executing a command and uses the outbound FIFO for responses and fault notifications. Error handling and resynchronization are firmware operations, not hardware command filtering.

Figure 3 shows the mailbox paths used for SEP commands and Key Manager responses.

The KM CPU enters at the top and the SEP host at the bottom. Each side’s decode sends its WRITE_DATA address to a FIFO push and its READ_DATA address to a FIFO pop, and every other address to its own register block. Words therefore travel upwards through u_inbound_fifo and downwards through u_outbound_fifo. Each register block reads the status of both FIFOs, and a FLUSH from either block clears both of them. MAILBOX_DEPTH sets the depth of each FIFO; SEP instantiates the KM with 16 words.

Keys reside in the KPV and reach accelerator sideload registers through the KM-mastered key path. Host-supplied material enters through mailbox commands; generated secret material is not returned through a direct host read path. The generated Section 3.1 defines the KM’s allocated windows.

Figure 4 separates the key-delivery path on the top row from the host-accessible data path on the bottom row. This separation does not establish resistance to physical fault injection or side-channel attacks. Firmware’s key-data CRC detects corruption; it is not a substitute for access control or a physical-attack guarantee.

The figure shows one engine wrapper; <eng> stands for otbn, aes, kmac or hmac. The KM port for that engine (otbn_req_o, aes_req_o, kmac_req_o or hmac_req_o) is a point-to-point 32-bit AXI4-Lite path. It passes only through u_<eng>_key_isolate in sep_crypto_axi_interconnect, which drains the path when sep_reset_ctrl requests isolation, and ends on the wrapper’s generated <eng>_wrapper_key_reg block. The KEY_SHARE0 and KEY_SHARE1 words are write-only, and reads return zero. The two shares and KEY_CTRL.KEY_VALID drive the engine’s keymgr_key_i sideload port; the XOR of the two shares is the key. The shares are 8 words each, or 12 words for OTBN.

The SEP host reaches the engine’s own registers on a separate path: the crypto interconnect demultiplexes the 64-bit AXI4 host bus in u_axi_demux, converts it to 32 bits in u_<eng>_axi_dw_converter and to AXI4-Lite in u_<eng>_axi_to_axi_lite, and passes it through u_<eng>_host_isolate, and the wrapper bridges it to the engine’s TL-UL port. isolate_req_i from sep_reset_ctrl drives both isolation stages. The host path does not reach the key registers, and the KM path does not reach the engine’s control registers. Adams Bridge follows the same pattern through u_abr_key_isolate and abr_wrapper_key_reg, where sep_abr_kv_shim turns the registers into Adams Bridge key-vault reads (see Section 1.5).

The KM provides dedicated sideload interfaces to the Adams Bridge (ABR) post-quantum engine, exposed as a single AXI4-Lite register block mapped at 0x0001_C000–0x0001_C7FF. The block has two directions: four seed inputs the KM drives into ABR, and one shared-key output ABR drives back into the KM.

Seed sideload inputs (KM → ABR). The four seed inputs carry key material the KM side-loads into ABR (Table 5).

Each seed uses the two-share masked layout (two key-share register banks whose XOR is the real value, plus a key_valid bit) and is write-only to KM firmware. The seeds are valid dest_valid destinations (bits 4–7), so they are targets of CMD_KEY_TRANSFER and CMD_ENGINE_SHRED, and ROM shreds them during the mutable-firmware handover. Word order matches the other engines: share word i is word i of the seed the engine consumes, as stated in ABR seed word order.

ML-KEM shared-key output (ABR → KM). ABR computes an ML-KEM shared key and presents it to the KM. The interface comprises a 256-bit (8-word) key register array, a KEY_CTRL register holding key_valid, and an IRQ_STATUS / IRQ_ENABLE interrupt pair.

The KM firmware ISR acknowledges the IRQ by clearing IRQ_STATUS and flags the main loop; it does not consume the key. The shared key is later captured into a KPV slot in response to a SEP CMD_ABR_SK_TRANSFER command (see the firmware documentation).

The PicoRV32 receives three separate external interrupt groups:

KMCSR IRQ_SET injects its corresponding status events for ISR testing. Mailbox and Adams Bridge interrupts retain their own status/enable controls. The CPU’s interrupt mask is an additional level of control. A reported event, an enabled interrupt and a CPU trap are distinct; see Unrecoverable Faults.

The SEP host submits key-load and key-transfer commands through the mailbox. The Key Manager validates the request and policy before accessing the vault or delivering key material to a cryptographic engine.

Figure 5 shows the command, validation, vault-access, and key-delivery sequence.

Time runs downwards. Each arrow is a mailbox word push or pop, a register write or read, or an interrupt, and each white box is a check or action the KM firmware performs without leaving the CPU. The figure shows the success path. A failed check ends the command with a RESP_CMD error code and leaves the KPV and the key registry unchanged.

On a key load, the firmware registers the handle before it writes the KPV, and destroys the handle again if a KPV write fails. On a key transfer, the firmware reads the key slots twice: once to check their CRC-32C against the key registry, and again to write the key. Each requested engine receives the key as two key shares whose XOR is the key, the first a DRBG mask, before its key-valid bit is set. The engines are written in the order of their DEST_ENGINE bits, and the first failed write ends the transfer.

The KPV exposes 64 slots through one KM-only AXI4-Lite interface. Each slot contains 512 bits (16 words) of key data and a 32-bit CTRL register. Multi-slot keys, such as RSA3K material, require consecutive slots; the firmware registry tracks the span and the used words in the final slot. Hardware has no span field.

The lock/seal bits clear on warm or cold reset. Erase uses the shared scrambler and key-data write port, so key-data accesses during an erase are not defined. The KPV driver in the Key Manager Application ROM appendix of the Programmer’s Guide gives the erase sequence.

Sealed and retired slots. A slot with seal set is sealed: readable, but not writable, because hardware holds lock_write set alongside the seal. That surviving lock_write is evidence that the slot holds what it held when the seal was taken, which is what lets firmware that inherits the vault after a handover trust material provisioned before it. A write lock on its own would prove nothing, since an erase clears it and frees the slot to be rewritten with chosen material and re-locked.

Erasing a sealed slot is still permitted, and leaves it retired: lock_write held, lock_use set, seal still set, and the data destroyed. A retired slot can be neither read, rewritten nor reused until the next warm reset, and repeating the erase changes nothing. Revocation and reuse are therefore separate: firmware can destroy a sealed key it no longer trusts without handing the slot to whoever asked for the destruction.

An emergency wipe also releases sealed and retired slots by clearing key data and all CTRL bits. The safety of that release depends on CPU containment: a trap already halts the CPU, whereas an externally requested wipe requires firmware or host coordination (Section 1.10). Do not assume that asserting wipe_state_i directly halts CPU execution.

CTRL resets to zero. Key-entry data flops have no reset value and power up undefined; cold or warm reset alone does not overwrite their contents.

The KPV supports address and data scrambling during normal operation for all key entry data reads and writes, using the same PRESENT-based approach as SRAM scrambling. When enabled, the stored representation of key data is scrambled; the KM port sees the logical (unscrambled) data on the bus, with scrambling/descrambling performed transparently by the KPV.

The KPV has a scrambler key register (32-bit) and a scrambler control register with an enable bit and a lock bit. These registers are accessible only via the KM port. The lock bit is write-one-only (0→1): software sets lock by writing 1; writing 0 has no effect; lock cannot be cleared until the next cold KM reset. The KPV scrambler enable and lock are state in the cold reset domain — they are preserved across a warm reset and cleared only by a cold reset. Scrambling is disabled by default after a cold reset.

When scrambling is enabled, the KPV uses the same scrambler algorithm as SRAM but sized for 1024×32 words (64 slots × 16 words). The scrambler address input is the linear register index (0..1023): slot_index × 16
word_index. Address scrambling maps the logical index to a scrambled physical storage index. Data is scrambled before storage and descrambled after retrieval. Only key entry data words are scrambled; CTRL registers are not scrambled.

The KPV scrambler key register has no reset value (powers up random/undefined for security). The scrambler control register (enable and lock) resets to 0. On an emergency wipe (rising edge of wipe_state), the entire KPV is reset to zero including key data, control registers, and the KPV scrambler key and control registers.

Hardware forms a wipe event from wipe_state_i | cpu_trap and detects its rising edge. The resulting pulse clears all 1024 KPV data words, all 64 slot CTRL registers, and KPV scrambler key/enable/lock state on the clock edge. It also records the KMCSR wipe event. This hardware action covers the KPV; it does not itself scrub SRAM, mailbox data or accelerator sideload registers.

In SEP, sep_cpu_ctrl.KM_WIPE_CTRL.wipe_state drives the external input. Hold it high for at least one complete KM clock period. Return it to zero before requesting another rising edge; the software-controlled registered level provides the required hold. SEP does not connect a hardware tamper or alarm source to this input. A CPU trap independently triggers the same KPV wipe and asserts unrecoverable_err_o while the CPU is halted.

An external wipe does not force a CPU trap in hardware. The ROM enables the wipe interrupt and treats it as an unrecoverable fault, but that response depends on interrupt delivery and execution of its handler. Software that masks the event or replaces ROM must not assume the CPU has stopped. The host/integrator must prevent continued use of the released vault after an external wipe until recovery resets the CPU. Warm reset clears the trap and re-enters ROM; it is not itself the KPV data erase mechanism.

The complete KM is Class 2 under SEP’s scan-chain protection policy: processor, vault, KMCSR, mailbox, entropy sampler, scramblers, internal fabric, reset logic and register blocks. Including non-secret control state avoids relying on a per-register classification.

KM-local copies of the UIDs, class key and public identities clear on cold and warm reset (including firmware soft reset) and reload from the shadow bus after release. Lifecycle/demotion captures persist across warm reset. Firmware access locks are independent of scan protection.

Writable KM SRAM is a Class 2 companion memory because it can retain key, message and firmware working state. Its memory-test policy must also forbid dump. Immutable ROM cannot retain runtime secrets and is excluded. These requirements define the integration boundary; the local KM RTL alone does not establish implementation of the external DFT controller.

KMCSR manages interrupts, reset requests, execution permissions, memory protection and OTP shadow readout. It is separate from the KPV and DRBG sampler banks. km_csr supplies the behavior around generated km_csr_reg; Section 3.2.2 supplies every offset and field definition. The operating contracts below supplement that generated map.

The VERSION register (offset 0x000) is a read-only register that reports the Key Manager hardware revision using semantic versioning. It uses the following canonical 32-bit layout, mandated so all software and testbenches decode the version identically (Table 8).

The current hardware revision reads as version 1.0.0 (MAJOR=1, MINOR=0, PATCH=0) after reset with no software initialization. The register is read-only: a write completes with an AXI SLVERR response and does not change the value.

The interrupt aggregation logic collects twelve hardware event sources into a single CPU interrupt. Each source has a sticky status bit in IRQ_STATUS (write-one-to-clear), a mask bit in IRQ_ENABLE, and a software-trigger bit in IRQ_SET for ISR testing. The aggregated interrupt output is the logical OR of the masked status bits (IRQ_STATUS & IRQ_ENABLE).

Table 9 maps hardware events to the sticky interrupt-status bits.

Bits [31:12] of IRQ_STATUS are reserved. Two interrupt sources are not part of the KMCSR IRQ_STATUS aggregation and are serviced separately: the mailbox sources (FIFO data-available/space-available and overflow/underflow/flush conditions), and the Adams Bridge ML-KEM shared-key interrupt on its own PicoRV32 interrupt (bit 5, see Section 1.5).

The CPU IRQ entry vector is programmable through two registers. IRQ_ENTRY_ADDR holds the effective IRQ entry address and resets to the built-in default 0x0000_0010; firmware may write any 32-bit value (the hardware performs no alignment or validity checking) and the register is always readable, returning the current effective entry address. IRQ_ENTRY_LOCK is a write-one-only lock bit that can only transition from 0 to 1: while it is 0 firmware may reprogram IRQ_ENTRY_ADDR freely; once it is 1, writes to IRQ_ENTRY_ADDR are ignored (the value remains readable and unchanged) and further writes to IRQ_ENTRY_LOCK have no effect. Both registers are in the warm reset domain: every reset that re-enters ROM (cold, external warm, and KM soft reset) restores IRQ_ENTRY_ADDR to 0x0000_0010 and clears IRQ_ENTRY_LOCK.

SRAM_LOCK controls writes to 32 SRAM regions of 1 KB each; see Section 1.18 for reset and handover policy. SRAM scrambling key/enable/lock state is cold-domain state and survives warm reset. The soft-reset code and cold-boot flag are described under Reset Conditioning.

Execute-Permission Whitelist (NX)

The PicoRV32 enforces a whitelist of executable memory regions on every committed instruction fetch (mem_valid && mem_instr). Any fetch from outside the whitelist immediately pulses KMCSR.IRQ_STATUS.EXEC_VIOLATION, which (if unmasked) routes to the ISR and triggers the unrecoverable fault ROM_KM_UFAULT_EXEC. A ROM fetch refused by the ROM lockout described below is reported on ROM_ACCESS_VIOLATION instead, so the two bits are disjoint.

The whitelist mode is controlled by the KMCSR.SRAM_EXEC_MODE.enable bit (write-1-only, warm-reset domain) (Table 10).

The fetch-region index is a plain slice of the byte address, which works only because the SRAM base (0x0000_8000) is aligned to the SRAM size; it is the same slice km_sram_interface uses to check data writes, so the two views of a region can never disagree.

For the define and the builds it is rejected in, see Key manager defines in the Integrator Guide.

SRAM_EXEC_MODE.enable is set by the stack-less handover assembly (rom_handover_jump.S) immediately before the jalr to mutable firmware, after SRAM write-lock regions have already been committed. This minimises the window between enabling SRAM execution and the first fetch from SRAM. The bit is write-1-only and cleared by warm reset, so the ROM-only whitelist is re-applied on every boot cycle.

ROM Lockout

Setting SRAM_EXEC_MODE.enable exchanges the ROM for write-locked SRAM rather than adding to the whitelist. Were it purely additive, mutable firmware would inherit read and fetch access to the ROM that handed control to it, leaving the ROM’s key-management routines and its rom_persist structure reachable by code the ROM does not trust.

The exchange is staged so that the handover can complete. Writing the bit only arms the lockout; the lockout engages on the first committed instruction fetch from a write-locked SRAM address, which is the point at which mutable firmware actually begins executing. Everything the handover assembly runs after its arming store — the store itself, the register clears, the jalr — is ROM code, and remains legal precisely because the lockout has not engaged yet. Engaging on a fetch rather than on any ROM access also keeps the rule independent of incidental data traffic: ROM code reads rom_persist, which itself lives in a write-locked SRAM region.

Once engaged, the lockout blocks ROM instruction fetches and ROM data reads until the next warm or cold reset. The latch is in the warm reset domain, the same domain as SRAM_EXEC_MODE.enable, so the transition is one-way within a boot and every reset that re-enters ROM restores ROM access. ROM writes are unaffected and continue to raise ROM_WRITE_ERR.

Blocked access behaviour. A blocked access returns zeros; ROM content is never delivered. What follows depends on the access type:

The two reports are ordered by causality rather than by arbitration. The violation is combinational in the cycle of the blocked access, whereas the illegal instruction cannot be detected until the zero word has been returned and decoded, which is strictly later. Since IRQ_STATUS is sticky, the violation bit is always recorded first.

Which mechanism acts depends on the interrupt mask, and after handover only one does. Handover leaves all CPU interrupts masked, so the illegal instruction takes the PicoRV32 trap state rather than an interrupt: the core halts, unrecoverable_err_o asserts, and the KPV is wiped. The ROM_ACCESS_VIOLATION interrupt is inert in that state — it sets its sticky bit but has nowhere to vector, because the ROM ISR it would have vectored to is itself in the ROM the lockout has just revoked. A real post-handover breach therefore halts the KM without emitting a mailbox fault code; ROM_KM_UFAULT_ROM_ACCESS is reportable only while the ROM is still live (via IRQ_SET) or through a vector that mutable firmware installed itself.

Both mechanisms are retained because they do different jobs. The violation bit is the diagnostic that distinguishes a lockout breach from any other illegal-instruction halt; the trap is the containment, and it requires no firmware cooperation, no enabled interrupt, and no reachable handler.

Error Events

Unrecoverable Faults

These events cause the CPU to halt when the corresponding interrupt is unmasked and the ISR determines recovery is not possible. They include, but are not limited to, the following conditions:

The PicoRV32 includes a trap state that asserts a trap signal. When the CPU enters this state execution halts. The CPU will enter this state under the following conditions:

If an ISR determines that an error event is not recoverable, it will call the EBREAK instruction to trap and halt the core. The CPU trap signal is passed out of KM to indicate an unrecoverable fault. This signal indicates the KM has encountered an unrecoverable fault and is no longer executing (it will not respond to further commands). The signal remains asserted for as long as the KM remains in the trap state. The trap is cleared by resetting the KM CPU — either a cold reset or a warm reset (the PicoRV32 core is in the warm reset domain) restarts the core and clears this signal.

Recoverable Faults

These events do not cause the CPU to halt. They include:

The KM provides an output signal that indicates when a recoverable fault has been successfully handled. This signal is driven by a dedicated register bit in the KMCSR. When an ISR recovers gracefully from an error, it sets this register bit. The bit remains set until the SEP sends a firmware command to the KM to clear it (KM firmware clears the register bit in response to that command).

The sampler bridges a CPU DATA read to the selected 32-bit entropy stream. It is an AXI4-Stream sink: TREADY is an output, and TVALID, TDATA[31:0] and TSTRB[3:0] are inputs. Availability is not guaranteed; a pending read waits for a word or an enabled timeout.

The KM consumes OTP-derived material over a private hardwired bundle so the values cannot be spoofed by software. SEP dual-rail-encodes each 256-bit field at the SEP-to-KM boundary ({~value, value}) from the sensed eFuse shadow:

UID delivery and protection. The UIDs are held in a KM-local copy. The KM’s own warm-domain read-lock protects that copy at mutable-firmware handover (see UID provisioning and access) so mutable firmware cannot read it. This KM-local lock is separate from, and additional to, the eFuse controller’s own locks.

Public identity delivery. The three public identity fuses take the same dual-rail encode as the secrets. They remain on the KM port in secure test mode: the eFuse controller blanks only the four secrets on the hardware shadow output. The eFuse per-field read-lock bits (LOCKS[59], [61], [63]) hide software and JTAG shadow reads; they do not blank the hardwired KM port. The KM’s own OTP_READ_LOCK and OTP_READ_LOCK_COLD bits zero the KMCSR readout words only.

Life-cycle state. The life-cycle state is hardwired into the KM as authoritative, software-readable status. Being non-secret it is neither locked nor wiped. The key registry does not bind keys to it.

eFuse access path. The KM also has a programmatic (AXI-Lite) path to the eFuse controller — for example to request a read or a program operation. That path is treated exactly like a system-host access: same access filtering, and it honors the eFuse controller’s native per-field read/write locks, so the KM gains no read privilege over the fuse array beyond the SEP host’s.

Demotion and PCR. The owner demotion state is hardwired from the Life Cycle Controller (LCC). A PCR Vault (PCRV) and PCR-change interrupt are not present in this integration.

KMCSR readout registers. The OTP-derived fields above are exposed to KM firmware in the KMCSR region as hardware-driven, read-only registers. Each field is delivered to the KMCSR as dual-rail complementary values ({~value, value}) and decoded within the KMCSR, which continuously verifies the complement relationship.

Table 13 lists the OTP-derived fields exposed to Key Manager firmware.

Dual-rail integrity. The hardware continuously checks that each value word is the bitwise inverse of its complement word. Any violation raises the OTP_SIGINT interrupt, which ROM firmware treats as an unrecoverable fault. This applies to the public identity fields as much as to the secrets.

Change detection. When a monitored field’s decoded value changes, the hardware sets the corresponding OTP_CHANGE_STATUS bit and raises the OTP_CHANGE interrupt. ROM firmware reads the status, invokes an overridable change hook, and clears the flag. Spurious change events are suppressed until the capture history is valid after cold or warm reset.

Unique Identifiers (UID) — provisioning and access

The KM receives three fuse-provisioned Unique Identifiers — CHIPLET_UID, SIP_UID, and SYS_UID (256 bits each) — provisioned respectively by the chiplet creator, the SiP owner, and the system owner. ROM does not derive keys from them.

The CPU services mailbox commands from ROM and supports loading and executing SRAM firmware. Before handing control to that firmware, ROM applies the OTP read locks and wipes secrets from the shared execution environment. A warm reset returns the CPU to ROM, where the handover protections are re-established.

Concretely, this safeguard is the OTP_READ_LOCK register: one write-one-to-set bit per OTP readout field (life-cycle, demotion, the four 256-bit secrets, and the three 256-bit public identities). Setting a bit causes the hardware to return zero for that field’s value and complement words. ROM applies the lock using a triple-write convention (three consecutive writes) so it commits even under a single-bit glitch. OTP_CHANGE_STATUS shares the same warm reset domain for the same reasons.

ROM does not lock the public identity fields at handover, since concealing them buys nothing. Their lock bits suppress KMCSR readback like those of the secret fields.

A parallel cold-reset-domain register, OTP_READ_LOCK_COLD, provides the same write-one-to-set, per-field locking semantics but survives warm reset (including soft reset) and is cleared only by cold reset. The effective read-lock for each field is the OR of the corresponding bits in OTP_READ_LOCK and OTP_READ_LOCK_COLD; either register alone is sufficient to suppress CSR readback. The SEP host can set cold-domain lock bits at any time by issuing CMD_OTP_READ_LOCK_COLD (0x28) over the KM mailbox. This allows the SEP host to establish read-locks that persist across warm resets for the entire duration of a power cycle, independently of the warm-reset lock applied by ROM firmware.

The KM CPU is fitted with a CRC accelerator attached through the PicoRV32 PCPI (Pico Co-Processor Interface). It provides hardware versions of the CRC functions the firmware uses on its high-value integrity paths — message header CRC-8/ROHC, message payload CRC-32C, and key-data integrity CRC-32C — so these computations consume far less CPU time than a software loop. The accelerator is always present in the KM build; firmware invokes it unconditionally and does not retain a software fallback path.

The accelerator exposes three R-type custom instructions on the PicoRV32 custom0 opcode. Each instruction takes two operands — the current CRC chaining state (rs1) and the next input unit (rs2) — and writes the updated chaining state to rd.

Table 14 lists the instruction encodings and input units for the hardware CRC updates.

Behavioral properties:

The three instructions share a single byte-update datapath. CRC-32C word mode runs four byte-update cycles per operation; the two byte modes run one cycle each. The datapath uses reflected CRC update behavior with the reflected polynomial 0x82F6_3B78 for CRC-32C and 0x0000_00E0 for CRC-8/ROHC (the reflection of the 0x07 CRC-8/ROHC polynomial), and never applies the CRC-32C final XOR. The CRC parameter definitions (init, reflection, and final XOR) are given in the firmware CRC function library documentation.

Any other encoding in the custom0 CRC instruction family is not recognized by the accelerator: it does not assert the PCPI ready/wait/write handshakes, so PicoRV32’s normal illegal-instruction handling is preserved. The feature introduces no new top-level KM ports or CSRs, and the PicoRV32 built-in multiply/divide support remains enabled and unchanged.

ROM and SRAM use one odd-parity bit per byte: four parity bits accompany each 32-bit data word. Checking cannot be disabled and performs no correction. Interrupt enables control reporting to the CPU; masking an event does not repair the affected data or make it safe to use.

Parity bits are stored out-of-band, outside the scrambled data word. This keeps parity storage separate from the scramble/descramble data path.

The SRAM interface incorporates a write-locking mechanism to designate specific 1 KB memory regions as read-only; 32 regions cover the whole 32 KB SRAM, one per SRAM_LOCK bit. This feature is primarily designed to protect dynamically loaded KM firmware from unauthorized modification.

Control of this functionality resides within the Key Manager Control and Status Registers (KMCSR). Once a memory region is locked, it cannot be unlocked within the current boot session. It will remain in the read-only state until the next warm or cold reset of the KM. The write-lock state is in the warm reset domain and is cleared on every warm or cold reset.

Protection across warm resets is maintained by the ROM, which is responsible for re-applying the full write-lock policy on every boot (both cold and warm) before handing control to mutable firmware. Because the KM CPU always re-enters ROM after a warm reset, mutable firmware never executes against an unlocked SRAM region.

The highest 1 KB of KM SRAM (region 31, 0x0000_FC00–0x0000_FFFF) are reserved as a ROM-managed warm-persistent data structure (rom_persist). The mutable-firmware load area, stack, and BSS/data occupy the SRAM below it.

This region is owned exclusively by ROM firmware: it holds ROM state that must survive warm reset and is not general-purpose scratch for mutable (SRAM-loaded) firmware. Mutable firmware must not place its own data here, and once ROM write-locks the region it cannot write it at all (see Write-lock policy below).

SRAM contents survive warm or soft reset. Reset of the memory interface does not itself specify an array erase. ROM carries state across warm resets and initializes this structure on cold boot; this is volatile SRAM retention, not non-volatile storage.

Cold initialization. On every cold boot, rom_boot_init() detects a cold boot via the COLD_BOOT_DONE flag (reads 0 before it is set at the end of boot) and calls rom_persist_cold_init(), which writes known-zero values to all fields. On a warm or soft reset, COLD_BOOT_DONE already reads 1 and rom_persist_cold_init() is skipped, preserving the contents of the region.

Contents. The rom_persist_t structure currently contains one field (Table 15).

Write-lock policy. Before handing control to mutable (SRAM-loaded) firmware, ROM must call rom_persist_lock(), which sets SRAM_LOCK bit 31 via a triple write for glitch resistance. After locking, any write into 0xFC00–0xFFFF is silently dropped and a SRAM_WRITE_LOCK_VIOLATION IRQ is raised. The lock is cleared on the next warm or cold reset; ROM re-establishes it before transferring control to mutable code.

The KM ROM can load a mutable image into SRAM and hand control to it, through the CMD_SRAM_LOAD_EXEC and CMD_SRAM_EXEC mailbox commands. The image is loaded at 0x8000, which is also its entry point, and must fit below a static load ceiling aligned to a 1 KB write-lock region, so the image never shares a region with the ROM stack or data. The load bounds, the key shred, the KPV read-lock, the image write-lock, the mailbox flush, the SRAM scramble and the jump are ROM behaviour, defined in the SRAM Firmware Handover sequence of the Key Manager Application ROM appendix in the Programmer’s Guide.

The handover relies on the following hardware behaviour:

Scrambler

The KM CPU addresses its internal peripherals through a flat 32-bit address space. The AXI4-Lite crossbar decodes the address and routes transactions to the corresponding slave port.

Every window except OTP/eFuse spans exactly the address bits its register block decodes, so no register is reachable from a second address. The last two columns of the map state how the crossbar and the register blocks answer an access that no register or memory backs, and Decode Response Codes defines them and their codes. The KM CPU does not see these responses: an error sets AXI_SLVERR or AXI_DECERR in the KMCSR IRQ_STATUS register.

The OTP/eFuse window is the exception: hardware preserves its lower 12 address bits and replaces the upper bits with the integration parameter OTP_EFUSE_REMAP_BASE before forwarding the transaction to SEP. Only the MAP, CTRL and MMR register maps are forwarded. The Key Manager answers any other offset in the window with SLVERR, so the KM CPU cannot reach the eFuse shim control registers.

^[1] A write completes without an error response, is dropped, and sets IRQ_STATUS.ROM_WRITE_ERR.
^[2] This range is inside the OTP/eFuse window, which answers every offset outside its register maps with SLVERR and read data 0xBADCAB1E rather than DECERR.