Quartus 26.1: quartus_asm triggers quartus_pfg despite disabled generation flags
Product: Quartus Prime Pro Edition Version: 26.1.0 Build 110 (03/26/2026) Component: Assembler (quartus_asm) / Programming File Generator (quartus_pfg) Environment: Linux Summary Running quartus_asm with programming file generation explicitly disabled still triggers an internal call to quartus_pfg. This secondary step fails non-deterministically, even when no inputs or environment variables change between runs. Expected Behavior When invoking: quartus_asm ... --set=GENERATE_PROGRAMMING_FILES=OFF --set=GENERATE_RBF_FILE=OFF quartus_pfg should not be invoked at all, or it should be strictly disabled / skipped internally Actual Behavior quartus_asm always invokes quartus_pfg, even with generation disabled. This then leads to quartus_pfg unpredictably succeeding or failing. See attached log file. This leads to inconsistent results across identical runs. Outcomes observed across runs: The attached log file shows exemplary the different outcome of successive runs with no changes in between. The order of these results are interchangeable as observed. 1. Success Quartus Prime Programming File Generator was successful. 0 errors 2. Corruption error Error (19192): File ..._hps_auto.sof is corrupted 3. Segmentation fault *** Fatal Error: Segment Violation ... Reproduction Run repeatedly without changing anything: quartus_asm <proj> --read_settings_files=on --write_settings_files=off -c <rev> --set=GENERATE_PROGRAMMING_FILES=OFF --set=GENERATE_RBF_FILE=OFF Impact Breaks reproducibility guarantees Causes intermittent CI failures Forces workarounds (retry logic, ignoring exit codes, etc.) Undermines trust in assembler output stage Suggested Fixes / Questions Why is quartus_pfg invoked when: GENERATE_PROGRAMMING_FILES=OFF GENERATE_RBF_FILE=OFF? Can this behavior be: disabled completely, or controlled via a strict flag? Is there a known issue with: HPS-related SOF post-processing Workarounds (partial) Re-running the same command sometimes succeeds Running quartus_pfg separately succeeds Ignoring exit codes is unsafe due to real corruption cases Conclusion quartus_asm appears to implicitly depend on quartus_pfg even when disabled, and that dependency is unstable. This behavior is first observed in Quarts 26.1. In 25.3 quartus_asm does not implicitly call quartus_pfg. At minimum, this should be documented; ideally, the invocation should be conditional or removable.
quartus pro 25.3 bug?
Now I am developing a project with agilex7 base on the quartus pro 25.3. the project contains R-TILE pcie hard ip and F-tile ethernet hard ip. During board bring-up debugging, we frequently encounter non-deterministic discrepancies between actual hardware behavior and simulation results. For instance, on a certain platform, the PCIe device fails to be enumerated by the host. Probing the Avalon-ST TX interface of the PCIe hard IP reveals continuous toggling on both the hvld and dvalid signals. However, we have verified that no traffic is being sourced to this interface, meaning these two signals should theoretically remain idle without constant toggling. And the timing of the project is cleaning. How should we proceed to troubleshoot this issue? Should we try upgrading the Quartus version as a potential solution?
How to create a Packaged Subsystem in TCL
I am hoping to create a script which will automatically package the IP I am working on as a packaged subsystem. So far, I have automated the creation of an IP directory which describes a new component using a _hw.tcl file and the various source files. I believe the next step is to take this component, instantiate it in a Platform Designer system, and create a Packaged Subsystem using it. I am also hoping that I can parameterise and hide/modify ports of the packaged subsystem, like I can with the _hw.tcl component description. I am encountering a problem; I am running the following command: qsys-script --script=create_packaged_subsystem.tcl --new-quartus-project=my_project_name However, the script fails for the following reason: Error: invalid command name "set_package_property" Here is the script itself (more or less a copy-and-paste from the GUI): package require -exact qsys 26.1 set_package_property NAME "packagename" set_package_property DISPLAY_NAME "PackageName" set_package_property VERSION "1.0" set_package_property GROUP "GroupName" set_package_property DESCRIPTION "A descripton." set_package_property ELABORATION_CALLBACK elaboration_callback set_package_property EXTRACTION_CALLBACK extraction_callback add_fileset synth_fileset QUARTUS_SYNTH fileset_callback "Quartus Synthesis Fileset" add_fileset sim_verilog_fileset SIM_VERILOG fileset_callback "Simulation Verilog Fileset" proc elaboration_callback {} { enable_all_instances } proc extraction_callback {} { extract_modules } proc fileset_callback { output_name } { generate_all_instances } Any help would be hugely appreciated, on this issue and on my general workflow. Also if it is possible to encrypt packaged subsystems or components using Quartus I'd be keen to know. Thanks!
Quartus 22.1 and 23.1 Synthesis Error
Hi, I am currently working on a project targeting a Cyclone V device using Quartus Prime versions 22.1 and 23.1. The design compiles and functions correctly with no issues. However, after adding an FFT IP core, Quartus frequently fails during synthesis with the error shown below. The issue is reproducible in both Quartus versions. Interestingly, the compilation succeeds only intermittently (approximately once every 5–6 attempts), while most synthesis runs fail. Another observation is that if I change the Synthesis Effort setting to Fast, the design compiles successfully every time. Has anyone encountered similar behaviour or have any suggestions on how to work around this issue? Thanks in advance.Quartus crashes on long carry chain in Agilex 5 FPGAs
We try to manually place a carry chain in the Agilex 5 FPGAs which consists of more than 40 LABs. When we place this carry chain using set_location_assignment, Quartus crashes during the placement phase whenever the carry chain is longer than 40 LABs. Is it expected that the carry chain cannot be made longer than 40 LABs in the Agilex 5 FPGAs? Crash was observed on Quartus 25.3 and Quartus 26.1 for the devices A5ED065BB32AE4S and A5ED013BB32AE4SCS. Internal Error: Sub-system: FLABS, File: /quartus/fitter/flabs/flabs_util.cpp, Line: 96 p_to_fill->next == FLABS_OPEN
