Hello, In my design I have 3 output pins that show a timing violation in Timequest.Their location is locked by the "set_location_assignment" TCL command in the project's QSF file.Because the PCB is still being designed - I can move pins around. So what I did is remove the "set_location_assignment" command from these pins and re-complied the design.As far as I understand, this gives the fitter the freedom to choose the best location for the pins to achieve timing closure. Looking at the fitter report after compilation I could see that the pins in question where moved to different location - and the design now passed timing! All good till this point... I then decided to return the "set_location_assignment" - only now with the automatically chosen fitter pins. I re-compiled and the designed failed timing again! I don't understand why this happens. I locked the pins to THE SAME LOCATION automatically chosen by the fitter - and this is the only thing I did (I didn't change the RTL). So why does it now fail timing ? Can you explain this please ?

The SEED value is used to initialize the random number generator that Quartus uses during placement and routing. Much of the P&R is driven by analysis of connectivity of the logic, but there is some randomness induced during the process. If you don't set a SEED, it will be different each time you run Quartus, and you may get different P&R and timing results. I usually start with a fixed SEED value of '42' (just an arbitrary number but it has some movie history) and if the layout completes and meets timing I leave it. Otherwise I'll change it and retry. Since you don't set your seed manually (and statically) then the SEED is changing between P&R runs as well as your lockdown assignments for the selected pins. So the runs are not ~exactly~ the same.

Hi,The path it takes to the assigned pin (destination) could be different from compilation to compilation. When you run a compilation, the Fitter creates a random initial placement for the logic based on the initial condition of your design. The initial condition of the design is a function of all the source files, optimization settings, and an integer called the Fitter seed value. A change in any of these parameters results in a change in the initial placement. A change in initial placement affects how optimizations proceed, producing a different Fitter result. Any modification, such as changing a net name, pin name, or making a new assignment affects the final results.ThanksBest regards,KhaiY

Thanks, but this doesn't answer my question. Please read again what I wrote: The only thing that was changed between the design that passed to the design that failed. Is copying the locations of the auto assigned pins from the fitter report of the design that passed and locking them (to the same location) using the "set_location_assignment" command in the QSF file. So, by definition I'm using the exact pin locations and NOTHING was changed in any of the sources.So the only thing that could've changed is the SEED value you mentioned. This SEED value presumably changes after every compilation...but I get the same negative slack - no matter how many times I compile afterwards. How do you explain this ?

Hi,Could you share the design before and after the location assignment? To generate the design QAR file, click on Project > Archive Project > ArchiveThanks.Best regards,KhaiY

Both designs are archived and attached.The pins in question are: P2_indv : AP6P2_ind[0] : AN6P2_ind[1] : AP8P2_ind[2] : AL7P2_ind[3] : AM7 According to the fitter report of both failing and non-failing designs - they're mapped to the same I/O locations.The ONLY difference between the 2 attached designs is that the one that fails has the "set_location_assignment" constraint assigned to the above location while the one that passes doesn't have the "set_location_assignment" constraint (it's commented out from the QSF). Thanks for your help.

Timing failure on auto assigned pins

12 Replies

KhaiChein_Y_Intel
Regular Contributor
6 years ago
Hi,

The path it takes to the assigned pin (destination) could be different from compilation to compilation. When you run a compilation, the Fitter creates a random initial placement for the logic based on the initial condition of your design. The initial condition of the design is a function of all the source files, optimization settings, and an integer called the Fitter seed value. A change in any of these parameters results in a change in the initial placement. A change in initial placement affects how optimizations proceed, producing a different Fitter result. Any modification, such as changing a net name, pin name, or making a new assignment affects the final results.

Thanks
Best regards,
KhaiY
- SKon1
  Occasional Contributor
  6 years ago
  Thanks, but this doesn't answer my question. Please read again what I wrote:
  
  The only thing that was changed between the design that passed to the design that failed. Is copying the locations of the auto assigned pins from the fitter report of the design that passed and locking them (to the same location) using the "set_location_assignment" command in the QSF file.
  
  So, by definition I'm using the exact pin locations and NOTHING was changed in any of the sources.
  So the only thing that could've changed is the SEED value you mentioned.
  
  This SEED value presumably changes after every compilation...but I get the same negative slack - no matter how many times I compile afterwards. How do you explain this ?
KhaiChein_Y_Intel
Regular Contributor
6 years ago
Hi,

Could you share the design before and after the location assignment? To generate the design QAR file, click on Project > Archive Project > Archive

Thanks.
Best regards,
KhaiY
- SKon1
  Occasional Contributor
  6 years ago
  Both designs are archived and attached.
  The pins in question are:
  
  P2_indv : AP6
  P2_ind[0] : AN6
  P2_ind[1] : AP8
  P2_ind[2] : AL7
  P2_ind[3] : AM7
  
  According to the fitter report of both failing and non-failing designs - they're mapped to the same I/O locations.
  The ONLY difference between the 2 attached designs is that the one that fails has the "set_location_assignment" constraint assigned to the above location while the one that passes doesn't have the "set_location_assignment" constraint (it's commented out from the QSF).
  
  Thanks for your help.
  fails_timing_with_lock.qar1.5 MB
  passes_timing_without_lock.qar1.5 MB
  - SKon1
    Occasional Contributor
    6 years ago
    Any news on this subject?
    
    Have you been able to see the problem I'm describing ?
KhaiChein_Y_Intel
Regular Contributor
6 years ago
Hi,

I reported the full path timing of one of the paths for comparison, the route it takes from the FROM Node to To Node are different.

From Node: Ethernet_Bridge_inst|pll_p6_tx_to_ethernet_bridge|pll_p6_tx_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk

To Node: P6_ind[0]

This happens when I recompile the same design for multiple times. The logic are routed differently even without any changes in the design, which is as explained in the document.

Thanks.

Best regards,

KhaiY
- SKon1
  Occasional Contributor
  6 years ago
  So you do see that the tool can meet timing when the pins aren't locked...and you also see that locking them (to the same location) makes the design fail timing.
  
  Do you agree it's a bug in the P&R tool ?
  Or at least something that can be considered sub-optimal behavior ?
  - ak6dn
    Regular Contributor
    6 years ago
    Just a question and a thought:
    
    Do you manually set the seed value for the place/route, or let Quartus choose it each time?
    
    Once I get a working combination, I will add to my master .qsf file:
    
    set_global_assignment -name SEED nnnn
    
    where I set the seed to some constant number for that layout. You can choose nnnn either before (and if you are lucky your P/R will work and meet all timing) or after a successful layout find the seed used.
    
    Once I do this, I can rerun P/R from scratch and recreate the same layout.
KhaiChein_Y_Intel
Regular Contributor
6 years ago
Hi,

When you run a compilation, the Fitter creates a random initial placement for the logic based on the initial condition of your design. The goal of the Fitter is to find a placement that can be successfully routed and meets all constraints. It may be possible to achieve this with different initial placements, which means the solution is not unique. The Fitter searches for the best solution among a set of different possible and valid solutions within a solution space. The Fitter might converge to different solutions in the solution space based on the given initial conditions.

You may see different timing result or compilation result even if you set both the location of the source and destination to a specific location. Take an example of one of the routing paths, the path it takes from the source to the destination, the clock control block used and the time it takes from source to destination are also different. This is why you see different result even you have the same location assigned to the source and destination.

Thanks.

Best regards,

KhaiY
KhaiChein_Y_Intel
Regular Contributor
6 years ago
Hi,

We do not receive any response from you to the previous question/reply/answer that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you

Best regards,
KhaiY

Forum Discussion

Timing failure on auto assigned pins

12 Replies

Recent Discussions

[Agilex 7F] How to setup my EMIF IPs for the toolkit?

QSYS 25.3pro failed to generate VHDL simulation files for altera_remote_update_core

IOPLL related clock constraints

Failing IO buffer

Unable to Enrol into SSLC Due to Microsoft Authentication App Issue