System Console master_read_memory fails above 7688 bytes on Agilex 5 (AXE5-Eagle)

A single master_read_memory of 7689 bytes or more never completes on an Agilex 5. It returns nothing, times out after 60 seconds, and leaves the JTAG channel closed so the next command fails too. 7688 bytes on the same master and the same address returns all 7688 values in under 0.1 second. The boundary is byte exact and repeats every time.

I can reproduce this entirely with an unmodified example bitstream published by Arrow, so no design of mine is involved and there is nothing for me to send you.

SETUP

• Board: Arrow AXE5-Eagle, device A5ED065BB32AE4SR0, IDCODE 0364F0DD
• Bitstream: axe5_eagle_voltage_temp.sof from https://github.com/ArrowElectronics/Agilex-5, path images/promo3/, md5 b391b9cd5226fe92fd2068ddc66f8442
• That bitstream was built with Quartus Prime Pro 24.3 and reports "HPS present: FALSE", so it configures straight over JTAG with no bootloader merge and no HPS involvement. It exposes a Nios V node and a JTAG PHY master.
• Tools: Quartus Prime Pro 26.1.1 build 130, System Console from the same installation, Windows 10 Enterprise LTSC 21H2
• Cable: Arrow USB Blaster ARA39943-TEI0004, JTAG clock pinned to 6 MHz, Altera JTAG Server running as a Windows service

STEPS

1. Program the board over JTAG:

quartus_pgm -c "Arrow-USB-Blaster [ARA39943-TEI0004]" -m jtag -o "p;axe5_eagle_voltage_temp.sof@1"

2. In System Console, open the JTAG PHY master and read:

set m [lindex [get_service_paths master] 0]
open_service master $m
master_read_memory $m 0x0 7688
master_read_memory $m 0x0 7689

RESULT

master_read_memory  7688 bytes -> 7688 values in 0
master_read_memory  7689 bytes -> nothing, 60.0 s, then:                                                                                             master_read_memory: This transaction did not complete e is giving up.

After the failure the channel is closed and the next command reports "Channel closed" until the service is reopened. Recovering costs 20 to 60 seconds.

WHAT I HAVE ALREADY RULED OUT

• Not the address. Identical behaviour reading from 0x0, 0x1000, 0x10000000 and 0x20000000, and shifting the base by 1, 2, 4 or 4092 bytes at a fixed size changes nothing. Only the requested byte count
• Not a timeout. Reads return in 0.0 s right up to 7688, then the very next byte fails. A timeout would show times rising as the limit approached, not an instant success becoming an outright fa
• Not the size of the reply. master_read_32 hands back a 45055 character answer without trouble, while master_read_memory fails while producing a 39044 character one.
• Not the design. The same byte boundary appears on two other unrelated bitstreams on this board, one with an HPS and one without, built with different Quartus versions. The Arrow example above is simy.

master_read_32 IS NOT AFFECTED, AND HAS NO COMP

On the same master and the same bitstream, master_read_32 was run at increasing sizes. Every one returned the full count, correctly, with no timeout and no channel closure:

master_read_32 $m 0x0   4096  ->   4096 words,   16 kB spanned,  0.5 s
master_read_32 $m 0x0   8192  ->   8192 words,   32 kB
master_read_32 $m 0x0  16384  ->  16384 words,   64 kB spanned,  2.2 s
master_read_32 $m 0x0  32768  ->  32768 words,  128 kB
master_read_32 $m 0x0  65536  ->  65536 words,  256 kB spanned,  9.8 s

That last one spans 262144 bytes, which is 34 times theead_memory cannot deliver, and it scales linearly at about0.15 ms per word with no sign of a ceiling. If the JTAG link, the Avalon bridge or the reply channel were the constraint, master_read_32 would degrade somewhere across that range. It does not.

master_read_32 is therefore a usable workaround, but a slow one: master_read_memory returns 7688 bytes in under 0.05 s, roughly 150 kB/s, where master_read_32 sustains about 26 kB/s. Around 6 times slowp>

QUESTIONS

1. Is 7688 bytes an intended limit for master_read_memory on Agilex 5? If so, where is it documented, and does it vary by device family? The same tool version against Arria V hardware is rock solid and sh
2. Whatever the limit is, could an oversized request return an error immediately instead of hanging for 60 seconds and closing the channel? The silent 60 second stall is far more expensive than a reject

Happy to run any additional test on this board if neede