Recent Content
Why 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 Contact Altera Support team for the patch file. Related Article Agilex® 5 FPGA Part Number DecoderWhy does the GTS AXI Streaming IP for PCI Express* on Agilex® 5 FPGA D-Series remain in reset or fail to initialize after system boot?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.3, the GTS AXI Streaming IP for PCI Express* on Agilex® 5 FPGA D-Series devices may not initialize successfully. Devices programmed with a .sof file or an image generated by version 26.3 may exhibit the following symptoms: The PCIe IP remains in reset. The PCIe endpoint fails to enumerate. These symptoms may occur even though device configuration and overall system boot-up have completed successfully. Impacted Agilex 5 OPN A5Dx130xxxxxxxx A5Dx160xxxxxxxx Resolution This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.Cyclone 10LP + EPCQ64A config flash corruption during power OFF
Hello, FPGA: 10CL120YF780C8G Flash: EPCQ64A (it holds an initial FW and later on we switch to an operational FW) Problem: Our operational FW used these settings: I was doing power cycling tests. I saw that sometimes (in 15-30 power cycles) flash data gets corrupted. 1-2 bytes are overwritten with 0x00h. If the corrupted section is in the initial FW region, then board becomes a brick and requires JTAG download of the initial FW again. If the corruption occurs at the operational FW section, then operational FW switching does not work and redownload is needed. We confirmed this by reading back the flash data, and doing hex comparison. Here is one example where one byte in the initial FW section became 0xF8 --> 0x00 which made the board completely not working until the JTAG reprogramming. Corrupted byte address it mostly the same across failures. So the actual corruption location did not appear to be random. Signal integrity, power supplies are checked to be OK This failure does not happen in all the boards we have. But we could not identify a HW issue as the boards operate normally, power supplies are OK and signal integrity are OK. When flash signals are probed, the issue did not happen, pushing me to think that something really on the edge is happening realted to timings etc. Solution we found: Checking with a different operational FW and setting the pins as regular IO after configuration fixed the issue This is tested for 300 cycles and it works Scope measurements: I see a clear difference in behavior between two pin assignment cases. During power OFF, original dpf is trying to communicate with the flash, but “REGULAR IO” dpf does not do that. Support request: As we see this issue happens sometimes, and not on all boards, I think we are exciting an edge case. I could not see a HW difference which can cause this behavior. I know that 0x05h is a valid command to the flash, and if it shifts by one bit it can become 0x02h which is a byte write command. I suspect that sometimes this happens during power OFF and we really write to the flash and corrupt it. I think the clear behavior difference during power off is a strong clue. Could you explain why different assignments cause this behavior difference?15Views0likes2CommentsWhy does the bas_axi_mm_rlast signal of the GTS AXI MCDMA IP not asserted on the final beat of a read burst?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.3 and earlier, the GTS AXI Multichannel DMA IP might fail to assert bas_axi_mm_rlast on the final beat of a multi-beat AXI read burst or may assert it on an earlier beat. This problem occurs in the Bursting Slave (BAS) read-response path for multi-beat PCIe completion, potentially causing an AXI protocol violation or an incorrectly terminated read burst. Resolution This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.Why is there a port width mismatch on d2h_usr_desc_cdt_avail_cnt in the generated top-level wrapper of the AXI Multichannel DMA IP for PCI Express*?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.1.1, the generated top-level wrapper (*_inst.v) for the AXI Multichannel DMA IP for PCI Express* exports an incorrect port width for d2h_usr_desc_cdt_avail_cnt when the D2H Descriptor Engine Credit Interface is enabled. For example, when Maximum D2H Descriptor Fetch (d2h_max_num_desc_fetch_hwtcl) is set to 64, the generated wrapper defines d2h_usr_desc_cdt_avail_cnt as a 6-bit output ([5:0]) instead of a 7-bit output ([6:0]). Resolution To work around this problem in the Quartus Prime Pro Edition software version 26.1.1, manually update the d2h_usr_desc_cdt_avail_cnt port width in the generated top-level wrapper (*_inst.v). The expected port width of d2h_usr_desc_cdt_avail_cnt for each Maximum D2H Descriptor Fetch setting is: d2h_max_num_desc_fetch_hwtcl = 64 --> [6:0] (7 bits) d2h_max_num_desc_fetch_hwtcl = 32 --> [5:0] (6 bits) d2h_max_num_desc_fetch_hwtcl = 16 --> [4:0] (5 bits) This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.5Views0likes0CommentsMissing AC characteristsics in A5E data sheet !
With reference to this link : https://docs.altera.com/r/docs/813918/current/agilex-5-fpgas-and-socs-device-data-sheet/switching-characteristics where are these numbers ? I would like the switching performance of the 1.8V Agilex5 I/O. Is there any AC/DC performance specification anywhere for the HVIO ? -glen67Views0likes2CommentsWhy do I see a generation failure with simulation enabled, or a compilation failure, in the Integrated PHY Dual-Simplex Serial Loopback design example with TX Clock Switching?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.3, you may see the following problems when generating or compiling the Integrated PHY Dual-Simplex Serial Loopback design example with TX Clock Switching enable: Generation failure when simulation is enabled When you enable simulation in the design example, generation fails. There is currently no workaround for this problem. This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software. Compilation failure when simulation is disabled The gxb_tx_refclk_cmd_bus_in[*] ports are missing from the shared_clocks list of the TX QHIP_IP_PROPERTY assignment in the .qsf file. Because of this, compilation fails with the following error: Error (26050): IP instance port name sdi_tx_inst|gxb_tx_refclk_cmd_bus_in[n] for DR_SHARED_CLOCK assignment in dual simplex/reconfiguration group dr_top is not allowed. To fix this compilation failure, follow the workaround in the Resolution section. Resolution To work around compilation problem, user needs to add the gxb_tx_refclk_cmd_bus_in[0] to gxb_tx_refclk_cmd_bus_in[9] ports to the shared_clocks list of the TX QHIP_IP_PROPERTY assignment in qsf file. Example: "shared_clocks" : ["system_pll_clk", "system_pll_lock", "tx_pll_refclk", "gxb_tx_refclk_cmd_bus_in[9]", "gxb_tx_refclk_cmd_bus_in[8]", "gxb_tx_refclk_cmd_bus_in[7]", "gxb_tx_refclk_cmd_bus_in[6]", "gxb_tx_refclk_cmd_bus_in[5]", "gxb_tx_refclk_cmd_bus_in[4]", "gxb_tx_refclk_cmd_bus_in[3]", "gxb_tx_refclk_cmd_bus_in[2]", "gxb_tx_refclk_cmd_bus_in[1]", "gxb_tx_refclk_cmd_bus_in[0]"]}} Save the file and recompile the design.Why does the NVMe device report errors after an HPS warm reset on Agilex® 5 ES devices when FPGA reconfiguration is skipped?
Description Due to a problem in the Agilex® 5 ES devices (A5Ex065BxxxxExxR0 and A5Ex065AxxxxExxR0), the FPGA-to-HPS (F2H) bridge can fail after an HPS warm or cold reset, or after a subsequent FPGA reconfiguration, when the System Memory Management Unit (SMMU) is enabled in HPS Boot First mode. To avoid this, some PCIe* Root Port designs skip FPGA reconfiguration in U-Boot after an HPS warm reset and keep the FPGA configuration from the previous boot. When FPGA reconfiguration is skipped, the PCIe Root Port in the FPGA fabric and the attached Non-Volatile Memory Express (NVMe) endpoint are not reset. They keep stale state from the previous boot. When Linux enumerates the PCIe bus and loads the NVMe driver, the stale state might cause the NVMe admin command to time out and the NVMe driver probe to fail. The kernel log shows messages similar to: nvme nvme0: pci function 0000:01:00.0 nvme nvme0: I/O tag 24 (0018) QID 0 timeout, disable controller nvme nvme0: Device not ready; aborting shutdown, CSTS=0x5 nvme nvme0: Identify Controller failed (-4) nvme 0000:01:00.0: probe with driver nvme failed with error -5 The NVMe device still enumerates and its BAR is assigned, but /dev/nvme0n1 is not created. Refer to the section "FPGA-to-HPS (F2H) bridge, HPS warm/cold reset and FPGA reconfiguration issues with SMMU enabled" in the Agilex® 5 ES Device Errata and User Guidelines. Resolution To work around this problem on Agilex 5 ES devices, reset the PCIe Root Port secondary bus and re-enumerate the PCIe devices from Linux after an HPS warm reset. Run these commands as root: Assert a secondary bus reset by setting bit 6 of the Bridge Control register on the Root Port: setpci -s 00:00.0 BRIDGE_CONTROL=40:40 Wait, then release the reset by clearing bit 6: sleep 1 setpci -s 00:00.0 BRIDGE_CONTROL=00:40 Wait for the link to retrain, then remove the Root Port device: sleep 1 echo 1 > /sys/bus/pci/devices/0000:00:00.0/remove Rescan all PCIe buses: echo 1 > /sys/bus/pci/rescan After the rescan, Linux re-enumerates the Root Port and the NVMe device with clean state. This problem is fixed in Agilex 5 production devices (A5Ex065BxxxxExx and A5Ex065AxxxxExx). Additional Information 00:00.0 is the Root Port bus/device/function in the Agilex 5 PCIe Root Port system example design. Run lspci to confirm the Root Port address in your system and replace 00:00.0 if it differs. The setpci value 40:40 uses the value:mask format, so it changes bit 6 only and leaves the other Bridge Control bits unchanged. The PCI Express® Base Specification requires the secondary bus reset to be held for at least 1 ms, and software to wait at least 100 ms after releasing it before sending configuration requests. The sleep 1 commands above meet both requirements. An FPGA power cycle (cold boot) also resets the Root Port and the NVMe device.Why is there D2H payload mismatch on GTS AXI MCDMA IP?
Description Due to a problem in the Quartus® Prime Pro Edition software version 26.3 and earlier, the GTS AXI Multichannel DMA IP for PCI Express* might transmit D2H data associated with the wrong queue on AXI-Stream TX interface. As a result, the Host may receive data at an incorrect destination address, potentially causing transaction mismatches. Resolution This problem is scheduled to be fixed in a future release of the Quartus Prime Pro Edition software.Why is the HPS I2C SCL clock frequency above 400 kHz in fast mode when using U-Boot?
Description When the HPS I2C controller is configured for fast mode (clock-frequency = <400000>) in U-Boot, the measured SCL frequency might exceed the 400 kHz maximum in the I2C specification (for example, 431 kHz) on SoC FPGA designs. This happens because the U-Boot DesignWare I2C driver (drivers/i2c/designware_i2c.c) calculates the SCL high and low counts from assumed SCL rise and fall times. When the device tree does not specify them, the driver assumes default 300 ns for both in fast mode. The driver subtracts the assumed rise time from the SCL period. If the board's actual SCL rise time is shorter than 300 ns, the unused part of that allowance shortens the period, and SCL runs faster than 400 kHz. The Linux DesignWare I2C driver uses a different calculation and different device tree properties, so the same device tree node can give different SCL frequencies in U-Boot and Linux. Resolution To set the SCL timing to match your board, follow these steps: Measure the SCL and SDA rise times (30%–70%) and fall times (70%–30%) on your board with an oscilloscope, in fast mode. In the U-Boot device tree, add the measured values to the HPS I2C node: &i2c0 { clock-frequency = <400000>; i2c-scl-rising-time-ns = <[measured tr]>; i2c-scl-falling-time-ns = <[measured tf]>; i2c-sda-hold-time-ns = <[required hold, default 300]>; }; For Linux, add the SDA fall time to the same node. The Linux driver uses i2c-sda-falling-time-ns for the SCL high count and i2c-scl-falling-time-ns for the SCL low count, and ignores i2c-scl-rising-time-ns: i2c-sda-falling-time-ns = <[measured tf]>; Rebuild U-Boot and the Linux device tree blob, then re-measure SCL in both U-Boot and Linux to confirm the frequency is at or below 400 kHz and that tLOW ≥ 1.3 µs and tHIGH ≥ 0.6 µs. Note these points when tuning: In U-Boot, enter the actual measured rise time. A larger i2c-scl-rising-time-ns value makes SCL faster, not slower. In U-Boot, i2c-scl-falling-time-ns changes only the high/low duty cycle, not the frequency. In Linux, larger fall-time values make SCL slower. Do not lower clock-frequency below 400000 in U-Boot to slow the bus. Any value below 400000 selects standard mode (100 kHz timing). snps,bus-capacitance-pf has no effect in fast mode. U-Boot ignores it, and Linux uses it only for high-speed mode (3.4 MHz). Additional Information Property U-Boot Linux clock-frequency Sets the target SCL period (default 100 kHz) Selects the speed mode only (default 400 kHz) i2c-scl-rising-time-ns Sets the SCL frequency (default 300 ns in fast mode, 1000 ns in standard mode) Ignored by the DesignWare driver i2c-scl-falling-time-ns Changes the duty cycle only (default 300 ns) Sets the SCL low count (default 300 ns) i2c-sda-falling-time-ns Ignored Sets the SCL high count (default 300 ns) i2c-sda-hold-time-ns Sets the SDA hold time (default 300 ns) Sets the SDA hold time (default: keeps the existing hardware value) snps,bus-capacitance-pf Ignored Used in high-speed mode (3.4 MHz) only
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,415 Topics
- fpga dev tools quartus® prime software pro4,368 Topics
- FPGA Dev Tools Quartus II Software3,131 Topics
- stratix® 10 fpgas and socs1,555 Topics
- agilex® 7 fpgas and socs1,550 Topics
- arria® 10 fpgas and socs1,384 Topics
- stratix® v fpgas1,316 Topics
- arria® v fpgas and socs1,230 Topics
- Configuration1,098 Topics
- cyclone® v fpgas and socs1,059 Topics
Recent Blogs
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
17 hours 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.
30 days 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
30 days ago0likes
1 MIN READ
Altera has begun shipping the new Agilex® 7 M-Series R31G multi-host acceleration package, giving customers a new way to build high-bandwidth systems that connect more hosts while moving more data through the network and memory subsystem. R31G is designed for architectures where data must move quickly between the network, memory, and multiple CPUs, GPUs, or other hosts. By bringing 800G or 2x400G Ethernet together with expanded PCIe 5.0/CXL host connectivity, the package opens new possibilities for AI NICs, storage acceleration, cloud acceleration, and other high-throughput platforms. What R31G enables More network bandwidth: 800G or 2x400G Ethernet capability for high-throughput data paths. More host connectivity: Two PCIe 5.0 x16 host interfaces, or up to four independent PCIe 5.0 x8 connections, with CXL support for flexible multi-host architectures. More memory bandwidth and I/O: DDR5-6400 and LPDDR5-6400 support, up to 204.8 GBps of memory bandwidth, and 768 GPIO in a compact 56 x 45 mm package. The result is a programmable platform that can connect, accelerate, and adapt as infrastructure requirements evolve, while keeping high-speed networking, host connectivity, and memory bandwidth tightly integrated. More network bandwidth. More hosts. More memory bandwidth. One programmable platform. Learn more in the Agilex® 7 M-Series product site.
1 month ago0likes
As AI, cloud, and high-performance computing systems continue to scale, data center operators need more bandwidth within increasingly constrained power and thermal envelopes. Linear Pluggable Optics (LPO) offers an important path forward by simplifying optical modules, reducing power consumption, and lowering latency. LPO places signal-conditioning responsibilities in the host device, allowing the optical module to operate without the DSP used in traditional retimed optics. This architecture can reduce optical module power by 30% to 40%, helping data center designers increase connectivity density while simplifying cooling and thermal management. Altera Brings LPO to the FPGA Market Altera is the first FPGA provider to publicly demonstrate Linear Pluggable Optics interoperability using production FPGA devices. Continued validation with LPO modules from Amphenol and FS further demonstrates the breadth of the emerging ecosystem supported by Altera. Agilex® 7 FPGAs and SoCs bring the power and latency advantages of LPO to programmable platforms used in SmartNICs, data processing units, AI accelerators, and custom infrastructure. The initial public demonstration established that Agilex 7 devices could successfully interoperate with 400G LPO modules. The latest validation advances that milestone by confirming that the implementation meets the performance requirements expected for deployment in demanding data center environments. Validated for Real Deployment Conditions Comprehensive testing confirms that Agilex 7 F-Tile transceivers meet the electrical and link-performance requirements defined by the 100G-DR-LPO specification. The validation demonstrated: Compliance with the required transmit, receive, and link-performance criteria Successful interoperability with LPO modules from Amphenol and FS Successful LPO connectivity across distances from 1 meter to 500 meters Consistent performance across temperature and voltage conditions Measurable performance margin beyond required thresholds Testing covered demanding signal conditions, voltage variation, and temperatures ranging from minus 40 degrees Celsius to 105 degrees Celsius for electrical characterization. Functional link testing included a 1-meter LPO connection, a 100-meter active optical cable, and 500-meter LPO modules from Amphenol and FS. The results demonstrate robust, repeatable operation across multiple module suppliers and link distances, with measurable margin relative to the required performance limits. For customers, this validation provides confidence that Agilex® 7 support for LPO is ready for real-world deployment. Following the industry’s first public FPGA interoperability demonstration, the solution has now been evaluated against LPO performance requirements using modules from multiple suppliers and over link distances up to 500 meters. Together, these results demonstrate a practical foundation for deploying LPO connectivity in next-generation data center systems. More Efficient Connectivity for AI and Cloud Infrastructure The value of LPO grows as data centers deploy more high-speed optical connections. Eliminating the DSP from each optical module can reduce power across thousands of links, simplify optical module design, ease thermal pressure at the front panel, and support lower-latency data movement. Agilex 7 FPGAs add programmability to this more efficient optical architecture. Customers can combine LPO connectivity with packet processing, acceleration, security, telemetry, and evolving protocol support on a single adaptable platform. This flexibility is especially valuable for AI clusters and cloud infrastructure, where workloads, network architectures, and connectivity standards continue to evolve. Validation with multiple module vendors also gives system designers greater flexibility as the LPO supplier ecosystem continues to develop. Ready for the Next Generation of Data Centers The combination of public interoperability and comprehensive validation marks a major step for LPO in the FPGA market. Altera has demonstrated that LPO works with production Agilex 7 devices and validated that the solution meets key LPO requirements with measurable operating margin. This gives customers a proven foundation for evaluating and deploying lower-power, lower-latency optical connectivity in real data center environments. With Agilex® 7 FPGAs, LPO is ready for real-world data center deployment.
2 months ago0likes