Cyclone 10 LP's Extended Industrial parts
[Question] Customer have questions about Cyclone 10 LP's Extended Industrial (Tj = -40degC to 125degC) in the Product Catalog at the following URL. https://www.intel.com/content/www/us/en/content-details/730595/altera-product-catalog.html What is part number of Extended Industrial of "10 CL010YM164I7 G" as part number of Normal Industrial? What should the customer do if they want to check the power consumption by EPE(Early Power Estimator)? How can the customer design with Extended Industrial part if they want to compile with Quartus? Best Regards
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 Samuel
Timing Behavior of Remote Update IP After Reset on Cyclone 10 GX (10CX150YF672E5G)
I am using the Remote Update IP with the Cyclone 10 GX FPGA, part number 10CX150YF672E5G. I observed that the Remote Update IP does not respond properly after reset until approximately 300 µs. I experimented with delays of 1 µs and 2 µs after reset, but did not observe the expected behavior. However, after waiting for 300 µs, the IP responded as expected. Previously, I used the same Remote Update IP with a different part number, 10CX150YF672I5G, and in that case, it worked as expected with just a 10 clock cycle delay after reset. Could you please confirm if there is a specific timing requirement after reset for initializing the Remote Update IP with the 10CX150YF672E5G device? I am using Quartus Prime Pro 24.2 tool for Both version of Cyclone 10GX FPGA(10CX150YF672E5G & 10CX105YF672I5G) Thank you.Quartus Prime Pro 25.1 fatal error during fitter: Windows "Efficiency mode" required
Quartus 25.1 usually crashes during fitter, with a number of different crash reports. Here below are two examples: Problem Details Error: *** Fatal Error: Access Violation at 000000BC2DC1E830 Module: quartus_fit.exe Stack Trace: Other 0xbc2dc1e82f: Other 0xbc2dc1e6af: Other 0x1bf404d29ff: End-trace Executable: quartus Comment: None System Information Platform: windows64 OS name: Windows 11 OS version: 10.0.22631 Quartus Prime Information Address bits: 64 Version: 25.1.0 Build: 129 Edition: Pro Edition ------------------------------- Problem Details Error: *** Fatal Error: Module: quartus_fit.exe Stack Trace: Quartus 0x5fb4b: RaiseException + 0x6b (KERNELBASE) Quartus 0x26ad: __ExceptionPtrRethrow + 0x15d (MSVCP140) Quartus 0x19cfe: tbb::detail::r1::current_context + 0x277e (tbb12) Quartus 0x19d78: tbb::detail::r1::current_context + 0x27f8 (tbb12) Quartus 0x17695: tbb::detail::r1::current_context + 0x115 (tbb12) Quartus 0xa2567: FDRGN_EXPERT::run_place_flow + 0xd17 (fitter_fdrgn) Quartus 0xa0018: FDRGN_EXPERT::run_place + 0x188 (fitter_fdrgn) Quartus 0x95135: FDRGN_EXPERT::place + 0x195 (fitter_fdrgn) Quartus 0x2c120: fit2_fit_place_auto + 0xc0 (comp_fit2) Quartus 0x16442: TclNRRunCallbacks + 0x62 (tcl86) Quartus 0x4e6b: fit2_fit_place + 0x33b (comp_fit2) Quartus 0x16442: TclNRRunCallbacks + 0x62 (tcl86) Quartus 0x17c4d: TclEvalEx + 0x9ed (tcl86) Quartus 0xa6a8b: Tcl_FSEvalFileEx + 0x22b (tcl86) Quartus 0xa5136: Tcl_EvalFile + 0x36 (tcl86) Quartus 0x230ac: qexe_evaluate_tcl_script + 0x66c (comp_qexe) Quartus 0x21be9: qexe_do_tcl + 0x8f9 (comp_qexe) Quartus 0x2a1ad: qexe_run_tcl_option + 0x6cd (comp_qexe) Quartus 0x4119f: qcu_run_tcl_option + 0x6ef (comp_qcu) Quartus 0x29969: qexe_run + 0x629 (comp_qexe) Quartus 0x2abd6: qexe_standard_main + 0x266 (comp_qexe) Quartus 0xbd32: qfit2_main + 0x82 (quartus_fit) Quartus 0x28708: msg_main_thread + 0x18 (ccl_msg) Quartus 0x29912: msg_thread_wrapper + 0x82 (ccl_msg) Quartus 0x2b063: mem_thread_wrapper + 0x73 (ccl_mem) Quartus 0x265df: msg_exe_main + 0x17f (ccl_msg) Quartus 0xcfab: __scrt_common_main_seh + 0x10b (quartus_fit) Quartus 0x1259c: BaseThreadInitThunk + 0x1c (KERNEL32) Quartus 0x5af37: RtlUserThreadStart + 0x27 (ntdll) End-trace Executable: quartus Comment: None System Information Platform: windows64 OS name: Windows 11 OS version: 10.0.22631 Quartus Prime Information Address bits: 64 Version: 25.1.0 Build: 129 Edition: Pro Edition ----------------------------- this happens with every design and with Arria10, Stratix 10 and also Agilex 7. The only way to avoid these Quartus crashes is to run the fitter in Windows "Efficiency Mode", but that makes fitting time more or less double. Any hints?
Cyclone 10 GX Startup Time Support
I have been utilizing Cyclone 10 GX (10CX105YF672E6G) FPGA for some time but now I require the FPGA to startup and run as fast as possible, I know there is a hard limit caused by flash communications or power sequencing, but I would like to know if there is anyway I could cut the startup time further, each 1ms would cause a difference, so if there are any documented or undocumented workarounds or tricks that could support this it would be fantastic.
Agilex 5 Sulfur Partial Write Issue on F2H ACE‑Lite I/F (256‑bit) with AXI Master of 128‑bit
Hello Intel Support Team, I am working on an Agilex 5 Sulfur Development Board and implementing an HPS‑based design where a USB Host module (custom logic) acts as an AXI Master and performs memory accesses to SDRAM through the F2H ACE‑Lite interface. I am seeing an issue related to partial writes when the AXI data width is translated from 128‑bit to 256‑bit before reaching the F2H bridge. a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Design Summary AXI Master (USB host logic) Address width: 32 bits Write data width: 128 bits Write strobe (WSTRB): 16 bits Interconnect Path (Platform Designer) The Master AXI interface passes through the following autogenerated components: mm_interconnect_0_ace5lite_cache_coherency_translator ace5lite_cache_coherency_translator ACE‑Lite Interface to F2H Address width: 32 bits Write data width: 256 bits Write strobe: 32 bits Observed Behavior (via SignalTap) The 128‑bit write data is properly expanded to 256‑bit by the translator. The 16‑bit WSTRB is correctly translated to 32‑bit, with only the lower or upper half asserted as expected. The AXI address falls correctly within the SDRAM region. The writes propagate through CCU → MPFE correctly (based on external visibility). Problem When reading back SDRAM from software running on the HPS, we observe that: 👉 The entire 256‑bit word in SDRAM is modified, even though 👉 only 128 bits of WSTRB were asserted on the ACE‑Lite interface. SignalTap shows the correct WSTRB on the F2H side, but SDRAM readback indicates that the "inactive" 128‑bit lanes are also being overwritten. Because the HPS subsystem is a hard macro, we cannot probe signals inside the CCU / MPFE / F2H bridge to see what is actually happening after the ACE‑Lite boundary. a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Questions for Intel We would greatly appreciate guidance on the following: 1. ACE‑Lite 256‑bit Partial Write Support Are there any documented limitations or required settings for partial‑word writes on the 256‑bit F2H ACE‑Lite interface in Agilex 5? 2. MPFE / SDRAM Controller Behavior Does the MPFE / CCU / SDRAM controller internally convert all writes to full‑width beats, regardless of WSTRB? If so, is there a way to ensure correct byte‑enable behavior? 3. Required Qsys Settings? Are there specific configuration requirements for: The ACE‑Lite translator Interconnect pipeline stages Burst alignment Address alignment for partial writes Write‑data interleaving settings 4. Debugging Recommendations Since internal HPS signals cannot be probed, is there: Any documented method to trace ACE‑Lite transactions inside HPS? Any diagnostic registers or trace capabilities in CCU/MPFE? Any recommended debug flow for this type of issue?Help with BTS and .sof example files for Agilex 7 AGM039EA
I'm trying to program the .sof BTS examples files onto my Agilex 7 AGM039EA dev board (files are from AGM039FES installer package). I'm using Quartus 25.3 and the BTS is able to detect the board however when loading the .sof files, BTS mentions the .sof files were compiled using an older version and not able to complete programming. When I switch over to Quartus 24.3.1, the JTAG scan does not pick up my board (lists it as Unknown_434CC0DD) and the BTS GUI will not open because there is a FPGA mismatch. Any help on getting the correct files to work with the proper BTS for my FPGA board?
