Routing resource starvation in spartan-6?

I recently ran into something that had me puzzled for a while.

I had a very regular design in the sense that essentially it was a small block copy-pasted along a line. As in, a long (192 bit) carry chain with a decode stage. The decode block was in chunks of 12 bits, so there were 16 of those decode blocks along the entire carry chain to handle all 192 bits.

I had all elements in place with RLOCs, LOCs and BELs, so it was about as regular as I could get it. Now most of that design met the timing constraints. However paths 2 did fail. The failing paths were parts of the decode blocks.

Since the carry chain spans multiple clocking regions, at first I thought it it might be related to these clocking regions. But after some more digging in fpga editor I noticed that for the failing paths it did the routing a bit different compared to the rest.

See fpga editor screenshot...



So these are 2 slices, both in the same CLB. The red line that bounces across is the failing path. As you can see the 4 routes from the lower slice all have a fanout of 3, one for each LUT in the upper slice that it routes to. So what you see in the screenshot is 12 colored paths total, of which only 1 is failing.

I still haven't found out why for this route it decides to bounce across (and not meet timings) while for all the others in identical blocks there is no problemo. Any idea what this can be? My guess at the moment was routing starvation (as in no more routes of a particular type), but then why do only 2 routes fail in 2 of these decode blocks while for all the other 14 blocks there is no problem?

And related to that, is there a way to get a report on routing resource usage in ISE? If I could get a report for each slice that summed up how much of the routing resources of each type was used I could find this sort of thing quicker, without spending an hour+ in fpga editor tracing down paths.

Did you try asking this on the Xilinx forum?

Alexium said:

Did you try asking this on the Xilinx forum?

Click to expand...

Now I have.

the switchboxes might not allow for a direct route, but clearly allow for some route without going too far. What does ISE list as the path for the failing net? eg, from the twr report.

permute said:

the switchboxes might not allow for a direct route, but clearly allow for some route without going too far. What does ISE list as the path for the failing net? eg, from the twr report.

Click to expand...

The timing report for the failing path was like this in planahead:



This was for a 375 MHz clock. In this particular run there were 2 more failing paths just like this one. The rest met timing.

still u can modify ur netlist(NGC or EDN), by manual selection of route path and try to synthesize it,
is this bouncing effects to the timing requirements of your design??

Regards,

How do you propose I do this modification of netlist? Any good tools for that? I can do manual fun stuff in fpga editor just fine, but that is not exactly the kind of solution I am looking for.

So if you know of tools that can modify the netlist without me having to do pointy-clicky then I'd be very much interested. To be more precise, me having to go through a user interface and having to manually select etcetc is a no-go. A command line tool that can be scripted that does the job would be very much welcome. Thanks!

u can modify the netlist(NGC or EDN)by only doing it manually, there is not tool which does user specific optimized routing as per design goal automatically. because auto routing is specific to design synthesis yield of target device with respect to its manufacturer, you can use the auto routing for 80-90% of your design, and for critical path you can use FPGA editor to modify the critical nets. that's it. in previous comment also you can se, i wrote about some timing specification of your design... so if it is really affecting the timing constraints of your design ,then go for manual routing by editor, after finding the critical timing paths.

gautamvsharma said:

u can modify the netlist(NGC or EDN)by only doing it manually, there is not tool which does user specific optimized routing as per design goal automatically.

Click to expand...

Hi gautamvsharma, thanks for your reply!

I must admit that up until now I have never done any manual edits on NGC or EDN files. Do you have any hint/tips/links I should read before I start messing with these files? Any help greatly appreciated!

Personally I'm a big fan of automating the job wherever possible, so ideally I'd like to make a little bash/perl/sed/whatever script that I can add to the Makefile.

in previous comment also you can se, i wrote about some timing specification of your design... so if it is really affecting the timing constraints of your design ,then go for manual routing by editor, after finding the critical timing paths.

Click to expand...

Good point. From your previous post ... "is this bouncing effects to the timing requirements of your design??" ... Yes, this does affect the timing. All the routes where this "bounce across" is done result in a larger delay, and hence this contributes to the design NOT meeting timing. All the other routes where it does not have this "bounce across" effect have smaller delays and meet timing.

