Run-time errors using EMIF in Agilex 5 NIOS-V design

Hello,

My name is Radu, and I am investigating your question. 

It is a bit out of my expertise area, so I am trying to enlist some experts to help. Will get back to you in a day or two.

In the meantime, see below some suggestions coming from an AI assistant, as they may be helpful:

Connecting s0_axi4_ctrl_ready only to the Nios reset pin is not enough, and it is not a synchronized reset. ctrl_ready is an asynchronous EMIF output. If you feed it into the same Reset Controller  that drives core_init_n, calibration deadlocks. Use two Reset Controllers:

1. EMIF reset: ninit_done + board reset + PLL lock → core_init_n and the EMIF AXI4-Lite CSR reset only.
2. CPU/system reset: EMIF reset output and s0_axi4_ctrl_ready, synchronized to the Nios clock → Nios reset, ndm_reset_in, OCRAM, JTAG UART.

That still may not be the whole issue. Nios V/m instruction and data managers are 32-bit AXI4-Lite, and they are connected directly to a 256-bit LPDDR4 s0_axi4 through Platform Designer GENERIC_CONVERTER logic. .text, .rwdata, .bss, heap and stack are all in LPDDR4 at 0x80000000, so alt_load_section() is a DRAM-to-DRAM copy while the CPU is already fetching from DRAM. That matches   “works when single-stepped, fails at full speed.”

On Agilex 5 Fabric EMIF, unaligned access is not supported (ARADDR/AWADDR must be a multiple of 32 bytes). A 256-bit beat with ARSIZE < 5 is a narrow read. This device (A5ED065BB32AE4SR0) is in the  OPN set documented as not supporting narrow reads. The GHRD does not exercise this topology: it runs from OCRAM and reaches LPDDR4 through Address Span Extender.

Please capture SignalTap on s0_axi4 during the crash (clock = Nios/s0_axi4 clock):

•  ctrl_ready / s0_axi4_reset_n must stay 1
•  ARSIZE/AWSIZE must be 5, addr[4:0] must be 0, RRESP/BRESP must be OKAY
•  WSTRB for a 32-bit store must enable only one 4-byte lane

If ARSIZE is 2 or addr[4:0] is non-zero, the interconnect is issuing an unsupported EMIF transfer and reset changes will not make XIP reliable. In that case insert the GHRD-style Address Span Extender (32-bit datapath, one window, control port disabled) — or another upsizer that forces full-width aligned beats — between Nios and s0_axi4.

In parallel, please run a small OCRAM-only program (code, stack, and data in on-chip RAM) that waits for EMIF ready and then does 32-bit and byte-lane memory tests into LPDDR4 at full speed. Also set hal.linker.allow_code_at_reset=1 and point the OCRAM init file at this application; it currently still references the old MIPI hex.

If you can, please also report mcause, mepc, and mtval from the trap. I do not want to call a final root cause until the AXI traces confirm the beat shape.

Thank you,
Radu