Recent Content
SoC EDS, compile uboot for Arria 10 SoC
Hi, I have a product with Arria 10 SoC, 10AS066H3F34I2SG. I need to compile uboot. I have a Linux Ubuntu 24.04.2 machine (x86 64-bit). I previously used SoC EDS 19.1 on an older Linux machine. I downloaded the Linux version for this and installed it. As other discussions here have asked installing EDS appears to require dependencies such as libc6:i386 libncurses5:i386 libstdc++6:i386 zlib1g:i386 Just installing EDS does not complete the DS-5 install (the ARM 32-bit libraries appear to be missing). I assume the 32-bit ARM libraries are required to compile uboot. Am I making correct assumptions on the required dependencies to compile uboot? The i386 dependencies appear to no longer have valid fingerprint keys for Ubuntu 24. How can I compile uboot? Best regards, Pete1View0likes0CommentsAgilex 5 LVDS reciver with custom pins
Hi all, We are working on an Agilex 5 project based on Eagleboard with the device A5ED065BB32AE4SR0. Our aim is to use the Cruvi connectors on the board, so we have to configure our pinning according to the board connections. Therefore, we need to use custom pinning for our LVDS receivers. We have been able to successfully set 4 LVDS lanes in I/O Bank 3B_B lane 1 and the reference clock in a differential pair of the same sub bank but in lane 2. Then we tried to set a receiver with 8 lanes using the same 4 differential pairs from I/O Bank 3B_B lane1 and 4 available differential pairs from I/O Bank 3B_B lane2. Like in the following pin planner screenshoot The parameter editor looks like follows, no errors are shown on core generator Once the LVDS receiver is regenerated and new pins assigned, we got the following error related to the 4 new lanes added: Error(14566): The Fitter cannot place 4 periphery component(s) due to conflicts with existing constraints (4 I/O pad(s)). Fix the errors described in the submessages, and then rerun the Fitter. The Intel FPGA Knowledge Database may also contain articles with information on how to resolve this periphery placement failure. Review the errors and then visit the Knowledge Database at https://www.intel.com/content/www/us/en/support/programmable/kdb-filter.html and search for this specific error message number. Error(175019): Illegal constraint of I/O pad to the location PIN_K65 Info(14596): Information about the failing component(s): Info(175028): The I/O pad name(s): Sensor2_Data_n[4] Error(16234): No legal location could be found out of 1 considered location(s). Reasons why each location could not be used are summarized below: Error(20196): Location(s) already occupied and the components cannot be merged. (1 location affected) Info(175029): PIN_K65. Already placed at this location: I/O pad Sensor2_Data_p[4](n) Error(175019): Illegal constraint of I/O pad to the location PIN_K74 Info(14596): Information about the failing component(s): Info(175028): The I/O pad name(s): Sensor2_Data_n[5] Error(16234): No legal location could be found out of 1 considered location(s). Reasons why each location could not be used are summarized below: Error(20196): Location(s) already occupied and the components cannot be merged. (1 location affected) Info(175029): PIN_K74. Already placed at this location: I/O pad Sensor2_Data_p[5](n) Error(175019): Illegal constraint of I/O pad to the location PIN_T74 Info(14596): Information about the failing component(s): Info(175028): The I/O pad name(s): Sensor2_Data_n[6] Error(16234): No legal location could be found out of 1 considered location(s). Reasons why each location could not be used are summarized below: Error(20196): Location(s) already occupied and the components cannot be merged. (1 location affected) Info(175029): PIN_T74. Already placed at this location: I/O pad Sensor2_Data_p[6](n) Error(175019): Illegal constraint of I/O pad to the location PIN_T77 Info(14596): Information about the failing component(s): Info(175028): The I/O pad name(s): Sensor2_Data_n[7] Error(16234): No legal location could be found out of 1 considered location(s). Reasons why each location could not be used are summarized below: Error(20196): Location(s) already occupied and the components cannot be merged. (1 location affected) Info(175029): PIN_T77. Already placed at this location: I/O pad Sensor2_Data_p[7](n) It seems like the fitter tries to create and assign new complementary ping where there are already assigned ones. Could you help us with this? Best regardsHow to generate a netlist when the design includes encrypted sources
I would like to ship my design to a customer as an encrypted netlist, however I am unable to create the netlist after a successful run, because my design includes encrypted RTL (unable to change this). I am running the following command (after running synthesis and P&R): quartus_eda my_project --simulation --format=vhdl --tool=modelsim -c my_project_revision I get the following error: Error (18580): Cannot generate netlist output files because the design includes encrypted source files: "/path/to/encrypted/rtl/file.vhdp" I see here that this was planned to be possible in "future" Quartus Prime updates, but I am using 26.1 and no such update has been made. I have also attempted to run the following command, with the exact same result: quartus_eda my_project --resynthesis --tool=modelsim Any help would be appreciated; perhaps this is plainly impossible, or perhaps there is some work-around. Thank you!4Views0likes0CommentsWhy am I experiencing compilation failures with the F-Tile Ethernet Hard IP design when the Ethernet mode is set to 25GE-1 variant and the FEC mode is configured as IEEE 802.3 RS(544,514)?
Description Due to a problem in the Quartus® Prime Pro Edition software version 25.3, the F-Tile Ethernet Hard IP GUI will not prompt any error message when you have the following settings: Ethernet mode: 25GE-1 FEC mode: IEEE 802.3 RS(544,514) The 25GE-1 variant does not support RS(544,514) FEC. Although the F-Tile Ethernet Hard IP failed to detect this error during IP generation, you will observe a compilation failure during the "Support-Logic Generation" stage. Resolution The problem has been fixed starting with Quartus® Prime Pro Edition software version 25.3.1.Why do I see intermittent device recovery failures with error code 0x3ff in ASx4 configuration mode with HPS?
Description When configuring Agilex® 5 or Agilex® 3 SoC FPGAs in Active Serial x4 (ASx4) mode, intermittent device recovery failures with error code 0x3ff may occur if the mailbox interface is under heavy usage from the Hard Processor System (HPS). This issue is more likely to happen when nCONFIG is toggled multiple times in quick succession, particularly under stress or repeated reconfiguration scenarios. Resolution To minimize the chance of this error: Reduce mailbox traffic from the HPS during configuration and reconfiguration. If error 0x3ff occurs, reassert nCONFIG and attempt to reconfigure the device. In rare cases, if the error persists, a full power cycle of the device may be required to restore normal operation. The problem has been fixed starting with Quartus® Prime Pro Edition software version 25.3. For more details on configuration modes refer to the Device Configuration User Guide: Agilex® 5 FPGAs and SoCs or Device Configuration User Guide: Agilex® 3 FPGAs and SoCs, for error handling refer to Agilex® 5 Hard Processor System Technical Reference Manual or Agilex® 3 Hard Processor System Technical Reference Manual.Why does the SPI (4 Wire Serial) IP report hold violations in Timing Analyzer?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 25.3.1 and earlier, you might see hold timing violations during Timing Analyzer when using the SPI (4 Wire Serial) IP. The SPI IP generates an SDC file that includes the following incorrect constraint: create_generated_clock -name spi_gen_clk -divide_by {4} -source [get_pins $ipath|tx_holding_primed|clk] [get_pins $ipath|SCLK_reg|q] This constraint can cause hold timing violations between the spi_gen_clk and the external clock, making timing closure difficult—especially in designs with multiple SPI instances. This problem does not occur in the Quartus® Prime Standard Edition Software, where such an SDC constraint is not generated for the SPI IP. Resolution To work around this problem: Remove the incorrect constraint from the IP-generated SDC file: Delete the following line: create_generated_clock -name spi_gen_clk -divide_by {4} -source [get_pins $ipath|tx_holding_primed|clk] [get_pins $ipath|SCLK_reg|q] The problem has been fixed starting with Quartus® Prime Pro Edition software version 26.1.Fatal Error: Segment Violation: faulting address=(nil), PC=0x7fffef9076bc : 0x7fffef9076bc: db_cdb_sgate!CDB_SGATE_NODE::get_string_hpath(std::__cxx11::basic_string, std::allocator
Description Due to a problem in the Quartus® Prime Pro Edition Software version 24.2, you might see the error message at Analysis & Synthesis stage when using the inference-flow for Tensor-Mode DSPs with RTL that has too many pipeline stages between the result of the intermediate multipliers and their column addition, but otherwise has the correct structure for a tensor-mode DSPs. Resolution To work around this problem, fix the RTL to match the actual tensor mode operation, refer to the templates that are included in the Quartus® Prime Pro Edition Software, as shown below: The problem has been fixed starting with Quartus® Prime Pro Edition software version 24.3.License file generated by SSLC missing host ID
My company is an ASAP partner, and we have been granted a partner license for Quartus. The license is present in SSLC. When I generate a license file by its activation code, the file I get does not contain the host ID that I have attached to the license, and therefore does not work. The email itself also does not contain this information. In the email: Products : Non-Commercial Software SW-PARTNER-IPA Primary Machine : christian_blixt Primary Machine ID : Host Type : In the attached license file: Fixed Node License # Primary Machine Name-christian_blixt # Primary Machine ID- I tried the ASAP portal support, but was redirected here. Anyone have an idea?Solved34Views0likes11CommentsWhy is the simulation failing with a timeout error when running 1x10.3125G RSFEC Direct Mode (System PLL Clocking) Example Design of the GTS PMA/FEC Direct PHY IP using the Questa* – Altera® FPGA Edition simulator?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 25.1.1, you may see simulation failure with a timeout error when running 1x10.3125G RSFEC Direct Mode (System PLL Clocking) Example Design of the GTS PMA/FEC Direct PHY IP using the Questa* – Altera® FPGA Edition simulator. This problem is limited only to 1x10.3125G RSFEC Direct Mode (System PLL Clocking). Example Design of the GTS PMA/FEC Direct PHY IP using the Questa* – Altera® FPGA Edition simulator. Resolution To work around this problem, modify the simulation timeout value defined in the file below. <design_example_dir>/example_testbench/rtl/param_defines.iv From: `define TIMEOUT 120000000 To: `define TIMEOUT 150000000 The problem has been fixed starting with Quartus® Prime Pro Edition software version 25.3.
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,402 Topics
- fpga dev tools quartus® prime software pro4,294 Topics
- FPGA Dev Tools Quartus II Software3,160 Topics
- stratix® 10 fpgas and socs1,550 Topics
- agilex™ 7 fpgas and socs1,470 Topics
- arria® 10 fpgas and socs1,373 Topics
- stratix® v fpgas1,317 Topics
- arria® v fpgas and socs1,230 Topics
- cyclone® v fpgas and socs1,057 Topics
- Configuration1,007 Topics
Recent Blogs
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
15 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.
16 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
16 days ago0likes
2 MIN READ
Altera introduced three new Agilex® 7 M-Series FPGA package options, R31G, R47C, and R47D, to give customers more flexibility in balancing bandwidth, connectivity, and performance for AI, networking, video, embedded, and acceleration applications. The new options support DDR5-6400, up to 204.8 GB/s memory bandwidth, and expanded transceiver configurations, enabling designers to optimize systems for PCIe connectivity, maximum data throughput, or efficient right-sized scaling.
21 days ago0likes
This post demonstrates a 200G-4 Ethernet link running on Agilex 7 FPGAs using F-Tile transceivers. It walks through the full link bring-up process, including Auto-Negotiation and Link Training, followed by stable high-speed data transmission using 53.125G PAM4 lanes over QSFP-DD. The demo provides real-time visibility into link status, signal integrity, and error metrics, and evaluates performance across loopback configurations and varying cable lengths. The result highlights reliable link initialization, consistent throughput, and robust operation under practical system conditions.
1 month ago0likes