Recent Content
Cyclone V SoC 5CSXC6 Series GXB Utilization and Limitations
Dear Intel Altera, I would like to confirm that the 6 channels GXB device: Q1) Do it possible to use all 6 TX / RX GXB Transceivers when Hard PCIe is used. Based on: CV-53004 There are no specific diagram to explains the single PCIe hard core device with only 6 channel case. Q2) Based on the document: CMU PLL will use CH5 and do this simply means there will be one extra for PCIe Hard-Core? Q3) If not understood falsely, Either PCIe X2 GEN1 + 4 custom GXB usage nor PCIe X4 GEN1 + 2 custom GXB usage is possible? And most protocol uses 1,2,4 and the only possible case is PCIe X4 GEN1 + 1 custom GXB? A little more info from CV-53002 So in order for PCIe Hard Core to run x2 or x4 CH4 must be used. As a result for custom TRX there is no way to use CH1 when PCIe is > x1? Thanks, BrianCyclone 10 GX Transceiver Power-Up Calibration Time (~353 ms) Analysis Request
We are observing a transceiver power-up calibration time of approximately 353 ms on a Cyclone 10 GX device (10CX220YF780I6G) using all 12 transceivers. The total system startup requirement is 250 ms (configuration + calibration + system boot constraints), and the calibration phase alone is currently a limiting factor. According to the Cyclone 10 GX Transceiver PHY User Guide, calibration is performed automatically during device configuration via the PreSICE engine and is dependent on reference clock stability, PLL lock conditions, and reset controller sequencing. The documentation does not specify a deterministic calibration duration. Please can you provide clarification on the following points: Is a ~353 ms calibration time expected behavior for a design using all 12 transceivers on this device family? Is transceiver calibration executed sequentially across multiple quads, or is full parallel calibration supported for all active transceiver banks in Cyclone 10 GX? Are there any recommended design practices (reset controller configuration, PLL topology, clocking architecture) that can reduce power-up calibration latency? Can calibration duration be significantly impacted by reference clock stabilization time or internal wait states prior to PreSICE execution? The goal is to determine whether the observed latency is inherent to the device architecture or if it can be optimized at system level.18Views0likes2CommentsAgilex 3 VCCLSENSE and GNDSENSE
Hello, For Agilex 3, what is the recommendation for VCCLSENSE and GNDSENSE if our regulator for VCC does not provide remote sense inputs? Can we just leave these two device outputs as no connects? Note that this is a very small form factor design. Thank you11Views0likes2CommentsARM DS5 debugger Access/Detection of CM55 on Agilex5 fpga device
Hi Team, We recently purchased license for the ARM DS5 IDE from Altera with License file contains note as NOTICE="For use with Intel or Altera devices only". I am using Arm Development studio IDE with version 2025.1-1. ALtera Agilex 5 FPGA device configured with custom soft macro based design which is only having ARM Cortex M55 processor cores with coresight debug IP . My question is whether ARM DS IDE will detect, access and debug the Cortex M55 cores which is in the fpga through the JTAG USB Blaster ? Please provide the detailed explanation Regards Suresh4Views0likes0CommentsWhy does the SEU test for Zephyr RTOS fail in the Agilex® 5 FPGA Premium development kit when using ATF and GHRD from the Quartus® Prime Pro Edition Software version 24.3.1 and later release?
Description Due to a compatibility problem between the latest version of Zephyr (24.3) and the ATF and GHRD releases from the Quartus® Prime Pro Edition Software version 24.3.1 and later, the SEU Zephyr test fails with a hang in the Agilex® 5 FPGA Premium Development kit. The test hangs after the following messages: SEU Test Started The Client No is 0x26ccad96 The Client No is 0x26dbf773 SEU Safe Error Insert Test Started. <hang is observed here> Resolution To work around this problem, it is recommended to use the latest version of the components in which this test passes, which corresponds to the Quartus® Prime Pro Edition Software version 24.3 release as documented on the following page: https://altera-fpga.github.io/latest/embedded-designs/agilex-5/e-series/premium/gsrd_zephyr/ug-zgsrd-agx5e-premium/ This problem will be fixed in a future release.Why does the Power Thermal Analyzer tool display device family compatibility errors when opening files from different device families in Quartus® Prime Pro Edition Software version 25.3?
Description Due to a problem in Quartus® Prime Pro Edition Software version 25.3, during a single session, if a new Power Thermal Analyzer (PTA) design file is created targeting a specific device family, all subsequent PTA design files opened will be loaded targeting the same device family. This occurs regardless of the actual target device defined in those files. This problem occurs when switching between Stratix® 10 FPGA and Agilex® FPGA device families within the same session. For example, if you first create a PTA file for a Stratix™ 10 FPGA device and then open a PTA file meant for an Agilex® 7 FPGA device, the Agilex® 7 FPGA file will incorrectly be loaded as targeting the Stratix® 10 FPGA device. This results in the error: "Error (25383): The Stratix® 10 FPGA PTA does not currently support opening files created by the Agilex® 7 FPGA PTA. Import canceled." The same issue occurs in reverse when opening Stratix® 10 FPGA PTA files after creating an Agilex® FPGA PTA file. Resolution You can avoid this issue using one of the following methods: Close and reopen Quartus® Prime Pro Edition Software before opening PTA files from different device families. This method works when PTA is launched from Quartus® Prime Pro Edition Software; for standalone PTA, closing and reopening PTA before opening different device family files is more appropriate. Create a new PTA file using the target device family, then open the desired file from the recently created PTA file. Use the open_design_file Tcl command by copying the equivalent Tcl command displayed in the Tcl Console and modifying it to replace the target device family in the -family parameter to match the desired device family. This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition software.Why is there a random hexadecimal number in my TCL console?
Description Due to a problem in the Quartus® Prime Pro Edition Software, you may see a random hexadecimal number printed in the TCL console after running the set_instance_assignment command. Resolution It is safe to ignore this number. This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition software.Why does the HDMI Design Example fail to generate when using the Quartus® Prime Standard Edition Software version 24.1?
Description From Quartus® Prime Standard Edition Software version 24.1 onwards, Nios® II has been removed and is now End-of-Life (EOL). The HDMI Design Example hasn't been upgraded to Nios® V yet, and so this causes the design example generation to fail. The error below will be seen when trying to generate the design example for the listed device families: "Error: Failed to generate example design example_design to: " Resolution No workaround for this problem exists. If necessary, use the Quartus® Prime Standard Edition Software version 23.1 until this problem is resolved in a future release. Additional Information This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition software.Why does Nios® V processor system simulation fail with no print-out message and multiple “x” values along the processor’s signals?
Description This problem may be seen in the Synopsys* VCS* and VCS* MX simulators when simulating the Nios® V processor system generated from Quartus® Prime Pro Edition Software version 23.1 to 23.4, or Quartus® Prime Standard Edition Software version 23.1std This is due to the X-propagation support in the simulators. Resolution To workaround this problem, follow these steps: Switch off the X-propagation feature on the processor core, Generate testbench system from the Platform Designer. Navigate into the Synopsys* simulator directory. $ cd <Project>/sys_tb/sys_tb/sim/synopsys Append -xprop=xpropconfig into the shell script in the vcs or vcsmx folder. For example: USER_DEFINED_ELAB_OPTIONS=”-xprop=xpropconfig” Create a file named xpropconfig in the vcs or vcsmx folder (beside the shell script). Copy the following text into xpropconfig, and change the processor entity name. tree {<Nios V processor HDL entity name>} {xpropOff}; Run the simulator. This problem is currently scheduled to be resolved in Quartus® Prime Pro Edition Software version 24.1 and later.Why am I seeing the Error: pgm_q_inst_intel_niosv_g_0_platform_irq_rx_bfm_ip.pgm_q_inst_intel_niosv_g_0_platform_irq_rx_bfm: "Irq width" (AV_IRQ_W) 2048 is out of range: 1-32?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 25.1 and Quartus® Prime Standard Edition Software 24.1, the error message might occur when generating a testbench system for Nios® V/g processor designs. As a result, the Quartus® Prime software fails to generate the testbench system. The error message occurs when ALL the following conditions are met: The processor implements CLIC interrupt mode with more than 32 platform interrupts (Number of Platform interrupt sources parameter). The processor’s interrupt receiver is exported to the top-level system (Double-click to export option). Selected Standard, BFMs for standard Platform Designer interfaces when generating testbench system (Generate Testbench System tools). This is because the maximum width of the Avalon Interrupt Source and Interrupt Sink BFMs is capped at 32 interrupts. Resolution To work around this problem in the Quartus® Prime software, you may proceed with any of the following options: Implements CLIC interrupt mode with fewer than 32 platform interrupts. Refrain from exporting the processor’s interrupt receiver. Selects Simple, BFM for clocks, and resets when generating the testbench system. Additional Information This problem is currently scheduled to be resolved in a future release of the Quartus® Prime Pro Edition Software and Quartus® Prime Standard Edition Software. Related Articles Nios® V General Purpose Processor (Number of Platform interrupt sources Parameter) Quartus® Prime User Guide (Generating the Testbench System Tool) Avalon® Interrupt Source and Interrupt Sink BFMs (IRQ Width Parameter)
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,399 Topics
- fpga dev tools quartus® prime software pro4,293 Topics
- FPGA Dev Tools Quartus II Software3,160 Topics
- stratix® 10 fpgas and socs1,548 Topics
- agilex® 7 fpgas and socs1,477 Topics
- arria® 10 fpgas and socs1,377 Topics
- stratix® v fpgas1,319 Topics
- arria® v fpgas and socs1,232 Topics
- cyclone® v fpgas and socs1,059 Topics
- Configuration1,009 Topics
Recent Blogs
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.
3 days 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.
3 days 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
22 days ago1like
Agilex® 9 Direct RF-Series FPGAs help system designers address two critical RF system priorities: lower latency and improved SWaP (size, weight, and power). By integrating high-performance RF data converters directly with FPGA fabric, Agilex 9 Direct RF-Series FPGAs can reduce RF-to-baseband latency, simplify the signal chain, lower system power, and free up valuable board space for future capabilities addition. In a draft comparison of discrete JESD-based architectures versus an Agilex 9 integrated Direct RF approach, the integrated solution showed up to 78% lower latency versus a JESD204C discrete solution and up to 86% lower latency versus a JESD204B discrete solution. The comparison also showed approximately 40% lower power consumption and up to 48% board-area reduction. These gains support both primary value propositions: faster system response through lower latency, and better SWaP through fewer external components, lower power, and a smaller, more efficient RF design. Digital radio frequency memory (DRFM), electronic attack, and electronic protection are good examples of applications where latency improvements can make a meaningful difference. In these types of RF systems, lower RF-to-baseband latency helps systems act on complex signals faster, improving responsiveness, timing precision, and mission effectiveness in contested electromagnetic environments. The SWaP benefit is also critical in long-lifecycle aerospace and defense platforms which may remain operational for decades, yet have limited space, weight, power, and cooling capacity for new hardware. As signal environments evolve, these platforms need room to add or upgrade capabilities without major system redesigns. By integrating RF data conversion with FPGA processing, Agilex 9 Direct RF-Series FPGAs can help system designers improve responsiveness, reduce board area, simplify the RF signal chain, and create more headroom for future upgrades. Learn more about Agilex 9 Direct RF-Series FPGAs and the benefits of integrated data converters. Discover how Agilex 9 Direct RF-Series FPGAs enable lower-latency and more power-efficient RF system designs Download the Altera® Direct RF-Series FPGA Wideband Product Brief Source for draft proof points: Agilex 9 Direct RF-Series integrated data converter app note draft, version 0.1, last updated March 31, 2026.
23 days ago0likes
2 MIN READ
New DDR5-6400 support delivers a 14% increase in maximum DDR5 data rate, strengthening Agilex® 7 M-Series device’s memory leadership on a production device family. This effort reflects Altera’s continued investment to improve features on platforms already in volume production. For customers building high-performance FPGA-based systems, memory capability is a core platform requirement, and the level of memory performance increasingly shapes overall system differentiation. That is why this latest Agilex 7 M-Series enhancement matters. With DDR5 support increasing from 5600 MT/s to 6400 MT/s, Agilex 7 M-Series devices support a 14% increase in maximum DDR5 performance on a device family already shipping in production. The significance of this update goes beyond speed alone. It reinforces a broader story about platform value: more usable bandwidth, better system efficiency, and continued innovation on a platform customers can design around today. More bandwidth, better system efficiency DDR5-6400 is not just a higher interface number. It enables more memory bandwidth from the same platform, helping customers move more data through bandwidth-intensive designs. That added bandwidth can also improve bandwidth density at the system level. In practical terms, it can help designers reach target throughput with a more optimized memory subsystem, potentially reducing DIMM or channel requirements in some designs and improving overall platform efficiency. Those advantages become increasingly important in the kinds of applications Agilex 7 M-Series devices are built to address. Across AI, networking, video processing, and data center infrastructure, system performance depends not only on compute capability, but also on how efficiently data can be moved and sustained through the platform. A broader production-ready platform advantage This update also says something important about the platform itself. Agilex 7 M-Series devices already offer production-ready support for advanced external memory technologies, and DDR5-6400 extends that advantage further. As next-generation infrastructure platforms evolve for AI, scale-out networking, and data-intensive acceleration, advanced memory capability is becoming an increasingly important platform differentiator. DDR5 support is now emerging across a broader range of FPGA segments, including mid-range devices such as Agilex 5 and even power- and cost-optimized devices such as Agilex 3 (with LPDDR5 support). Agilex 7 M-Series devicesbrings DDR5-6400 to a high-end FPGA platform tier built for larger, more data-intensive AI, networking, and infrastructure applications. By combining advanced memory performance with substantially greater logic capacity, it delivers differentiation at the platform level. This enhancement is enabled through an upcoming release of Quartus® Prime Pro Edition and is designed to be backward compatible with previously shipped silicon and boards. Customers interested in enabling DDR5-6400 should contact Altera for additional guidance on supported configurations, applicable speed grades, and implementation details. Conclusion The move to DDR5-6400 on Agilex 7 FPGAs and SoCs M-Series delivers a 14% improvement in maximum DDR5 data rate, improving bandwidth density and system-level efficiency while extending the value of a production-ready platform for evolving customer requirements. Watch the DDR5-6400 Demo Performance Video
23 days ago0likes