Recent Content
USB Device Issue on Cyclone V / HPS
Hello, Please find below a description of the USB issue we are experiencing with our Cyclone V / HPS board. To test our USB interface, we integrated the TinyUSB library into our existing firmware and enabled FreeRTOS support. Since the Cyclone V is not natively supported, I implemented the missing functions using Altera's hwlib, which we already use in our project (source file attached). The USB is used only in Device mode. I tested the following four configurations: Full-Speed with Slave mode Full-Speed with Simple DMA High-Speed with Slave mode High-Speed with Simple DMA The behavior is identical in all four cases: Connecting our board to a Windows or Linux host is correctly detected. The SETUP transaction is successfully received, and the host receives the device descriptor in response. When the IN transfer complete interrupt is triggered, the USB controller is configured to receive a zero-length packet on OUT0. However, the USB protocol analyzer shows that the device continuously responds with NAK to this packet. The host retries for approximately 5 seconds, but the device keeps responding with NAK. The register values immediately after configuring the reception of the OUT0 packet are: Gotgctl = 0xd00c0 Gintsts = 0x4000020 (PTxFEmp, NPTxFEmp) Gdfifocfg = 0x1f802000 Dctl = 0 Dcfg = 0x8100001 Dsts = 0x18702 Doepctl0 = 0x80008000 Doepint0 = 0 Doeptsiz0 = 0x80000 Grxfsiz = 0x50 After a few milliseconds, I observe that DOEPINT0.NAKINTRPT = 1, which seems to confirm that the device is sending NAKs. However, I do not understand why the OUT packet is not being accepted, since the receive FIFO is not full and both DCTL.GOUTNAKSTS = 0 and DOEPCTL0.NAKSTS = 0.
Xcelium Simulation using XRUN with Verilog Configurations defining Library Search Order
I have an AgileX based design using Quartus 26.1.0.110 and Simulating with Xcelium 24.09.005. If I simulate the FPGA entirely standalone using this combination and embracing the xcelium/xcelium_setup.sh approach I can have some success. So I know that everything within the FPGA is resolving. If I attempt to develop a Verilog Configuration for the design by integrating the xmelab run for the resolved libraries found in order to develop my "default liblist" within the Verilog configuration and then migrate the flow to Cadence XRUN it fails. My XRUN environment does NOT have a cds.lib or hdl.var files as they are empty. Everything in this flow is to be governed by the XRUN environment. I need the XRUN flow to run to further integrate this FPGA into a larger multiple Mixed Signal ASICs. Can someone tell me the correct order that should be present in the "default liblist" for a Verilog Configuration? The errors I get are unresolved cells in library where everything inside the rest of the error is inside the encrypted Altera libraries. So it is impossible to debug exactly which cell it is referencing. Something like: xmelab: *E, BILCNF: Cell '{Name Protected*}' not found for instance '{*Name Protected*}' through configuration '{*Name Protected*}' The cell listed was: ip7521serdes_uxs2t1r1gpd_pipe_msvmodelknobmod Has anyone tried this? Could Altera Engineering provided a defined expected library order for the lowest level encrypted libraries? Thanks, Thomas D. Tessier
Cyclone VGT Dev Kit boards - some new boards failing to boot from NOR Flash
We've been using these boards for years, having certified them for use in one of our products. In the last few months we have now received 5 of these boards and they fail to configure from NOR flash. These are all the new Rev B CVGT Dev Kit edition. Not all of the new RevB fail, but the fail rate is high, getting close to 50%. Yes, we know they changed to a Micron NOR flash for Rev B and rerouted some data lines, we are using the new RevB MAX5 files and have updated the Cyclone V NOR flash pins to match as well. I made some diagnostic changes to the MAX5 boot source (I set the PGM leds to count retries) and discovered that on the bad boards, the boot process goes through multiple configuration retries and eventually the watchdog timer fires, turns on the ERR (D5) red LED and stops. With the factory image they come with, there are also dozens of retries, then sometimes the boards fail, sometimes they boot up. With the slow speed that the NOR flash configuration runs at, there is no reason that it should ever fail and retry, and indeed on good boards they configure the first time every time with no retries. The first four we were able to send back to Altera (Via digikey where we bought them). We just got another bad one yesterday, this one from Mouser. Has anyone else seen this issue, and/or heard from Altera about this? Board link: https://docs.altera.com/r/docs/792833/current/cyclone-v-gt-fpga-development-kit-user-guide/kit-features
LVDS Output of FPGA
Hi all, I am using Arria 10 FPGA part number: 10AX066N2F40E1HG for one of my projects. There is a clock output from FPGA that goes to an external chip. This clock is configured as LVDS. Currently debugging an issue, and focused on enhancing the signal quality at the output of the FPGA. The output signal we measure in scope is not as good as we would expect. We expect a step signal, but the testing output shows a triangular signal! I have the following questions. 1) Is there settings/knobs I could tweak in my LVDS IP, or any other ideas to improve output signal quality? ( I learned about pre_emphasis setting), But other ideas could help. 2) Is there an inbuilt tool within FPGA to check the eye diagram or measure the output signal quality?instead of relying on an oscilloscope?. Note: I am using Quartus 2018 standard version. Let me know if you need further information. Thankyou.
Cyclone IV GX PCIe Hard IP behaves differently on Intel Core I7 vs Xeon root complexes
Hello, I am working with a Cyclone IV GX (EP4CGX22) using the Altera PCIe Hard IP configured as PCIe Gen1 x1 with an Avalon-MM interface. The same FPGA image shows different behavior depending on the host platform. Platforms Tested Working Platform Intel Core i7-13700 Windows 11 Platforms Where the Issue Is Observed Supermicro X10SRA + Xeon E5-1620 v3 Supermicro X12SPL-F + Xeon Silver 4309Y PCIe Configuration The FPGA endpoint is configured as PCIe Gen1 x1 The Xeon platforms provide newer PCIe root complexes: Xeon E5-1620 v3 -> PCIe Gen3/4 capable slot Xeon Silver 4309Y -> PCIe Gen3/4 capable slots However, the link correctly negotiates down to: Link Width : x1 Link Speed : Gen1 (2.5 GT/s) which matches the FPGA endpoint capability. Common Observations On all platforms: PCIe enumeration succeeds Vendor ID and Device ID are detected correctly BAR resources are assigned correctly The device driver loads successfully The PCIe link is established successfully TLP as data input getting unexpected value Observed Difference Although the PCIe link is established correctly on all systems, the FPGA observes different transaction behavior on the Xeon platforms compared to the Intel Core i7 platform. The same FPGA image and software stack operate as expected on the Intel Core i7-13700 system, while different behavior is observed on both Xeon-based systems. Questions Are repeated accesses to BAR-space offsets after boot expected from BIOS/UEFI, Windows PCI bus enumeration, or other background PCIe activity? Has anyone observed different behavior between Intel Core desktop root complexes and Xeon/server root complexes when using the Cyclone IV GX PCIe Hard IP? Are there known interoperability issues between older Cyclone IV GX PCIe endpoints and modern Gen3/Gen4 server root complexes, even when the link successfully negotiates to Gen1 x1? Is there a recommended way to distinguish firmware/OS-generated PCIe accesses from accesses generated by the application or function driver? Any feedback or similar experience would be greatly appreciated. Thank you.
ALTPLL - BANDWIDTH OPTION ?
Here is a professional and technically accurate English translation: Hi, I would like to ask about the meaning of the following setting in ALTPLL: Bandwidth - Preset Options: Auto, Preset (Low, L, H), Custom What is the purpose of this setting? I am using the FPGA device 10M02SCM153C8G and implementing an SCFIFO. Due to the signal logic requirements, I need to generate a stable 180-degree phase-shifted version of the signal and feed it into the SCFIFO, as well as to the FX2 IFCLK connected after the SCFIFO. Currently, I am encountering a very rare issue: image tearing (or frame splitting). My system architecture is: sensor → FPGA (FIFO) → FX2 → PC. Although this issue occurs very infrequently, I would still like to explore possible improvements. Previously, the FPGA setting was configured as Auto, and under this condition, the image tearing issue occurred more frequently. After changing the setting to Low, the system became significantly more stable. I am now considering whether to try the Medium setting, but before making further changes, I would like to understand what this bandwidth setting actually controls. Would you like me to refine this into a more formal email style (for vendor support like Intel/Altera), or keep it as a technical discussion tone?MAX 10 PLL Inverted Output Timing Inquiry
Hi, We are using a MAX 10 PLL in normal mode with an output phase shift of 180 degrees to drive the SCFIFO clock. What is the actual clock-to-clock phase relationship and propagation delay between the original pixel clock and the PLL-inverted output clock at the device pins? More specifically, is the 180-degree phase shift ideal at the pin level, or should we expect additional PLL insertion delay, jitter, or phase error that must be accounted for in setup/hold timing?F2SDRAM 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? Hudson
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.
1 month ago 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.
1 month ago
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.
1 month ago
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.
1 month ago
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 ago