gautamvsharma, following up on your suggestion ...

I just opened a few of the NGC files, but they don't exactly look manual-edit friendly. So what did you mean by "u can modify the netlist(NGC or EDN)by only doing it manually"?

HINT for you comment:
As i told you, You can open NGC and EDIF netlist ans can see complete path(after synthesis, tool will add up best path to meet all constraints & strategies entered.
You can see the written NGC and EDIF is similar to ADA language where net to net path is given. there itself you can modify as you can see the same path by opening the FPGA editor and can see & compare the componet inferred in that path, and can add/remove/modify netlist and re-route it for best result.

One more thing, this all manual editing is also to be done by application of XTMRtool by xilinx(you might aware of it). this tool is utilized for TMR applicable system design(i.e., SPACE and AVIONICS).

So try by yourself, learning and tweaking will only give you better engineering solution.

Have fun..

gautamvsharma said:

HINT for you comment:
As i told you, You can open NGC and EDIF netlist ans can see complete path(after synthesis, tool will add up best path to meet all constraints & strategies entered.
You can see the written NGC and EDIF is similar to ADA language where net to net path is given.

Click to expand...

Thanks for helping. I cannot however see that the NGC and EDIF are similar to ADA.

1) NGC ... The NGC looks like this:


2) EDIF ...
If I convert the above .ngc file to EDIF using the ngc2edif utility I get a human readable file. It doesn't look like ADA to me however.


To me this edif file looks like lisp. Are we talking about the same files?

I'm using ISE 13.3, so maybe you are using an older version in which the .ngc files are still human readable?

Okay, I just checked some older ISE 11.1 files I had, and there the .ngc files are also in that


... format. Only difference between the ISE 11.1 and 13.3 .ngc files is the XILINX-XDM version V1.5e instead of V1.6e.

And you are talking about .ngc and not .ngd?

I re-read all your posts a few times to check if I missed anything. Just to make sure I understand you correctly, let me try to summarize it:

"1) you can read either NGC or EDIF file to get full path information for instances."
"2) using this full path for instances, you can then find these instances in FPGA editor."
"3) for the instances that do not meet timing you can then press buttons inside FPGA editor until it meets timing."

Is the above roughly what you were trying to say? If no, what then?

I hope I understand it wrong, because that way there's still room for the magic solution. If I do however understand what you mean ==> "Bugger! Still no solution". So I'm still hoping I'm just stupid, and just not understanding what you mean.

On the plus side it did get me playing around a little with ngcbuild, ngdbuild and ngc2edif, which got me some useful results. Nothing that solves the problem from the original post, but useful info nonetheless. So thanks for that part of the inspiration. Your assertion "you can see this in the .ngc" got me searching for it. Unfortunately I still cannot read that .ngc directly (using a text editor I mean). From ISE I can open the .ngc file, but that just gives me a Technology Viewer.

The trick I learned today was:
1 - concenate all your project .ucf files into one big "all_constraints.ucf" file, because ngcbuild is stupidererer than ngdbuild.
2 - ngcbuild -verbose -intstyle ise -dd _ngcbuild/ -sd ../src/ipcore_dir -uc all_constraints.ucf -p xc6slx45-csg324-3 top_frequency_counter.ngc top_frequency_counter_now_with_banana_flavor_and_actual_constraints.ngc
3 - ngc2edif top_frequency_counter_now_with_banana_flavor_and_actual_constraints.ngc top_frequency_counter_now_with_banana_flavor_and_actual_constraints.edif

That procedure gives me 2 files:
- top_frequency_counter_now_with_banana_flavor_and_actual_constraints.edif
- top_frequency_counter_now_with_banana_flavor_and_actual_constraints.xncf

This newly generated EDIF file contains some constraints in it such as "TIG" (timing ignore) which are in the form of a "property TIG" on a net.


Most of the timing related constraints do NOT appear inside the EDIF file. The ngc2edif puts most of the timing related stuff inside the .xncf output file.


I can use this for some other things, so the end result of todays messing about is useful. Unfortunately still no solution to the original post, so I still hope I'm just stupid and missing something.