Recent Content
Why does Fitter show "Dedicated Pin" as "Reference Clock Source by" for downstream PLL in cascade?
Hi everyone, I created a design that connects two PLLs in a simple cascaded configuration. However, I noticed something that seems inconsistent in the Fitter report: In the Resource Section → PLL Usage Summary, the "Reference Clock Sourced by" field for the downstream side PLL shows "Dedicated Pin". This seems unusual because it does not reflect the actual connection (which uses the upstream side PLL’s cascade output). On the other hand, the "PLL Refclk Select" section in the report looks correct and matches the intended cascading setup. Could anyone explain why this discrepancy occurs? Is this normal behavior or a reporting issue in Quartus Prime? Environment: Tool: Quartus Prime Standard Edition version 23.11 Target Device: Cyclone V GX (5CGXFC5F6M11C6) Target IP: "Altera PLL" or "PLL Intel FPGA" Sample Design: Simple_Two_plls_shortest_cascading_refclk_from_clkpin.qar Settings Summary (Only the key parameters are listed.): Upstream side PLL: In [General] tab PLL Mode: Integer-N PLL Operation Mode: Normal Feedback Clock: Global Clock In [Cascading] tab "Create a 'cascade_out' signal to connect with a downstream PLL" : Enabled ( PLL Use As Upstream PLL. → Create cascade_out signal ) In [Settings] tab Bandwidth Preset: Low Downstream side PLL: In [General] tab PLL Mode: Integer-N PLL Operation Mode: Normal Feedback Clock: Global Clock In [Cascading] tab "Create an adjpｌｌin or cclk signal to connect with an upstream PLL" : Enabled ( PLL Use As Downstream PLL → Create adjpll_in or cclk signal ) In [Settings] tab Bandwidth Preset: High Thank you for any insights on this!
MaxV - Current Value
My customer is using MAX V CPLD. Part numbers are 5M1270ZF256C4N, 5M1270ZF324C5N. They have to interface 5V address and data lines of flash memory to these CPLDs. I studied datasheet, it is saying that we can interface 5V signal to Bank-3 IO pins if we use series resister plus internal I/O clamp diodes being enabled. I could not find acceptable current limit for clamp diode from datasheet. So that I can calculate resister value. Can you please provide max and nominal current limit value for internal IO clamp diode which can pass safely through it? Regards amolkumar
Stratix 10 Linux SD card booting
Hi Altera Community, I tried multiple attempts to boot the SD card from Rocketboard.org. https://releases.rocketboards.org/ I downloaded and booted the SD card with the .wic image file. It only has the .itb file by default in the boot partition. Whenever I try to boot, it asks for the U-Boot.img file. And also it says "failed to load "socfpga_stratix10_socdk.dtb" even if the file is there. And then I compiled my simple HPS design and can easily program the FPGA from the Quartus Programmer (rbf and sof file), but whenever I try to overlay it, like say: echo overlay.dtb > /sys/kernel?config?device-tree/overlays/0/path It says "FPGA manager error, timeout," and so on. Does any community member have notes or steps that you made to boot the SD card of the Stratix 10 FPGA? I am following this link: https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderStratix10
Teransceiver & FPGA
Hello, We would like to transmit digital logic signals between multiple FPGA boards over optical fiber. Is it possible to use the FPGA transceivers with SFP or SFP+ modules for this type of application? In addition, would it be feasible to transmit these signals across multiple FPGA boards in a daisy-chain configuration, where each FPGA receives the data and then forwards it to the next FPGA through its transceivers? If so: Which FPGA families or devices would you recommend for this type of architecture? Which communication protocol would you recommend? Is it possible to implement our own custom protocol, or would you advise using a standard protocol instead? Thank you in advance for your feedback. Best regards,
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
Expanding the Nios® V Processor Portfolio
2 MIN READ 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.
Recent Blogs
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.
12 hours ago
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 day 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.
8 days 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.
8 days 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
28 days ago