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: 
Observer glennchid
Observer
3,539 Views
Registered: ‎05-09-2017

Xilinx ISE - changing signal names alters implementation

Jump to solution

Hi all,

 

I am using Xilinx ISE 14.7 (targetting Virtex5, hence no Vivado), and have come across a problem with the tools whereby changing names of signals within the design has an impact on the implementation, and hence timing, and in some cases a slight change in the name of, say, a counter can make a difference between a design comfortably timing and failing quite badly.

 

Has anybody else experienced this?

 

I had come across this several times before, but always managed to convince myself that there was another underlying reason, as I did not want to believe that the tools could be so picky. I now have some very concrete examples of this now, and have discovered that it is not the signal name itself that matters but the number of characters in the name! For example, two designs differring by one signal called 'j' and 'jjj' can have vastly different timing results, whereas designs differing by 'jjj' and 'ctr' will be identical. Also, from comparing reports it appears that difference originates from the mapping tool, as synthesis appears to infer an identical output for the different designs.

 

I am still hoping that that a more logical answer can be given, as otherwise this adds a new challenge to timing closure if you need to also randomly change signal names in order to meet timing!

 

I would love to hear any comments or solutions ...

 

Cheers,

 

Glenn.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide avrumw
Guide
5,934 Views
Registered: ‎01-23-2009

Re: Xilinx ISE - changing signal names alters implementation

Jump to solution

Welcome to the joys of digital design!

 

Many of the problems involved in these processes are "NP hard" problems (both synthesis optimizations and place and route are). As a result they are "solved" with heuristics. Heuristic solvers for NP problems are, by their very nature, chaotic systems.

 

The definition of mathematical chaos means a system that is "extremely" sensitive to the initial conditions. If you give this system identical inputs it will generate the same outputs. If you change the inputs, even by what may be considered an imperceptible amount, the result can be wildly different from the original. This is chaos.

 

So, yes, if you change anything in your system (RTL code - yes, even a name change, constraints, tool options) even by a tiny bit, you will end up with a different solution. And, yes, one solution may comfortably meet timing, and the one after the change may violate timing (potentially even by a lot).

 

This is true, has always been true, probably will always be true, and is one of the unavoidable consequences of using highly automated processes (RTL synthesis, automatic place and route) for these problems...

 

(Sorry)

 

Avrum

View solution in original post

Tags (1)
0 Kudos
5 Replies
Highlighted
Guide avrumw
Guide
5,935 Views
Registered: ‎01-23-2009

Re: Xilinx ISE - changing signal names alters implementation

Jump to solution

Welcome to the joys of digital design!

 

Many of the problems involved in these processes are "NP hard" problems (both synthesis optimizations and place and route are). As a result they are "solved" with heuristics. Heuristic solvers for NP problems are, by their very nature, chaotic systems.

 

The definition of mathematical chaos means a system that is "extremely" sensitive to the initial conditions. If you give this system identical inputs it will generate the same outputs. If you change the inputs, even by what may be considered an imperceptible amount, the result can be wildly different from the original. This is chaos.

 

So, yes, if you change anything in your system (RTL code - yes, even a name change, constraints, tool options) even by a tiny bit, you will end up with a different solution. And, yes, one solution may comfortably meet timing, and the one after the change may violate timing (potentially even by a lot).

 

This is true, has always been true, probably will always be true, and is one of the unavoidable consequences of using highly automated processes (RTL synthesis, automatic place and route) for these problems...

 

(Sorry)

 

Avrum

View solution in original post

Tags (1)
0 Kudos
Professor
Professor
3,518 Views
Registered: ‎08-14-2007

Re: Xilinx ISE - changing signal names alters implementation

Jump to solution

Your best bet with projects like yours is to use Smart Xplorer with a range of starting placement cost table seeds.  As noted, the tools start with a seemingly random placement and then work to a "best" placement using some proprietary algorithm that probably involves a series of placement swaps.  In any case, the "best" placement is really only a local minimum in the routing length, because as already pointed out finding the absolute minimum in routing length would not be solvable.  It's something like the traveling salesman problem with thousands of places to visit and multiple salesmen that need to share the road without creating too much traffic...

 

Even after you find a seed that works, you still need to go back to Smart Xplorer each time you make even a small change.  However I have found that locking down a portion of the design can be helpful.  Typically when you find a working solution, it helps to lock down the position of non-fabric elements like BRAM, clock buffers, and DSP.  This often helps to tools to converge on a similar solution the next time around.  You can also use guided placement, however that has some drawbacks.  The main drawback is that the guide is based on already packed slices.  That means that even a small change in the design can end up with a large number of differences in slice names, and hence non-guided cells.

-- Gabor
Observer glennchid
Observer
3,320 Views
Registered: ‎05-09-2017

Re: Xilinx ISE - changing signal names alters implementation

Jump to solution

Hi Avrum and Gabor,

 

Many thanks for your prompt answers, and sorry for my delay in replying. I am sure everything you both say is correct, but it still leaves me with a bit of queasy feeling! I can understand that changes to the RTL behaviour, constraints, or tool settings would result in a different implemention and hence the timing, but signal names *ought* to just be treated as labels, and ideally not change the result. In fact, I verified (using ngc2edif, and diff) that the syntheisised netlists from XST (for two designs with differently named signals) were identical, modulo the names themselves.

 

Anyway, I understand a bit better now what was causing the wild variation in timing results in my example designs. As I was only implementing part of a design (just to get a feel for the timing closure of a few submodules) I had not loc'ed down any pin assignments, and so the tools were free to freely float the top-level IO pins. Indeed, (arbitrarliy) assigning LOC constraints gave much more constistent results when changing signal names, although not identical for reasons you both describe, the variation was much reduced. This gives me some confidence that a design which comfortably meets timing, should continue to do so, for example when just the name of a counter is changed.

 

I don't think I have ever tried using Smart Xplorer but I remember I often needed to use Multi-pass place & route in the past. My impression was that MPPR had more of less been superseded by things like physical synthesis and timing-driven map, which tend to give much better results than changing the placer seed. i have also tried guided P&R with variable success. If I have timing problems these days I tend to try to fix things at the RTL level first, and then with advanced constraints, such as false paths, if appropriate, rather than varying tool settings if I can.

 

Thanks again for your help.

 

Glenn.

0 Kudos
Professor
Professor
3,312 Views
Registered: ‎08-14-2007

Re: Xilinx ISE - changing signal names alters implementation

Jump to solution

MPPR is replaced by Smart Xplorer.  There are more modes that just playing with cost table seeds, however in that mode it is essentially multi-pass Map/Place&Route.  That is necessary because placement occurs during mapping in the newer versions of ISE.  In ISE you can manually change the cost table seed for both Map and Place&Route, but it really only affects Map.  You get a warning if the two seeds don't match.

 

Another Smart Xplorer mode is to try different sets of canned settings (other than cost table seeds) to see if any of them works better for your project.  I rarely use this mode, since I've been using ISE for a long time and have discovered the settings that work best for me for a given type of design.  Everything that Smart Xplorer changes in the canned sets can be tweaked individually in the properties for Map and Place&Route.

-- Gabor
0 Kudos
Observer glennchid
Observer
3,178 Views
Registered: ‎05-09-2017

Re: Xilinx ISE - changing signal names alters implementation

Jump to solution

Thanks Gabor,

 

I may try SmartXplorer again if I run into timing difficulties in the future. Like you, I tend to know which tool work for my designs, and I override these locally with synthesis attributes for signals which diverge from the default settings.

 

Cheers,

Glenn.

0 Kudos