Recent Content
USB-Blaster II malfunction
I’m unable to get a new Altera USB-Blaster II cable working. My setup comprises the Altera 10M08 Evaluation Kit, a Altera USB-Blaster II cable, and Quartus Prime Programmer (Version 25.1std). The USB-Blaster II cable is properly detected by the operating system (Windows 11 Enterprise, Version 25H2). The default JTAG clock frequency is set to 24 MHz. With this setting, the attached evaluation board cannot be detected using Programmer GUI → Auto Detect. After lowering the JTAG clock frequency to 6 MHz and disabling the JtagClockAutoAdjust feature using jtagconfig --debug --setparam 1 JtagClockAutoAdjust 0 jtagconfig --setparam 1 JtagClock 6000000 the MAX 10 FPGA is detected. Programming the FPGA using the Programmer GUI still fails. The programming process is interrupted at random and never completes, even after multiple retries. However, programming is successful when initiated using the following console command: quartus_pgm -c USB-BlasterII -m jtag -o "P;demo10m08.pof" How can I fix this problem? Programming works perfectly when using an Altera USB Blaster or a TERASIC Blaster.592Views0likes16CommentsWhy does the Quartus® Prime Pro Edition Software report Error (170084) for Agilex® 5 Configuration via Protocol CvP designs?
Description Due to a problem in the Quartus® Prime Pro Edition Software version 26.1.1, Error (170084) might occur during the Fitter stage when compiling designs that enable Configuration via Protocol (CvP) with the GTS AXI Streaming IP for PCI Express* for Agilex® 5 FPGA devices because of a control shadow register connectivity problem in the IP. This problem happens when the design enables CvP in the GTS AXI Streaming IP for PCI Express* and in the Device and Pin Options CvP settings is enabled. Designs that do not enable CvP are not affected. You might see an error message similar to the following: Error (170084): Can't route signal "<hierarchy>|...|O_HIO_USER_RX_CLK1_CLK" to atom "<hierarchy>|...|u_ctrl_shadow_loader|avmm_clk_o" Resolution A patch is available to fix this problem for the Quartus® Prime Pro Edition Software version 26.1.1. Download and install patch 1.21 below. This problem is scheduled to be resolved in a future release of the Quartus® Prime Pro Edition Software.Why does the Nios® V/g processor become unstable when both CLIC and shadow registers are enabled?
Description Due to a problem in the Quartus® Pro/Standard Edition software version 26.1/25.1, Nios® V/g interrupt handling might be unstable when both CLIC mode and Shadow Register are enabled. This is because the Shadow Register CSR (msrfstatus) is not saved/restored during interrupt context saving under CLIC mode. Resolution To work around this problem in the Quartus® Prime Pro/Standard Edition Software version 26.1/25.1, follow these steps: Download the machine_trap.zip Extract to get the new machine_trap.S Search for the old machine_trap.S in your BSP project Replace with the new machine_trap.S file Rebuild your software Additional Information This problem is currently scheduled to be resolved in a future release of the Quartus® Prime Pro and Standard Edition Software.Error: CPU "intel_niosv_g_0" has no memories connected to its Avalon host(s)
Description Due to a problem in the Quartus® Pro Edition software version 26.1.1, you might see an error when generating a Nios® V BSP, when the AXI Address Span Extender IP is inserted between the Nios V processor and the memory device connected to the instruction and data buses of the Nios V. This is because the AXI Address Span Extender IP does not recognize the connected device as a memory device for the Nios V processor. Resolution To work around this problem in the Quartus® Prime Pro Edition Software version 26.1.1, follow these steps: 1. Open <QUARTUS_INSTALL_DIR>/ip/altera/merlin/axi_address_span_extender/axi_address_span_extender_hw.tcl 2. Go to around line 448, then delete the lines marked in red and add the lines marked in green as shown below. # this assignment allows this component to appear as a memory target in the Nios II linker script configuration GUI # it makes the memory map of our slave look like a valid linker target memory region # <<to be revisited in 13.0>> - #set_interface_assignment windowed_slave embeddedsw.configuration.isMemoryDevice 1 + set_interface_assignment $slave embeddedsw.configuration.isMemoryDevice 1 # # this assignment allows the macros of components attached to our master to appear in the Nios II system.h header # <<to be revisited in 13.0>> - #set_interface_assignment windowed_slave embeddedsw.configuration.affectsTransactionsOnMasters "expanded_master" + set_interface_assignment $slave embeddedsw.configuration.affectsTransactionsOnMasters $master Please do not include the leading "+" and "-" characters. 3. Regenerate your design in Platform Designer. Additional Information This problem is currently scheduled to be resolved in a future release of the Quartus® Prime Pro Edition Software. However, the updated statements are commented out by default. To apply the changes, remove the comment markers.How to properly constrain bidirectional I2C SCL / SDA ports ?
Hi, We are using an I2C slave controller and like to know how to properly constrain bidirectional SDA and SCL lines to meet setup and hold time requirements. I searched on the internet and cannot find anywhere advising what constraints to use for I2C SDA, SCL bidirectional ports. Will they be also different constraints for eg START, STOP conditions etc? I will appreciate if you can advise with an example of SDC constraints. Our I2C interface within the I2C controller module follows the defined behaviour of a I2C slave in the NXP specification (https://www.nxp.com/docs/en/user-guide/UM10204.pdf) We are using stability check components (checkstable digital filters for the read sda/scl condition to ensure only stable values of SDA and SCL are used by testing over a period of 10 clock cycles (100nS per cycle) that the bit has not changed) for SDA and SCL set to the shortest setting to ensure this works with the 10MHz clock that is used for our FPGA Cyclone V. We are using a higher frequency clock (10MHz) driving state machine i2c_fsm, bus_strobe process etc. The transfer can occur over speed of 100kbits/s in standard mode. Your prompt reply to this matter will be appreciated. Regards, Kevin1.5KViews0likes3CommentsWhy do I see Error (18950), Error (18948) and Error (209012) when program SOF file for Agilex® 5 FPGA device in Quartus® Prime Pro Edition version 26.3 ?
Description You may encounter programming failure in Quartus® Prime Pro Edition Software version 26.3 with an Agilex® 5 FPGA device SOF File. The operation fails with the following errors: Error(18950): Device has stopped receiving configuration data Error(18948): Error message received from device: Failed to load firmware due to authentication failure. Ensure the firmware is signed with the correct signing key. Error(209012): Operation failed Impacted Agilex 5 OPN A5Dx130xxxxxxxx A5Dx160xxxxxxxx Resolution A patch is available to fix this problem for the Quartus® Prime Pro Edition version 26.3. Download and Install patch below. quartus-26.3-0.05fw-windows.exe quartus-26.3-0.05fw-linux.run quartus-26.3-0.05fw-readme.txt Related Article Agilex® 5 FPGA Part Number DecoderQuartus 26.1.1: GTS AXI Streaming PCIe Reset Output Connection Error
Hi everyone, After upgrading from Quartus Prime Pro 25.1.1 to 26.1.1, I encountered a new connectivity error in Platform Designer related to the GTS AXI Streaming IP for PCI Express. The design was working correctly in version 25.1.1. However, after the upgrade, Platform Designer reports the following error: intel_pcie_gts_0.p0_pin_perst_n must be connected to a reset source According to the Altera documentation, p0_pin_perst_n is an asynchronous reset output derived from the PCIe Hard IP's PERST# input. Platform Designer also identifies this interface as a "Reset Output", so it seems inconsistent that the tool requires it to be connected to a reset source. My questions: Is this a known issue or regression in Quartus Prime Pro 26.1.1? Has the handling of p0_pin_perst_n changed between versions 25.1.1 and 26.1.1? Is there a recommended workaround, such as exporting the unused reset output, or is an additional connection now required? I would appreciate any clarification or suggestions. Thanks in advance!54Views0likes3CommentsIntermittent DDM Failure in Quartus 22.4
Currently we utilize Quartus Pro 22.4 to build our project for Arria 10 devices. Recently (last couple of days) our runners and local installs have started experiencing intermittent crashes and failures attributed to DDM (See dump below). In other versions of Quartus Pro that we use (Quartus 24.3.1), a patch was available to fix this problem. However, it appears that 22.4 is not listed as affected by the DDM bug and so I have not been able to find a patch for 22.4. *** Fatal Error: Program termination requested *** *** Below is the stack trace at the time the error occurred. *** The lines beginning "Err Handler" represent frames relating *** to generating this report. *** The point at which the error occurred is somewhere after these lines. *** There may be a few frames representing standard/library code *** before the Quartus frames begin. *** The search for the error should begin with the Quartus frames. *** Unwinder: libunwind *** Stack depth: 15 Quartus 0x174ea: err_terminator() + 0x16e (ccl_err) Quartus 0xaa38c: (stdc++) Quartus 0xaa3f7: (stdc++) Quartus 0xaa6a9: (stdc++) Quartus 0x1221f: void ddm_throw<DDM_RUNTIME_ERROR>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) + 0x16f (ddm_report) Quartus 0x14cdb: DDM_REPORT::DDM_ASSERTION_HANDLER::assertion_error(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) const + 0xcb (ddm_report) Quartus 0x13fbc: DDM_REPORT::ASSERTION_HANDLER::error(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 0x8c (ddm_report) Quartus 0x14bdf: DDM_REPORT::detail::assert_at_line(char const*, char const*, int, char const*, ...) + 0x19f (ddm_report) Quartus 0x14f5e3: ddm_set_lassessor(DDM_T_ASSESSOR*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) + 0x53 (ddm) Quartus 0xe28aa: DMS_MANAGER::DMS_MANAGER() + 0x784 (dni_dms) Quartus 0xe29e6: DMS_MANAGER::get() + 0x7a (dni_dms) Quartus 0xe4d31: _GLOBAL__sub_I_dms_manager.cpp + 0x7f (dni_dms) Quartus 0x11b9a: (ld-linux-x86-64) Quartus 0x11ca1: (ld-linux-x86-64) Quartus 0x113a: (ld-linux-x86-64) Error (22912): Unhandled exception: Fatal Error: Assertion failed tools/cpp/ddm/ddm_assessor.cpp:53: DDM_T::verify27Views0likes2CommentsSOPC Builder reports missing DB9000 Avalon components, but Quartus compilation does not
I am troubleshooting a legacy FPGA design in Quartus II 12.1 SP1 using SOPC Builder.During SOPC Builder system generation, I receive the following errors: db9000avln_mstr_0: Component db9000avln_mstr 1.0 not found or could not be instantiated db9000avln_slv_0: Component db9000avln_slv 1.0 not found or could not be instantiated Additional errors report that the custom Avalon master has no waitrequest signal, cannot be connected to an SDRAM slave that supports backpressure, has a data-width mismatch, and has missing or invalid address-unit settings (SYMBOLS / WORDS). I have located the generated db9000avln.vqm file and copies of the component PTF files. One important observation: although SOPC Builder reports these errors, the Quartus FPGA compilation flow does not report the same component-discovery and Avalon interface errors. I would like to understand the reason for this difference and the correct way to resolve it. My questions are: Why does SOPC Builder report that these components cannot be found or instantiated? Is this typically caused by missing component registration/metadata, an incompatible component definition, or something else? Why can Quartus compilation proceed without reporting these errors? Could it be because the generated db9000avln.vqm netlist is already available and included directly in the Quartus project, allowing Quartus to compile the existing hardware implementation without regenerating the SOPC system? If that is the case, does successful Quartus compilation mean the existing DB9000 logic is being compiled from the .vqm, while SOPC Builder is failing only when it tries to reconstruct or regenerate the system? What is the correct way to restore SOPC Builder generation so that these components can be discovered and their Avalon interfaces validated? How can I determine whether the reported waitrequest, data-width and address-unit errors reflect a genuine hardware-interface incompatibility or only incorrect/missing component metadata? I want to preserve the existing hardware behavior and avoid unnecessary changes to the Avalon interfaces or generated netlist. So can I ignore the SOPC builder issues and move ahead with compilation and programming file generation in Quartus, will that have the functionality of the DB9000 IP implemented. Thank you for your help.64Views0likes7Comments
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,424 Topics
- fpga dev tools quartus® prime software pro4,377 Topics
- FPGA Dev Tools Quartus II Software3,131 Topics
- stratix® 10 fpgas and socs1,558 Topics
- agilex® 7 fpgas and socs1,557 Topics
- arria® 10 fpgas and socs1,387 Topics
- stratix® v fpgas1,316 Topics
- arria® v fpgas and socs1,230 Topics
- Configuration1,102 Topics
- cyclone® v fpgas and socs1,059 Topics
Recent Blogs
Many FPGA designs hit a power wall before they hit a logic wall. The enclosure is sealed, the rack has a fixed power envelope, or the board controller has to run every hour the system is on. In each case, the question is the same: how much work can you fit within the available power budget? The answer is mostly set long before the first power estimate. It’s set by the fabric architecture: how signals are registered, how data moves, and how densely logic packs. That’s where Agilex® 2X does its power work, and it does it differently at each end of the portfolio. Why does power set the limit now? Power used to be a line item checked late in a design. In many systems it’s now the first constraint. Data center line cards and accelerator platforms work inside rack-level power and cooling budgets. Radios and satellite payloads live with thermal limits that don’t move. At the other end, board controllers, motor drives, and root-of-trust devices never switch off, so every milliwatt they draw, they draw all day. Those are two different power problems. A bandwidth-heavy system needs more work per watt. An always-on control system needs fewer watts. A portfolio that solves only one of them sends designers to a new architecture when the requirement changes. Agilex 2X addresses both through the HyperFlex® fabric architecture: 3rd Gen HyperFlex fabric targets performance per watt, while HyperFlex-LP targets low power. How does HyperFlex reduce fabric power at the same frequency? 3rd Gen HyperFlex fabric architecture places registers throughout the routing fabric, enabling efficient pipelining and retiming. As congestion and utilization increase, routing paths can become longer and slower; HyperFlex registers help maintain higher performance under these challenging conditions. Each generation has further refined this approach, as reflected in the performance curve. At the same frequency, Agilex 27 fabric uses approximately 40 percent less power than Agilex 7 fabric.¹ As the chart shows, Agilex 7 made a step of similar size over Stratix 10. Agilex 27 also delivers 1.8X performance per watt versus Agilex 7. Separately, it runs at more than 15 percent higher Fmax, on average, versus Agilex 7.¹ For systems where cooling and power delivery set the limit, the power reduction often matters more than the speed gain. It’s headroom you can spend on the workload. Where else does the power go? 3rd Gen HyperFlex fabric can move large amounts of data across the device. But in bandwidth-heavy designs, implementing wide data movement in soft interconnect consumes logic and routing resources and can increase compile time, leaving fewer fabric resources available for the application workload. Agilex 27 hardens that job in the HyperFlow data network. Data moves across the device at multi-terabit-per-second rates without consuming soft logic or adding routing congestion. Logic packing helps too. Recompile an existing design for Agilex 27 FPGAs in Quartus® Prime Pro Edition Software and it packs 5 to 10 percent more densely, using fewer adaptive logic modules (ALMs). Together, those changes cut the power spent on design infrastructure and leave more of the budget for the application. That shows up three ways: Reaching target performance within rack or enclosure power budgets Reducing cooling and operating costs Giving more of the thermal budget to the workload instead of to moving data What does low power mean for I/O-centric systems? At the other end of the portfolio, the problem changes. A board and rack controller, a motor drive, or an interface bridge rarely needs peak fabric performance. It needs plenty of I/O across a broad voltage range, a small footprint, and a power draw low enough to disappear into the system budget, because it never switches off. That’s the job Agilex 22 is built for, and it’s why Agilex 22 uses HyperFlex-LP, a low-power implementation of the HyperFlex fabric architecture. HyperFlex-LP optimizes programmable logic for lower area, lower power, and higher packing density. It uses the familiar Quartus Prime design flow while tuning the fabric to minimize power. Agilex 22 FPGAs are right-sized for I/O-centric systems, offering high I/O density for board and rack control, motor control, root-of-trust, and interface-bridging applications. Why does one architecture matter for power? Power savings are easy to lose in a migration. A new architecture means new IP, new timing behavior, and new tools. Each change is a chance for the power estimate to drift from what ships. Agilex 2X keeps one architecture and one software experience across every family. Every device is supported by Quartus Prime software, extended by QuartusIQ, the AI expert companion for Quartus Prime software. Design workflows, IP, interfaces, and engineering knowledge carry forward from family to family. The takeaway Power efficiency is decided by the architecture, long before the board is built. Agilex 2X tunes one fabric for two different power problems: more work per watt where bandwidth rules, and lower power where the FPGA is always on. Read the Agilex 27 architecture white paper Notes and disclaimers ¹ Based on Altera’s modelling of Agilex 27 versus Agilex 7 device fabric performance and power. Results may vary. Agilex 2X device architecture and feature descriptions are preliminary and subject to change. Interface support, device options, and performance figures are Altera targets and vary by device. Capabilities and availability vary by family and series.
18 hours ago0likes
Aerospace, defense, and high reliability systems must deliver demanding processing performance while operating in environments where extreme temperatures and mechanical stress can compromise electronics. Developers must also plan for long service lives, supply continuity, and mission requirements that continue to evolve. Altera’s defense-grade Agilex FPGA and SoC FPGA portfolio brings these priorities together. It combines scalable programmable performance with military-temperature and ruggedized packaging options, while U.S. wafer fabrication supports supply resilience. For system designers, that means more ways to balance performance, deployment conditions, and long-term program needs. Designed for harsh environments Defense-grade Agilex devices offer military-temperature options supporting operation from −55°C to +125°C, helping designers target extreme hot and cold environments in applications such as outdoor radar, vehicle-mounted communications, and airborne sensors. A wider specified temperature range can provide more thermal headroom and may reduce heating or cooling needed solely to keep a narrower-rated FPGA within its specified limits, easing size, weight, and power trade-offs. Ruggedized packaging options, including leaded-ball configurations, help address temperature cycling, vibration, and shock in mobile and deployed systems. For customers with tin-lead assembly requirements, leaded-ball options can also avoid a separate reballing step and its associated process-control and qualification burden. Addressing environmental durability and manufacturing compatibility early can reduce the risk of late-stage redesign. Together, these capabilities help designers bring Agilex FPGA performance into demanding mission environments with fewer thermal and manufacturing workarounds. Temperature grades and packaging options vary by device and configuration. Supply resilience for long-life platforms Aerospace and defense platforms often remain in service for many years, making continuity of supply an important consideration. Agilex FPGAs provide a domestic source of wafer fabrication that supports supply resilience and helps customers plan for long program lifecycles. Performance and choice across Hi-Rel applications Defense applications call for different combinations of performance, power efficiency, and integration. The Agilex portfolio spans low-power, cost-optimized Agilex 3 FPGAs, mid-range Agilex 5, high-performance Agilex 7, and Agilex 9 Direct RF-Series FPGAs. This range supports applications from embedded processing for industrial and automotive to high-bandwidth communications, radar, and electronic warfare. Altera’s HyperFlex® architecture supports higher clock frequencies and processing throughput through Hyper-Retiming and Hyper-Pipelining. Alongside FPGA programmability, these capabilities offer a flexible foundation as mission-critical systems integrate more sensing, processing, and AI within constrained platforms. Availability Initial shipments of defense-grade Agilex FPGAs are planned for the first quarter of 2027, with software support targeted for Quartus® Prime Design Software version 27.1. For more information about defense-grade device options, contact your local Altera sales representative.
7 days ago0likes
Meet QuartusIQ Quartus® Prime (Pro Edition, 26.3) introduces the QuartusIQ AI Expert Companion, bringing FPGA expertise and project-aware AI assistance directly into your design workflow. Get guidance where you work, explore design decisions, and connect knowledge with hands-on tasks. Alongside new capabilities in system design, power analysis, and embedded development, QuartusIQ creates a more connected FPGA development experience. QuartusIQ: FPGA Expertise, Closer to Your Design QuartusIQ integrates AI assistance directly into the Quartus GUI, providing access to FPGA knowledge and project-aware guidance within your design environment. You can ask questions, explore design recommendations, and find relevant information without leaving Quartus. QuartusIQ connects to supported LLM providers using your own API key. Beyond general-purpose AI assistance, QuartusIQ combines FPGA-specific knowledge with project summaries to help make questions and recommendations more relevant to your design. Whether you're learning a new tool in Quartus, looking for documentation, or investigating approaches to design closure, this context can help you identify useful next steps. QuartusIQ also supports practical programming and configuration tasks. Analyze and convert programming files, discover connected hardware, and program devices through JTAG. Supports Secure Device Manager (SDM) commands, QSPI compatibility checks, and Remote System Update (RSU) image generation, extending these capabilities to additional device-configuration tasks. For teams exploring AI-assisted development beyond the Quartus GUI, Model Context Protocol (MCP) integration makes QuartusIQ expertise accessible to external AI workflows. And there is also an extension for Visual Studio Code that lets QuartusIQ work with GitHub Copilot. MCP integration and agent capabilities are available, providing additional ways to incorporate FPGA-specific knowledge and tools into connected development environments. Together, these capabilities make QuartusIQ a companion for finding information, understanding your project, and completing tasks, with recommendations you can review and apply to your design. Visual Designer Studio: Keep the System in View Visual Designer Studio (VDS) expands Platform Designer system import to include generic components and parameterized RTL, allowing more of your existing design to be incorporated into a visual workflow. Cross-probing between VDS and other Quartus applications makes it easier to navigate between the system-level view and related design information. Clock/reset fanout simplifies logical hierarchies. Improved separation of source and generated files makes revision control easier to manage. Expanded support for Arria 10, Cyclone 10 GX, and Stratix 10 devices provide greater design flexibility. Board awareness (beta) introduces board-package creation and use within VDS, adding board-level context to the system-design environment. Power & Thermal Analyzer: Streamline Power Analysis Workflows Power analysis is most valuable when it's integrated into the design process. With Tcl scripting and example scripts, Power & Thermal Analyzer makes it easier to automate analysis workflows, maintain consistency, and reassess power consumption as designs evolve. Several usability enhancements simplify working with device resources and analysis results. Device-aware resource filtering and controls help prevent invalid actions, while improved device selection, graphical displays, and numeric alignment make the interface easier to navigate. Common power-analysis reports are now available in the Report Database, providing access to power-analysis results within a familiar reporting environment. HPS is also modeled as a resource rather than a global setting, making its treatment more consistent with other design resources. Embedded Development: Expanded Platform Support and Design Examples Quartus Prime (Pro Edition, 26.3) expands embedded development support with the following: Initial Agilex® 27 SoC Hard Processor System (HPS) enablement, including Simics support and baseline hardware and software reference designs. For Agilex 5 E-Series devices, expanded FreeRTOS support includes Cortex-A76 symmetric multiprocessing (SMP) capabilities, along with the re-release of the bare-metal library. New Agilex 5 E-Series design examples help developers explore a wider range of embedded architectures. These include heterogeneous Linux and FreeRTOS operation using Bao static partitioning, cache-coherent accelerator examples for both operating systems, and Ubuntu and Docker-based Linux configurations. A new bare-metal "Hello World" example provides a simple starting point for development. Updated Nios V design examples include Triple-Speed Ethernet (TSE) designs with FreeRTOS TCP/IP and web-server functionality for Agilex 3 and Agilex 5 devices. Additional enhancements include initial Agilex 27 Nios enablement and soft-processor debug module improvements. Additional Productivity, DSP Builder Machine Learning, and Device Support Enhancements Node Finder improvements include a persistent top-level hierarchy, single-click navigation, and side-by-side search results, making it easier to explore a design while maintaining context. DSP Builder expands machine-learning capabilities with new CNN layers, expanded activation-function support, and AI Tensor DSP optimizations. Enhanced network import, quantization, and automatic sizing simplify implementation, while new demos and MATLAB/Simulink MCP-based agentic workflows support model creation, updates, and verification. Device enablement also expands for Agilex 5 E-Series and D-Series, including additional temperature-grade support for Agilex 5 D-Series devices. AI models with FPGA AI Suite FPGA AI Suite 26.3 expands the tools and capabilities available for developing and integrating AI workloads. Beta features include spatial compiler and developer APIs that enable customers to build CNN and transformer models with examples (ResNet-8, Qwen 3.5, Majika, GPT-neo), and configurable external memory interface (EMIF) connectivity. Additional updates include a new Altera Model Zoo, better integration with the Altera Video and Vision Processing, SoC/x86 profiling, and VDS examples. New production-quality design examples for Agilex 3 Memory-to-Memory designs. These additions provide more options for model exploration, data-path integration, and performance analysis. Explore Quartus Prime (Pro Edition, 26.3) From project-aware AI assistance to enhancements in system design, power analysis, embedded development, and AI workloads, Quartus Prime Pro 26.3 provides new capabilities for your FPGA projects. Visit the Quartus Prime Pro website to learn more. What's New in the Quartus® Prime (Pro Edition) Design Software Download the Quartus® Prime (Pro Edition) version 26.3 Software Learn more about QuartusIQ Read the QuartusIQ white paper Learn more about FPGA AI Suite software Agilex 3 FPGAs and SoCs overview Agilex 5 FPGAs and SoCs overview Agilex 7 FPGAs and SoCs overview
14 days ago0likes
PACKET CLASSIFICATION | FPGA | NETWORKING + SECURITY Every packet decision starts with classification. Routers, firewalls, SmartNICs, security gateways, and service-edge platforms must determine which policy applies before traffic can be forwarded, blocked, inspected, redirected, or prioritized. TCAM earned its place in these systems because it provides predictable lookup behavior and native ternary matching for ACL and LPM workloads. But as policy databases grow, search keys widen, and rules change more frequently, the traditional approach of scaling specialized ternary memory creates tougher tradeoffs in capacity, power, resource utilization, and system integration. Altera Stellar solutions takes a different approach. Instead of scaling packet classification by building ever-larger ternary-memory structures, Stellar turns classification into an optimized search problem that runs on configurable FPGA resources. The result is an FPGA-native path for large, dynamic packet-classification tables without giving up the policy semantics that made TCAM useful in the first place. TCAM scales through memory expansion. Stellar scales through search intelligence. Keep the TCAM semantics. Change the scaling model. Stellar preserves the intent of ACL, LPM, and multi-field classification, but changes how those rules are represented and searched. The Stellar Software Stack organizes policies into optimized graph structures, partitions the rule database, and continuously manages those search structures as the database evolves. The hardware then executes the search using configurable FPGA search engines while rule information is stored in conventional memory resources. Depending on the configuration, Stellar can use on-chip M20K memory, eSRAM, DDR, or HBM. That gives architects more freedom to balance throughput, capacity, latency, power, and FPGA resource use around the needs of the actual system. Use dense memory where it makes sense, and intelligence where it matters A traditional TCAM combines storage and comparison circuitry inside specialized ternary-memory arrays. That architecture delivers deterministic matching, but scaling the table means scaling the specialized comparison structure as well. Stellar separates rule storage from search execution. Ternary information can be represented as value-and-mask data in conventional memory, while graph organization and software-managed optimization direct each search toward the relevant parts of the database. As tables grow from thousands of entries toward hundreds of thousands or millions, this creates a different path for scaling capacity and power. The white paper goes deeper into why this matters, including the tradeoffs between TCAM and Stellar, the role of memory hierarchy, and a set of Stellar configurations spanning different key widths, capacities, memory resources, and projected five-tuple performance. Bring classification into the programmable datapath The value is bigger than the lookup engine itself. Stellar is designed to operate inside the FPGA alongside packet parsing, telemetry, encryption, traffic management, host-interface logic, and customer packet-processing RTL. For system architects, that means classification can become part of the same programmable platform already handling the datapath. A firewall can pair large, dynamic ACL processing with the rest of its traffic pipeline. A router can combine LPM and policy enforcement with programmable networking functions. A SmartNIC can integrate flow classification with offload and customer-specific acceleration. That system-level flexibility is especially relevant for 100GE to 400GE designs where classification must scale without consuming the platform that surrounds it. Read the full whitepaper! The full Altera white paper, Altera TCAM Alternative Solutions Scale Packet Classification to Millions of Rules for Networking Equipment, explains the architecture behind Stellar and the design choices that make it different. It covers TCAM fundamentals and scaling limits, Stellar graph-based search and software partitioning, memory-hierarchy options, configuration examples, quantitative architectural comparisons, dynamic updates, and deployment use cases across networking and security. Read the white paper See how Stellar uses search intelligence, configurable FPGA resources, and a flexible memory hierarchy to create a scalable alternative for large ACL and LPM workloads.
1 month ago0likes
4 MIN READ
September 28, 2026 The next generation of embedded systems will not be defined by compute alone. It will depend on how quickly, reliably, and intelligently systems can move data from the physical world into AI engines and turn insights back into action. That message came through clearly at Embedded World North America 2026, held September 22–24 at the Anaheim Convention Center. For Altera, the show provided an opportunity to highlight a growing collaboration with NVIDIA and demonstrate the role of FPGAs in high-performance edge AI architectures. Connecting sensors to AI with flexibility and determinism At the center of the story was NVIDIA Holoscan Sensor Bridge technology. The solution creates a high-bandwidth, low-latency path between real-world sensors and GPU-based AI processing, an increasingly important capability for robotics, industrial automation, intelligent video, medical systems, and other physical AI applications. FPGAs are well suited to this role because they can provide deterministic processing, flexible I/O, and protocol adaptation close to the sensor. Rather than forcing every application into the same hardware configuration, FPGA-based designs can be tailored to performance, connectivity, and latency requirements of a specific system. In the show’s keynote, NVIDIA Vice President Deepu Talla described the value of this flexibility: “You can select any of the Altera FPGAs depending on the application and pair them with any of the NVIDIA frameworks.” Altera’s post noted that Altera offers Holoscan Sensor Bridge solutions spanning 10G to 100G, where 25G and 100G offer significantly more bandwidth compared to other Holoscan ecosystem partners, helping developers scale connectivity for demanding edge workloads. The result is a practical sensor-to-compute architecture: Altera FPGAs handle the flexible, deterministic front end, while NVIDIA platforms provide the accelerated environment for AI and robotics workloads. An ecosystem approach to accelerating development The demonstrations also underscored that successful edge AI deployments require more than individual components. Developers need reference designs, production-ready boards, and partners that help bridge the gap between evaluation and deployment. Altera’s growing Holoscan ecosystem includes more than 10 reference designs and partner boards. These building blocks can help teams reduce integration effort and move faster from proof of concept to a real-time AI product. One example was on display at Altera partner Critical Link’s booth. Critical Link was recognized as a Best in Show Award winner in the AI & Machine Learning category at the show. Visitors to the booth could see a live demonstration of a 5-camera Holoscan Sensor Bridge solution, using Critical Link’s MitySOM-A5E as the featured Agilex® 5 FPGA hardware platform. The demonstration showed how an Agilex 5 FPGA-based system can help bring sensor data into an NVIDIA-powered AI pipeline while preserving the low-latency, high-bandwidth behavior required by edge applications. From 10G to 100G: Building the data plane for edge AI Altera’s Holoscan Sensor Bridge solutions are designed to make the sensor-to-GPU path faster and more adaptable. A recent Altera technical blog describes 10G, 25G, and 100G reference designs, including a 25G design on Agilex 5 SoC FPGAs for multi-camera sensor data flow and accelerated processing at the edge. In this architecture, the FPGA serves as the data plane: connecting to diverse sensors, aggregating streams, adapting protocols, and preprocessing data before it reaches the NVIDIA GPU. That division of labor helps reduce data-movement bottlenecks while preserving deterministic timing and giving developers room to evolve the system as sensor interfaces and AI workloads change. Altera Technical Holoscan blog for Robotics: Altera Pushes the Boundaries of Edge AI with New Holoscan Sensor Bridge Solutions | Altera Community - 355665 Watch the 25G Holoscan demo video: YouTube/Altera Why the sensor-to-compute path matters As AI moves into physical environments, system designers are balancing several competing requirements: Real-time response: Applications such as robotics and industrial inspection cannot always afford the delay of sending raw sensor data to a remote system. High-bandwidth data movement: Modern sensors generate increasingly rich data streams that must be transported without creating a bottleneck. Deterministic behavior: Safety-critical and industrial systems need predictable timing and consistent performance. Design flexibility: Product teams must support different sensors, interfaces, and deployment conditions without redesigning the entire platform. Faster development: Reference designs and ecosystem partnerships can shorten the path from concept to production. The Altera and NVIDIA approach addresses these needs by combining FPGA-based connectivity and processing with GPU-accelerated AI. It gives developers a modular foundation for building systems that can adapt as sensors, models, and application requirements evolve. Building what comes next at the edge The conversation at Embedded World North America 2026 pointed toward a broader shift in embedded design. Edge systems are becoming intelligent, connected, and increasingly autonomous, but their performance still depends on the data path that feeds them. By pairing Altera FPGAs with NVIDIA platforms and collaborating with partners such as Critical Link, developers gain more options for designing that path. The combination of flexible hardware, high-speed connectivity, and accelerated AI can help transform raw sensor input into timely decisions at the point where data is created. For teams developing the next generation of robotics, industrial automation, intelligent vision, and physical AI systems, this is the opportunity: Build a sensor-to-compute architecture that is fast enough for today’s workloads, flexible enough for tomorrow’s requirements, and ready to scale from demonstration to deployment. Learn more about Altera’s Physical AI-related Solutions: Holoscan: https://www.altera.com/fpga-solutions/sensory-interfaces Robotics: https://www.altera.com/fpga-solutions/robotics-solutions-stack Video: https://www.altera.com/fpga-solutions/video-solutions-stack
1 month ago0likes