New ContributorQuartus 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.
