Recent Content
Agilex 5E: How to access FPGA-side EMIF DDR4 from HPS through HPS2FPGA?
Hi, I am building on top of the Agilex 5E GSRD design. My goal is not to use the HPS-side DDR for the FPGA accelerator data buffer. Instead, I want the data path to be: ARM/HPS writes input data -> HPS2FPGA bridge -> FPGA-side DDR4 via EMIF_IO96B_DDR4COMP FPGA IP reads input data from FPGA-side DDR4 FPGA. IP computes and writes result back to FPGA-side DDR4 ARM/HPS reads result back from FPGA-side DDR4 via HPS2FPGA My current Platform Designer connection is roughly: HPS hps2fpga master -> EMIF_IO96B_DDR4COMP AXI memory-mapped slave FPGA accelerator memory port -> same EMIF_IO96B_DDR4COMP EMIF pins -> external DDR4 The EMIF configuration and DDR4 pin assignments are matched carefully against the example design: /agilex5e_installer_package/examples/bts_emif/bts_ddr4_2b downloaded from the agilex5e installer package. I also tested the original bts_ddr4_2b style flow in the example using: JTAG -> pattern adaptor -> EMIF -> DDR4 and DDR4 read/write tests pass without errors. So the FPGA-side EMIF DDR4 calibration/pattern test appears to work. However, when I try to access the same FPGA-side DDR4 from Linux on HPS through the HPS2FPGA bridge using devmem2, the access fails badly. For example, accessing the HPS2FPGA mapped address causes a bus error / fatal SError. One example log: root@agilex5dka5e065bb32aes1:~# devmem2 0x40000000 w /dev/mem opened. [ 1017.877669] SError Interrupt on CPU2, code 0x00000000be000011 -- SError [ 1017.877707] CPU: 2 PID: 791 Comm: devmem2 Not tainted 6.12.19-altera-g7b497655d942 #1 [ 1017.877717] Hardware name: SoCFPGA Agilex5 SoCDK (DT) ... [ 1017.877814] Kernel panic - not syncing: Asynchronous SError Interrupt ... Bus error For comparison, I connected the same HPS2FPGA bridge to an on-chip memory in the FPGA fabric. Accessing that on-chip memory from HPS with devmem2 works correctly. So the HPS2FPGA bridge itself seems functional. Current observations: HPS2FPGA -> on-chip memory works. JTAG -> pattern adaptor -> EMIF -> DDR4 works. EMIF calibration appears to pass. HPS2FPGA -> EMIF DDR4 causes SError / bus error / Linux kernel panic. Here is my current Platform Designer connection. In the screenshot, you can see that I copied over the EMIF-driving logic from the installer package. For emif_axi4, one connection goes to my IP’s memory port, and the other goes to the HPS hps2fpga interface, although that HPS connection is not shown in this screenshot. Does anyone have any clues about what might be wrong here? Is this expected to work, or is this use case currently not supported, i.e. HPS reading/writing data directly to FPGA-side DDR through HPS2FPGA while an FPGA IP also accesses the same DDR through the EMIF AXI4 interface? If any additional files would be helpful, I can provide them. Thank you in advance!SolvedQuartus Prime Download
I am unable to download the Quartus Prime Std 23.1 application because of some internet issue. I checked the internet where it said that i can upload a ca certificate but i dont see any option to upload that i dont know how to download this. Any help here?53Views0likes13CommentsF-Tile PCIe Root Port 1x Gen3x4 - Configuration Read Type 0 receives no answer
Hello Support, I am using the Agilex 7F Dev Kit with F-Tile configured in Root Port Gen3x4. When I am doing a Configuration Write Type 0 to write the End Point BAR0 with FFFF_FFFFh, the end point send an answer , when I follow this write with a Configuration Read type 0 to read the BAR 0 of the End point I do not receive any answer. Is there any configuration which avoid the read data to go through the F-Tile ? Is there any problem with my Configuration Read type 0 command I have attached the STP file as well. Thank you for help. Serge53Views0likes9CommentsArria 10 HPS - DMA EMAC reset issue
Hello, We are bring-up the custom Arria 10 board, we have some issue with HPS GMAC in U-Boot. Arria 10 connect to SFP (1 G Ethernet) , our interface is : HPS EMAC0 → FPGA GMII-to-SGMII Converter → SFP (SGMII PHY) We are working without MDC/MDIO , in fixed mode. During our testing we performed ping and after this we read register 0xFF801000 and we received value 0x00020101( Last bit DMA_BUS_MODE.SWR = 1 instead of the 0). We checked : The input clock of 125 MHz by oscilloscope - looks ok. Reset Manager: 0xFFD05024 = 0xFF7FBEBE (EMAC0 is released from reset). Bridge is working. GMII-to-SGMII registers are accessible Device tree addresses were verified agaonst the .sopcinfo file Looking forward to your response, thanks in advance.avalon MM generator read issue
I'm using avalon MM BFM to stimuli my slave avalon interface, however, when doing u_avalon_MM_gen.mm_master_bfm_0.set_command_address(addr); u_avalon_MM_gen.mm_master_bfm_0.set_command_byte_enable(4'hF, 0); u_avalon_MM_gen.mm_master_bfm_0.set_command_request(REQ_READ); u_avalon_MM_gen.mm_master_bfm_0.push_command(); @(u_avalon_MM_gen.mm_master_bfm_0.signal_read_response_complete); data = u_avalon_MM_gen.mm_master_bfm_0.get_response_data(0); $display("[%0t] READ Addr=0x%08h Data=0x%08h", $time, addr, data); the data seem delay by 1 register transaction eg. READ addr=0 data=0 READ addr=4 data=1020001 <- this data should be at addr=0, but get_response_data(0) pop on the next addr return.data (get_response_data) has 3 ns delay from rising clock edge or from complete.data change11Views0likes2CommentsAXI violation on H2F interface of S10
I'm using the H2F AXI interface to access external RAM via EMIF on an S10 SX SoC DK (1SX280HU2F50E1VGAS). There are situations where I see the valid signal of the W channel go from 1 to 0 while the ready signal is 0. This is a violation of the valid/ready handshake protocol of AXI. After a while the system freezes because no more write transaction are accepted on the AW channel. What can cause this? Are there any known bugs in the bus master of the HPS? Here is a waveform I sampled with SignalTap that shows the behavior: There is a Linux 6.1 running on the ARM core. The RAM on the FPGA side is used for video memory. It is listed in the device tree and our drivers use it to make video memory allocations. The memory is then mapped into user space and our test application transfers data into the memory (e.g. texture data).40Views1like2CommentsHPS ip configuration in platform designer for uart0 enabling in arria 10 soc
I have software tools Quartus prime pro 26.1, soc eds 20.1 and linaro baremetal tool chain. Now i configure the HPs ip for uart0 enabling but i am not sure wether it is correct or not, can you please conform it, and guide if there any changes required and if configuration is fine tell me the next steps to do. Regards Tean D&D, ESSEN186Views0likes7CommentsUnstable fpga programming using HPS(Agilex3)
Hi I have a problem where the fpga programming sometime fail when using the overlay method described here under "Reconfiguring Core Fabric from Linux": https://altera-fpga.github.io/rel-25.3.1/embedded-designs/agilex-3/c-series/boot-examples/ug-linux-boot-agx3/#reconfiguring-core-fabric-from-u-boot Here I have first two successful attempt then it fail on the third: root@agilex3:~# rmdir /sys/kernel/config/device-tree/overlays/0 ; sleep 1 ; mkdir /sys/kernel/config/device-tree/overlays/0 ; cd /lib/firmware/ ; sleep 1; echo overlay.dtb >/sys/kernel/config/device-tree/overlays/0/path rmdir: '/sys/kernel/config/device-tree/overlays/0': No such file or directory [ 182.671913] fpga_manager fpga0: writing overlay.rbf to Stratix10 SOC FPGA Manager [ 184.865664] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /fpga-region/firmware-name [ 184.876007] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /fpga-region/config-complete-timeout-us root@agilex3:/lib/firmware# rmdir /sys/kernel/config/device-tree/overlays/0 ; sleep 1 ; mkdir /sys/kernel/config/device-tree/overlays/0 ; cd /lib/firmware/ ; sleep 1; echo overlay.dtb >/sys/kernel/config/device-tree/overlays/0/path [ 196.530735] fpga_manager fpga0: writing overlay.rbf to Stratix10 SOC FPGA Manager [ 198.659279] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /fpga-region/firmware-name [ 198.669650] OF: overlay: WARNING: memory leak will occur if overlay removed, property: /fpga-region/config-complete-timeout-us root@agilex3:/lib/firmware# rmdir /sys/kernel/config/device-tree/overlays/0 ; sleep 1 ; mkdir /sys/kernel/config/device-tree/overlays/0 ; cd /lib/firmware/ ; sleep 1; echo overlay.dtb >/sys/kernel/config/device-tree/overlays/0/path [ 214.383163] fpga_manager fpga0: writing overlay.rbf to Stratix10 SOC FPGA Manager [ 217.508857] arm-smmu-v3 16000000.iommu: CMD_SYNC timeout at 0x00004405 [hwprod 0x00004408, hwcons 0x00004405] [ 217.509907] arm-smmu-v3 16000000.iommu: CMD_SYNC timeout at 0x00004407 [hwprod 0x00004408, hwcons 0x00004405] U-Boot SPL 2025.10 (May 18 2026 - 08:34:29 +0000) Reset state: Cold MPU 800000 kHz L4 Main 400000 kHz L4 sys free 100000 kHz L4 MP 200000 kHz L4 SP 100000 kHz SDMMC 200000 kHz init_mem_cal: Initial DDR calibration IO96B_0 succeed DDR: Calibration success is_mailbox_spec_compatible: IOSSM mailbox version: 1 LPDDR4: 1792 MiB ecc_interrupt_status: ECC error number detected on IO96B_0: 0 SDRAM-ECC: Initialized success Does anybody know how to debug and fix this? I'm using Quartus Prime Version 25.3.0 Build 109 Devboard: DK-A3W135BM16AEA: Agilex™ 3 FPGA and SoC C-Series Development Kit163Views0likes7CommentsCyclone V nRST assertion upon nPOR
Hello, I am looking for a confirmation on whether the nRST pin is driven low upon a nPOR input assertion. I have found no definite answer in the HPS TRM (cv_5v4 dated 2024.12.03). But HPS TRM version 1.3 (Nov 2012), Table 3-3 page 3-7 says with I ran an experiment today on our prototype, asserting nPOR once the system has boot-up (linux) and see no assertion of nRST pin. Also, in the Reset Manager register description, I see no configuration bit that would enable/disable nRST assertion upon nPOR. Can someone confirm the unconditional assertion of nRST upon a nPOR as I understand from HPS TRM from Nov 2012. Thanks, Best regard Pascal32Views0likes2CommentsRX Mac segmented interface detailed information
I am using Ftile ethernet hard IP (400G configuration) . I complied the example test design with signal tap to monitor RX mac segmented interface and loaded on MA2700 . The kit is connected to a host with 400G capable NIC in it. I am using ping command and via wireshark I can see that host sends ARP request packet to the kit. As the ARP request packets are sent to the kit, I triggered STP and capture I have attached screenshot. you can see all data in the capture other than rx_mac data. rx mac data on clock -1 and 0 are as following -1 -> E39001000406000801000608AAEB6A17E390FFFFFFFFFFFFD5555555555555FB070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707 0 -> 070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707070707FDE831AB370000000000000000000000000000000000006501A8C0000000000000C801A8C0AAEB6A17 From wireshark I can see this ARP packet is 60bytes and all the fields matches with what I see in the o_rx_mac_data. Now I am trying to make sense of Rx mac segmented interface and I have following questions. rx mac inframe values are E000h and 000Fh meaning total 7 bits are 1 (logic high) indicating 56 byte packet but from payload is 60 bytes. So how do I equate for remining 4 bytes? in user guide o_rx_mac_eop_empty [47:0] signal is explained as "Indicates the number of empty bytes on the RX data signal, starting from the most significant byte (MSB). Valid only on EOP segments." I dont understand this statement completely so please help; as per signal tap waveform clock 0 is where packet ends and the value of bus is 4800h. I am not sure if and how this value can help equates for missing 4 bytes. Figure 44. Receiving Data Using the RX MAC Client Interface is little help- and small explanation below it (has typos i think) is not much help. Do you have more details and example for MAC segmented interface which you can share with me so that I can learn exact details on how to use this interface to receive incoming packets from Ftile. Using above signaltap screenshot and o_rx_mac_data values for clock -1 and 0; how do i detect sop? how do i use rx mac_sengemented interface to detect eop ? how do i use rx mac_sengemented interface detect exact length of ethernet frame which is being supplied during clock -1 and 0.5Views0likes1Comment
Featured Places
Community Resources
Check out the support articles on personalizing your community account, contributing to the community, and providing community feedback directly to the admin team!Tags
- troubleshooting10,333 Topics
- fpga dev tools quartus® prime software pro4,276 Topics
- FPGA Dev Tools Quartus II Software3,131 Topics
- stratix® 10 fpgas and socs1,539 Topics
- agilex® 7 fpgas and socs1,496 Topics
- arria® 10 fpgas and socs1,368 Topics
- stratix® v fpgas1,311 Topics
- arria® v fpgas and socs1,224 Topics
- cyclone® v fpgas and socs1,054 Topics
- Configuration1,031 Topics
Recent Blogs
Agilex® 5 and Agilex® 3 FPGAs now provide native MIPI D-PHY support for CSI-2 camera and DSI display interfaces, making it easier to bring sensor and display data directly into FPGA fabric for real-time processing, aggregation, adaptation, and transport. The blog highlights how scalable MIPI bandwidth, multi-interface connectivity, and integration with the Altera Video Solutions Stack enable high-performance vision, robotics, medical imaging, edge AI, and display systems while simplifying the path from image capture to processing and AI workflows.
29 days ago0likes
The Nios® V/c compact microcontroller is the third and the latest addition to the Nios V soft processor family and is supported in Intel® Agilex®, Intel® Stratix® 10, Intel® Arria® 10, and Intel® Cyclone® 10 GX FPGAs and SoCs. With the Nios V processor, you can easily create a processor and peripheral system using the traditional hardware tool flows like Intel® Quartus® Prime Software and Platform Designer as needed for your production solution.
29 days ago0likes
2 MIN READ
Altera is extending the availability of its Agilex®, MAX® 10, and Cyclone® V FPGA families through 2045 to support long-lifecycle applications like industrial, aerospace, and medical systems. This helps customers avoid costly redesigns and ensures reliable, long-term supply, reinforcing Altera as a trusted partner for decades-long deployments.
1 month ago2likes
To help address these challenges, Altera® is expanding the Agilex® 9 Direct RF-Series FPGA portfolio with the addition of the AGRW039, a new maximum-compute wideband device designed for demanding aerospace and defense RF applications.
1 month ago0likes
4 MIN READ
Runtime flexibility is only valuable when it is reliable High-speed systems are being asked to do more with the same hardware. A data-center platform may need to operate as a single 400G Ethernet link in one deployment, then support multiple 100G links in another. A front-haul or edge system may need to adapt to different rates, protocol roles, or customer configurations over the life of the product. The promise is simple: deploy one platform, then adapt it as requirements change. But in high-speed design, changing a configuration is not the hardest part. Changing it correctly is. A live transition is not just a speed change. It can require coordinated updates across the the various networking layers, along with clocking, lane mapping, reset behavior, and link recovery. If those layers do not move together and in the right order, the result can be an unstable link, silent data corruption, or a system that hangs indefinitely waiting for CDR lock. That is the real value of Altera Dynamic Reconfiguration: it gives designers confidence that runtime transitions are clean, verified, and repeatable. The Altera difference: clean, verified transitions Altera Dynamic Reconfiguration is built around a profile-driven, silicon-aware flow. Designers define the target operating modes in Quartus Prime, and the system generates validated profiles for each supported state. At runtime, the Dynamic Reconfiguration Controller applies the selected profile through a managed, hardware-driven sequence. It orchestrates the transition across the full protocol stack, ensuring MAC, FEC, PCS, and PMA layers are updated in a coordinated and deterministic order, rather than leaving the designer to manually manage each step. The result: clean, verified transitions - no partial configurations, no unsequenced resets, and no user-managed state machines to debug at 2 a.m. This matters because the transition itself is often where risk appears. A system may appear to support multiple modes on paper, but if each layer must be independently controlled, reset, and validated by user logic, the design team carries the burden of proving that every edge case works under real operating conditions. Altera reduces that risk by turning reconfiguration into a controlled system operation. The selected profile is known, and the transition is repeatable. Silicon-driven confidence The assurance comes from the architecture. Agilex devices use hardened transceiver and protocol IP designed for high-speed operation. Rather than treating reconfiguration as a collection of ad hoc register writes, Altera Dynamic Reconfiguration works with hardened IP and validated profiles to help ensure that runtime switching happens in a controlled, silicon-driven way. That silicon foundation is especially important at 100G and 400G data rates, where small sequencing mistakes can lead to difficult debug cycles. When designers hand-craft transceiver reset state machines, getting the order right, the timing right, and the edge cases right can take weeks. With Altera, those critical sequencing responsibilities are built into the reconfiguration flow. The benefit is not just ease of use. Ease of use is a result. The primary benefit is trust: designers can enable live switching with greater confidence that the system will move from one valid state to another without glitches. A practical advantage for real systems In real deployments, flexibility has business value only if it does not create operational risk. Altera Dynamic Reconfiguration helps a single hardware platform support multiple configurations while avoiding the disruption of a full FPGA reprogramming cycle or duplicate hardware paths for every possible mode. For networking platforms, this can mean supporting different Ethernet configurations on the same physical transceiver resources. For multi-protocol systems, it can mean adapting a port role as requirements evolve. For platform owners, it means more deployment options from the same hardware design. This is where Altera has a practical positioning advantage: customers get runtime flexibility with more of the critical transition behavior handled by the platform. Instead of asking designers to manually manage every reconfiguration step, Altera provides a structured flow designed to produce predictable, verified results. What the demo proves The Agilex 7 400G Dynamic Reconfiguration demo turns this story into proof. In the demo, two Agilex 7 FPGA boards are connected over QSFP-DD, and the system dynamically switches between a 400G Ethernet configuration and multiple 100G Ethernet links using the same setup. The demonstration shows more than a mode change. It shows live traffic validation, link status, packet counters, error status, and FEC behavior during the transition. That is the point: the feature is not theoretical. It is running on silicon, switching in real time, and validating the kind of clean transition designers need before they trust the feature in production systems. Why this matters now As data-center, telecom, edge, and industrial systems become more configurable, customers increasingly need hardware platforms that can support multiple roles over time. The question is no longer whether a system can support more than one mode. The question is whether it can switch modes cleanly, predictably, and with confidence. Altera Dynamic Reconfiguration is designed for that moment. It combines hardened IP performance, profile-driven control, and coordinated sequencing to deliver runtime flexibility without compromising reliability. Dynamic reconfiguration is valuable because it enables flexibility. Altera makes it compelling because it makes that flexibility trustworthy. Watch the Runtime Reconfiguration You Can Trust demo video
1 month ago1like