Recent Content
Proper PERST# connection for FMC on Agilex5 Modular Development Kit
I am using an Agilex5 Modular Development Kit to implement a design that has two PCIe endpoints. Each endpoint would run at the same x4 configuration (start with Gen3 and maybe move to Gen4). The first endpoint is easy as the board supports it natively. For the second endpoint I am planning to use the Terrasic P16E-FMCP board and use a separate adapter to limit the width to x4. I went through the schematic several times and I am fairly confident that FMC PCIe lanes 0-3 (plus the reference clock) would connect to the transceiver bank 1B on the Agilex5 device. So the high speed signals look to be OK. My issue is with how to achieve a proper PERST connection. The FMC board connects the PERST# signal to the FMC RES0 pin which is not connected on the Agilex board. This means I have to make a manual connection to the appropriate pins on the FPGA device. Assuming that my bank 1B analysis is correct then the possible PERST# pin connections are: CF132 net A5E_HVIO_5A_6 IO_D61 pin on the primary board-to-board connector Carrier board: net MIPI_XHS0_1V8 which is floating if there is nothing plugged to the MIPI connector Manual PERST connection: Level shift the PERST signal down to 1.8V and then solder it to the MIPI_XHS0_1V8 net. BU109 net A5E_HVIO_5B_6 IO_A56 pin on the primary board-to-board connector Carrier board: BMC_UART_RX0_I2C_SCL_3V3 which is connected to the MAX10 device Manual PERST connection not possible Before I do the board modification, I would like to confirm my analysis is correct (maybe 1B is not the correct bank) and that I am not missing some other, easier, connection. Thank you very much in advance. Any help is greatly appreciated
Synthesis error
I generated HDL file from qsys and did the compilation in Quartus. Following error log was found: Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_rdwr.sv(287): index 3 is out of range [31:5] for 'addr' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_rdwr.sv(287): index 3 is out of range [31:5] for 'addr' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_rdwr.sv(287): index 3 is out of range [31:5] for 'addr' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_rdwr.sv(287): index 3 is out of range [31:5] for 'addr' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_txctrl.sv(196): index 4 is out of range [1:0] for 'tx_data' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_txs.sv(196): index 95 is out of range [65:0] for 'rx_fifo_data' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_app.sv(597): index 257 is out of range [71:0] for 'rx_fifo_dataq' Error(16851): Verilog HDL error at udh_en0.sv(127): formal port avs0 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(125): formal port avs1 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(123): formal port avs2 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(122): formal port avs3 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(121): formal port avm0 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(119): formal port mdio_r of type mdio_ifc' from library 'function_enet_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at udh_en0.sv(120): formal port mdio_s of type mdio_ifc' from library 'function_enet_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at udh_en0.sv(118): formal port mdio_t of type mdio_ifc' from library 'function_enet_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at hssl_i.sv(130): formal port avs of type avlmm_ifc' from library 'function_hssl_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at hssl_i.sv(127): formal port avm0 of type avlmm_ifc' from library 'function_hssl_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at hssl_i.sv(128): formal port gmii_r of type gmii_ifc' from library 'function_hssl_20 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at hssl_i.sv(129): formal port gmii_s of type gmii_ifc' from library 'function_hssl_20 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at hssl_i.sv(131): formal port gmii_t of type gmii_ifc' from library 'function_hssl_20 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at hssl_i.sv(125): formal port mdio_r of type mdio_ifc' from library 'function_hssl_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at hssl_i.sv(126): formal port mdio_s of type mdio_ifc' from library 'function_hssl_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at hssl_i.sv(124): formal port mdio_t of type mdio_ifc' from library 'function_hssl_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(380): formal port gmii0 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(382): formal port gmii1 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(377): formal port gmii2 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(378): formal port gmii3 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(374): formal port gmii4 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(376): formal port gmii5 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(372): formal port gmii6 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(373): formal port gmii7 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(370): formal port gmii8 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(371): formal port gmii9 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(366): formal port gmii10 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(367): formal port gmii11 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(391): formal port avs0 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(390): formal port avs1 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(387): formal port avs2 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(386): formal port avs3 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(389): formal port avs4 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(388): formal port avs5 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(383): formal port avs6 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16186): Can't elaborate top-level user hierarchy Error: Flow failed: Error: Quartus Prime Synthesis was unsuccessful. 65 errors, 191 warnings Error: Peak virtual memory: 1041 megabytes Error: Processing ended: Wed Sep 23 11:02:52 2026 Error: Elapsed time: 00:01:58 Error: System process ID: 23412 Error(293001): Quartus Prime Full Compilation was unsuccessful. 67 errors, 191 warnings It seems the instantiated avlmm(for instance) is trying to map to the same module in altera_work which gneerates this error. How do i solve it?
ModelSim Intel FPGA Ed. 2020.1 not updating changes to HDL File
I have ModelSim open and Quartus Prime Lite v. 22.1, while I'm simulating, I often make changes back to the Quartus, but when I reload the design into ModelSim, it cold-archives the initial HDL file and references that file instead of the changes I make in Quartus. No matter how many times I recompile the code for both the wrapper function and main entity, it always goes back to the original? How is this possible? Does ModelSim copy the file into it's own directory and simply references it? I've spent days trying to figure this out, wihtout creating a new project and adding the changed code to it, how can I force it to use the updated files?
Boundary scan access to SDM pins on Agilex 7
In the Agilex 7 BSDL files available from the Altera website, all of the SDM pins are marked as 'Linkage' indicating that there is no boundary access or control of them. However, from some early investigations on the DK-SI-AGF014EB Development Kit it seems that boundary scan can be used to read and control at least some of these signals (so far I’ve tried SDM_IO5, SDM_IO7, and SDM_IO9). Please can you clarify why this functionality isn't included in the supplied BSDL files, and whether there is a way to obtain BSDL files which include this information?
R-TILE PIPE DIRECT MODE SIMULATION PHY STATUS ISSUE IN RESET RELEASE SEQUENCE
HI, I am currently working on r-tile pipe direct mode simulation in questasim. So, initially i have generated r-tile ip with configuration of pipe direct mode, 16x1. I have generated hdls using generate hdl option(enabling verilog,questasim). I have written pipe control fsm to provide control inputs to r-tile ip. Ref_clock1,ref_clock2 frequency is 100mhz. Reconfig_clock frequency is 100mhz. pipe_direct_pld_tx_clk_out_o from ip is 500mhz(validated in sim) So, i start with providing ninit_done using reset release ip. once nint_done goes low, i am providing pin_perst_n to high. then pin_perst_n_o goes high. After sometime, pipe_direct_pld_tx_clk_out_o becomes active. So, i am waiting for ln0_pipe_direct_tx_transfer_en_o to goes high. once this signal goes high, i will release ln0_pipe_direct_pld_pcs_rst_n_i to high. I am checking the phy signal to toggle. but from beginning itself it stays low, it never toggles. Along with this standard procedure, i tried 2 more possibilities i tried, After i released the ln0_pipe_direct_pld_pcs_rst_n_i to high. I provided the ln0_pipe_direct_txdetectrx_i to high. No response from phy_status. After i released the ln0_pipe_direct_pld_pcs_rst_n_i to high. I provided the ln0_pipe_direct_txdetectrx_i , rx_standby to high. still No response from phy_status I am attaching some screenshots of waveforms. Kinly look into it and help me out. I am really stuck at midway..Preconfiguration BSDL Editor for Agilex 7 with disabled F-Tiles
On a design with an AGIA040R39A some of the FHT are disabled. We tried to modify the BSDL file using the “Preconfiguration BSDL Editor for Agilex 7 Devices with F-Tiles” as mentioned here: https://docs.altera.com/r/docs/683748/current/agilex-7-jtag-boundary-scan-testing-user-guide/agilex-7-bst-guidelines This does modify the BSDL file, but the BSDL file it generates (BSR length 3077 bits) doesn't match the boundary scan register length we're detecting in the device (3061 bits). We suspect this is because the BSDL editor doesn't include the options for disabling FHT12B or FHT13B. Would disabling these parts of the device reduce the BSR length by 16 bits? If so, can the BSDL Editor be updated, or a modified BSDL file be supplied?
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.Terasic P16E-FMCP PCIE Express 3.0 compatibility issues with AMD processors
Hi I bought the Terasic P16E-FMCP to use on my Terasic Apollo S10 SOM board for PCI Express 3.0 implimentation. However after testing the included program, it did not work, so I emailed Terasic Support and they told me it was only tested on Intel CPU and it appears never tested on AMD. So they made me run a simple program called System Information Viewer from rh-software.com which tested the information sent and received from the PCI endpoint and it appears there are errors stimming back from the demo program does not natively run on AMD processors. So for the past 6 months, Terasic has been dragging there feet on this issue, telling me they will work on a solution but I must go out and purchase another computer by Intel, then run several versions of Quartus Pro, starting from 19.1, through 23.3, I must download them individually. I told them I am not doing this, I am not being paid to test out your code, I simply purchased the board direct from you for $650, and NOWHERE on the website does it publish it works only with Intel CPU. Instead they are pointing the fingers at me saying I'm delayin a resolution on this issue by not testing out there code, I told them that IS YOUR JOB! I AM NOT EMPLOYED BY TERASIC! Terasic is a partner program of Intel, they have all the means to reach out and contract a device driver writer and solve this incompatiblity issue. This is beyond my expertise. They simply won't do it. Does anyone have a solution to this problem? Why are they passing the buck at me?Terasic Apollo S10 SOM_FA
I bought the Terasic P16E-FMCP to use on my Terasic Apollo S10 SOM board for PCI Express 3.0 implimentation. However after testing the included program, it did not work, so I emailed Terasic Support and they told me it was only tested on Intel CPU and it appears never tested on AMD. So they made me run a simple program called System Information Viewer from rh-software.com which tested the information sent and received from the PCI endpoint and it appears there are errors stimming back from the demo program does not natively run on AMD processors. So for the past 6 months, Terasic has been dragging there feet on this issue, telling me they will work on a solution but I must go out and purchase another computer by Intel, then run several versions of Quartus Pro, starting from 19.1, through 23.3, I must download them individually. I told them I am not doing this, I am not being paid to test out your code, I simply purchased the board direct from you for $650, and NOWHERE on the website does it publish it works only with Intel CPU. Instead they are pointing the fingers at me saying I'm delayin a resolution on this issue by not testing out there code, I told them that IS YOUR JOB! I AM NOT EMPLOYED BY TERASIC! Terasic is a partner program of Intel, they have all the means to reach out and contract a device driver writer and solve this incompatiblity issue. This is beyond my expertise. They simply won't do it. Does anyone have a solution to this problem? Why are they passing the buck at me?ModelSim_FA
I have ModelSim open and Quartus Prime Lite v. 22.1, while I'm simulating, I often make changes back to the Quartus, but when I reload the design into ModelSim, it cold-archives the initial HDL file and references that file instead of the changes I make in Quartus. No matter how many times I recompile the code for both the wrapper function and main entity, it always goes back to the original? How is this possible? Does ModelSim copy the file into it's own directory and simply references it? I've spent days trying to figure this out, wihtout creating a new project and adding the changed code to it, how can I force it to use the updated files?
Recent Blogs
1 MIN READ
Altera has begun shipping the new Agilex® 7 M-Series R31G multi-host acceleration package, giving customers a new way to build high-bandwidth systems that connect more hosts while moving more data through the network and memory subsystem. R31G is designed for architectures where data must move quickly between the network, memory, and multiple CPUs, GPUs, or other hosts. By bringing 800G or 2x400G Ethernet together with expanded PCIe 5.0/CXL host connectivity, the package opens new possibilities for AI NICs, storage acceleration, cloud acceleration, and other high-throughput platforms. What R31G enables More network bandwidth: 800G or 2x400G Ethernet capability for high-throughput data paths. More host connectivity: Two PCIe 5.0 x16 host interfaces, or up to four independent PCIe 5.0 x8 connections, with CXL support for flexible multi-host architectures. More memory bandwidth and I/O: DDR5-6400 and LPDDR5-6400 support, up to 204.8 GBps of memory bandwidth, and 768 GPIO in a compact 56 x 45 mm package. The result is a programmable platform that can connect, accelerate, and adapt as infrastructure requirements evolve, while keeping high-speed networking, host connectivity, and memory bandwidth tightly integrated. More network bandwidth. More hosts. More memory bandwidth. One programmable platform. Learn more in the Agilex® 7 M-Series product site.
2 days ago
As AI, cloud, and high-performance computing systems continue to scale, data center operators need more bandwidth within increasingly constrained power and thermal envelopes. Linear Pluggable Optics (LPO) offers an important path forward by simplifying optical modules, reducing power consumption, and lowering latency. LPO places signal-conditioning responsibilities in the host device, allowing the optical module to operate without the DSP used in traditional retimed optics. This architecture can reduce optical module power by 30% to 40%, helping data center designers increase connectivity density while simplifying cooling and thermal management. Altera Brings LPO to the FPGA Market Altera is the first FPGA provider to publicly demonstrate Linear Pluggable Optics interoperability using production FPGA devices. Continued validation with LPO modules from Amphenol and FS further demonstrates the breadth of the emerging ecosystem supported by Altera. Agilex® 7 FPGAs and SoCs bring the power and latency advantages of LPO to programmable platforms used in SmartNICs, data processing units, AI accelerators, and custom infrastructure. The initial public demonstration established that Agilex 7 devices could successfully interoperate with 400G LPO modules. The latest validation advances that milestone by confirming that the implementation meets the performance requirements expected for deployment in demanding data center environments. Validated for Real Deployment Conditions Comprehensive testing confirms that Agilex 7 F-Tile transceivers meet the electrical and link-performance requirements defined by the 100G-DR-LPO specification. The validation demonstrated: Compliance with the required transmit, receive, and link-performance criteria Successful interoperability with LPO modules from Amphenol and FS Successful LPO connectivity across distances from 1 meter to 500 meters Consistent performance across temperature and voltage conditions Measurable performance margin beyond required thresholds Testing covered demanding signal conditions, voltage variation, and temperatures ranging from minus 40 degrees Celsius to 105 degrees Celsius for electrical characterization. Functional link testing included a 1-meter LPO connection, a 100-meter active optical cable, and 500-meter LPO modules from Amphenol and FS. The results demonstrate robust, repeatable operation across multiple module suppliers and link distances, with measurable margin relative to the required performance limits. For customers, this validation provides confidence that Agilex® 7 support for LPO is ready for real-world deployment. Following the industry’s first public FPGA interoperability demonstration, the solution has now been evaluated against LPO performance requirements using modules from multiple suppliers and over link distances up to 500 meters. Together, these results demonstrate a practical foundation for deploying LPO connectivity in next-generation data center systems. More Efficient Connectivity for AI and Cloud Infrastructure The value of LPO grows as data centers deploy more high-speed optical connections. Eliminating the DSP from each optical module can reduce power across thousands of links, simplify optical module design, ease thermal pressure at the front panel, and support lower-latency data movement. Agilex 7 FPGAs add programmability to this more efficient optical architecture. Customers can combine LPO connectivity with packet processing, acceleration, security, telemetry, and evolving protocol support on a single adaptable platform. This flexibility is especially valuable for AI clusters and cloud infrastructure, where workloads, network architectures, and connectivity standards continue to evolve. Validation with multiple module vendors also gives system designers greater flexibility as the LPO supplier ecosystem continues to develop. Ready for the Next Generation of Data Centers The combination of public interoperability and comprehensive validation marks a major step for LPO in the FPGA market. Altera has demonstrated that LPO works with production Agilex 7 devices and validated that the solution meets key LPO requirements with measurable operating margin. This gives customers a proven foundation for evaluating and deploying lower-power, lower-latency optical connectivity in real data center environments. With Agilex® 7 FPGAs, LPO is ready for real-world data center deployment.
1 month ago
Security requirements are entering a new phase. Systems being designed today may remain deployed for many years, while regulatory expectations, cryptographic standards, and threat models continue to evolve. For designs in industrial, communications, infrastructure, aerospace, defense, and embedded applications, long-term security is becoming a core platform requirement. FPGA-based designs allow designs to meet today’s security needs and evolve with tomorrow’s requirements. Altera is now offering Agilex® 3 and Agilex® 5 devices with PQC-enabled secure boot and configuration support, helping customers prepare for the next generation of security requirements. With the Quartus® Prime Pro Edition 26.1.1 release, customers can begin using a PQC flow that works with Agilex 3 and Agilex 5 based hardware. This milestone extends the security architecture already built into the Agilex platform. Agilex devices use the Secure Device Manager as a hardware root of trust for secure configuration and device management. By combining PQC-capable devices with Quartus software enablement, Altera is helping customers strengthen the FPGA chain of trust as post-quantum requirements move from planning to implementation. The value is immediate and practical. Customers can start designing with supported devices today, while using Quartus 26.1.1 to take advantage of the current software flow. This gives teams a path to address emerging compliance and security expectations without needing a future platform redesign. The same hardware foundation also allows for additional security enhancements over time. Customers designing with PQC-capable Agilex 3 and Agilex 5 devices can benefit from planned software and firmware improvements enabled by the underlying hardware, with no further FPGA hardware upgrade required for those enhancements. Agilex 3 devices bring this capability to power- and cost-optimized FPGA and SoC designs used in embedded, edge, industrial, control, and platform-management applications. Agilex 5 devices extend the same security direction into mid-range FPGA and SoC designs that require higher performance, greater integration, and broader system capability. Post-quantum readiness will continue to advance, and Altera is building that evolution into the Agilex platform roadmap. With PQC-capable Agilex 3 and Agilex 5 devices and Quartus 26.1.1 software enablement, customers have a practical starting point today and a scalable foundation for future security enhancements.
1 month ago
Altera has started to sample Agilex® 5 D-Series FPGA devices to customers, expanding the Agilex 5 family for customers building higher-performance midrange systems. This adds a second Agilex 5 path alongside Agilex 5 E-Series FPGAs, which are already in full production. Agilex 5 E-Series remains the production-ready choice for power- optimized midrange designs. It is a strong fit when customers need production availability, efficient power, and right-sized capability for applications such as industrial control, edge compute, physical AI, and embedded systems. Agilex 5 D-Series extends the family for designs that need more system performance headroom. It is intended for applications that place heavier demands on signal processing, embedded memory, memory bandwidth, and fabric performance, including broadcast, wireless, video, AI-enabled embedded systems, and higher-performance applications that benefit from memory interfaces such as DDR5 and LPDDR5 capability. One Agilex 5 family, two design paths Agilex 5 E-Series Agilex 5 D-Series In full production Engineering samples available Power-optimized midrange designs Higher-performance midrange designs Right-sized logic and efficient power More DSP, embedded memory, EMIF bandwidth, and higher DDR and LPDDR bandwidth Industrial control, edge compute, physical AI and embedded systems Data Center, Communications, Broadcast, video, and AI-enabled embedded systems Together, Agilex 5 E-Series and D-Series enable customers a clearer way to choose the right midrange FPGA path: production deployment today with E-Series, or higher-performance design evaluation with D-Series. Customers evaluating Agilex 5 D-Series can begin real-silicon design work with Quartus® Prime Pro Edition 26.1.1 support. To order Agilex 5 D-Series engineering samples, please contact your Altera representative. Visit the Agilex 5 D-Series page Visit the Quartus Pro 26.1 Page
1 month ago
Quartus® Prime Pro Edition 2026.1.1 expands memory options across the Agilex® FPGA portfolio. Memory is increasingly setting the performance, power, and lifecycle limits of modern systems. AI acceleration, packet processing, storage, video, industrial automation, and edge computing all depend on moving large amounts of data efficiently. At the same time, memory availability and vendor transitions can force design teams to revisit component choices long after a platform architecture has been selected. With Quartus® Prime Pro Edition 2026.1.1, Altera expands memory options across the Agilex portfolio. The release brings higher-speed DDR5 and LPDDR5 options to Agilex 7 M-Series FPGAs and SoCs, broadens component choice through documented LPDDR5X device support, and extends LPDDR5 support to Agilex 3 FPGAs and SoCs. Together, these enhancements give designers greater flexibility to balance performance, power, footprint, memory cost, and supply continuity. What is new with Quartus Prime Pro Edition 2026.1.1 Enhancement Customer value DDR5-6400 and LPDDR5-6400 on Agilex 7 M-Series devices Higher Memory Bandwidth Raises the maximum supported memory data rate from 5600 to 6400 MT/s, an increase of more than 14%. DDR5 delivers up to 204.8 GB/s of aggregate bandwidth, while LPDDR5 provides a lower-power, compact-footprint option for bandwidth-intensive designs. LPDDR5X device use in LPDDR5-compatible mode New Sourcing Option Adds sourcing flexibility when LPDDR5 availability, or component strategy favors an LPDDR5X device. LPDDR5 now available for Agilex 3 devices New Memory Support Added Brings a modern low-power memory option to power- and cost-optimized Agilex 3 device configurations. Two 6400 MT/s paths for high-performance systems Agilex 7 M-Series FPGAs and SoCs already combine high logic density, high-speed connectivity, and advanced external memory functionality in a device family available today in full-volume production. Quartus Prime Pro Edition 2026.1.1 strengthens that family’s offering with DDR5-6400 and LPDDR5-6400 in approved configurations. For DDR5, the move from 5600 MT/s to 6400 MT/s increases the maximum data rate by more than 14%. That additional throughput can help AI, networking, storage, and infrastructure designs sustain higher data movement without expanding the FPGA footprint. It can also give architects more flexibility in how they meet a target bandwidth, including the potential to optimize channel count, DIMM selection, board space, and subsystem complexity when the application and supported configuration allow it. LPDDR5-6400 brings a second option to the same top-line interface rate. LPDDR5 is increasingly relevant beyond mobile products because it combines strong bandwidth with lower I/O power and a compact board footprint. Those characteristics are valuable in embedded systems, smart network interface cards, industrial platforms, edge compute, and other designs, where thermal limits and board area matter alongside performance. The result is a high-end FPGA platform that lets designers choose between DDR5 for capacity and server-class memory options, or LPDDR5 for power and footprint efficiency, while reaching up to 6400 MT/s and 204.8 GB/s of aggregate memory bandwidth in selected Agilex 7 M-Series device configurations. LPDDR5X device compatibility adds practical supply-chain flexibility The LPDDR5X enhancement addresses a different customer need. LPDDR5X devices are backward compatible with the LPDDR5 interface, so components can be used with an Agilex LPDDR5 memory interface while operating at the same speeds, voltages, and specifications as the LPDDR5 configuration. Customers can now design with LPDDR5X components in LPDDR5-compatible mode with greater confidence, backed by documented Altera support process. A complete memory offering across the Agilex portfolio Because the Agilex portfolio spans high-performance, mid-range, and power- and cost-optimized devices, customers can carry a consistent FPGA architecture and Quartus development flow across products with very different memory requirements. That continuity helps reduce redesign effort and gives engineering teams more freedom to scale compute, connectivity, and memory together. Teams can preserve DDR4 or LPDDR4 where product requirements, temperature range, or supply conditions still favor those technologies. New designs can move to DDR5 or LPDDR5 for higher bandwidth and better system efficiency. LPDDR5X device compatibility provides an additional sourcing path without requiring customers to redesign a separate memory interface. Explore Agilex FPGA external memory solutions and review the Quartus Prime Pro Edition 2026.1.1 documentation for supported devices, speed grades, memory components, and configurations.
1 month ago