Recent Content
Possible Incorrect Clock Label in Cyclone IV Handbook Figure 7-8 (DQ/DQS)
Hello Altera Support Team, While studying the DDR output architecture of Cyclone IV devices, I noticed a possible inconsistency in the official documentation. **Document information:** - Document: Cyclone IV Device Handbook, Volume 1 - Document Number: CYIV-5V1-2.2 - Chapter 7: External Memory Interfaces in Cyclone IV Devices - Revision: March 2016 **1. Figure 7-8: Cyclone IV Dedicated Write DDIO** In Figure 7-8 (page 7-14), the clock input to the DDIO registers is labeled **"-90° Shifted Clock"**, while the output is labeled **"DQ or DQS"**. This appears to imply that the same phase-shifted clock arrangement applies to both DQ and DQS output paths. **2. Figure 7-9: Extending the OE Disable by Half a Clock Cycle for a Write Transaction** However, Figure 7-9 (page 7-15) explicitly identifies two different output clocks: - System Clock: outclock for DQS - Write Clock: outclock for DQ, shifted by -90° relative to the System Clock Furthermore, the PLL section on page 7-15 states that the system clock generates the DQS write signals, while the -90° shifted write clock generates the DQ signals during write operations. **3. My question** These descriptions appear inconsistent with the clock labeling in Figure 7-8. Could you please clarify: 1. Is Figure 7-8 intended to represent a generic DDIO structure, with the "-90° Shifted Clock" label applying specifically to the DQ path? 2. For the DQS output path, are its DDIO data registers and output-enable registers clocked by the unshifted System Clock, as suggested by Figure 7-9? 3. If so, should the clock label in Figure 7-8 be corrected or clarified to distinguish the DQ and DQS paths? I would appreciate confirmation of the actual hardware clock connections and whether this is a documentation error. Thank you for your time and assistance.2Views0likes2CommentsQuartus 16.1: Seven no_clock buried registers in cyclonev_jtag — timing model clarification
I would like clarification on seven buried registers reported as having no clock in the cyclonev_jtag timing model. Environment: Quartus Prime 16.1 Standard Edition, Build 196. Device: 5CSXFC6D6F31C6. Board: Terasic DE10-Standard. The design includes a generated JTAG-to-Avalon Master and SLD hub. After running create_timing_netlist, read_sdc, and update_timing_netlist, check_timing reports these seven nodes under “No Clock”: altera_internal_jtag~FF_36 altera_internal_jtag~FF_38 altera_internal_jtag~FF_39 altera_internal_jtag~FF_32 altera_internal_jtag~FF_33 altera_internal_jtag~FF_5 altera_internal_jtag~FF_1 The reported reason is: “No clock feeds this register's clock port.” Tcl queries confirm that all seven nodes belong to cell altera_internal_jtag, with WYSIWYG type cyclonev_jtag. This cell contains 30 buried registers: 23 have clock_edges, while the seven listed above do not. The following direct arcs were identified: FF_36 → tmsutap FF_38 → tckutap FF_39 → tdiutap FF_32 and FF_33 → tdo tdi → FF_5 tms → FF_1 For comparison, the same atom also contains these arcs: tck → FF_4, and tdi → FF_4 tck → FF_0, and tms → FF_0 All pin names above belong to altera_internal_jtag. The altera_reserved_tck clock is already defined by the generated SLD constraints. Could you please clarify: What functions do these seven buried nodes represent in the timing model? Is this a known behavior or limitation of the Cyclone V JTAG timing model in Quartus 16.1? Are additional constraints required? If timing exceptions are appropriate, please provide the supported syntax, exact scope, and applicable documentation. If this is a tool issue, is there a patch or a later version that resolves it? I have not added clocks directly to these buried registers or applied false-path exceptions to suppress the diagnostics. The attached console transcript contains the queries and results. It also includes some initial Tcl query errors, followed by the corrected commands and successful results. These query errors are separate from the no_clock diagnostics. Thank you for your assistance.2Views0likes1CommentUSB-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.488Views0likes13CommentsA5E : high transceiver power consumption?
According to the Power and Thermal analyser for A5E (B) the transceivers running at 10 Gbps (say for 10G ethernet) consume 500mW each. This is more than double the Xilinx, even 7nm... Is the tool wrong ? Have I got the tool set wrong ? is it really this high ? How can I reduce the power consumption of these transceivers down to say 200-250mW ? 4 lanes of PCIe Gen3 and that's 2W of dissipation just to route signals 4" across a PCB.... ???. regards124Views0likes2CommentsAbout Single Event Upset (SEU)
The target devices are MAX 10, Cyclone 10 LP, Cyclone V, and Agilex 3. I would like to confirm the details about SEU for these devices. Question 1: Please explain how the FIT value shown in the "Projected SEU FIT" report for a project in Quartus is calculated. We are being asked, “What is the basis and condition under which this number is derived?” Since our competitors provide this information, we would like Altera to present it as well. I have the following publicly available documents, but since they do not mention any specific calculation formulas, we are making this inquiry. https://docs.altera.com/r/docs/683869/current/an-866-mitigating-and-debugging-single-event-upsets-in-quartus-prime-standard-edition/quartus-prime-software-seu-fit-reports Question 2: Please provide information on the device structure and supporting data (numerical values) regarding SEU tolerance. Since both AMD (Xilinx) and Lattice have disclosed such information, we would like Altera to present it as well. Best Regards6Views0likes2CommentsCyclone-V SCFIFO with M10K/MLAB memory - adding ECC
Hi, I am working with a Cyclone-V 5CSXFC6C6U2317 FPGA and using the MegaWizard's IP FIFO SCFIFO in it. The SCFIFO is for custom logic and is outside of the HPS/ARM/Nios sub-system. My Quartus is 23.1 Prime Standard Edition. From the "FIFO IP User Guide for Quartus® Prime Design Suite: 25.1.1" it looks like I can enable (hard, memory-build in) ECC protection only for Arria 10 devices with M20K memory. My Cyclone-V has M10K memory (and Auto and MLAB memory) . It should be possible for me to add a soft-ECC module in the fabric, either inside the SCFIFO wrapper (from MegaWizard), or outside the SCFIFO wrapper. Has anyone done (or seen in Altera's Github) such a soft-ECC module ( for example using a Hamming SEC-DED (24,16) code or similar) ?169Views0likes8CommentsIs there any way to script the creation of a signal tap instance?
I have been trying to see if it is possible to create a signal tap instance using a scripted approach. For example, create an instance, add some signals from the design using wildcards, setup triggers etc. But I can't seem to find an API for this - does it exist? I have seen that there are scripting APIs for interacting to an existing running signal tap instance, but that isn't what I'm looking for. I could script the creation of a "signal tap logic analyser" IP instance and then instantiate that in HDL code in my design. However that seems quite heavy - adding it do different parts of the design becomes cumbersome and I don't want to keep them in my codebase. The use case is I want to have a collection of debugging nodes that I can conditionally insert and quickly change the configuration of, without cluttering my main RTL. Thanks!171Views0likes8CommentsQuartus® II Web Edition Design Software Version 13.0sp1 for Windows Still Free to Use?
Hi everyone, I am looking into Quartus® II Web Edition Design Software Version 13.0sp1 for Windows for use by a group of students and recently revisited the download page linked below. https://www.altera.com/downloads/fpga-development-tools/quartus-ii-web-edition-design-software-version-13-0sp1-windows I noticed that the download page looks different from what I remember, so I would like to clarify two things: (i) Is the Quartus® II Web Edition Design Software Version 13.0sp1 for Windows, available from the link above, still free to use? (ii) Does downloading the software require first-time users to create an account and provide the requested information on the page that appears after clicking the download button? If so, was this also the procedure in the past, or is it a recent change? I apologise if these questions have been addressed before. I would appreciate any clarification, as I would like to confirm these details before asking the students to download and install the software. Thank you very much for your time and assistance. Regards, OSL35Views0likes4CommentsSystem Console master_read_memory fails above 7688 bytes on Agilex 5 (AXE5-Eagle)
A single master_read_memory of 7689 bytes or more never completes on an Agilex 5. It returns nothing, times out after 60 seconds, and leaves the JTAG channel closed so the next command fails too. 7688 bytes on the same master and the same address returns all 7688 values in under 0.1 second. The boundary is byte exact and repeats every time. I can reproduce this entirely with an unmodified example bitstream published by Arrow, so no design of mine is involved and there is nothing for me to send you. SETUP Board: Arrow AXE5-Eagle, device A5ED065BB32AE4SR0, IDCODE 0364F0DD Bitstream: axe5_eagle_voltage_temp.sof from https://github.com/ArrowElectronics/Agilex-5, path images/promo3/, md5 b391b9cd5226fe92fd2068ddc66f8442 That bitstream was built with Quartus Prime Pro 24.3 and reports "HPS present: FALSE", so it configures straight over JTAG with no bootloader merge and no HPS involvement. It exposes a Nios V node and a JTAG PHY master. Tools: Quartus Prime Pro 26.1.1 build 130, System Console from the same installation, Windows 10 Enterprise LTSC 21H2 Cable: Arrow USB Blaster ARA39943-TEI0004, JTAG clock pinned to 6 MHz, Altera JTAG Server running as a Windows service STEPS 1. Program the board over JTAG: quartus_pgm -c "Arrow-USB-Blaster [ARA39943-TEI0004]" -m jtag -o "p;axe5_eagle_voltage_temp.sof@1" 2. In System Console, open the JTAG PHY master and read: set m [lindex [get_service_paths master] 0] open_service master $m master_read_memory $m 0x0 7688 master_read_memory $m 0x0 7689 RESULT master_read_memory 7688 bytes -> 7688 values in 0 master_read_memory 7689 bytes -> nothing, 60.0 s, then: master_read_memory: This transaction did not complete e is giving up. After the failure the channel is closed and the next command reports "Channel closed" until the service is reopened. Recovering costs 20 to 60 seconds. WHAT I HAVE ALREADY RULED OUT Not the address. Identical behaviour reading from 0x0, 0x1000, 0x10000000 and 0x20000000, and shifting the base by 1, 2, 4 or 4092 bytes at a fixed size changes nothing. Only the requested byte count Not a timeout. Reads return in 0.0 s right up to 7688, then the very next byte fails. A timeout would show times rising as the limit approached, not an instant success becoming an outright fa Not the size of the reply. master_read_32 hands back a 45055 character answer without trouble, while master_read_memory fails while producing a 39044 character one. Not the design. The same byte boundary appears on two other unrelated bitstreams on this board, one with an HPS and one without, built with different Quartus versions. The Arrow example above is simy. master_read_32 IS NOT AFFECTED, AND HAS NO COMP On the same master and the same bitstream, master_read_32 was run at increasing sizes. Every one returned the full count, correctly, with no timeout and no channel closure: master_read_32 $m 0x0 4096 -> 4096 words, 16 kB spanned, 0.5 s master_read_32 $m 0x0 8192 -> 8192 words, 32 kB master_read_32 $m 0x0 16384 -> 16384 words, 64 kB spanned, 2.2 s master_read_32 $m 0x0 32768 -> 32768 words, 128 kB master_read_32 $m 0x0 65536 -> 65536 words, 256 kB spanned, 9.8 s That last one spans 262144 bytes, which is 34 times theead_memory cannot deliver, and it scales linearly at about0.15 ms per word with no sign of a ceiling. If the JTAG link, the Avalon bridge or the reply channel were the constraint, master_read_32 would degrade somewhere across that range. It does not. master_read_32 is therefore a usable workaround, but a slow one: master_read_memory returns 7688 bytes in under 0.05 s, roughly 150 kB/s, where master_read_32 sustains about 26 kB/s. Around 6 times slowp> QUESTIONS Is 7688 bytes an intended limit for master_read_memory on Agilex 5? If so, where is it documented, and does it vary by device family? The same tool version against Arria V hardware is rock solid and sh Whatever the limit is, could an oversized request return an error immediately instead of hanging for 60 seconds and closing the channel? The silent 60 second stall is far more expensive than a reject Happy to run any additional test on this board if neede196Views0likes8Comments
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,408 Topics
- fpga dev tools quartus® prime software pro4,358 Topics
- FPGA Dev Tools Quartus II Software3,131 Topics
- stratix® 10 fpgas and socs1,553 Topics
- agilex® 7 fpgas and socs1,548 Topics
- arria® 10 fpgas and socs1,382 Topics
- stratix® v fpgas1,315 Topics
- arria® v fpgas and socs1,229 Topics
- Configuration1,096 Topics
- cyclone® v fpgas and socs1,058 Topics
Recent Blogs
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.
27 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
27 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
Security requirements are entering a new phase. Systems being designed today may remain deployed for many years, while regulatory expectations, cryptographic standards, and threat models continue to evolve. For designs in industrial, communications, infrastructure, aerospace, defense, and embedded applications, long-term security is becoming a core platform requirement. FPGA-based designs allow designs to meet today’s security needs and evolve with tomorrow’s requirements. Altera is now offering Agilex® 3 and Agilex® 5 devices with PQC-enabled secure boot and configuration support, helping customers prepare for the next generation of security requirements. With the Quartus® Prime Pro Edition 26.1.1 release, customers can begin using a PQC flow that works with Agilex 3 and Agilex 5 based hardware. This milestone extends the security architecture already built into the Agilex platform. Agilex devices use the Secure Device Manager as a hardware root of trust for secure configuration and device management. By combining PQC-capable devices with Quartus software enablement, Altera is helping customers strengthen the FPGA chain of trust as post-quantum requirements move from planning to implementation. The value is immediate and practical. Customers can start designing with supported devices today, while using Quartus 26.1.1 to take advantage of the current software flow. This gives teams a path to address emerging compliance and security expectations without needing a future platform redesign. The same hardware foundation also allows for additional security enhancements over time. Customers designing with PQC-capable Agilex 3 and Agilex 5 devices can benefit from planned software and firmware improvements enabled by the underlying hardware, with no further FPGA hardware upgrade required for those enhancements. Agilex 3 devices bring this capability to power- and cost-optimized FPGA and SoC designs used in embedded, edge, industrial, control, and platform-management applications. Agilex 5 devices extend the same security direction into mid-range FPGA and SoC designs that require higher performance, greater integration, and broader system capability. Post-quantum readiness will continue to advance, and Altera is building that evolution into the Agilex platform roadmap. With PQC-capable Agilex 3 and Agilex 5 devices and Quartus 26.1.1 software enablement, customers have a practical starting point today and a scalable foundation for future security enhancements.
2 months ago0likes