Recent Content
Quartus Pro 25.3 crash using rhel7/8
Hello everybody I'm working on an Agilex-5 project since fex months on our internal couputer farm using Quartus Pro 25.3. To generate the final bitstream, a bash script is used to execute all the steps. Until now, we have no specific issue using this script with Quartus. But since few days, we're unable to generate the project because Quartus Pro returns strange errors (see attachments). We also tried to use latest 23.5.1 version on an Ubuntu host under WSL and we also saw the same errors. Running Quartus GUI may also end with same error. (see quartus_4.png) Has anyone already experienced this issue? Thanks a lot Benjamin1.4KViews5likes15CommentsDevice migration about DD and DA
Hi Sir, 10M50DDF256C8G vs 10M50DAF256C8G My understanding is that the DD and DA packages are the same, or at least pin-to-pin compatible. However, when I tried using Quartus, I found that Device Migration cannot be set between these two devices. What is the reason for this? Are these two devices actually not pin-to-pin compatible? Thanks. Best Regards, Aaron1View0likes0CommentsWhy does the system report an error when generating rbf from sof files and fsbl files?
Error message: Error: Internal Error: Sub-system: BITASM, File: /quartus/pgm/bitasm/bitasm_common_code.cpp, Line: 518 HPS data start address(-1950584) is not 16 aligned Device and tool information: The device used is Stratix 10 1SX110HN2F43I2VG, without using the Stratix 10 SoC Development Kit; Quartus Prime Pro25.1.1 U-boot source code:u-boot-socfpga-socfpga_v2025.04 ATF source code:arm-trusted-firmware-socfpga_v2.13.0 Operation steps: Simplified the Platform Designer section of the Stratix 10 GHRD project; 【Device and Pin Options】->【Configuration】Set the HPS/FPGA configuration order to be HPS First; The Quartus full compilation generates the sof file in the "output_files" directory; Compile the ATF source code, and obtain the bl31.bin file in the path of ./build/stratix10/release; Copy the bl31.bin file to the root directory of u-boot, compile the u-boot source code, and obtain the u-boot-spl file in the ./spl/ directory; Convert u-boot-spl to u-boot-spl.hex and copy it to the output_files directory; Open the Programming File Generator tool and configure the Output Files: Configure Input Files, add sof and HEX files: 9. Configuration Device: 10. Generate error:Solved78Views0likes8CommentsFailing IO buffer
A very simple desiggn to trap failure. Using an IO buffer (8 off) I have proved that the input from an EEPROM is read corrcly but the recieving instance's register records X"FF". I cannot see why. Any help would be appreciated because it is driving me nuts.202Views0likes19CommentsHow can I successfully upgrade designs that use the F-Tile Ethernet Hard IP, created in Quartus® Prime Pro Edition version 22.4 or earlier, to version 25.3.1 from version 25.3?
Description Upgrading the F-Tile Ethernet Hard IP from the Quartus® Prime Pro Edition software version 25.3 to 25.3.1 causes an error in designs created with versions 22.4 or earlier when using Advanced Mode with a custom Ethernet line rate of 25.78125 Gbps. The error occurs because the maximum allowed range was reduced to 17.4 Gbps, while the upgraded IP requires up to 29 Gbps to support that rate. Resolution To work around this problem in the Quartus Prime Pro Edition software version 25.3.1, overwrite the link_fault_config bit 3 (force_rf) when the generated design is configured with Link fault generation option as “Bidirectional”. This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.What is the difference between HDMI configuration compared to HDMI_NATIVE and HDMI_STATIC configurations in the F-tile PMA/FEC Direct PHY IP?
Description Due to a problem in the Quartus® Prime Pro Edition software version 25.3.1, the F-tile PMA/FEC Direct PHY IP has incorrectly displayed the HDMI_NATIVE and HDMI_STATIC configuration as part of the FGT PMA configuration rules parameter options. These options should not be used when you are operating in HDMI mode. Resolution To work around this problem In the Quartus Prime Pro Edition software version 25.3.1, you should select the HDMI configuration under the F-tile PMA/FEC Direct PHY IP and apply the below HSSI QSF assignment in your Quartus Setting Files (.qsf). Ensure the correct HSSI QSF assignment is being added following the parameters/configurations listed in the table. FGT PMA Configuration Rules PMA Mode Adaptation Mode Action required for user: Update HSSI QSF Assignment in .qsf file HDMI RX Simplex TX Simplex Manual (for Data Rate: 3Gbps, 6Gbps) Update QSF file to include add in TX/RX_TUNING_HINT_HDMI_STATIC tuning hint. This HSSI QSF assignment need to be set for every F-tile PMA/FEC Direct PHY IP instances in the design for every TX Simplex instance or RX Simplex instance in your design. set_instance_assignment -name HSSI_PARAMETER "TX_TUNING_HINT=RX_TUNING_HINT_HDMI_STATIC" -to <instance> set_instance_assignment -name HSSI_PARAMETER "RX_TUNING_HINT=TX_TUNING_HINT_HDMI_STATIC" -to <instance> exm: set_instance_assignment -name HSSI_PARAMETER "TX_TUNING_HINT=TX_TUNING_HINT_HDMI_NATIVE" -to u_hdmi_tx_top|gxb_tx_inst|u_tx_phy_3|tx_phy_6g|dphy_hip_inst|persystem[0].perxcvr[0].fgt.tx_ux.x_bb_f_ux_tx -entity agx_hdmi21_frl_demo exm: set_instance_assignment -name HSSI_PARAMETER "RX_TUNING_HINT=RX_TUNING_HINT_HDMI_NATIVE" -to u_hdmi_rx_top|gxb_rx_inst|u_rx_phy_3|rx_phy_6g|dphy_hip_inst|persystem[0].perxcvr[0].fgt.rx_ux.x_bb_f_ux_rx -entity agx_hdmi21_frl_demo Native (for Data Rate: 8Gbps, 10Gbps, 12Gbps) 1. Update QSF file to add in TX/RX_TUNING_HINT_HDMI_NATIVE tuning hint. This HSSI QSF assignment need to be set for every F-tile PMA/FEC Direct PHY IP instances in the design for every TX Simplex instance or RX Simplex instance in your design. set_instance_assignment -name HSSI_PARAMETER "TX_TUNING_HINT=RX_TUNING_HINT_HDMI_NATIVE" -to <instance> set_instance_assignment -name HSSI_PARAMETER "RX_TUNING_HINT=TX_TUNING_HINT_HDMI_NATIVE" -to <instance> exm: set_instance_assignment -name HSSI_PARAMETER "TX_TUNING_HINT=TX_TUNING_HINT_HDMI_NATIVE" -to u_hdmi_tx_top|gxb_tx_inst|u_tx_phy_0|tx_phy_12g|dphy_hip_inst|persystem[0].perxcvr[0].fgt.tx_ux.x_bb_f_ux_tx -entity agx_hdmi21_frl_demo exm: set_instance_assignment -name HSSI_PARAMETER "RX_TUNING_HINT=RX_TUNING_HINT_HDMI_NATIVE" -to u_hdmi_rx_top|gxb_rx_inst|u_rx_phy_0|rx_phy_12g|dphy_hip_inst|persystem[0].perxcvr[0].fgt.rx_ux.x_bb_f_ux_rx -entity agx_hdmi21_frl_demo 2. Update QSF file to add in rxeq_vga_gain=37 setting. This HSSI QSF assignment need to be set for every F-tile PMA/FEC Direct PHY IP instances in the design for every RX Simplex instances. set_instance_assignment -name HSSI_PARAMETER "rxeq_vga_gain=37" -to <rx_instance>. exm: set_instance_assignment -name HSSI_PARAMETER "rxeq_vga_gain=37" -to u_hdmi_rx_top|gxb_rx_inst|u_rx_phy_0|rx_phy_12g|dphy_hip_inst|persystem[0].perxcvr[0].fgt.rx_ux.x_bb_f_ux_rx -entity agx_hdmi21_frl_demo This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.Behavior of 10 GX Avalon-MM Interface for PCI Express* IP Core when byteenable=16'h0000
Hi, we are using an Arria® 10 and Cyclone® 10 GX Avalon® Memory-Mapped (Avalon-MM) Interface for PCI Express* IP Core. During our tests we noticed some illegal PCIe packages generated presumable due to a wrong data length. We could tackle down the problem to the following basic setup: avalon_mm_master => 128 bit bus => PCIe-Core When we send the following sequence (two words), we get an illegal/unexpected PCIe transfers/behavior: burstcount = 2, address = address_a, data = some_data, byteenable=16'h0000 burstcount = 1, address = address_a+16, data=some_data, byteenable=16'hFFFF When we only send the second word everything works fine. This sequence originally comes from a qsys autogenerated 256=>128 width change in the interconnect somewhere upstream in our project. My question is: Do we miss something here? Does the IP-Core not allow for a first word to be completely disabled? If so, is there any (automatic) way to tell qsys / the interconnect to discard a leading all_bytes_disabled word? 5.3. 64- or 128-Bit Bursting TX Avalon-MM Slave Signals Best regards, Michael30Views0likes2CommentsMAX10 Single end I/O low/high speed bank frequency
In single-ended I/O use cases, the actual performance differences between low-speed and high-speed I/O pins are still unclear, particularly with respect to the maximum safe operating frequency. Are there any official documents or guidelines that describe this difference? In our case, the protocol is SPI with a required maximum operating frequency of 100 MHz. We would therefore like to ask: if the SPI signals are routed to low-speed I/O pins, what is the maximum frequency at which stable operation can realistically be achieved? Are there any recommended limits, characterization data, or application notes that address this scenario?2Views0likes0CommentsMandelbrot viewer on Cyclone V - Platform Designer layout
Hello, I’ve been trying to implement on my DE1-SoC an outstanding Mandelbrot Viewer written by 3 fellows at Cornell, which published partial information in an online available final report I manage to compile the C++ code and perform a sanity check on my x86 host: And I manage to compile the C++ to run on the DE1-SoC HPS: Also, I got Quartus to compile the Verilog provided in the report, though it’s not in its final, working form. I’m pretty sure my problem is in the Platform Designer (formerly Qsys) layout. Been trying many variations around this layout for several weeks, but with no success: I chose the components to my best understanding based the report, that mentions: "The communication between the FPGA and the hard processor system happens over a memory-mapped AXI bus. Requests for tiles are placed into a FIFO on the FPGA, and solved tile data is written out into external SDRAM memory. Requests from the HPS are sent over the AXI bus into a FIFO located on the FPGA. A request distributor then pulls the message off of the FIFO using the avalon streaming interface and handles it. (I assume this is with reference to request_distributor.sv attached in report) As the solvers solve pixels of the output tile, they write the results to SDRAM. Arbitration logic collects results from any solvers which are ready to write. (I assume this is with reference to write_arbitrator.sv attached in report)" Additional info: To my understanding, a top module (not attached to the report) is probably instantiating a multi_tile_solver.sv module and a module from Platform Designer, nothing more. As can be seen in the files in the report, multi_tile_solver.sv instantiates a request_distributor.sv module, a write_arbitrator.sv module, and NUM_SOLVERS tile_solver_legit.sv modules. Each tile_solver_legit.sv instantiates a solver.v, which instantiates a solver_control.v and a solver_datapath.v. It uses on-chip SRAM in the form of M10K block, which are created from the verilog source code, rather than having anything to do with the Platform Designer layout. I think I’m pretty close to running this amazing project, yet have been stuck on this platform designer layout and don’t succeed in finalizing. Any help would be much appreciated.37Views0likes5Comments
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,246 Topics
- fpga dev tools quartus® prime software pro4,128 Topics
- FPGA Dev Tools Quartus II Software3,159 Topics
- stratix® 10 fpgas and socs1,508 Topics
- agilex™ 7 fpgas and socs1,361 Topics
- arria® 10 fpgas and socs1,331 Topics
- stratix® v fpgas1,306 Topics
- arria® v fpgas and socs1,218 Topics
- cyclone® v fpgas and socs1,046 Topics
- Configuration917 Topics
Recent Blogs
Using FPGAs and MCUs Collaboratively FPGAs and microcontrollers can be used alternatively in some applications, but they can also be used cooperatively. FPGAs provide ultimate flexibility, but microcontrollers often include peripherals like USB or wireless interfaces that may be more convenient for communications and updates. Both devices require supporting circuitry such as power, reference clocks, and storage. Fortunately, these can often be shared when using FPGAs and microcontrollers together. This blog introduces an open-source tool that enables microcontrollers to load a programming file into a programmable device, and the practical application of this with the Raspberry Pi RP2350 MCU. An Open Standard for Loading Programmable Devices Loading programmable devices from embedded processors is a common task. The Jam Standard Test and Programming Language (STAPL) was originally developed by Altera engineers to address challenges in programming programmable logic devices (PLDs) in-system, such as proprietary file formats, vendor-specific algorithms, large file sizes, and long programming times. It provides a software-level standard for in-system programming (ISP), enabling flexibility and platform independence. Figure 1. In-system programming using the Jam File & Jam Player via an embedded processor. In August 1999, JAM/STAPL was adopted as JEDEC standard JESD-71, making it an industry-recognized solution for JTAG-based programming. The language introduced features like compact file formats, branching, and looping, which reduced programming time and file size—ideal for embedded systems. JAM/STAPL consists of two main components: Jam Composer: Generates Jam Files (.jam) containing programming algorithms and user data. Jam Player: Interprets these files and applies JTAG vectors for programming and testing devices. Over time, JAM/STAPL gained widespread support from PLD vendors, programming equipment makers, and test equipment manufacturers, becoming a cornerstone for in-field upgrades, prototyping, and production programming. Its evolution also included a byte-code format (.jbc) for even smaller files, making it suitable for resource-constrained embedded processors. Recently, Altera updated the license terms of the JAM and JBC players source code to MIT-0, to better clarify the usage rights. A Practical Example The CycloMod board is an example of an FPGA and microcontroller working cooperatively. The board combines a Raspberry Pi RP2350 MCU with a Cyclone® 10 LP FPGA in the SparkFun MicroMod form factor. In this board, the FPGA is connected to some of the edge connector I/O, while the RP2350 is used to provide a flexible USB interface. The boot ROM in the RP2350 is leveraged extensively for firmware and FPGA image updates. Figure 2. CycloMod Board At 22mm x 22mm (including the card-edge connector), the MicroMod form factor is quite compact. This necessitates sharing resources, as there is not much room for multiple oscillators or flash devices. The 12 MHz crystal oscillator in the RP2350 is easily shared by routing it to one of the GPIO clock outputs. Both the Cyclone 10 LP device and RP2350 rely on external storage, but this can also be shared. On this board, the flash is connected to the RP2350 to take advantage of the UF2 loading provided in the boot ROM, and the RP2350 loads the Cyclone FPGA. The Cyclone 10 LP device supports active configuration with an external SPI flash device, but it can also be configured/programmed passively through JTAG. Figure 3. CycloMod Block Diagram The STAPL byte code format (sometimes referred to as JBC) is compact enough to be used with microcontrollers like the RP2350. Altera provides source code for implementing the “players” to process these files in embedded systems. They offer players for the ASCII (JAM) and bytecode (JBC) versions of the files. Altera’s Quartus® software provides the option to generate JAM and JBC files. Since STAPL is a JEDEC standard, other FPGA vendors also support generating these files. Using the open-source code provided by Altera, the RP2350 is able to read a JBC file from flash and load the Cyclone 10 LP FPGA through the JTAG interface. A Python script is provided to convert the JBC files to the UF2 format, which the RP2350 uses for drag-n-drop programming. The script also adds a header with the file length and other details. Thanks to the ingenuity of the UF2 format created by Microsoft, this enables cross platform field updates with zero software to install. Results and Link to Source Porting Altera’s JBC player to the RP2350 eliminated the need for a second flash device and enabled user-friendly drag-n-drop FPGA updates. The port is available on GitHub if you want to use this in your system. https://github.com/steieio/pico-jbc
27 days ago0likes
The expanded Agilex™ 5 D-Series FPGA and SoC family delivers a big leap in capabilities for mid-range FPGA applications, offering up to 2.5× more logic, memory, DSP/AI compute, and up to 2× external memory bandwidth. These enhancements make it ideal for designs that demand high compute performance in power and space-constrained environments.
29 days ago1like
We’re gearing up for AOC 2025! From December 9–11, we’ll be at the Gaylord National Resort & Convention Center in National Harbor, Maryland for AOC2025—one of North America’s premier events dedicated to electronic warfare and radar. Visit us at booth #505 to discover the latest innovations in our Agilex™ 9 Direct RF and Agilex™ 5 product families. What to Expect at Altera’s Booth #505: 1. Wideband and Agility Demo using Agilex 9: Overview: Discover the power of frequency hopping with Altera’s Direct RF FPGA, enhancing system resilience and adaptability. Key Features: Demonstrates swift frequency changes and wideband monitoring. 2. Wideband Channelizer Demo using Agilex 9: Overview: Wideband Channelizer features polyphase filter and 65 phases FFT blocks with variable channel support. Key Features: Demonstrates sampling rate that supports 64 GSPS with 32GHz instantaneous bandwidth. 3. Direction of Arrival Demo using Agilex 5: Overview: Explore Direction of Arriaval estimation and signal detection using AI-based approach with deployment of neural networks. Key Features: Demonstrates neural networks implementation using DSP Builder Advanced Blockset (DSPBA), showcasing end-to-end operation running real time inference. 4. Altera COTS Partner Showcase: Come see our Agilex based COTS boards from partners including Annapolis Microsystems, CAES, Hitek, iWave Global, Mercury Systems, & Spectrum Controls. We are hosting customer meetings at the event, contact your local Altera salesperson to schedule a slot.
1 month ago0likes
5 MIN READ
The computing world is hitting a wall. As AI models grow to trillions of parameters, as in-line databases scale to massive sizes, and as high-performance computing (HPC) workloads push bandwidth and memory to their limits, the need for more efficient data movement has never been greater. Traditional approaches to scaling bandwidth and capacity can’t keep pace without unsustainable cost expenditures on power usage and infrastructure build-out. Compression offers a practical and elegant solution to this challenge. By reducing the size of data that moves across interconnects, we can stretch bandwidth, improve memory efficiency, and lower system power—all without requiring a fundamental re-architecture. The Open Compute Project (OCP) has recently recognized this reality, highlighting compression as a key enabler for modern workloads. The combination of ZeroPoint Technologies (an Altera Partner), advanced compression IP, and Altera’s CXL Type 3 IP and FPGAs results in a 2–3x increase in bandwidth, giving the industry a proven path to meet the growing demand head-on. The Problem: Data Bottlenecks in Today’s Workloads AI and LLMs Large language models are exploding in size—parameters have grown from millions to billions, and now to trillions, in just a few short years. Training and inference of these models are fundamentally constrained by memory bandwidth and capacity. Without compression, these models would require even larger amounts of data movement, which increases latency, power consumption, and cost. In-line Databases Databases are increasingly run in-line with applications, from analytics pipelines to transaction processing. These in-line databases demand high throughput and low-latency access to massive datasets. Without compression, systems are forced to overprovision bandwidth and memory resources, dramatically increasing the total cost of ownership (TCO). High-Performance Computing (HPC) From climate modeling to genomics, HPC workloads require immense amounts of parallel data movement. Without compression, HPC centers must continue scaling raw interconnect bandwidth, which is unsustainable in terms of energy and cost at exascale levels. CXL Expansion (CXL Device Type 3) CXL (Compute Express Link) has emerged as the industry-standard protocol for memory pooling and expansion. Yet, as more systems adopt CXL for disaggregated memory, the sheer volume of data moving across CXL links risks overwhelming interconnect bandwidth. Without compression, the benefits of CXL expansion hit a hard ceiling. Demo Video: ZeroPoint demonstrates 2–3x increased bandwidth using its CXL compressed memory tier solution at the Future of Memory and Storage (FMS) 2025 CXL Acceleration (CXL Device Type 2) Beyond memory expansion, CXL enables accelerators to share memory seamlessly with CPUs. But in accelerator-heavy environments, data transfer volumes explode. Lack of compression makes accelerator scaling inefficient, power-hungry, and cost-prohibitive. Contact Altera to see the demo video: 2x–6x higher QPS running a VectorDB workload using a CXL 2.0 interface. Without compression, every one of these workloads faces a bottleneck that would be extremely difficult to solve with hardware scaling alone. OCP Introduces Compression into its Specification The Open Compute Project (OCP) organization recently underscored the importance of compression by including it in its specifications. This is a landmark shift: compression is no longer viewed as optional but included as a supported feature for next-generation compute infrastructure. James Kelly, VP Market Intelligence and Innovation at the OCP Foundation, said: “Within the OCP Community, our Composable Memory Systems Project, leveraging CXL and compression technologies, is driving the development of interoperable, scalable memory architectures that empower AI workloads with unprecedented efficiency and flexibility. By enabling disaggregated memory resources to be pooled and allocated across heterogeneous systems, we’re directly supporting OCP’s Open System for AI strategic initiative, fostering open specifications and standards that accelerate innovation and accessibility in AI infrastructure.” Klas Moreau, CEO of ZeroPoint Technologies, added: “What excites us about working with Altera’s CXL Type 3 IP is not just its performance, but its flexibility. Unlike other FPGA providers, Altera’s CXL solution gives us the low-latency, high-bandwidth fabric we need to showcase the full potential of our compression IP. Together, we’re able to deliver measurable gains—up to a 2–3x effective bandwidth increase—without changing the underlying hardware footprint. That’s a game-changer for customers scaling AI, HPC, and database workloads.” The Solution: ZeroPoint Compression IP + Altera CXL Type 3 IP and FPGA-based Boards ZeroPoint Compression Technology ZeroPoint brings a powerful, low-latency, hardware-efficient compression engine designed specifically for memory and interconnect applications. Unlike general-purpose compression algorithms, ZeroPoint’s IP is optimized for inline operation at wire speed, ensuring data is compressed and decompressed seamlessly without introducing overhead. Key benefits include: High compression ratios across AI, HPC, and database workloads Ultra-low latency to avoid bottlenecks on memory paths Energy savings by reducing data movement requirements Proven scalability across CXL and memory expansion use cases Altera CXL Type 3 IP Altera’s CXL Type 3 IP provides the foundation for memory expansion and pooling. It enables compute nodes to access disaggregated memory resources efficiently and securely. By integrating ZeroPoint’s compression IP, Altera’s solution extends even further—allowing CXL links to move more effective bandwidth, reduce congestion, and scale system capacity without increasing physical resources. There is a wide variety of CXL-capable FPGA-based boards available from Altera or partners. Together: Meeting the Market Need When combined, ZeroPoint’s compression IP and Altera’s CXL Type 3 IP address the OCP-driven specification requirements and solve the core problem facing data-intensive applications, ranging from AI to databases: moving massive amounts of data efficiently. Benefits to customers include: More bandwidth without more lanes: Compression effectively multiplies CXL throughput. Boost performance, cut costs: Unleash untapped performance in your current infrastructure with minimal new investment. Future-proof compliance: Alignment with OCP specifications ensures long-term viability. This combination delivers not just a technology improvement, but a market-ready solution that meets both current and emerging requirements. Conclusion The computing industry is shifting to adjust to new demands. AI, HPC, databases, and disaggregated systems are demanding exponential growth in bandwidth and memory efficiency—growth that hardware scaling alone cannot deliver. One answer is compression. OCP’s inclusion of compression in its specifications validates this direction and creates a mandate for solutions that integrate compression seamlessly with interconnect technologies like CXL. Through the combination of ZeroPoint’s cutting-edge compression IP and Altera’s CXL Type 3 IP, customers can now confidently deploy systems that are not only faster and more efficient but also aligned with the industry’s forward-looking standards. The future of computing depends on smarter ways to move and manage data. Compression + CXL is that smarter way—and with ZeroPoint and Altera, the future is already here. Learn More Presentations or videos are available for on-demand viewing or download: FMS 2025 session (video | slides) OCP 2025 session (video | slides) Next Steps Learn more about Altera’s CXL IP core. For technical details, partnership discussions, or general inquiries, please contact: nilesh.shah@zptcorp.com — CXL compression solutions phillip.swart@altera.com — FPGA-based CXL IP and boards
2 months ago0likes
4 MIN READ
Availability of Quartus Prime Pro Edition 25.3 & the simultaneous release of FPGA AI Suite 25.3 marks a major leap forward in FPGA design productivity. This release delivers smarter tools, deeper insights, and faster compiles, achieving a 6% compile time improvement over 25.1, a 27% reduction since Agilex 7 transitioned to production, as well as improved AI tool ease of use.
2 months ago1like