Recent Content
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 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 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 needeAgilex 5 GTS Reference Clock Buffer Protection
While reviewing the Agilex 5 GTS documentation, I found that the Input Reference Clock Buffer Protection mechanism automatically disables the reference clock buffer when the input clock is not toggling, and that the documented recovery methods are either reconfiguration or a buffer turn-on request. For an Agilex 5 design, I would like to clarify: Is there any supported method to keep the GTS reference clock buffer permanently enabled? Can the Input Reference Clock Buffer Protection mechanism be disabled? Is there any alternative to repeatedly issuing a Buffer Turn-on Request when the reference clock may stop and restart during normal operation? If not supported, is the documented re-enable procedure the only recommended approach?Agilex 5 HPS EMIF - Differential Pair Polarity Inversion Support
For the Agilex 5 HPS DDR interface, is P/N swapping (polarity inversion) within a differential pair supported? I could not find a clear statement in the Agilex 5 EMIF documentation. Specifically: Is polarity inversion supported for HPS DDR differential signals? If yes, is any Quartus, HPS EMIF, or firmware configuration required? If not, must polarity be preserved at the PCB level? Is there a documentation section or application note that explicitly covers this requirement? I am looking specifically for the Agilex 5 HPS EMIF/DDR interface, not a generic FPGA differential I/O or transceiver interface.
Quarus Prime Installer 24.1 - Error SSL Certificate, Curlcde : 60
Hello, I've got an error during the installation of quartus prime 24.1 : During somes mounths, I uses this solution I've found on the download page. It works great until a few days ago. There s an other solution t use the 24.1 installer now ?
Stratix 10 fPLL is cascade source mode doesn't lock
Hello everyone. I use fPLL cascading with Stratix 10 FPGA: fPLL in cascade source mode is connected to fPLL in transceiver mode. In my design reference clock for fPLL in cascade source mode is not stable after power-up and I apply user recalibration to it. But after user recalibration when reference clock is stable, fPLL doesn't set lock signal. After some investigation of the issue, I found that my design works fine with Quartus Pro 21.2 but doesn't work with newer versions like Quartus Pro 23.4/25.1/26.1. Is there any known issue about fPLL is cascade source mode? Any suggestions about how to overcome this issue are welcomed.
Agilex 7M RSU: Incorrect SPT Magic Number During Cold Boot on the Agilex 7M HBM2e board
We are investigating an intermittent RSU SPT detection issue on the Agilex 7M HBM2e board. The main observation is: Cold boot → automatic U-Boot boot → Linux rsu_client reports an invalid SPT magic number: Bad SPT1 magic number 0x577134E7 Bad SPT0 magic number 0x577134E7 No valid SPT0 or SPT1 found Cold boot → stop at U-Boot → wait → boot Linux The issue does not occur. Warm reboot The issue does not occur. We verified the SPT directly from U-Boot: sf probe SF: Detected mt25qu02g with page size 256 Bytes, erase size 64 KiB, total 256 MiB sf read 0x02000000 0x00f10000 0x40 SF: 64 bytes @ 0xf10000 Read: OK md.b 0x02000000 0x40 02000000: 27 34 71 57 01 00 00 00 07 00 00 00 e3 56 ee e0 ... The expected SPT magic is 0x57713427, stored as bytes 27 34 71 57. Linux identifies the same flash as: /sys/bus/spi/devices/spi0.0 modalias: spi:mt25qu02g driver: spi-nor and the device path confirms: /sys/devices/platform/soc/ff8d2000.spi/spi_master/spi0/spi0.0 U-Boot dm tree also shows: spi cadence_spi spi@ff8d2000 spi_flash jedec_spi_nor flash@0 Therefore, both U-Boot and Linux are using the Cadence QSPI controller at 0xFF8D2000. For Linux access, we tested /dev/mtd0 corresponding to the QSPI region starting at 0x00F10000. We tested reads using bs=4 as well as byte-wise reads. The results showed that the behavior depends on the read method, and byte-wise reads have shown inconsistent data, while other MTD read methods can return the expected SPT bytes. The Linux RSU driver/librsu nevertheless reports: Bad SPT0 magic number 0x577134E7 Bad SPT1 magic number 0x577134E7 We would like your guidance on the following: Since the QSPI flash is physically connected to the SDM on this board, what is the exact hardware/software path used by: U-Boot sf read Linux /dev/mtd0 librsu / stratix10-rsu Can the SDM/QSPI initialization or HPS-to-SDM handoff affect the Linux SPI-NOR read path during cold boot? Is any bridge, firewall, or QSPI initialization required before Linux accesses the QSPI flash/RSU SPT? Is there any known Agilex 7M issue involving QSPI/SDM initialization, Linux SPI-NOR, or RSU SPT access during cold boot? Our objective is to determine whether the SPT is actually being corrupted in flash or whether the incorrect magic number is caused by the Linux/RSU QSPI access path. To resolve this issue and ensure a reliable automated boot sequence, please provide: U-Boot Configuration: The recommended bootcommand settings or environment variables needed to initialize the RSU subsystem properly. Patches or Updates: Any official driver or SDM firmware patches available to fix this intermittent initialization error. We need a stable, automated boot workflow to proceed with our deployment validation. Thank you for your support and guidance on this issue. Thanks and Regards, M.Charan.
Agilex 5 FPGA EMIF: sharing LPDDR4 reference clock between Bank 3A and Bank 3B
Hello, I'm working with an Agilex 5 E-Series A5ED043BB32AI4S device. On my board, I have two 32-bit LPDDR4 interfaces connected to the HSIO banks 3A and 3B. The DDR reference clock is available only on the dedicated differential CLK pins in bank 3A (K105/M105). There is no refclk in bank 3B. HPS EMIF case Using the External Memory Interfaces for HPS IP configured as 2x32 LPDDR4, Quartus instantiates two EMIFs (one in bank 3A and one in bank 3B). From the generated netlist (see attached images), it appears that the PLL associated with the EMIF in bank 3A receives the external CLK (K105/M105), the PLL reference clock is then internally forwarded/shared to the PLL associated with the EMIF in bank 3B. The design routes and fits successfully. This is the intended DDR architecture on my board and works correctly. FPGA EMIF case For debug purposes, I would like to use the LPDDR4 External Memory Interfaces (EMIF) IP together with the EMIF Debug Toolkit. Since this IP only supports up to 1x32 LPDDR4, I instantiated one LPDDR4 EMIF in bank 3A and one LPDDR4 EMIF in bank 3B. The EMIF in bank 3A works correctly when using the REFCLK in bank 3A (on K105/M105). However, I cannot get the EMIF in bank 3B to fit when its PLL reference clock is assigned to the same REFCLK source located in bank 3A. The fitter reports routing/connectivity issues. Questions 1) For the FPGA LPDDR4 External Memory Interfaces (EMIF) IP, is it mandatory that the PLL reference clock be located in the same bank as the EMIF instance? 2) Is there any supported mechanism to share or bypass the PLL reference clock from the EMIF PLL in bank 3A to the EMIF PLL in bank 3B, similar to what appears to be done automatically by the HPS EMIF 2x32 implementation? Any guidance would be appreciated. Thanks,
Timing models don't match measured delays
I am working with an Agilex 7 I-series device in Quartus Prime Pro 25.3. The device is fully supported by that QPP version and has final timing models. Since I am working with precise timing, I need to find out the propagation delay from internal clock to output on a pin with as good precision as possible. I am trying to use the Timing Analyzer (TA) to do this. The results do not match my expectations though. The TA reports paths for five operating conditions for this device: fast/vid1/100C, fast/vid1a/100C, fast/vid1a/0C, slow/vid1b/100C and slow/vid1/100C. My expectation is that one of them corresponds to the shortest propagation delay (used for hold analysis) and one the longest (used for setup analysis) and that my measured delay should therefore fall somewhere between these extremes. It does not. To test this, I have added two registers to my design, both clocked by the same clock, both toggling at every clock edge. I have instructed Quartus to preserve these and don't merge them. These two registers drive two outputs that I can measure on the board. Then I control the placement of the two registers to get different propagation delay to their pins. I start out by calibrating the setup. Placing the two registers in the same LAB close to the relevant I/O bank results in very nearly the same path delay to both pins according to the TA. As expected, I also measure a very small difference between the edges (around 100 ps). This shows that there is no significant difference between the board traces or measurement cables. Then I move one of the registers a bit, 271 LABs in the X direction to be exact. According to the TA, this design should have the following propagation delay differences between the pins for the five operating conditions: Fast vid1 100C 3.134 ns Fast vid1a 100C 3.138 ns Fast vid1a 0C 2.795 ns Slow vid1b 100C 3.028 ns Slow vid1 100C 3.011 ns However, I measure just 2.32 ns. This is lower than even the 0C model, which must be the fastest timing that is used to guarantee hold timing. How can this be?
