Featured Content
Forum Widgets
Recent Discussions
Power management Agiilex 3/5 - Powerdown then HPS restart ?
I read in the power management section of (841346) Section 9 "Only power-off operations are supported, and they are done one time as a static option through boot mode user configuration. After power is turned off, the power manager does not support powering back on the CPU cores or L3 cache blocks." As I understand it = for a(partial ) power down , or power up of the HPS, the system needs to set some memory locations and then trigger a HPS restart and ther SDM has control then passes it to the FSBL. , then the FSBL can look at these locations and see what power mode it needs to come up or down as the system requires...... IE to change the power settings, there needs to be an HPS restart , or complete device configuration reload ? Perhaps put another way : In HPS boot-first mode : When a power CHANGE is required in the HPS domain, can the fabric stay running (assuming that there are no outstanding HPS<> fabric DMA requests or transactions pending across the fabric<>HPS bridge ) ? regards, glen.1View0likes1CommentAgilex 5/3 FreeRTOS SDK Release
Stable Version: v26.1.1 Quartus Version: 26.1.1 Supported devices: Agilex™ 3 and Agilex™ 5 Source: https://github.com/Ignitarium-Technology/freertos-socfpga Branch/Tag: v26.1.1 Release Date: October 9, 2026 Hello Everyone, A new version of the FreeRTOS SDK for Agilex 5/3 is now available. This release contains some fixes, along with UHS-1(SDR12/25/50) support for SD/eMMC. Visit the GitHub repository for instructions on how to get started. Features and Comments Feature Agilex3 Agilex5 Agilex3 SMP Agilex5 SMP Supported Features Limitations / Known Issues A55 boot Yes Yes Yes Yes Single-core boot, Dual-core SMP, Quad-core SMP (Agilex 5) A76 boot NA Yes NA Yes Single-core boot, Dual-core SMP, Quad-core SMP QSPI boot Yes Yes Yes Yes eMMC boot NT Yes NT Yes SD boot NT Yes NT Yes NAND boot No No No No Clock Manager Yes Yes Yes Yes API to get clock speed of different blocks Reset Manager Yes Yes Yes Yes Peripheral reset assert/de-assert DMA driver Yes Yes Yes Yes Memory-to-Memory, Memory-to-Peripheral and Peripheral-to-Memory GPIO driver Yes Yes Yes Yes Write, read and interrupt support Timer driver Yes Yes Yes Yes User-defined and free-running modes UART driver Yes Yes Yes Yes Full-duplex TX and RX I2C driver NT Yes NT Yes Master/Slave mode, standard and fast modes QSPI driver Yes Yes Yes Yes QSPI flash read/write/erase I3C driver NT Yes NT Yes Master mode, I3C and legacy I2C devices SPI driver NT Yes NT Yes Master/Slave mode write and read NAND driver No No No No SDM Mailbox driver Yes Yes Yes Yes SDM commands with SIP_SVC SMMU support Yes Yes Yes Yes Static identity mapping for cache coherency SDMMC driver Yes Yes Yes Yes Standard and HS HS, and UHS-I (SDR12/25/50) speeds, SDMMC and eMMC devices, FATFS support Ethernet stack Yes Yes Yes Yes TCP/IP, UDP, ICMP, DHCP, IPv4 and IPv6 USB 2.0 stack NT Yes NT Yes USB mass storage class Tested with a custom board and SOF USB 3.1 stack Yes Yes Yes Yes USB mass storage operation WDT driver Yes Yes Yes Yes Interrupt or reset on timer expiry EDAC support Yes Yes Yes Yes Error injection and detection for EMAC, USB and QSPI blocks OCRAM not supported IOSSM driver Yes Yes Yes Yes Error injection and detection Bridge driver Yes Yes Yes Yes Enable/Disable bridges Reboot Manager Yes Yes Yes Yes Warm/Cold reboot FPGA Manager Yes Yes Yes Yes FPGA configuration Legend: Yes: Feature available and tested No: Feature not available in SDK NA: Not applicable NT: Not tested Note: If you find any issues, please raise an issue on the GitHub repository.42Views2likes1CommentIntroducing the Altera Community AI Responder — Beta
Altera is introducing the AI Responder, an assistant built into the Altera Community to help provide faster, context-aware guidance for Altera product questions. It uses relevant public Altera documentation and Knowledge Database content, with coverage continuing to expand. The AI Responder may provide source references and can hand off complex or out-of-scope questions to an Altera subject-matter expert. As a beta feature, responses may contain errors or omissions, so please review the sources and verify technical guidance against official Altera documentation before implementation. If the response does not fully address your question, add more context and tag ai_responder to continue the discussion. We welcome your feedback as we improve the Community experience.19Views0likes0CommentsLWH2F Throughput
Dear all, I'm facing the issue that the throughput on the Agilex 5 LWH2F interface appears to be lower compared to Cyclone 5. - I have two custom boards, one is based on Cyclone 5, the other on Agilex 5. - I use a linux OS. The code runs in a linux kernel driver. The code for the driver is the same for both devices. - The memory is mapped using ioremap(), i.e. it is mapped as device memory. - I measure performance by taking a timestamp with ktime_get_ns(), then read/write 10000 uint32 values, then take another timestamp. - I've measured the follwing values - Cyclone5 board read: 47.2 MB/s (million bytes per second or 11.8 million words à 4 byte per second) - Cyclone5 board write: 73.1 MB/s - Agilex5 board read: 24.8 MB/s - Agilex5 board write: 18.8 MB/s - I've noticed that performance varies, depending on the CPU that the process is running on (when measuring in userspace I can explicitly set the cpu affinity; For the kernel driver I've noticed that it is sometimes slower than above, presumably because it's running on a different cpu). - There is a slight difference in the QSYS design: - The Cyclone5 based board: - drives the AXI bus with a 64 MHz clock. - uses the Avalon MM Slave Translator. - The Agilex5 based board: - drives the AXI bus with a 200 MHz clock. - uses the Avalon Memory Mapped Pipeline Bridge Intel FPGA IP. - Our FPGA takes one 64/200 MHz cycle to process the read (readdatavalid). For a write our FPGA doesn't generate a writeresponsevalid, this is handled by the IP block. - I'm using Quartus 25.1.1 for the Agilex 5 design. I'm aware that the LWH2F interface is not intended for high throughput. Also, since the memory is mapped as "Device Memory", every load/store is processed separately and we're not taking advantage of AXI bursts, etc. I'm aware that we could improve performance by using the H2F interface and mapping the memory as normal memory. That said, we have a prooven design and are reluctant to change it unless absolutely neccessary. So I have the following questions: - Is a higher latency expected on Agilex5? (E.g. due to a different architecture of the interconnect) - Have you measured the performance of the LWH2F interface? Can you give me a number on how many transactions per second we can expect? Kind Regards, Eric Opitz488Views0likes13CommentsStore custom keys on SDM Agilex3
Hi I know it's possible to store encryption and siging keys on the SDM for fpga firmware decryption and authentication, but is it possible to store my own keys on it? I will use the key to decrypt my own software files on the HPS, so I need some way to send the ecrypted software to the SDM then the SDM will use the key to decrypt it and send it back. Is there any documentation or tutorial for this?552Views0likes13CommentsNAND flash issue with dual-core ARM® Cortex®-A9
The 5CSEBA2U19I7SN SoC HPS NAND pins are connected to a 4Gb NAND flash memory chip (S34ML04G200TFI003). In this design, the active-low Write Protect pin (#WP) is connected to both a 10kΩ pull-up resistor (to 3.3V) and a 10kΩ pull-down resistor (to Ground). During booting or flashing, a few NAND flash chips do not work properly, and a few nand flashes have been permanently damaged. Is connecting the #WP pin to both a pull-up and a pull-down resistor a correct hardware approach for cyclone SOC HPS NAND configuration? Best Regards, Keshav210Views0likes3CommentsAgilex 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.129Views0likes2Comments