Recent Content
CXL 2.0 support on the NEW Agilex™ 7 FPGA I-Series Development Kit (2x R-Tile and 1x F-Tile)
Hello, We are interested for our research in the Agilex™ 7 FPGA I-Series Development Kit (2x R-Tile and 1x F-Tile) and more specifically in its CXL support. The site mentions that the board supports CXL, but is does not specify the version: https://www.altera.com/products/devkit/po-3012/agilex-7-fpga-i-series-development-kit-2x-r-tile-and-1x-f-tile The link that leads to Mouser for buying the DISCONTINUED board (https://mou.sr/4sgT5nd), after clicking to "More Information", indeed states that CXL 2.0 is supported. The link that leads to Mouser for buying the NEW board (https://mou.sr/3NIsCj8) does not have the "More Information" option. From the datasheet, I understand that the device AGIB027R29A1E1VB R-tiles support up to CXL 32.0 GT/s (which implies CXL 2.0): https://docs.altera.com/viewer/book-attachment/pwDuPLTY_A5BDsX8xHSnYA/mgIMz3Gq3QFrvMYNhNiQqA-pwDuPLTY_A5BDsX8xHSnYA Can someone verify that the NEW development kit also supports CXL 2.0? I know that it most probably does, but we need to be 100% sure :) Thank you, dtheodor79
Why I can't open Early Power Estimators (EPE) tool in the latest version of Microsoft* Excel?
Description Due to the legacy design of the Early Power Estimator (EPE) worksheets, which include VBA macros, ActiveX components, and embedded DLL files, errors may occur when opening the Excel file on newer Windows platforms or when using Microsoft* Office 365, in both 32-bit and 64-bit versions. When the spreadsheet is opened, several actions occur in the background. Excel extracts the embedded DLLc files to the user's %TEMP% directory. A script then decompresses the DLLc files into standard DLL files. The script subsequently loads and executes the DLL files, which is used by the Excel macros. Why the issue occurs: To extract and execute the required DLL files, the Excel macros rely on a set of commands provided by Microsoft .NET and Microsoft Visual C++ runtime libraries, depending on the specific version of the Excel worksheet.Additionally, the legacy script design does not support symbolic linking or modern handling of the user's %TEMP% directory, which can cause issues when extracting and accessing temporary files. ActiveX restrictions in newer versions of Microsoft Excel Trust Center policies that block code execution from untrusted locations Operating system security policies in Microsoft Windows that may prevent DLL execution from the %TEMP% directory if such restrictions are enabled As a result, if any of these conditions are triggered, users may encounter errors such as “Unable to find or load DLL files.” For example, errors may appear related to the zlib.dll file (the 32-bit or 64-bit version used depends on the installed Excel architecture). Modern systems also enforce stricter security controls, including: In newer versions of Microsoft Windows and Microsoft Office 365, these runtime components are no longer bundled together by default, and some legacy functions used by older scripts have been deprecated or replaced with newer implementations. As a result, scripts designed for earlier environments may fail when attempting to call these functions. Note: In some systems, some of these are already installed automatically by other 3rd party software tools during installation. Resolution To workaround this issue PART A: Unblocking the Excel and Enable Macros/ActiveX 1. Unblock the Excel File • Right-click the EPE Excel file → Properties → Check Unblock under Security. • Click Apply → OK. 2. Enable Macros and ActiveX • Open Excel → File → Options → Trust Center → Trust Center Settings: Enable Macros. Enable ActiveX controls. Leave other settings as default (Safe Mode can remain enabled or disabled). 3. Check whether you can now open the EPE excel sheet. Else proceed to PART B. PART B: Installing the necessary Microsoft .NET and Visual C++ runtime libraries. Microsoft .NET installation Go to your Installed apps settings and find for .NET. It is recommended to have both .NET Runtime and ASP .NET installed in your system. If you already have a version installed on your machine then proceed to the next step( you only require 1 version each), otherwise refer to this location to download Download .NET 8.0 (Linux, macOS, and Windows) | .NET Example: Microsoft Visual C++ Installation As different EPE Excel sheet relies on specific Visual C++ version, you will need to install multiple versions of Visual C++ for both 32bit and 64bit. This is because even though Excel is running on 64bit, existing scripting might have dependency on 32bit functions as well. Recommendation to install C++ version for both 32 bit and 64 bit as below Latest Supported Visual C++ Redistributable Downloads Visual Studio 2017-2026 Visual Studio 2015 (in older Microsoft release, it might show as C++ V14 or 2015-2022 version) Visual Studio 2013 Visual Studio 2012 Example After installing both 32 bit and 64 bit, do restart the system and then try launching the EPE excel sheet again. In some rare occurrences, you might need to install Visual Studio C++ 2010 , Visual Studio C++ 2008 and Visual Studio C++ 2005. Do refer to PART C first as the issue might not be due to Visual C++ but symbolic link. PART C: Symbolic Link issue workaround (optional) If installing the .NET and Visual C++ runtime libraries still does not help in resolving the error opening EPE Excel, you should check whether your %TEMP% file folder is the same as what reported in the error when opening the EPE excel sheet. If the folder path are different between %TEMP% and the path reported by Excel sheet, it means that they are using symbolic link folder. In this case user should copy the .dll files generated out from the %TEMP% when they opened the excel sheet and copy it over to the Windows SySWoW folder (%windir%\SysWOW64). To access your %TEMP% folder , just type %TEMP% into your explorer and it will open your folder location (%TEMP% is set in windows environment variables) From the %TEMP% folder, there are multiple *epe* DLL files if you open different EPE excel sheets. Copy all of these .DLL files into your Windows SysWOW64 folder and try launching the EPE excel sheet again. Example, if using Cyclone V EPE excel sheet, these are the 4 files required in red box in %TEMP% to be copied over NOTE 1: The SysWOW64 folder is selected because it is part of Windows’ default search locations when required DLL files cannot be found. Alternatively, you can add a custom directory to the Windows Environment Variables (PATH) so that Windows will also search that folder when looking for the DLL files. NOTE 2: Adding the %TEMP% folder into the system environment variables will not have any effect as latest Microsoft Windows have blocked the DLL searching mechanism to prevent search %TEMP% folder as part of the security to prevent remote execution from DLL. Additional Information If all fails, alternatively install Process Monitor from Microsoft to analyze the DLL failure/error 1. Download Process Monitor from this location Process Monitor - Sysinternals 2. Close all excel sheets that is open in Windows. 3. Launch the Process Monitor , then select Filter . Set to Process Name and EXCEL.exe and press add. 4. After adding the filter, ensure that capturing is started 5. Then open any of the EPE excel file,and wait till you get the DLL (eg. epe_zlib_32bit.dll) error then press pause on the Process Monitor 6. Then use Find and search for the dll error stated in the excel(eg. epe_zlib_32bit.dll) It will give you a list of things, but important is to check the details on createfile, open, close ,query, those are the functions that are in the zlib dll file. Example Good case scenario where no error occurred. Fail case scenario where Windows unable to locate the DLL (due to symbolic link issue)
ASx4 Interface debug in MSEL=111 (JTAG mode)
Hi, could you, please, help me understand what is happening here: I am working with an Agilex3 FPGA (fuses are on factory default, no keys programmed, etc.) MSEL=111, so we are in JTAG mode I am trying to debug the NOR flash interface through Configuration Debugger / QSPI Controller and SFDP page. I have connected an oscilloscope. When I press Read button without QSPI Debug Session Activate button pressed, I see some NOR flash transactions on the oscilloscope and get back an Error 0x515 Unknown error and nothing is read in the SFDP window. So I try the QSPI debug session active way, and when I press it I get a lot of content but anything below the SFDP line in the tree structure is random at each read button press AND I do not see any NOR flash transaction at all on the ASx4 interface. (Did it several time, so yes, I did not forgot press the trigger active button.) So questions: is this an expected behavior? Copilot suggest that ASx4 interface is not initialized when MSEL=111 and I am reading some internal "garbage" If this is expected, should not the Quartus Programmer tool (which reads MSEL=111 correctly) warn me that I should not expect any meaningful output in this debug window? Is there any way to use the JTAG interface here as supposed: test the interfaces for problems? if yes, how?! (I stuck for a few more days/weeks with MSEL=111, so if that is the solution just let me know.) Thanks, PeterWhy do I see additional GPIO blockage in bank 3A of Agilex® 7 FPGA M-Series?
Description You will see additional I/O bank blockage at BL4, BL5, BL6, and part of BL7 in bank 3A when you route the NoC PLL lock signal of NoC Clock Control IP to core fabric. You will not see additional I/O bank blockage in the bottom I/O bank. Resolution To work around this problem, follow one of the methods below. Do not route the NoC PLL lock signal of NoC Clock Control IP to core fabric in your full project. Use this signal only in debug projects. Place GPIO in pin index [89:95] in BL7 of bank 3A.
Avalon-ST configuration with Agilex 3 fails
Hi, I have implemented a kind of passive serial programming from a CPU using SPI and a shift register. The signals nSTATUS, nCONFIG, CONF_DONE, READY, and VALID are directly controlled by GPIOs. This works well except after a power cycle. After the system has powered up, the programming fails — CONF_DONE does not go high. All retries afterward succeed. I already went through the debugging guidelines but couldn’t find an issue. However, I have observed two things: The nSTATUS pin follows exactly the timing of the nCONFIG pin during the first attempt. Normally, nSTATUS is delayed and goes high later. The CPU must finish the complete programming cycle before retrying; otherwise, the FPGA remains stuck in this erroneous state. I recorded some curves with a logic analyzer: full_timing.png: Power cycle First configuration cycle fails Retry works Another cycle also works 2_start.png: Beginning of cycle 2. Here, the nSTATUS pin follows exactly the timing of the nCONFIG pin. 2_3_restart.png: End of cycle 2 and beginning of cycle 3. 4_start.png: Another configuration cycle that works. Any idea what could cause this problem? Regards SamuelSlow Runtime Performance in FIL Implementation on DE2-115 Using Ethernet
Dear Technical Support Team, I am currently working on an FPGA-in-the-Loop (FIL) implementation using the DE2-115 FPGA development board with MATLAB/Simulink. My objective is to implement a complete PMSM drive system in FIL, which includes: A three-phase PWM inverter model A Permanent Magnet Synchronous Machine (PMSM) model The system is developed in Simulink, converted to HDL, and deployed to the DE2-115 board using HDL Verifier. The FIL setup is functioning correctly, and communication with the FPGA board through Ethernet is established successfully. The FPGA bitstream is generated and loaded without issues. However, during FIL simulation I observe that the runtime execution is very slow compared to the expected performance, and the simulation progresses significantly slower than real time. I would like to ask whether this behavior is expected when implementing a full electrical drive system inside the FIL environment. From reviewing several publications, it appears that many implementations only place a portion of the drive system in the FPGA. For example: * Bogdan Fabiański, “FPGA Emulator of Switched Reluctance Motor in a FIL Structure,” Poznan University of Technology Academic Journals, Electrical Engineering, No. 87, 2016. * Ahmet Gundogdu, Resat Celikel, Beşir Dandil, and F. Ata, “FPGA-in-the-loop implementation of direct torque control for induction motor,” Automatika, 2021, DOI: 10.1080/00051144.2021.1934365. In these works, only specific parts of the system (such as the motor model or control algorithm) are implemented on the FPGA, while the remaining components remain in the simulation environment. Therefore, I would appreciate your guidance on the following points: 1. Is it recommended to implement the entire drive system (inverter and machine model) inside the FIL for the DE2-115 platform? 2. Are there known performance limitations when using Ethernet-based FIL communication for relatively large models? 3. Is there a recommended partitioning strategy between the FPGA and Simulink for electric drive simulations? If necessary, I can provide the model configuration, HDL Workflow Advisor settings, or additional implementation details. Thank you for your support. Kind regards, Ahmed Sayed SolimanMAX 10 FPGA Programming Failure via JTAG – nSTATUS & CONFIG_DONE as No Connect
Title: MAX 10 FPGA Programming Failure via JTAG – nSTATUS & CONFIG_DONE as No Connect Hello Community, I am unable to program my Intel MAX 10 (10M08SAU169C8G) via JTAG using USB Blaster on Quartus Prime 24.1 (Windows 11). HARDWARE CONFIGURATION: • nCONFIG → Pulled HIGH to VCCIO • nSTATUS → No Connect • CONFIG_DONE → No Connect • CONFIG_SEL → No Connect WHAT I TRIED: • Unchecked "Enable nCONFIG, nSTATUS, and CONF_DONE pins" in Device Pin Options • Unchecked "Enable CONFIG_SEL pin" and "Auto-restart after error" • Recompiled and reprogrammed • USB Blaster recognized ✅ • MAX 10 detected in JTAG chain ✅ • Correct .SOF file selected ✅ Despite all this, programming still fails. QUESTIONS: 1. Are NC config pins the root cause even in JTAG mode? 2. Is there a Quartus workaround without a PCB re-spin? 3. Recommended pull-up values for nSTATUS and CONFIG_DONE? Any help is appreciated. Happy to share schematics or screenshots. Thank you!
B32A (1591) Package Mechanical Drawing
Hi Altera users, I checked a B32A (1591) Package Mechanical Drawing below. Is there a newest version of this content? There is a word of "preliminary", so I'm wondering if this is the latest version of the document. https://www.intel.com/content/www/us/en/content-details/822563/b32a-1591-package-mechanical-drawing-a5e-043-052-065-devices-2-drawings-a5e-065-b32a-es0-prq-part-numbers.html Thank you. Best Regards,
Request for Cyclone V Pinout File Information
I would like to download the Cyclone V pinout file (Excel format) from the Altera website; however, an error occurs and I am unable to download the file. https://www.altera.com/design/devices/resources/pinouts Could you please advise on how to resolve this issue and inform me of any alternative methods to obtain the Cyclone V pinout file?
recovery timing issue
I am working on Agilex 7 FPGA with quartus 25.3 software. in my project, I use the asynchronous reset and sync de-asserted stragegies. and I add the rst synczer circuit for each sub module in the top. background: clk freq is 416Mhz; all design use asynchronous reset; after fitting all design, the timing report about recovery violation has -1.8ns. for one timing path, the start point is reset_sync flop2, the end point is aclr port of one flop in the module B. from the following figure 1, I find the distance start point and end point is not far apart but the routing delay is nearly 4.386ns. and How I fix the timing? Doesn't the reset route go through global network? figure 1: for compasion，I have taken the follwoing screenshot of the common path routing as figure 2 here, the path from start point pll to clk port of reset_sync flop spans nearly the fabric fpga, but the actual routing delay is only 4.04ns. figure 2:
Recent Blogs
Modern infrastructure systems are facing growing challenges as many legacy ASSPs and ASIC devices reach end-of-life, creating pressure to find scalable and future-ready alternatives. FPGAs are emerging as a powerful replacement platform, offering programmability, lifecycle extension, and adaptability to evolving standards such as DDR5 and post-quantum security. With platforms like Altera’s Agilex family, organizations can replace fixed-function silicon while maintaining high performance, flexibility, and long-term production viability.
14 hours ago
Agilex® 7 FPGAs push FPGA fabric performance toward the gigahertz range by combining the HyperFlex® architecture with Quartus® Prime Pro software optimization. In Altera testing, a 32-bit SIMT soft processor implemented on Agilex 7 operated above 950 MHz, demonstrating how high-performance soft logic can be achieved in real designs. Hyper-registers distributed throughout the routing fabric enable deeper pipelining and advanced retiming, while Quartus Prime Pro optimizes synthesis, placement, routing, and timing to reach aggressive clock targets—allowing compute-intensive FPGA workloads to run faster and scale more efficiently.
18 hours ago
Linear Pluggable Optics (LPO) is gaining traction for AI/cloud infrastructure because it removes DSPs from optical modules, shifting signal conditioning to the host—cutting power by 30–40%, simplifying design, and lowering latency. Altera demonstrated public LPO interoperability using Agilex™ 7 devices running 400GbE (4×100G) with performance well beyond LPO spec thresholds in lab testing. Agilex 7’s high-speed transceivers and integrated capabilities make it a strong fit for SmartNICs, DPUs, and AI offload, with a roadmap toward next-gen 200G/224G LPO standards.
3 days ago
Dell’s Open RAN radio platforms use Altera Agilex® 7 SoC FPGAs to deliver secure, adaptable 5G infrastructure. The FPGA architecture enables hardware-rooted security and post-deployment updates, allowing radio units to evolve with new protocols and threats while maintaining trusted edge infrastructure.
3 days ago
As the industry accelerates its transition from DDR4 to DDR5 and LPDDR5, memory choices are becoming a defining factor in system longevity, performance, and supply continuity. Altera is uniquely positioned to help customers navigate this shift with production-ready DDR5 and LPDDR5 solutions available today across a broad FPGA portfolio. DDR5 Is the New Standard Major memory vendors have announced plans for DDR4 end-of-life plans or significant production reductions, with full transitions to DDR5, LPDDR5, and next-generation memory already underway. While DDR4 will remain available for long lifecycle segments through multiple suppliers, new design starts today are increasingly looking to DDR5 and LPDDR5. Altera’s Head Start in DDR5 and LPDDR5 While DDR5 and LPDDR5 support is emerging across the industry, Altera stands apart with the broadest set of production devices supporting these standards across high-performance, mid-range, and power-optimized platforms: Agilex™ 7 M-Series and Agilex™ 5 devices support DDR5 and LPDDR5 for high-performance and embedded applications Altera is also planning to add LPDDR5 support within Agilex™ 3 devices, reinforcing its long-term design scalability. Competitive Advantage Across Every Market Tier Altera’s memory leadership spans across a range of design requirements: - High-Performance designs: Agilex™ 7 AGM032 and AGM039 support: DDR5 up to 5,600 MT/s LPDDR5 up to 5,500 MT/s - Mid-Range designs: Agilex™ 5 D-Series support: DDR5 up to 5,600 MT/s LPDDR5 up to 5,500 MT/s - Power/Cost-optimized designs: Agilex™ 3 support: LPDDR5 up to 2133 MT/s Unlike FPGA-only devices, Agilex integrates an optional HPS that allows DDR5 and LPDDR5 to function as a shared memory resource for both processing and acceleration, delivering higher effective bandwidth and system efficiency. Key Takeaway With DDR5 and LPDDR5 moving from ‘next-generation’ to ‘now,’ Altera offers customers a clear advantage: production-ready memory leadership, a broad and scalable FPGA portfolio, and a smooth transition path from DDR4 to DDR5—without waiting for future silicon. Download the The Agilex™ 5 SoC Memory Advantage with DDR5 and LPDDR5 White Paper
6 days ago