UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor gillesb
Visitor
7,302 Views
Registered: ‎12-11-2012

PAR Taking forever

Hey

I am implementing a design vor Virtex 6 on ISE 12.4 (please do not tell me to upgrade, licenese issues...).

My most recent design seems to have problems implementing.

 

The PAR has been running over the whole weekend+1day and still hasnt finished. It seems stuck at:
"Phase  4  : 122774 unrouted; (Setup:2901102, Hold:61052, Component Switching Limit:0)     REAL time: 10 mins"

 

I enabled multi-threading with up to 4 cores. And "par.exe" is using 50% of my 8-core-CPU right now. So it seems there are some massive calculations still being done.

My question:
If the process-consumption is 100% of the allowed core-usage, is it guaranteed to move forward or could it be stuck in a never ending loop?

 

FYI: We are using a floating licenese and in the licenese manager it says "Licenses in use" is 0/1 everywhere. Is this an indicator that it is not moving on anymore?

Thank you,

 

Gilles B

0 Kudos
6 Replies
Community Manager
Community Manager
7,295 Views
Registered: ‎06-14-2012

Re: PAR Taking forever

From your observation, this looks stuck.

 

From the log. unusually high hold time violation  is seen. Can you try without using any timing constraints?

 

This can be  caused by sub-optimal clock structure which brings high clock skew. You can check in FPGA Editor or PlanAhead to see how the clock net(s) driving the source and destination is(are) connected. Following are some scenarios that may cause this issue. 

  1. The clock net that drives the source and destination does not go through a BUFG
  2. The source clock net goes through a BUFG but the destination clock doesn't
  3. BUFG cascading on the clock net(s)
  4. Other structures that bring high clock skew
0 Kudos
Visitor gillesb
Visitor
7,289 Views
Registered: ‎12-11-2012

Re: PAR Taking forever

Finally finished!!

Total REAL time to PAR completion: 3 days 18 hrs 24 mins 34 secs
Total CPU time to PAR completion (all processors): 15 hrs 8 mins 15 secs

but both timing constraints not met :-(

but thats usually the case... still performs nicely.

whats the easiest way to make sure the clokc distribution isnt the problem.

 

because consumption is about 18%

though DSP slices is about 78%...

Thanks,

Gilles B

0 Kudos
Community Manager
Community Manager
7,278 Views
Registered: ‎06-14-2012

Re: PAR Taking forever

Thanks for the update. Please analyze your clocking structure to make sure that this is not the root cause.

0 Kudos
Historian
Historian
7,268 Views
Registered: ‎01-23-2009

Re: PAR Taking forever

But....

 

In 3 days and 18 hours, it only managed to consume 15hrs of CPU time (on all cores). This is a pretty large indication that you do not have enough RAM on your computer, and it is spending all its time swapping.

 

While it is running (next time) look at your memory utilization, and you will probably be able to confirm this. If so, adding more RAM will likely have a HUGE impact on your placement time - probably bringing it down to (around) 15 hours.

 

Avrum

Teacher rcingham
Teacher
7,254 Views
Registered: ‎09-09-2010

Re: PAR Taking forever

If it's doing A LOT of swapping, you should be able to hear the disk drives. That happened to me once (many years ago), and when the man from IT heard the sound it was making, he put more memory in straight away!

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Historian
Historian
7,244 Views
Registered: ‎02-25-2008

Re: PAR Taking forever


@gillesb wrote:

Finally finished!!

Total REAL time to PAR completion: 3 days 18 hrs 24 mins 34 secs
Total CPU time to PAR completion (all processors): 15 hrs 8 mins 15 secs

but both timing constraints not met :-(

but thats usually the case... still performs nicely.

whats the easiest way to make sure the clokc distribution isnt the problem.

 

because consumption is about 18%

though DSP slices is about 78%...

Thanks,

Gilles B


I wonder if your design has a LOT of combinatorial logic.

 

Look through your reports for number of logic levels. What's the worst value, and what is a more-common value?

----------------------------Yes, I do this for a living.
0 Kudos