Recent Content
GTS Reset Sequencer IP o_refclk_on_ack
Hi, I am using Quartus ver 26.1 PRO Edition and investigating the GTS Reset Sequencer IP. In the figure below, o_refclk_on_ack is described as a pulse. Is there a specified minimum pulse width for this signal? For example, would it be safe to sample this pulse with a 100 MHz clock, or is there a possibility that the pulse width could be shorter than that? 3.7.6. Guidelines for Obtaining the Real-Time GTS TX PLL Lock Status27Views0likes2CommentsQuestions About Custom Linux Device Tree Handling in the Agilex 5 GSRD kas Build Environment
Hello, I have two questions regarding the following kas build environment: https://github.com/altera-fpga/agilex5e-ed-gsrd/tree/main/dk-a5e065bb32aea-enablement/baseline-a55/software/yocto_linux Custom Device Tree Application in FPGA Configuration First Mode My understanding is that FPGA_ENABLE_CORE_PGM, defined in kas.yml, is used to enable or disable FPGA core configuration from HPS, effectively selecting between HPS Boot First and FPGA Configuration First modes. However, when FPGA_ENABLE_CORE_PGM is set to 0 (FPGA Configuration First), I observed that the custom Linux Device Tree specified by CUSTOM_LINUX_DTS_FILE in machine.yml is not applied. After investigating the build flow, it appears that the kernel recipe (linux-socfpga-lts_%.bbappend) checks the value of FPGA_CORE_PGM_ENABLE (which corresponds to FPGA_ENABLE_CORE_PGM) to determine whether a custom Linux Device Tree should be applied. On the other hand, kas.yml also defines CUSTOM_LINUX_DEVICE_TREE, which seems to be the variable specifically intended to control custom Linux Device Tree usage. Therefore, I would have expected the kernel recipe to check CUSTOM_LINUX_DT (which corresponds to CUSTOM_LINUX_DEVICE_TREE) rather than FPGA_CORE_PGM_ENABLE. As an experiment, I made the following changes: 1) Modified the conditional check in the kernel recipe Before: FPGA_CORE_PGM_ENABLE After: CUSTOM_LINUX_DT 2) Set the following in kas.yml CUSTOM_LINUX_DEVICE_TREE = "1" With these changes, the custom Linux Device Tree was successfully applied even when using FPGA Configuration First mode. Could you please confirm whether the current implementation is intentional? If this behavior is by design, could you also explain the reason for using FPGA_CORE_PGM_ENABLE to determine whether a custom Linux Device Tree should be applied? Definition Location of CUSTOM_LINUX_DTS_FILE While reviewing the README located under: meta-custom/recipes-kernel/linux/device-tree/ I found the following statement: "FIT image - kernel.itb will use the custom device tree in CUSTOM_LINUX_DTS_FILE if defined in kas/bsp.yml, else it will use Linux Kernel in-tree device tree defined using LINUX_DTS_FILE in kas/bsp.yml." However, I observed that defining CUSTOM_LINUX_DTS_FILE in kas/bsp.yml does not seem to have any effect. After further investigation, I noticed that CUSTOM_LINUX_DTS_FILE is already defined by default in kas/machine.yml, and it appears that the value from machine.yml is actually being used. In addition, LINUX_DTS_FILE is also defined by default in kas/machine.yml. Based on these observations, I am wondering whether the README might contain a typo, and that the references to kas/bsp.yml should actually be kas/machine.yml. Could you please confirm whether this understanding is correct? Thank you for your time and support.4Views0likes0Comments2.5G Ethernet Reference Porting inquiries.
Hi, guys~ My customer wants to use the 2.5G Ethernet feature, but unfortunately, they purchased the Agilex5 Premium Kit instead of the Modular Kit. I am currently following the R&D guide with them, but the 88E2110 is not being recognized properly. Which parts should we check? First, I followed below link. And have built the Reference Design boot images. https://altera-fpga.github.io/rel-26.1/embedded-designs/agilex-5/e-series/modular-065b/tsn/sgmii_xcvr_3x2.5G/ug-tsn-sgmii-xcvr-3x2.5G-agilex5/ Second, I regenerated the hardware image after updating the Modular design pinout to match the Premium Kit specs. In the Premium schematic, the 88E2110 PHY reset pin is connected to the FPGA, but there was no control logic applied. So, I added logic to release the reset after 20 ms. Third, in the device tree, I enabled emac0 and disabled emac1 and emac2. Since the soft MDIO logic remains unchanged, the addresses shouldn't have changed. However, while the emac0 logs appear, the PHY is still not being recognized. Please refer to the attached boot log. Why did they use soft MDIO instead of the native EMAC0 MDIO? Is this a characteristic of 2.5G Ethernet?DK-DEV-AGI027RES Install Package
I'd like to download an old outdated install package. It is for DK-DEV-AGI027RES. The link was removed a while back. Can someone at Altera please find the install package for me? A .qsf file with all the pinouts (e.g. golden_top.qsf in the install package) defined would work too.219Views0likes8CommentsIntermittent DE10-Standard error starting GDB server with quartus_hps
Hello, We have 15 DE10-Standard boards being used with Quartus 18.1 and the associated version of Altera Monitor Program on Ubuntu 24.04 (amd64). Generally the boards work without issue, however in the Monitor Program we occasionally see 'Download System - Partial Success: The system has successfully downloaded onto the board, but HPS components could not be configured.' Power cycling the board doesn't seem to resolve the error, nor does swapping the board to a different desktop. After a number of tries the error will go away. We haven't been able to isolate an exact pattern but issue doesn't appear random either, it will keep showing up for certain boards, and then go away, then show up on other boards. Another symptom we see is that when a board downloads the systems successfully, during the final step of the process the JTAG TX LED on the board appears to turn solid green. On the boards that hang and fail, the same LED flashes rapidly while the process hangs. The monitor program logs show the following commands are run before the error appears: $ /home/$USER/DE10/monitorprogramtutorial/ $ make clean # The board name in quotes below is variable and appears to be unique to each board or connection $ /opt/intelFPGA_lite/18.1/quartus/bin64/quartus_pgm -c "DE-SoC [1-10]" --auto $ quartus_pgm -c "DE-SoC [1-10]" -m jtag -o "P;/opt/intelFPGA_lite/18.1/University_Program/Computer_Systems/DE10-Standard/DE10-Standard_Computer/verilog/DE10_Standard_Computer.sof@2" $ quartus_hps --cable="DE-SoC [1-10]" -o GDBSERVER --gdbport0=3212 --preloader=/opt/intelFPGA_lite/18.1/University_Program/Monitor_Program/arm_tools/u-boot-spl.de10-standard.srec --preloaderaddr=0xffff14f0 Running these commands manually results in the final command either: 1. Starting a GDB server very quickly: >>Resetting HPS. >>Downloading preloader....... >>Program loaded. PC set to program entry (0xFFFF0000) >>Setting vector base address register to: 0xffff0000 >>Running preloader.. >>Preloader successfully run. Starting GDB Server. Listening on port 3212 for connection from GDB 2. Hanging for a long time when 'Downloading preloader.......' and then failing at the 'Running preloader...................' stage and hanging indefinitely. Ending the process with Ctrl+C shows: Error: Encounter JTAG AJI error while accessing HPS Error: send_access_data() error while accessing DP Register Error: Fail to select Access Port Error: Fail to access Bank 0x0 of Port 1 Error: Fail to READ ACCESS to the Physical Reg Error: AJI failed to send data Error: Encounter JTAG AJI error while accessing HPS Error: send_access_data() error while accessing DP Register Error: Fail to select Access Port Error: Fail to access Bank 0x0 of Port 1 Error: Fail to READ ACCESS to the Physical Reg Error: Fail to enable DEBUG feature Error: AJI failed to send data Error: Encounter JTAG AJI error while accessing HPS Error: send_access_data() error while accessing DP Register Error: Fail to select Access Port Error: Fail to access Bank 0x0 of Port 1 Error: Fail to READ ACCESS to the Physical Reg Error: Failed to load program. Error: AJI failed to send data Error: Encounter JTAG AJI error while accessing HPS Error: send_access_data() error while accessing DP Register Error: Encounter JTAG AJI error while reading Control/Status Register Error: AJI failed to send data Error: Encounter JTAG AJI error while accessing HPS Error: send_access_data() error while accessing DP Register Error: Fail to select Access Port Error: Fail to access Bank 0x0 of Port 0 Error: Fail to READ ACCESS to the Physical Reg Error: Fail to write to MPU Module Reset Register Error: Engine failed to set down the hardware Error: Quartus Prime Programmer was unsuccessful. 0 errors, 0 warnings Error: Peak virtual memory: 187 megabytes Error: Processing ended: Tue Aug 11 11:44:38 2026 Error: Elapsed time: 00:05:05 Error: Total CPU time (on all processors): 00:00:01 Any thoughts or suggestions are greatly appreciated.84Views0likes4CommentsF2SDRAM fails to synthesize with custom logic
Hello guys, We are using Agilex5 SOC F2SDRAM bridge. I am trying to connect custom logic to the F2SDRAM, but it absolutely refuses to synthesize unless I export the signals directly to the top-level ports. Does anyone know why this is happening? Also, is there an example design for F2SDRAM available? The GHRD is not very helpful since it only includes the JTAG master. I suspect it might be a design issue, so I even removed the adapter and connected it only within Qsys, but it’s still acting up like this. Does anyone know why this is happening even though everything is clearly declared and connected? HudsonSolved281Views0likes20CommentsRun-time errors using EMIF in Agilex 5 NIOS-V design
Hello, I am using Quartus Prime Pro 26.1.1, with the Agilex 5 development board (AXE5-Eagle). I am trying to run the NIOS-V code from the LPDDR4 memory, using JTAG to download/debug. The reset and exception vectors are set to the On-Chip RAM. I used the sample design provided for that board - AXE5 Eagle mipi_hdmi_mira220 and removed everything related to MIPI and HDMI. Added JTAG Uart IP. The resulting sample design is attached (mipi_hdmi_mira220.zip). In the software/ directory you can also see the FreeRTOS BSP I used. I created a simple FreeRTOS application that just prints some string to stdout. What I am seeing is - the RISC-V processor throws exceptions - one of the following - Misaligned Read Address, Misaligned Write Address or Invalid Instruction. This happens in alt_load_section(). If I execute step-by-step, no exception is thrown. But if I just run the application it fails. Is there something else that need to be added/updated/changed, in order to be able and execute code from LPDDR4 using the EMIF IP? I could not find any existing sample design, using NIOS-V and EMIF, with code execution from EMIF. Thank you, D.126Views0likes3CommentsNios V/g load-writeback hazard
Summary On a NiosV/g core, a long-latency load from an on-chip memory immediately followed by a short-latency load from the core's own TCM returns the TCM load's data in both destination registers. The first load's writeback is lost. lw a0, 0(t0) # t0 -> On-chip memory lw a1, 0(t1) # t1 -> DTCM (core-local) # a0 and a1 both end up holding the DTCM value Inserting a single instruction between the two loads is enough to avoid it. Two on-chip memory loads back to back are fine, and so is the reverse order (TCM load first, then the on-chip memory load). Minimal reproducer Assembly: _start: lui t0, 0x40 # t0 = 0x00040000 on-chip memory ("input memory") lui t1, 0x10 # t1 = 0x00010000 DTCM (core-local) lui t2, 0xe0 # t2 = 0x000e0000 2nd on-chip memory ("output memory") li a2, 0x47414c47 # a value distinct from the DTCM sentinel sw a2, 0(t0) # ...store it into input_mem nop # let the store retire. The hazard is about two nop # adjacent *loads*; keep everything else well nop # clear of the pair below so the test stays nop # unambiguous. lw a0, 0(t0) # long-latency load: on-chip memory (input memory) lw a1, 0(t1) # short-latency load: DTCM, immediately after sw a0, 0(t2) # output_memory[0] = result of the AXI load sw a1, 4(t2) # output_memory[1] = result of the DTCM load spin: j spin System details NiosV/g data_manager (AXI master) is directly connected to on-chip memories and pipeline stages are limited to 3 in Platform Designer.13Views0likes1CommentCyclone 10 LP Bitstream Compression Failing
I am using the Altera Cyclone 10 LP Development Kit with the 10CL025YU256I7G Device. Do do the design, I am using Quartus Prime Version 24.1 Standard. I am trying to compress my bitstream in order to have a faster configuration. I am using Active Serial with the on-board flash device. Altera documentation suggests two ways of performing the compression: Cyclone 10 LP bitstream compression I can get the compression to work using the 2nd way, where the .sof file is compressed during "Convert Programming Files" by accessing the file properties. The 1st suggested way of compression is not working: "To enable compression before design compilation: Click Assignment Menu > Device. Select the appropriate Intel ® Cyclone ® 10 LP device and then click Device and Pin Options. In the Device and Pin Options window, select Configuration under the Category list and turn on Generate compressed bitstreams. Click OK." The checkbox for "Generate compressed bitstreams" is checked, but after compilation, the .sof file is not compressed and configuration takes the same amount of time as when the checkbox is not checked. Why is this occurring?Solved82Views0likes3CommentsReg SoC Example without using Linux
Team, Just want to understand do we have any SoC example or steps for implementing SoC without using Linux, as customer is Xilinx legacy user and they are implementing and running System-on-Chip (SoC) on a Xilinx FPGA without using Linux. Regards amolkumar135Views0likes5Comments
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,361 Topics
- fpga dev tools quartus® prime software pro4,308 Topics
- FPGA Dev Tools Quartus II Software3,131 Topics
- stratix® 10 fpgas and socs1,542 Topics
- agilex® 7 fpgas and socs1,514 Topics
- arria® 10 fpgas and socs1,374 Topics
- stratix® v fpgas1,312 Topics
- arria® v fpgas and socs1,226 Topics
- Configuration1,063 Topics
- cyclone® v fpgas and socs1,055 Topics
Recent Blogs
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.
20 days 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.
25 days 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
25 days ago0likes
Quartus® Prime Pro Edition 2026.1.1 expands memory options across the Agilex® FPGA portfolio. Memory is increasingly setting the performance, power, and lifecycle limits of modern systems. AI acceleration, packet processing, storage, video, industrial automation, and edge computing all depend on moving large amounts of data efficiently. At the same time, memory availability and vendor transitions can force design teams to revisit component choices long after a platform architecture has been selected. With Quartus® Prime Pro Edition 2026.1.1, Altera expands memory options across the Agilex portfolio. The release brings higher-speed DDR5 and LPDDR5 options to Agilex 7 M-Series FPGAs and SoCs, broadens component choice through documented LPDDR5X device support, and extends LPDDR5 support to Agilex 3 FPGAs and SoCs. Together, these enhancements give designers greater flexibility to balance performance, power, footprint, memory cost, and supply continuity. What is new with Quartus Prime Pro Edition 2026.1.1 Enhancement Customer value DDR5-6400 and LPDDR5-6400 on Agilex 7 M-Series devices Higher Memory Bandwidth Raises the maximum supported memory data rate from 5600 to 6400 MT/s, an increase of more than 14%. DDR5 delivers up to 204.8 GB/s of aggregate bandwidth, while LPDDR5 provides a lower-power, compact-footprint option for bandwidth-intensive designs. LPDDR5X device use in LPDDR5-compatible mode New Sourcing Option Adds sourcing flexibility when LPDDR5 availability, or component strategy favors an LPDDR5X device. LPDDR5 now available for Agilex 3 devices New Memory Support Added Brings a modern low-power memory option to power- and cost-optimized Agilex 3 device configurations. Two 6400 MT/s paths for high-performance systems Agilex 7 M-Series FPGAs and SoCs already combine high logic density, high-speed connectivity, and advanced external memory functionality in a device family available today in full-volume production. Quartus Prime Pro Edition 2026.1.1 strengthens that family’s offering with DDR5-6400 and LPDDR5-6400 in approved configurations. For DDR5, the move from 5600 MT/s to 6400 MT/s increases the maximum data rate by more than 14%. That additional throughput can help AI, networking, storage, and infrastructure designs sustain higher data movement without expanding the FPGA footprint. It can also give architects more flexibility in how they meet a target bandwidth, including the potential to optimize channel count, DIMM selection, board space, and subsystem complexity when the application and supported configuration allow it. LPDDR5-6400 brings a second option to the same top-line interface rate. LPDDR5 is increasingly relevant beyond mobile products because it combines strong bandwidth with lower I/O power and a compact board footprint. Those characteristics are valuable in embedded systems, smart network interface cards, industrial platforms, edge compute, and other designs, where thermal limits and board area matter alongside performance. The result is a high-end FPGA platform that lets designers choose between DDR5 for capacity and server-class memory options, or LPDDR5 for power and footprint efficiency, while reaching up to 6400 MT/s and 204.8 GB/s of aggregate memory bandwidth in selected Agilex 7 M-Series device configurations. LPDDR5X device compatibility adds practical supply-chain flexibility The LPDDR5X enhancement addresses a different customer need. LPDDR5X devices are backward compatible with the LPDDR5 interface, so components can be used with an Agilex LPDDR5 memory interface while operating at the same speeds, voltages, and specifications as the LPDDR5 configuration. Customers can now design with LPDDR5X components in LPDDR5-compatible mode with greater confidence, backed by documented Altera support process. A complete memory offering across the Agilex portfolio Because the Agilex portfolio spans high-performance, mid-range, and power- and cost-optimized devices, customers can carry a consistent FPGA architecture and Quartus development flow across products with very different memory requirements. That continuity helps reduce redesign effort and gives engineering teams more freedom to scale compute, connectivity, and memory together. Teams can preserve DDR4 or LPDDR4 where product requirements, temperature range, or supply conditions still favor those technologies. New designs can move to DDR5 or LPDDR5 for higher bandwidth and better system efficiency. LPDDR5X device compatibility provides an additional sourcing path without requiring customers to redesign a separate memory interface. Explore Agilex FPGA external memory solutions and review the Quartus Prime Pro Edition 2026.1.1 documentation for supported devices, speed grades, memory components, and configurations.
25 days ago0likes
A customer recently shared with me an interesting way they viewed the updated Altera brand: It’s like a long-time friend who had moved away for a few years but is now back and it’s time to get caught up. One of the things customers might want to 'catch up' on is Altera's efforts with regards to AI. It started when early FPGA products included the first basic digital signal processing (DSP) circuits within the FPGA fabric to improve performance for math-based logic, such as Fast Fourier transforms (FFTs) and finite impulse response (FIR) filters. These early enhancements improved general purpose FPGA-based computing but since 2015, our focus has shifted to improving AI capabilities in both silicon and software tools. DSP capabilities have gotten more sophisticated (fixed point, floating point, small and large bit precisions, etc.) and the quantity of available DSPs within a single device, have increased dramatically. Modern FPGAs are now capable of handling complex equations, especially those needed with the introduction of AI. This historical reminisce catches us up all the way until today’s news, where the latest Altera FPGA family is now broadly available to any customer who wants it; Agilex™ 5 SoC FPGAs, the first FPGAs infused with AI tensor blocks throughout the FPGA fabric. A short list of features that would be attractive to embedded or intelligent edge applications include: For those haven’t heard about Agilex™ 5 devices before today, here is how you can get started: Learn about the family. Review technical details. Download FPGA software. Free for anyone wanting access to Agilex™ 5 E-Series devices: Download Quartus® Prime Pro Test drive hardware (generally available now, lead-times may apply, via franchised distributors): Buy Altera development kits or 3rd party boards and SoMs The initial wave of board/SoM options include 9+ variants, with more coming. Evaluate AI or embedded options: Test out the FPGA AI Suite. Contact Altera sales for limited time introductory pricing. Utilize 3rd party tools (Arm DS, MathWorks) to design for the new, best-in-class Arm dual-A76 + dual-A55 based SoC subsystem or RISC-V based Nios® V soft IP processors. Altera is announcing the Agilex™ 5 family broad availability coincident with Embedded World 2024 because it is one of the key markets this mid-range FPGA family was architected for. Embedded customers clearly told us they perceive a lack of adequate compute in embedded processors, see a big need to fill security gaps, and want to add AI into their next generation systems. Agilex™ 5 devices can address all these concerns. Coming back to our initial topic, AI: GPUs are certainly a popular choice for AI training, but power consumption of GPUs for AI inferencing may be too high for intelligent edge or embedded applications. Instead of adding a separate GPU/AI semiconductor device to an embedded system (resulting in higher cost, more power, more thermal, etc.), why not add the AI function into an FPGA already planned to be used in embedded/edge equipment? For decades, FPGAs have been used in embedded/edge and communication systems for real-time control, IO connectivity, or image/data processing. The estimates on Agilex™ 5 device AI performance look good compared to equivalent class competitors. Because the FPGAs new DSP/tensor is implemented in a fine-grained architecture, it provides the FPGA designer the ability to tune for higher performance or lower power consumption, using the minimum amount of FPGA resources for the desired algorithm. Agilex™ 5 devices – AI key figures of merit: Tensor neural acceleration performance: Up to 26 / 56 TOPS ² Better performance per power efficiency versus embedded market inference GPUs. 1.7x higher frames per second per watt ³ Better raw performance versus other AI targeted FPGAs. 69% higher frames per second ⁴ There are many great reasons to look at this new family of FPGAs. If you are an architect, AI developer, or FPGA designer for embedded systems, don’t wait. As Mark Twain famously said, “The secret of getting ahead is getting started.” Don’t believe the marketing hype, try out your ideas in actual hardware, to see what is ‘possible’. Agilex™ 5 SoC FPGAs are just the latest phase in our DSP/AI journey. Altera, accelerating innovators. Come visit us at Embedded World 2024: Altera booth Hall 5, 5-135 and 5-136. Footnotes: Performance per watt: https://edc.intel.com/content/www/us/en/products/performance/benchmarks/agilex-fpga/ Theoretical peak INT8 calculations for the largest density Agilex 5 E-Series or D-Series devices. 1.7x higher frames per second per watt vs. Nvidia Jetson-class GPUs (AGX Orin) 69% higher frames per second vs. AMD/Xilinx Versal AI devices (VE2302)
28 days ago1like