XC9500 design does not fit into Coolrunner

Klaus Falser wrote: : Hello,

: I have a rather large design for a XC95288XL which consumes 276 macrocells : of 288 possible. : Since Xilinx seems to prefer Coolrunner devices to the good old XC9500's : I tried to stuff the design into a Coolrunner II chip to look how it : would behave.

Did you play with the fitter options?

: However, I was not able to make it fit even in a 512 macrocell device. : Timing should not be so tight, it has to run at 8 MHz clock, but the : timing analyzer gives me 17-18 MHz on the slowest 10 ns device.

The Macrocell of the XC2 is not as wide as the cell of the XC95X(V), so some logic may need expansion on two cells.

: Can anybody which know's the XCR2 better than me give me a hit where : to pay attention? : How can I see from the report where the fitter has a problem?

Did you look look at the *.rpt files?

Bye

Have you considered other vendors?

Lattice makes several devices that will go bey> : Hello,

macrocells

some

There are not so many. You can choose between speed, density and balanced. Something which improves fitting is to switch off "Keep hierarchy" in the VHDL compiler options.

This may be on of the reasons. But on the other side, not all equations are so large and having twice as much macrocells should be more than enough.

Sure I did. It is, however, at least a little bit difficult to scan 250 equations to look for some anomaly. And I have got no idea how such an anomaly should look like.

Thanks

: Sure I did. It is, however, at least a little bit difficult to scan 250 : equations : to look for some anomaly. And I have got no idea how such an anomaly : should look like. : Try to understand what equations blew up. Strip down your code line by line and see how the fitter behaves.

Bye

Try contacting the Xilinx hotline, they're usually willing to help look at designs and can save you some time by at least identifying the cause of the no-fit.

should look

Klaus -

A couple of things you might try:

1. Compare the XC9500 reports to the CoolRunner reports.
2. Compile parts of the design by themselves, first to XC9500 then to CoolRunner. See which modules blow up in the CoolRunner.

Robert

Have you constrained the design (pin assignments, etc)? What is the fitter complaining about?

There are some hard limits, like less OE lines than there are outputs to a block. If, for instance, you are trying to create a large GPIO device with more than 4 I/Os per block (8 are possible) it won't work.

Kind regards,

Iwo

..snip .

No, for my first try I did not give any constrains, whether for pins nor for the timing. The I/O interface is bus-like, so the I/O lines share all the same OE. From my experience with the 9500's I have seen there are sometimes problems when creating a too large multiplexor, which comes from the available Product terms per macrocell. For instance, if you have a bus and you want to read back from more than 5 different registers, which implies a multiplexor before the output-pins, you have to distribute your pins carefully, since every macrocell with an output pin needs to steel PT from their neighbours. Coolrunner CPLD seems to have less PT inputs per macrocells, but give enough macrocells and without placing constraint I did expect some fit.

Best regards

"Klaus Falser" wrote

for the

problems when

terms per

output-pins,

output pin

enough

Comparing the two RPT files should give some guidelines ?. It is common for fitters to give better info, for a design that fits, so 'approaching the problem from (just) below' can be much more productive. When you have a partial design fitting, check the correct globals have been mapped OK. Missing a global resource can balloon usage. Sometimes the device package can have an influence - if there is more than one choice, get a report file for each package.

-jg