Recent Content
New Quartus/Questa license Questa Issue
I received a fulfillment message to generate a new license and the dates are all correct, however Questa FPGA 25.1 does not work. In looking at the new license, I see the Questa version is 2024.8, could this be the issue? Note, the SALT path is set to the correct license file. Support said since I am non-commercial (ASAP partner), I have to post here. This is holding up a project. Below are the license entries. # Questa*-FPGA Edition (License: SW-QUESTA-PLUS), 1 Seat(s) # - Maintenance Expiration of 2024.08 - License Expires 30-Jun-2027 # FEATURE START # The following is the license file for Questa*-FPGA Edition - Questa Plus # Number of seat licenses is 1 # License Expires 30-Jun-2027 DAEMON mgcld path_to_mgcld INCREMENT intelqsim mgcld 2027.01 30-jun-2027 uncounted \ 6FACEB5E7A42A2D9DA1C VENDOR_STRING=D20DAB7F HOSTID=080027cbc9ae \ ISSUER=Altera SN=2109769017 SIGN2="1392 510D 3792 D6DE 281C 2CF3 88E7 \ 20EC A2EE 106B D91A 534D C105 ECD1 CA52 08D5 170B FF42 6DED 5B95 F933 \ 8F24 2872 08A5 FEB3 7ECC 2E3E 81ED 00F5 260B" # FEATURE END8Views0likes2CommentsLPDDR4 not available in NIOSV/g linker script - Agilex-5, Quartus 26.1 Pro
Hello, I have a simple design for Agilex 5, using NIOS V/g and EMIF IP with LPDDR4 memory. I have the NIOS V instruction and data manager ports connected to the EMIF IP. Design compiles Ok. But when I create a BSP, in the linker section, there is not a memory device for the LPDDR4. In this thread, a similar problem seems to be mentioned - issue-with-bsp-creation-for-nios-vm-using-lpddr4-on-agilex-5-quartus-24-1--24-3 Does it mean that Address Span Extender IP must be used in order to have the LPDDR4 show in the linker script section, as an available memory device?Solved158Views0likes7CommentsBER Degradation Observed When Enabling Multiple DFE-Adapted Channels on Arria 10 GX
Hello Altera Support Team / Forum Members, We are currently conducting a comprehensive transceiver channel test on our Arria 10 GX FPGA (part number: 10AX066K4F35M3SG and 10AX066K1F35I1SG). Our test setup and configuration parameters are as follows: Transceiver Configuration Rule: Basic (Enhanced PCS) PMA Configuration Rule: Basic Transceiver Mode: TX/RX Duplex Data Rate: 10 Gbps CDR Reference Clock Freq : 200MHz Number of CDR Reference clocks : 1 Selected CDR reference clock : 0 Test Pattern: External PRBS31 Measurement Tool: Transceiver Toolkit (Quartus Prime 20.2) Test Setup Description: Our system consists of a carrier board, an FPGA board, and a passive loopback connector. The carrier board contains no active components. The FPGA board is populated with various discrete interface components—including SDRAM, SRAM, FLASH, power sequencers, oscillators, clock buffers, and clock generators—to provide all necessary interfaces for the FPGA. The TX channels generated on the FPGA board are routed down to the carrier board, where they are looped back via the loopback connector and returned to separate RX channels on the FPGA. It should be noted that the TX and RX pairs are mostly located in different banks. The trace lengths of each channel along the loopback path vary between 8 inches and 11 inches. Reference Clock Architecture: We generate a 50 MHz signal using an on-board oscillator, pass it through a low-jitter clock buffer, and then feed the buffered output into a clock generator to produce the transceiver reference clocks. For the user clock, we apply a separate 100 MHz oscillator output directly to the Clkuser pin. Observed Behavior: During our test campaigns, we have achieved BER results on the order of 1e‑18 across many of the 36 looped‑back transceivers. In an effort to further minimize errors, we have selected pre‑emphasis, CTLE, and DFE settings within the Transceiver Toolkit that yield a zero‑error condition (i.e., no observed errors). Critical Issue: We are facing a significant inconsistency. When we test the 36 transceiver channels in four separate runs (9 channels per run), with VGA, EQ Control, and DFE parameters already set, we observe no errors for each channel during temperature cycling from 60 °C to 90°C (die temperature) and back down to 60 °C. Under these conditions, the BER remains zero. However, when we increase the number of channels with DFE adaptation enabled to the range of 12 to 15, we begin to observe errors on channels that previously exhibited no errors. Questions: What could be causing this degradation when the number of DFE‑adapted channels is increased? Are we exceeding some power, thermal, or resource limitation? Could there be an interaction between DFE‑enabled channels in adjacent banks or through the shared clocking/power distribution networks? Could this issue be attributed to silicon-level crosstalk between the DFE-adapted channels? More specifically, is it possible that enabling a larger number of DFE-adapted transceivers introduces additional noise coupling or interference within the FPGA silicon, potentially degrading the signal integrity of adjacent or nearby channels? If so, what would be the recommended approach to isolate or mitigate such effects in our current design and test environment? Additionally, we would like to ask: is there a known limitation on the number of transceivers that can reliably support a 10 Gbps data rate simultaneously across a wide temperature range ? Any guidance on debugging or resolving this issue would be greatly appreciated. Thank you in advance for your support. Regards, Onur15Views0likes2CommentsNeed a way to make firmware upgrade
Hello, I'm using altera cyclone with flash and Sram and usb_uart. My goal is to upgrade the commands to the nios processor(upgrade the Nios code) without using jtag. I want the cpu to read its commands from the flash device and If I want to change the commands I will simply write them to the flash using a elf file that will written by the PC to the Flash. after the write, I'll reset the system and the processor would run with the new commands. Is there a way to do that? If so, I would love to get all of the commands that do that. Thanks. asaf1.6KViews0likes5CommentsF2SDRAM fails to synthesize with custom logic
Hello guys, We are using Agilex5 SOC F2SDRAM bridge. I am trying to connect custom logic to the F2SDRAM, but it absolutely refuses to synthesize unless I export the signals directly to the top-level ports. Does anyone know why this is happening? Also, is there an example design for F2SDRAM available? The GHRD is not very helpful since it only includes the JTAG master. I suspect it might be a design issue, so I even removed the adapter and connected it only within Qsys, but it’s still acting up like this. Does anyone know why this is happening even though everything is clearly declared and connected? Hudson52Views0likes12CommentsAI Suite - Why does the Sequential IP not take a model argument?
Hello Altera Community Why does the Sequential IP not take a model argument? When targeting the Spatial IP, there is an argument where you can input your model, which is an xml file (and a bin file), exported using OpenVino. Then it will convert these weights and such to .mif files for the FPGA to load. This is easy to understand. The Sequential IP is a lot harder to understand. I get that the architecture file does all the fpga block related configuration. But I don't understand how it will know which weights to use. Does the Sequential IP only work for the pre defined example graphs?17Views0likes2CommentsCyclone 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, BrianUnderstanding the Purpose of Active Discharge Circuits in FPGA Power Design (Terasic DE10 Reference)
Hello everyone, While reviewing the schematics for a Terasic DE10 board, I noticed a specific circuit block on the power rails. See attached image From my understanding of the schematic, when a specific Enable (EN) signal drops or is disabled, this circuit actively shorts the power rails to ground. My question is regarding the fundamental design here: If the power to the board drops, or the EN signal to the voltage regulators is pulled low, the voltage to the FPGA will naturally stop being supplied anyway. Why is there a need to spend BOM cost and board space on actively shorting the rails to ground? I would love a more in-depth explanation from a board-level design perspective. What exact failure modes or risks does this active discharge circuit prevent in FPGAs? Is this considered a mandatory best practice for all Agilex/Stratix/Cyclone designs, or is it only necessary under specific power supply topologies? Thank you for the insights!21Views0likes2CommentsDedicated Clock Pins for MAX 10
Hello Intel Community, I am currently designing a system using the Intel MAX 10 FPGA, specifically the 10M02SCM153C8G in the compact M153 micro-package. Due to the highly constrained pin resources and the presence of only a single hardware PLL (PLL1) on this device, I need to ensure that my clock network architecture conforms strictly to the hardware requirements to achieve optimal jitter performance and complete phase compensation. My Application Topology: Clock Input: An external reference clock enters the FPGA and drives the inclk0 port of the instantiated ALTPLL IP core. Phase Shift: Inside the ALTPLL, the clock waveform is inverted by 180 degrees. Clock Distribution: This 180-degree phase-shifted clock is split into two destinations: Internal: It drives an internal single-clock FIFO (scfifo) within the FPGA fabric. External: It is routed out through a physical I/O pin to drive an external MCU. My Questions for Intel Support: Dedicated Input Pins: For the M153 package of the 10M02 device, which physical pin numbers are the true Dedicated Clock Input Pins that are directly hardwired to the internal PLL1's inclk0 port, enabling full hardware-level phase compensation (Normal Mode) without introducing routing delays or Quartus compilation warnings? Dedicated Output Pins: To output the 180-degree inverted clock to the external MCU, does this device feature any Dedicated Clock Output Pins (such as PLL external clock outputs) that are physically bonded out in the M153 package? Or are we required to route this clock out via regular user I/O pins through the global clock network? ALTPLL Operation Mode Advice: Considering that this clock simultaneously drives an internal FIFO and an external MCU, which compensation mode (Normal Mode vs. Zero-Delay Buffer Mode) does Intel recommend for the ALTPLL IP core to minimize clock skew and ensure optimal timing closure? Are there any specific parameters (e.g., compensate_clock) that must be explicitly configured to align with the chosen dedicated pins? Any official documentation snippets, device handbook references, or design guidelines regarding the clock routing constraints for this specific micro-package would be highly appreciated. Thank you in advance for your technical assistance! Best regards, Martin.32Views0likes4CommentsError (209014): CONF_DONE pin failed to go high in device 1.
I want to flash a simple led blink code bitstream file in Cyclone V E Dev kit using USB blaster. When I am trying to flash using USB blaster I am getting below error: Error (209014): CONF_DONE pin failed to go high in device 1. Make sure all communication cables are securely connected, select a different device, check the power on the target system, or make sure all nCE pins are connected to GND. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number. I tried to configure the DPI switch below combination: DPI SW1.1 =ON, 1.2 = ON, 1.3=ON, 1.4=ON DPI SW2.1=OFF,2.2=ON,2.3=OFF,2.4=OFF & same switch i tried DPI SW2.1=ON,2.2=ON,2.3=OFF,2.4=OFF DPI SW4.1=ON,4.2=OFF,4.3=OFF,4.4=OFF When I am opening programmer and hardware setup USB Blaster is coming and then I am performing auto detect and it is showing 3 options: 5CEBA7 5CEFA7 5CEFA7ES I choose 5CEFA7 and then change the files and choose configure and the start. But after 32% it is showing failed and i am getting the error message. Can anyone plese suggest do I set the DPI switch correctly or shall I miss anything.
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,348 Topics
- fpga dev tools quartus® prime software pro4,273 Topics
- FPGA Dev Tools Quartus II Software3,143 Topics
- stratix® 10 fpgas and socs1,537 Topics
- agilex® 7 fpgas and socs1,489 Topics
- arria® 10 fpgas and socs1,369 Topics
- stratix® v fpgas1,315 Topics
- arria® v fpgas and socs1,228 Topics
- cyclone® v fpgas and socs1,053 Topics
- Configuration1,023 Topics
Recent Blogs
Agilex® 5 and Agilex® 3 FPGAs now provide native MIPI D-PHY support for CSI-2 camera and DSI display interfaces, making it easier to bring sensor and display data directly into FPGA fabric for real-time processing, aggregation, adaptation, and transport. The blog highlights how scalable MIPI bandwidth, multi-interface connectivity, and integration with the Altera Video Solutions Stack enable high-performance vision, robotics, medical imaging, edge AI, and display systems while simplifying the path from image capture to processing and AI workflows.
14 days ago0likes
The Nios® V/c compact microcontroller is the third and the latest addition to the Nios V soft processor family and is supported in Intel® Agilex®, Intel® Stratix® 10, Intel® Arria® 10, and Intel® Cyclone® 10 GX FPGAs and SoCs. With the Nios V processor, you can easily create a processor and peripheral system using the traditional hardware tool flows like Intel® Quartus® Prime Software and Platform Designer as needed for your production solution.
15 days ago0likes
2 MIN READ
Altera is extending the availability of its Agilex®, MAX® 10, and Cyclone® V FPGA families through 2045 to support long-lifecycle applications like industrial, aerospace, and medical systems. This helps customers avoid costly redesigns and ensures reliable, long-term supply, reinforcing Altera as a trusted partner for decades-long deployments.
24 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.
24 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
1 month ago1like