Recent Content
Agilex-7 AXI MCDMA for PCIe hang
Hi! I'm working with AGIB023R18A1E1VC device and having issues with AXI Multichanned DMA IP for PCIe. Since I require a PCIe bridge, I configured the IP in MCDMA+BAS+BAM mode (PCIe Gen 4, 512-bit), generated an example design, and integrated the subsystem into my project. Although I do not use MCDMA, I rely heavily on the BAS and BAM functionality. The issue I’m seeing is that writing more than 448 bytes to the BAS causes the host to hang and subsequently reset. Notably, between the write transaction and the host reset, the FPGA internal logic is still able to write to the BAS, indicating no hang on the AXI bus. There are no issues with read transactions. We observe this issue not with only one card. At first we run into it in Q25.1 but still have it in Q25.3.1 If you need some captures from the signal tap or any additional details I may provide them. Thank you in advance! Mikhail.314Views0likes12CommentsQuartus Prime Lite 25.1 - Issue with the Verilog generate loops
Hi! I believe, this is the same issue mentioned here, or at least its sibling. Long story short, here is a snippet from the IEEE Std 1364™-2005 standard, page 185: module addergen1 (co, sum, a, b, ci); parameter SIZE = 4; output [SIZE-1:0] sum; output co; input [SIZE-1:0] a, b; input ci; wire [SIZE :0] c; wire [SIZE-1:0] t [1:3]; genvar i; assign c[0] = ci; // Hierarchical gate instance names are: // xor gates: bit[0].g1 bit[1].g1 bit[2].g1 bit[3].g1 // bit[0].g2 bit[1].g2 bit[2].g2 bit[3].g2 // and gates: bit[0].g3 bit[1].g3 bit[2].g3 bit[3].g3 // bit[0].g4 bit[1].g4 bit[2].g4 bit[3].g4 // or gates: bit[0].g5 bit[1].g5 bit[2].g5 bit[3].g5 // Generated instances are connected with // multidimensional nets t[1][3:0] t[2][3:0] t[3][3:0] // (12 nets total) for(i=0; i<SIZE; i=i+1) begin:bit xor g1 ( t[1][i], a[i], b[i]); xor g2 ( sum[i], t[1][i], c[i]); and g3 ( t[2][i], a[i], b[i]); and g4 ( t[3][i], t[1][i], c[i]); or g5 ( c[i+1], t[2][i], t[3][i]); end assign co = c[SIZE]; endmodule Quartus Prime 25.1std.0 Build 1129 10/21/2025 SC Lite Edition reports the error 10170 when attempting to compile this module: Error (10170): Verilog HDL syntax error at main.v(22) near text: "for"; expecting "endmodule". Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number. Error (10170): Verilog HDL syntax error at main.v(23) near text: ")"; expecting ";". Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number. Error (10170): Verilog HDL syntax error at main.v(28) near text: "end"; expecting "endmodule". Check for and fix any syntax errors that appear immediately before or at the specified keyword. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number. Error (10112): Ignored design unit "addergen1" at main.v(1) due to previous errors It accepts it, though, if to embrace the generating loop into "generate/endgenerate" framing. The Verilog version in the project settings is "Verilog-2001". Changing it to "System Verilog" has no impact on the behavior. ========== For comparison, I fed this exact snippet to the Questa Altera Starter FPGA Edition-64 2025.2 and it had no problems with it. ========== So my question is: "What is the root cause of this misbehaving?". Am I understanding the standard wrong? Ot is it some peculiarity of the Quartus itself? Thanks in advance!Solved380Views0likes2CommentsQuarus Prime Installer 24.1 - Error SSL Certificate, Curlcde : 60
Hello, I've got an error during the installation of quartus prime 24.1 : During somes mounths, I uses this solution I've found on the download page. It works great until a few days ago. There s an other solution t use the 24.1 installer now ?111Views0likes6Commentsgetting a licnese
Hello everyone, I just bought my DE10 standard board for my graduation project. Unfortunately, my university doesn't provide a license for the Quartus standard, and I need more than 90 days to finish the project. Is there any way to get a license as a student for free? My project is about an AI accelerator, so I need the standard version; the lite one isn't enough. Thank you,387Views1like6CommentsBeyond TCAM: Scale Packet Classification with Altera Stellar IP
3 MIN READ 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 IP 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's TCAM Alternative Solution for Routers and Firewall Security 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.10Views0likes0CommentsDoes anyone actually use the FPGA AI Suite?
Hello Altera Community My question today is: does anyone actually use the ai suite, and is able to profit from it? I am thinking of vibe coding a micro service with the docker image, such that one can try the compiler and have the output presented nicely. That way they dont have to read the entire manual to try it out. However it does not make sense for me to make it, if nobody will use it. I only know 3 people who have used it, myself, fpga zealot, and one guy on linkedin. Thanks in advance.49Views0likes1Comment[PCIE_DESIGN_EXAMPLE][AGILEX7][QUARTUS25.3.0] - failed at elaboration process
Hello, I am trying to simulate with questa fe the pcie design example (with pipe mode for external dma controller) based on agilex7 generated with quartus pro 25.3.0 but i am facing these issues when i run this script under "pcie_ed_sim_tb/pcie_ed_sim_tb/sim/mentor" as follow : vsim -do run_msim.tcl # ** Warning: (vsim-3008) [CNNODP] - Component name (i_pclk__x16_l0) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_pclk__x16_l0' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_pclk__x16_l0. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_pclk__x4_l12) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_pclk__x4_l12' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_pclk__x4_l12. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_pclk__x4_l4) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_pclk__x4_l4' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_pclk__x4_l4. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_pclk__x8_l8) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_pclk__x8_l8' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_pclk__x8_l8. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_rxpipe0__dirfeedback) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_rxpipe0__dirfeedback' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_rxpipe0__dirfeedback. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Warning: (vsim-3008) [CNNODP] - Component name (i_rxpipe0__linkevaluationfeedbackfiguremerit) is not on a downward path. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 # ** Error: (vsim-3043) Unresolved reference to 'i_rxpipe0__linkevaluationfeedbackfiguremerit' in ftile_s20_v0__pcie__tile_0.z1577b.z1577b_inst.i_rxpipe0__linkevaluationfeedbackfiguremerit. # Time: 0 fs Iteration: 0 Instance: /pcie_ed_sim_tb/dut_pcie_tb_ip/dut_pcie_tb/tile File: ../../../../support_logic/pcie_ed_sim_auto_tiles.sv Line: 34589 ..... I also have followed the Altera recommendations : Note: Due to a problem in the Quartus ® Prime Pro Edition Software version 25.3, you are required to add "-suppress 2732" to USER_DEFINED_COMPILE_OPTIONS and "-suppress 10000 " to USER_DEFINED_ELAB_OPTIONS in the run_msim.tcl simulation script manually for a successful simulation with the Questa simulator. But i am still facing these above issues. What can i do ? Regards, Frederic22Views0likes1CommentRequest about FPGA 10CL025YU256A7G
I wanted to ask you a question about the Altera 10CL025YU256A7G FPGA. We would like to implement a QSPI bus that could operate at a maximum frequency of 166 MHz in DDR mode and at a supply voltage of 3.3 V. In theory, the I/O pins of this FPGA should be able to operate at 200 MHz, so we believe this should be feasible: However, when running simulations with the FPGA acting as the driver, we are encountering some limitations at a 3.3 V supply voltage. While reviewing the FPGA's IBIS file, I noticed that for supply voltages below 3.3 V, the file provides several models that allow the drive strength and slew rate configurations to be adjusted. As an example, below are the available I/O models for a supply voltage of 1.8 V. The number following the letter 'd' indicates the current provided by the buffer (for example, d8 = 8 mA drive strength), while the letters at the end of the model indicate the slew-rate configuration ('s' = slow, 'm' = medium, 'f' = fast). ttl18_cio_d2 ttl18_cio_d4 ttl18_cio_d6 ttl18_cio_d8s ttl18_cio_d10s ttl18_cio_d12s ttl18_cio_d16s ttl18_cio_d8m ttl18_cio_d10m ttl18_cio_d12m ttl18_cio_d16m ttl18_cio_d8f ttl18_cio_d10f ttl18_cio_d12f ttl18_cio_d16f For a 3.3 V supply voltage, the IBIS file provides far fewer models. For TTL, there are two models, one with 4 mA drive strength and another with 8 mA, while for CMOS there is only one model with 2 mA drive strength: ttl33_cio_d4 ttl33_cio_d8 cmos33_cio_d2 This brings me to my question: are there any limitations on the output buffers when operating at a 3.3 V supply voltage? If not, do you have a more complete IBIS file with additional drive-strength and slew-rate models? What we are seeing in our simulations is that, at this supply voltage and a frequency of 166 MHz, the signal quality is somewhat poor from a signal-integrity perspective. The model that provides the best performance is ttl33_cio_d8, but we are seeing relatively slow rise/fall times (greater than 1 ns), which somewhat limits the maximum operating frequency. At lower supply voltages, the availability of models with higher drive strengths results in faster signal transitions, and the signal integrity looks better at the frequency we are targeting. Could you please confirm whether the 3.3 V I/O buffers have any inherent limitations in terms of drive strength or slew rate, and whether a more comprehensive IBIS model is available? Thank you in advance for your help. As additional information, I am attaching a screenshot of the DQS signal generated by the FPGA when operating at 120 MHz. As you can see, the signal already shows some degradation at this frequency: I generated this signal using the TTL33_CIO_D8 model, which provides the best results among the models available for a 3.3 V supply voltage. The other models provided in the IBIS file for 3.3 V have lower drive strength, and the resulting signal is even worse (TTL33_CIO_D4 and CMOS33_CIO_D2). As mentioned in my previous message, at lower supply voltages the IBIS file provides a wider range of models, including models with higher drive strength. This is the reason for our question: is the IBIS model for 3.3 V incomplete, or is there actually a limitation on the output buffer at this supply voltage?39Views0likes1CommentPreconfiguration BSDL Editor for Agilex 7 with disabled F-Tiles
On a design with an AGIA040R39A some of the FHT are disabled. We tried to modify the BSDL file using the “Preconfiguration BSDL Editor for Agilex 7 Devices with F-Tiles” as mentioned here: https://docs.altera.com/r/docs/683748/current/agilex-7-jtag-boundary-scan-testing-user-guide/agilex-7-bst-guidelines This does modify the BSDL file, but the BSDL file it generates (BSR length 3077 bits) doesn't match the boundary scan register length we're detecting in the device (3061 bits). We suspect this is because the BSDL editor doesn't include the options for disabling FHT12B or FHT13B. Would disabling these parts of the device reduce the BSR length by 16 bits? If so, can the BSDL Editor be updated, or a modified BSDL file be supplied?59Views0likes4Comments
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,386 Topics
- fpga dev tools quartus® prime software pro4,335 Topics
- FPGA Dev Tools Quartus II Software3,131 Topics
- stratix® 10 fpgas and socs1,544 Topics
- agilex® 7 fpgas and socs1,531 Topics
- arria® 10 fpgas and socs1,376 Topics
- stratix® v fpgas1,313 Topics
- arria® v fpgas and socs1,227 Topics
- Configuration1,080 Topics
- cyclone® v fpgas and socs1,056 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 IP 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's TCAM Alternative Solution for Routers and Firewall Security 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.
21 hours 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.
4 days 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.
1 month 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.
1 month ago0likes
Altera has started to sample Agilex® 5 D-Series FPGA devices to customers, expanding the Agilex 5 family for customers building higher-performance midrange systems. This adds a second Agilex 5 path alongside Agilex 5 E-Series FPGAs, which are already in full production. Agilex 5 E-Series remains the production-ready choice for power- optimized midrange designs. It is a strong fit when customers need production availability, efficient power, and right-sized capability for applications such as industrial control, edge compute, physical AI, and embedded systems. Agilex 5 D-Series extends the family for designs that need more system performance headroom. It is intended for applications that place heavier demands on signal processing, embedded memory, memory bandwidth, and fabric performance, including broadcast, wireless, video, AI-enabled embedded systems, and higher-performance applications that benefit from memory interfaces such as DDR5 and LPDDR5 capability. One Agilex 5 family, two design paths Agilex 5 E-Series Agilex 5 D-Series In full production Engineering samples available Power-optimized midrange designs Higher-performance midrange designs Right-sized logic and efficient power More DSP, embedded memory, EMIF bandwidth, and higher DDR and LPDDR bandwidth Industrial control, edge compute, physical AI and embedded systems Data Center, Communications, Broadcast, video, and AI-enabled embedded systems Together, Agilex 5 E-Series and D-Series enable customers a clearer way to choose the right midrange FPGA path: production deployment today with E-Series, or higher-performance design evaluation with D-Series. Customers evaluating Agilex 5 D-Series can begin real-silicon design work with Quartus® Prime Pro Edition 26.1.1 support. To order Agilex 5 D-Series engineering samples, please contact your Altera representative. Visit the Agilex 5 D-Series page Visit the Quartus Pro 26.1 Page
1 month ago0likes