Summary
sram_init preload (loading a program into SRAM at sim start — the natural way
to get an X-aware --xprop run of post-reset firmware without a debug-port
load) currently supports only the single-SRAM case. A design whose memory is
built from N SRAM macros — the usual byte-lane × bank split (e.g. a 32-bit
word striped across 4 byte-lane macros, several banks deep) — panics:
multi-SRAM preload is a future schema extension (issue #80)
(src/sim/sram_preload.rs). #80 is closed — it wired up single-SRAM
SramInitConfig — so the multi-macro extension is the remaining gap and is
otherwise untracked. Filing it explicitly.
Why it matters
X-aware cosim of debug-port-loaded firmware is fundamentally hard: the
JTAG/DM load path is full of uninitialised state (DTM CDC synchroniser flops, DM
command FSM, program buffer) that --xprop correctly reads as X, so the load
issues no SRAM writes and the CPU never sees valid instructions (see #102). The
clean way to X-aware-verify post-reset firmware execution is to preload the
program into defined SRAM and skip the debug load — but for any real SoC whose
memory is several macros, that path panics, so there is currently no way to do an
X-aware run of a multi-macro-memory design at all.
Ask
Extend sram_init to multi-macro memories: a schema mapping ELF/byte ranges to
(macro, address, byte-lane), and an apply that writes the values and
clears the sram_xmask across all targeted macros (mirroring the single-SRAM
fix in 296cc12). The macro/lane/bank decode could come from the config or be
inferred from the netlist's SRAM instances.
Repro
A design with an N-macro SRAM wrapper + sram_init.elf_path set → panic in
sram_preload.rs.
Summary
sram_initpreload (loading a program into SRAM at sim start — the natural wayto get an X-aware
--xproprun of post-reset firmware without a debug-portload) currently supports only the single-SRAM case. A design whose memory is
built from N SRAM macros — the usual byte-lane × bank split (e.g. a 32-bit
word striped across 4 byte-lane macros, several banks deep) — panics:
(
src/sim/sram_preload.rs). #80 is closed — it wired up single-SRAMSramInitConfig— so the multi-macro extension is the remaining gap and isotherwise untracked. Filing it explicitly.
Why it matters
X-aware cosim of debug-port-loaded firmware is fundamentally hard: the
JTAG/DM load path is full of uninitialised state (DTM CDC synchroniser flops, DM
command FSM, program buffer) that
--xpropcorrectly reads as X, so the loadissues no SRAM writes and the CPU never sees valid instructions (see #102). The
clean way to X-aware-verify post-reset firmware execution is to preload the
program into defined SRAM and skip the debug load — but for any real SoC whose
memory is several macros, that path panics, so there is currently no way to do an
X-aware run of a multi-macro-memory design at all.
Ask
Extend
sram_initto multi-macro memories: a schema mapping ELF/byte ranges to(macro, address, byte-lane), and anapplythat writes the values andclears the
sram_xmaskacross all targeted macros (mirroring the single-SRAMfix in 296cc12). The macro/lane/bank decode could come from the config or be
inferred from the netlist's SRAM instances.
Repro
A design with an N-macro SRAM wrapper +
sram_init.elf_pathset → panic insram_preload.rs.