FIR IP configured for Interpolation
Why does my Altera FIR IP, configured for interpolation by 80, produce the expected outputs when I provide 3 input samples, but fail to produce the expected behavior when I provide 10 input samples? In this case, the FIR IP keeps tready asserted high, but only generates 4 valid outputs. What could be causing this behavior? I am simulating this in Quartus Prime Lite Edition.
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 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.
agilex7 ram back-annotation
in my project with agilex7， I want to lock down placement of my optimized results, so I export the ram assignment. and I save the back-annotated assignments to a tcl file. when I re-compile the project with back-annotated tcl, the fit.plan.rpt shows the following warning: Warning (171007): Demoted location assignment EC_X34_Y116_N2 on embedded cell "x_blk_wk|x_eth_wrap|x_tx_dp_synczr|cdc.x_afifo|use_ram.x_afifo_ram_sp_wrap|x_ram_2p_2clk|data_rtl_0|auto_generated|altera_syncram_impl1|ram_block2a2" to EAB location M20K_X34_Y116_N0 File: /scratch/home/xinxu/ms2/signoff/quartus/20260525_161838_r11681_fullchip__tdbp_noskid__ram_noinit__mc_pipe_gt1k_m20k__pipe_gt1k_srcin__crc_aqm_pipe__m20k_back/ms_top/tmp-clearbox/ms_top/3185747/altera_syncram_impl_78p81.tdf Line: 97 and the fit.place.rpt shows the following warning: Warning (15706): Node "x_blk_wk|x_eth_wrap|x_tx_dp_synczr|cdc.x_afifo|use_ram.x_afifo_ram_sp_wrap|x_ram_2p_2clk|data_rtl_0|auto_generated|altera_syncram_impl1|ram_block2a978" is assigned to location or region, but does not exist in design How to fix the warning? The project rtl code has not been modified.altera scfifo ip with power-up initial value
in the quartus 25.3 with agilex7, I can see the retiming restriction about scfifo power-up initial value in the retiming rpt. from the altera user guide, the scfifo sclr must be asserted by user logic during power-up, so can I enable the setting ignore_power_up_initial_value to fix retiming restriction without any side effect?retiming issue
we develop a project with agilex7 fpga and using quartus pro 25.3 version. now we fix timing by analyze the retiming report. we see the following retiming restriction: But the register GEN_REG_INUT.R_DATA[0][0] is directly driven by quartus hyper register, and it has no power up value and no sync reset. the retiming critical path as follow: -------------------------------------------+ ; Critical Chain Details ; +--------------------------+-------------------------+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ; Path Info ; Register ; Register ID ; Element ; +--------------------------+-------------------------+-------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ; Power-up Restriction ; ALM Register ; #1 ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0] ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]|q ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~LAB_RE_X221_Y195_N0_I99 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~R1_X221_Y195_N0_I10 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~C4_X220_Y191_N0_I11 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~LOCAL_INTERCONNECT_X220_Y191_N0_I26 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~BLOCK_INPUT_MUX_PASSTHROUGH_X220_Y191_N0_I35 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~LAB_RE_X220_Y191_N0_I39 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn|dataf ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn|combout ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~cw_la_lab/lab_lut6outt[4] ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_LAB_RE_X220_Y191_N0_I138 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C1_X220_Y190_N0_I17 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R1_X220_Y190_N0_I16 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R12_X208_Y190_N0_I2 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R12_X196_Y190_N0_I2 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X195_Y182_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X195_Y174_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R12_X184_Y174_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R12_X172_Y174_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R12_X160_Y174_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R12_X148_Y174_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R12_X136_Y174_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X135_Y166_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X135_Y158_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X135_Y150_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X135_Y142_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X135_Y134_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R12_X124_Y134_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X123_Y126_N0_I0 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C8_X123_Y118_N0_I0 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R0_X123_Y118_N0_I2 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R2_X124_Y118_N0_I15 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_R1_X126_Y118_N0_I31 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C1_X126_Y118_N0_I30 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_C1_X126_Y119_N0_I30 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_LOCAL_INTERCONNECT_X126_Y120_N0_I61 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_BLOCK_INPUT_MUX_PASSTHROUGH_X126_Y120_N0_I80 ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg_rst_f|GEN_REG_INPUT.R_data[0][0]~xsyn~_LAB_RE_X126_Y120_N0_I82 ; ; Long Path (Critical) ; Bypassed Hyper-Register ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg|x_pe_pkg_pkt_pack|pack_data_padding_cross~xtophalf/xale2/xcw_ml_le_regctrl/xcw_la_le_regctrl_reg/sclr_out ; ; Long Path (Critical) ; ; ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg|x_pe_pkg_pkt_pack|x_pack_data_shifter|bcnt[4]|sclr ; Long Path (Critical) ; ALM Register ; #2 ; x_blk_pe|x_pe|x_pe_top_no_hmc|x_pe_pkg|x_pe_pkg_pkt_pack|x_pack_data_shifter|bcnt[4] ; why quartus report the retiming restriction?
RTL Simulation fails with: couldn't execute ip-setup-simulation: invalid argument
Hello, I am using Quartus Prime Pro Edition 25.3.1 on Windows 10/11. RTL simulation fails immediately with the following error: Error: Failed to run ip-setup-simulation: couldn't execute "ip-setup-simulation": invalid argument Error: Simulation flow failed Error(23031): Evaluation of Tcl script c:/altera_pro/25.3.1/quartus/common/tcl/internal/nativelink/qnativesim.tcl unsuccessful Additional stack trace: Simulation TCL script failed with errorCode: 1 (procedure "iputf_call_script_gen" line 1) invoked from within "iputf_call_script_gen $spd_file_list" I already checked the following: - Same error occurs for all projects - Same error occurs in Quartus Pro 25.1 and 25.3.1 - Same error occurs after deleting db/, incremental_db/, simulation/ folders - PATH conflict removed (only one vsim exists in PATH) - `vsim -version` shows: "Questa Altera FPGA Edition-64 vsim 2025.2 Simulator" - `where vsim` returns only: C:\altera_pro\25.3.1\questa_fe\win64\vsim.exe - `Generate Simulator Setup Script for IP` also fails - IP regenerate fails with: "Failed to retrieve Quartus project IP search paths" I also noticed that Quartus reports: "Questa Altera FPGA Edition simulator is not supported for simulation library compilation." Questions: 1. Is Questa Altera FPGA Edition (questa_fe) unsupported for Quartus Pro 25.x NativeLink RTL simulation? 2. Is this a known issue with ip-setup-simulation or qnativesim.tcl? 3. Does Quartus Pro require Questa Intel FPGA Edition/full Questa instead of questa_fe? 4. Is there a workaround besides manually running Questa simulation scripts? Thank you.Quartus/Signaltap complains about wrong version
Hello, we are using Quartus prime V24.1.0 for a rather large project. We have various signaltap files stored within git for analysis. Now, from time to time, it happens that quartus throws the following warning/assertion. Obviously, this assertion can be suppressedwith ENABLE_VHDL_STATIC_ASSERTIONS OFF, and everything is working. However this is no soulution as we want to have ENABLE_VHDL_STATIC_ASSERTIONS ON Error (22148): VHDL error at sld_ela_control.vhd(1263): Failure: "The design file sld_ela_control.vhd is released with Q uartus Prime software Version 24.1.0. It is not compatible with the parent entity. If you generated the parent entity us ing the Signal Tap megawizard, then you must update the parent entity using the megawizard in the current release.": exi ting elaboration File: c:/intelfpga_pro/24.1/quartus/libraries/megafunctions/sld_ela_control.vhd Line: 1263 If I remove the signaltap(file) entirely, and readd it, everything works. However, this is very annoying and time consuming. Q1. Why is this assertion triggered in the first place? We do not use any other versions. Q2. How do I "update the parent entity using the megawizard"? I'm unable to find an "update" option. To me deleting signaltap and re-creating it is not an update.... Thanks, Michael
