Xilinx ISE 9.1

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

Reply to
g.eckersley
Loading thread data ...

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
 Click to see the full signature
Reply to
Georg Acher

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
 Click to see the full signature
Reply to
Georg Acher

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.

Reply to
tullio

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.

Reply to
g.eckersley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.