Recent Content
ModelSim Intel FPGA Ed. 2020.1 not updating changes to HDL File
I have ModelSim open and Quartus Prime Lite v. 22.1, while I'm simulating, I often make changes back to the Quartus, but when I reload the design into ModelSim, it cold-archives the initial HDL file and references that file instead of the changes I make in Quartus. No matter how many times I recompile the code for both the wrapper function and main entity, it always goes back to the original? How is this possible? Does ModelSim copy the file into it's own directory and simply references it? I've spent days trying to figure this out, wihtout creating a new project and adding the changed code to it, how can I force it to use the updated files?Cyclone 10 GX AS x4 Configuration Compatibility with Infineon S25FS512S (Custom Flash Definition)
We are trying to use the Infineon S25FS512S QSPI NOR Flash with Cyclone 10 GX in Active Serial x4 (AS x4) configuration by creating a Custom Flash Definition based on AN229767. JTAG programming completes successfully, but FPGA configuration fails in AS x4 mode. We have performed extensive debugging and would like to understand whether this is a supported use case or if there are any known limitations. Observations Flash Programming JTAG programming completes successfully. Flash verification completes successfully. Configuration Behavior Active Serial x1 configuration works correctly. Active Serial x4 configuration fails. The FPGA successfully issues the RDID (0x9F) command. The FPGA then attempts to read the Boot Information from address 0x00000000. Logic Analyzer Observation During AS x4 configuration, the FPGA issues the EBh (Quad I/O Read) command. According to the Infineon S25FS512S datasheet, the expected transaction is: EBh → 4-byte Address → Mode Byte (8 bits) → Dummy Cycles → Data However, the captured waveform shows: EBh → 4-byte Address → Dummy Cycles → Data No Mode Byte is observed between the address and dummy cycles. Based on the S25FS512S command protocol, this could cause the flash to interpret the transaction differently and return misaligned data. We would like Altera to confirm whether this behavior is expected from the Cyclone 10 GX configuration controller. Additional Information We reviewed AN229767, but could not find any mechanism in the Custom Flash Definition to configure or insert the Mode Byte required by the EBh command. We also observed that the Custom Flash Definition supports Read Register commands only for fixed register opcodes and does not appear to support RDAR (0x65) with a register address. Questions Does the Cyclone 10 GX configuration controller support transmitting the mandatory Mode Byte required by the EBh (Quad I/O Read) command? If not, is this a known limitation of the Cyclone 10 GX configuration controller or Quartus Programmer? Is there any supported method to modify the Quad I/O Read command sequence in the Custom Flash Definition? Has Altera validated any Custom Flash Definition for the S25FS512S that can be shared as a reference? Environment FPGA: Cyclone 10 GX Flash: Infineon S25FS512S Configuration Mode: Active Serial x1 (working), Active Serial x4 (failing) Programming Method: Quartus Programmer using a Custom Flash Definition based on AN229767 We would appreciate any guidance, clarification, or a reference implementation for using the S25FS512S with Cyclone 10 GX in Active Serial x4 mode.Terasic P16E-FMCP PCIE Express 3.0 compatibility issues with AMD processors
Hi I bought the Terasic P16E-FMCP to use on my Terasic Apollo S10 SOM board for PCI Express 3.0 implimentation. However after testing the included program, it did not work, so I emailed Terasic Support and they told me it was only tested on Intel CPU and it appears never tested on AMD. So they made me run a simple program called System Information Viewer from rh-software.com which tested the information sent and received from the PCI endpoint and it appears there are errors stimming back from the demo program does not natively run on AMD processors. So for the past 6 months, Terasic has been dragging there feet on this issue, telling me they will work on a solution but I must go out and purchase another computer by Intel, then run several versions of Quartus Pro, starting from 19.1, through 23.3, I must download them individually. I told them I am not doing this, I am not being paid to test out your code, I simply purchased the board direct from you for $650, and NOWHERE on the website does it publish it works only with Intel CPU. Instead they are pointing the fingers at me saying I'm delayin a resolution on this issue by not testing out there code, I told them that IS YOUR JOB! I AM NOT EMPLOYED BY TERASIC! Terasic is a partner program of Intel, they have all the means to reach out and contract a device driver writer and solve this incompatiblity issue. This is beyond my expertise. They simply won't do it. Does anyone have a solution to this problem? Why are they passing the buck at me?
Queries on 46.6944 Gbps PAM4 F-Tile Configuration and Loopback Testing using Agilex7
Team, Quartus: Quartus Prime Pro 26.1.0 I am currently working on an Agilex 7 F-Tile transceiver configuration for a 46.6944 Gbps PAM4 application. Please find my query (Read file) as attached and provide advise.. Regards amolkumar
System 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 neede
Agilex5 o_tx_ready and o_rx_ready not asserting
I'm working on a design for a video router, and having trouble with the transceivers. I have the premium devkit to test run the setup. This board has ES silicon, A5ED065BB32AE6SR0. The design would implement 4 or 8 lanes of 12.5Gbps (later 17Gbps or faster), on the GTS XCVR, PCS Direct with IEEE_FLEXE_66 implementation. I followed the User Guide to implement the startup sequence (Reset_Sequencer is OK - it handshakes src_rst_req and src_rst_grant). Figure 65 was my guideline to develop the FSM to bring the Tx and Rx lane up and running. The issue I'm observing: The TX run-time reset sequence (UG Fig 56) completes: i_tx_reset asserted → o_tx_reset_ack asserts → i_tx_reset deasserted → o_tx_pll_locked asserts → src_rs_grant completes. But o_tx_ready never asserts (o_rx_ready likewise). As an extra measure against metastability, all status signals are 2-flop synchronized before use. When I hook up the Transceiver Toolkit, it brings the same channel up reliably. What additional condition gates o_tx_ready that isn't in Figure 56, or what should I look for to get the XCVR reliable up and running. After the initial 'bring_up_sequence, I'll run 4kb packets at 64/66bit to minimize overhead, hence the FLEXE_66. I'm kind of stuckMAX 10 – Sporadic configuration failure after firmware update
I am using the internal configuration flash for field firmware updates. The factory/golden image is programmed via JTAG during production and write-protected, while the application image is updated in CFM2. Sporadically, an update fails and the FPGA subsequently cannot configure from either the factory or application image. Reprogramming the internal flash via JTAG restores normal operation. Expected: If the application update is interrupted or corrupted, the protected factory image should remain bootable as a fallback. Support request: What could cause both images to become unbootable after a failed update? Could an interrupted flash operation or power-down with excessive supply-voltage slew rate affect flash/configuration data required for fallback? Please advise which power-sequencing, slew-rate, brownout, or flash-update requirements and diagnostics should be checked.
Synthesis error
I generated HDL file from qsys and did the compilation in Quartus. Following error log was found: Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_rdwr.sv(287): index 3 is out of range [31:5] for 'addr' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_rdwr.sv(287): index 3 is out of range [31:5] for 'addr' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_rdwr.sv(287): index 3 is out of range [31:5] for 'addr' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_rdwr.sv(287): index 3 is out of range [31:5] for 'addr' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_rxm_txctrl.sv(196): index 4 is out of range [1:0] for 'tx_data' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_txs.sv(196): index 95 is out of range [65:0] for 'rx_fifo_data' Error(13224): Verilog HDL or VHDL error at altpcieav_256_rp_app.sv(597): index 257 is out of range [71:0] for 'rx_fifo_dataq' Error(16851): Verilog HDL error at udh_en0.sv(127): formal port avs0 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(125): formal port avs1 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(123): formal port avs2 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(122): formal port avs3 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(121): formal port avm0 of type avlmm_ifc' from library 'function_enet_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at udh_en0.sv(119): formal port mdio_r of type mdio_ifc' from library 'function_enet_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at udh_en0.sv(120): formal port mdio_s of type mdio_ifc' from library 'function_enet_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at udh_en0.sv(118): formal port mdio_t of type mdio_ifc' from library 'function_enet_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at hssl_i.sv(130): formal port avs of type avlmm_ifc' from library 'function_hssl_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at hssl_i.sv(127): formal port avm0 of type avlmm_ifc' from library 'function_hssl_20 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at hssl_i.sv(128): formal port gmii_r of type gmii_ifc' from library 'function_hssl_20 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at hssl_i.sv(129): formal port gmii_s of type gmii_ifc' from library 'function_hssl_20 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at hssl_i.sv(131): formal port gmii_t of type gmii_ifc' from library 'function_hssl_20 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at hssl_i.sv(125): formal port mdio_r of type mdio_ifc' from library 'function_hssl_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at hssl_i.sv(126): formal port mdio_s of type mdio_ifc' from library 'function_hssl_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at hssl_i.sv(124): formal port mdio_t of type mdio_ifc' from library 'function_hssl_20 does not match with actual type mdio_ifc' from library 'altera_work Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(380): formal port gmii0 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(382): formal port gmii1 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(377): formal port gmii2 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(378): formal port gmii3 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(374): formal port gmii4 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(376): formal port gmii5 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(372): formal port gmii6 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(373): formal port gmii7 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(370): formal port gmii8 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(371): formal port gmii9 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(366): formal port gmii10 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(367): formal port gmii11 of type gmii_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type gmii_ifc' from library 'function_enet_20 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(391): formal port avs0 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(390): formal port avs1 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(387): formal port avs2 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(386): formal port avs3 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(389): formal port avs4 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(388): formal port avs5 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16851): Verilog HDL error at qsgmii2gmii_0.sv(383): formal port avs6 of type avlmm_ifc' from library 'QSGMII_to_GMII_Bridge_10 does not match with actual type avlmm_ifc' from library 'ast2avmm_pcie_bridge_hw_191 Error(16186): Can't elaborate top-level user hierarchy Error: Flow failed: Error: Quartus Prime Synthesis was unsuccessful. 65 errors, 191 warnings Error: Peak virtual memory: 1041 megabytes Error: Processing ended: Wed Sep 23 11:02:52 2026 Error: Elapsed time: 00:01:58 Error: System process ID: 23412 Error(293001): Quartus Prime Full Compilation was unsuccessful. 67 errors, 191 warnings It seems the instantiated avlmm(for instance) is trying to map to the same module in altera_work which gneerates this error. How do i solve it?
Inconsistent Eyes with S10 E-tile Transceiver.
Hi Support and Community. Why am I obtaining eyes sticking to the left instead of the middle? Quartus Prime Pro 26.1 Stratix 10 TX SI Signal : NRZ @1.4Gbps Channel: External Loopback (Tx+ to Rx+ Rx- via single ended to differential converter, Tx- terminated with 50 Ohms) Eye h/w: ~90/~500 PMA: Settings are on default (after initial adaptation)Why can’t I open the Early Power Estimator (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 does this issue occur? 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. 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. 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. Modern systems also enforce stricter security controls, including: 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). 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 click 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)
Recent Blogs
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 day ago
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 ago
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 ago
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 ago
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.
1 month ago