Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Novice
100 Views

Timing failure on auto assigned pins

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 ?

 

0 Kudos
10 Replies
Highlighted
83 Views

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


0 Kudos
Highlighted
Novice
75 Views

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 ?

 

0 Kudos
Highlighted
61 Views

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


0 Kudos
Highlighted
Novice
57 Views

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.

 

0 Kudos
Highlighted
Novice
38 Views

Any news on this subject?

Have you been able to see the problem I'm describing ?

0 Kudos
Highlighted
30 Views

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

 

0 Kudos
Highlighted
Novice
24 Views

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 ?

0 Kudos
Highlighted
Valued Contributor I
16 Views

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.

0 Kudos
Highlighted
Novice
11 Views

No, I didn't change the seed manually.

I don't really understand to what value you want me to change it.

0 Kudos
Highlighted
Valued Contributor I
8 Views

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.