Forum Discussion

zjj's avatar
zjj
Icon for Occasional Contributor rankOccasional Contributor
22 days ago

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.

5 Replies

  • KennyT_altera's avatar
    KennyT_altera
    Icon for Super Contributor rankSuper Contributor

    Hi

     

    can you attached your design here to take a look?

     

    Here is some bkm when you use this feature:

     

    Regenerate Back-Annotated Assignments

    • Always generate the back-annotation from the exact build you want to lock down. If anything changes (tool version, settings, database, or synthesis options, seed number), regenerate the assignments.

    Check Instance Naming Consistency

    • Compare node names in your design (via Assignment Editor or Fitter reports) with those referenced in your TCL file. If they don't match, the assignments won't apply.

    Use Wildcards or General Assignment Filters

    • If instance names change frequently, consider using wildcards or locking down assignments by module/entity rather than full instance path.

    Clean Project Database

    • Delete the db and incremental_db folders to ensure there are no stale database files causing mismatches. Then recompile.

    Check Quartus Version and Settings

    • Make sure tool versions and all synthesis/fitter settings are consistent between runs.

     

    Thanks

    • zjj's avatar
      zjj
      Icon for Occasional Contributor rankOccasional Contributor

      in my project, all ram is inferred to M20K by quartus eda tool.   the ram behavior as follow:

      always @(posedge clk) begin

      if (ram_wra) data[ram_addra] <= wrp_dina;

      end

      always @(posedge clk) begin

      if (rdb_c) wrp_doutb <= data[addrb];

      end

      the ram hierarchy as follow:  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

      The hierarchical name of the RAM changes after each compilation. It was data_rtl_0 in the previous build and becomes data_rtl_1 in the next one. 

  • KennyT_altera's avatar
    KennyT_altera
    Icon for Super Contributor rankSuper Contributor

    The warning is caused by the inferred RAM instance name changing between compilations. Although the RTL is unchanged, Quartus may rename internal inferred RAM nodes such as data_rtl_0 to data_rtl_1, so the back-annotated .tcl from the previous compile no longer matches the new design database.

    This causes:

    • Warning (15706) because the old node path no longer exists
    • Warning (171007) because Quartus relaxes the exact low-level RAM cell assignment to a broader legal EAB location

    Recommended action:

    • regenerate the back-annotated assignments from the exact compile you want to preserve
    • remove db/ and incremental_db/ before recompiling
    • avoid constraining the deepest auto-generated inferred RAM node names
    • if stable RAM placement is required, use explicit RAM/IP instantiation or a more stable hierarchy for assignment targeting

    So the main issue is not RTL change, but name instability of inferred RAM implementation nodes across compilations.

     

    Keep all compile conditions identical

    • Quartus version
    • seed
    • synthesis settings
    • fitter settings
    • revision/database state

    You may also attached your design.qar files for us to investigate.