Forum Discussion
otto-Q
New Contributor
1 hour agoNios V/g load-writeback hazard
Summary
On a NiosV/g core, a long-latency load from an on-chip memory immediately followed by a short-latency load from the core's own TCM returns the TCM load's data in both destination registers. The first load's writeback is lost.
lw a0, 0(t0) # t0 -> On-chip memory
lw a1, 0(t1) # t1 -> DTCM (core-local) # a0 and a1 both end up holding the DTCM value
Inserting a single instruction between the two loads is enough to avoid it. Two on-chip memory loads back to back are fine, and so is the reverse order (TCM load first, then the on-chip memory load).
Minimal reproducer
Assembly:
_start:
lui t0, 0x40 # t0 = 0x00040000 on-chip memory ("input memory")
lui t1, 0x10 # t1 = 0x00010000 DTCM (core-local)
lui t2, 0xe0 # t2 = 0x000e0000 2nd on-chip memory ("output memory")
li a2, 0x47414c47 # a value distinct from the DTCM sentinel
sw a2, 0(t0) # ...store it into input_mem
nop # let the store retire. The hazard is about two
nop # adjacent *loads*; keep everything else well
nop # clear of the pair below so the test stays
nop # unambiguous.
lw a0, 0(t0) # long-latency load: on-chip memory (input memory)
lw a1, 0(t1) # short-latency load: DTCM, immediately after
sw a0, 0(t2) # output_memory[0] = result of the AXI load
sw a1, 4(t2) # output_memory[1] = result of the DTCM load
spin:
j spin
System details
NiosV/g data_manager (AXI master) is directly connected to on-chip memories and pipeline stages are limited to 3 in Platform Designer.
1 Reply
- otto-Q
New Contributor
This was found in Quartus 25.3 and has not been tested in newer versions