Re: Getting on the Spartan3e carry chain.

Symon wrote:
Guys,
Using ISE10.1 my design's timing fails, whereas it used to be fine. Here's
the problem:-

In ISE8.2 the P&R tools had the sense to use the topcyf path to get onto the
carry chain which takes 1.162ns

file:///C:/Xilinx/10.1/ISE/doc/usenglish/help/delay_types/html/web_ds_sp3/ta_topcyf.htm

In ISE10.1 the P&R tools seem intent on using the tbxcy path to get onto the
carry chain which, although it saves a LUT, takes 1.882ns adding 720ps
delay.

file:///C:/Xilinx/10.1/ISE/doc/usenglish/help/delay_types/html/web_ds_sp3/ta_tbxcy.htm

I tried messing about with the ISE10.1 Map and P&R properties, with no luck.
In MAP, I changed 'Optimization strategy' to speed. I set the tick box for
'Perform timing-driven packing and placement'.

Any clues?

Thanks, Symon.

If you can't change the source or the constraints file, you probably
don't have recourse. If you can't change the source, you might still
have the chance for a "keep" constraint in the right place specified
in the ucf. If you can change the source, you have a decent chance.

I tend to change the source in the logic at the bottom of the carry
chain. A "keep" in the right place or exchanging the LSbits between
two vectors that are added ({a[9:1],b[0]}+{b[9:1],a[0]}) or even
sometimes b+a instead of a+b coding is enough to make a synthesizer
"think" differently. Even adding an unused LSbit in a manner that
doesn't get optimized away can push the synthesis to produce a
"better" result though at the cost of one Tbyp.

It's probably the synthesizer and not the map/p&r tools giving you the
troubles; if you have an edif flow or a technology view that is true
to the synthesis output, see if there are hints on whether you succeed
before p&r.

- John_H
.