Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16885 Discussions

Timing failure on auto assigned pins

SKon1
Novice
2,114 Views

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
12 Replies
KhaiChein_Y_Intel
2,097 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
SKon1
Novice
2,089 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
KhaiChein_Y_Intel
2,075 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
SKon1
Novice
2,071 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
SKon1
Novice
2,052 Views

Any news on this subject?

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

0 Kudos
KhaiChein_Y_Intel
2,044 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
SKon1
Novice
2,038 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
ak6dn
Valued Contributor III
2,030 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
SKon1
Novice
2,025 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
ak6dn
Valued Contributor III
2,022 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.

KhaiChein_Y_Intel
2,000 Views

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

 

0 Kudos
KhaiChein_Y_Intel
1,981 Views

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


0 Kudos
Reply