Xilinx ISE 9.1

Apr 16, 2007 4 Replies

It seems to work better (much better than 8.1), but seems to have a few issues that make it a bit hard to use.


1/ Sometimes it auto trims logic which is required - particularly when it is associated with Jtag devices. This behaviour seems unpredictable, and happens when completely unrelated logic is moved around, or even when an identical logical expression in vhdl is expressed differently.
2/ Sometimes multiple contending tristate drivers are generated when only one exists. This seems to depend on completely unrelated logic and also seems to depend on the syntax level in vhdl where the driver is declared.
3/ Routing sometimes fails, but adding a bit of extra random stuff can make it work. Sometimes a source program which fails to route on 9.1 routes quite happily on 7.1 .
4/ The random experimentation (usually tedious) to get round these problems is usually successful ,but can be very time consuming.

Does anyone have any comment , or way round any of these difficulties



Try playing with the -t parameter for map and par. Officially it's called "cost table" but I think it's just a seed for the random number generator. There are occasions where par simply won't meet the constraints in 40min, but with another -t-value it's done in 7min...

Georg Acher, acher@in.tum.de http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

There

formatting link

And then there is usually more than one constraint that isn't met. Otherwise it would be too easy to find out *the* critical path ;-)

I'm currently working on a design with an (until now) 30% used 3S1600E, but tight constraints. In most of the runs par is finished in 4 to 6mins. But there were also runs with 30min with and without success. Exactly the same input design with a different -t gives the fast runtimes again.

Maybe this randomness goes away when doing "real" floorplanning, at least it gets worse with no floorplanning at all.

I have an older design with an 95% used 2S200E which actually needs -t, because only 1 of 20 routings meets the timing... But at least you can do a batch lottery :-)

Georg Acher, acher@in.tum.de http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias

these are serious issues. You should open a webcase on xilinx.com and report them. I am often satisfied with their support. Be ready to submit your design, or even better just a small part of it showing the problems that you report.

Xilinx support has been excellent, and when I've submitted cases to them they have generally been resolved promply. I only submit cases when there does'nt seem to be a way around them. The issues I mention above would be known to Xilinx, as I have no doubt they do extensive benchmarking. Asking the user base for help on a net forum is often the best way to find tweaks to get around known problems. It would be good if Xilinx and other FPGA companies supported the development of open source tools for writing and programming. I have used only 2 devices, the xc2c64 cpld and the xc3s200 144 pin. Both have been excellent and the prices are low enough to make them well worth considering for low end applications. VHDL is a good tool for logic design. ISE produces good results, but is touchy, and its eccentricities add significant time to project development . Despite these issues I think FPGA's are a better choice than DSP's for many applications , and can save both development time and final cost now that the silicon has become much cheaper and better.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required