- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
PROBLEM RETURNS! Pl_Uap_Flo w1FitterRu leFastFeed backs: bad index to sec_nodes array.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
10-24-2011 06:59 AM
Sorry to be back posting this again but the problem does not go away. After ruling out a corrupt file my project would PAR yestrday. Today, with no changes whatsoever to the source code, the error is back. I am working on a second PC with a new install of 13.2. Unfortunately I have been denied a webcase and have no professor to make one. Any help gratefully received.
Phase 6 : 0 unrouted; (Par is working to improve performance) REAL time: 1 mins 16 secs FATAL_ERROR:Place:PlXil_Uapflow1.c:805:1.169.14.3 - Pl_Uap_Flow1FitterRuleFastFeedbacks: bad index to sec_nodes array. Process will terminate. For technical support on this issue, please open a WebCase with this project attached at http://www.xilinx.com/support.
Process "Place & Route" failed
Re: PROBLEM RETURNS! Pl_Uap_Flo w1FitterRu leFastFeed backs: bad index to sec_nodes array.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
10-24-2011 07:09 AM
This is not a solution, but playing around with the properties, if I change PAR effort from High to Standard I seem to be able to get route to complete, but I don't know if this is going to be a permanent fix. Why would it make a difference?
Re: PROBLEM RETURNS! Pl_Uap_Flo w1FitterRu leFastFeed backs: bad index to sec_nodes array.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
10-24-2011 08:30 AM
------------------------------------------
"If it don't work in simulation, it won't work on the board."
Re: PROBLEM RETURNS! Pl_Uap_Flo w1FitterRu leFastFeed backs: bad index to sec_nodes array.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
10-24-2011 08:56 AM
If this is a Spartan-3 device check to see that MAP is being run with the timing driven flow (-timing) otherwise placement is done during PAR which is no longer a mainstream use case. Otherwise, I suggest that you change the placement cost table during MAP (-t #) so that the placement is varied from the failing case.











