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: 
Newbie gnk_envent
Newbie
3,182 Views
Registered: ‎06-10-2010

PAR report

Hi,

 

I am using ISE 12.1 and getting the following PAR report after place and route .

Its not showing any of setup values, but shows only in final stage as follows:

 

Phase  5  : 0 unrouted; (Setup:273, Hold:486295, Component Switching Limit:0)     REAL time: 4 mins 32 secs

Phase  6  : 0 unrouted; (Setup:273, Hold:486295, Component Switching Limit:0)     REAL time: 4 mins 35 secs

Phase  7  : 0 unrouted; (Setup:0, Hold:486295, Component Switching Limit:0)     REAL time: 5 mins 9 secs

Phase  8  : 0 unrouted; (Setup:0, Hold:486295, Component Switching Limit:0)     REAL time: 5 mins 9 secs

Phase  9  : 0 unrouted; (Setup:0, Hold:486295, Component Switching Limit:0)     REAL time: 5 mins 10 secs

Phase 10  : 0 unrouted; (Setup:0, Hold:0, Component Switching Limit:0)     REAL time: 5 mins 33 secs

Phase 11  : 0 unrouted; (Setup:3867, Hold:0, Component Switching Limit:0)     REAL time: 5 mins 43 secs

 

 

How come It will show setup value in final phase instead of earliey phases of PAR report...I never seen this kind of report in earlier versions  and is happening with ISE 12.1

 

Do I need to (consider) react for this report to reduce the design's " timing score"? Looking for clarifiction. Thanks in advance

 

Tags (1)
0 Kudos
2 Replies
Anonymous
Not applicable
3,167 Views

Re: PAR report

I would open up a webcase to see why  timing score regressed after it met timing.

0 Kudos
Xilinx Employee
Xilinx Employee
3,142 Views
Registered: ‎07-01-2008

Re: PAR report

The router does a lot of pin-swapping as it rips up and re-routes the design and pin delays can change as that occurs. It doesn't immediately recalculate the new pin delays to save run-time so it is temporarily working with old pin delay information. I think what happened in your case was that the router met timing in phase 10, updated the pin delays and then reported a "new" timing violation in phase 11.

 

That said I don't remember seeing a swing as large as this. I also think based on when this occurred that the hold time router must be involved. It's not clear from your post whether phase 11 was the final router iteration. Did it quit with that timing error?

0 Kudos