Fast Carry Chains in Xilinx SpartanII FPGA's

I want to be able to use the fastest possible paths within a SpartanII FPGA to create internal signals which are simple copies of each other linked in a chain. Delay between each should be in the order of a few tens to hundreds of picoseconds. All of the created signals should however be usable by other internal logic (in fact on D inputs of a chain of flip-flops clocked all the same) My first idea was to define a chain of BUF "components", and see what happens. As feared, the (Foundation) development tool just merged all the signals (No BUF generated). Forcing a KEEP attribute on all the signals just did not help. I tried with LUT1's. This works but is much too slow for the application. Looking at the FPGA Editor gave me the idea of using the MUXCY, MUXCY_L or MUXCY_D components of the SpartanII library. Some sort of a miracle happened then: the dedicated carry chain was selected, running thru the expected number of CLB's, and speed was excellent. But to my great surprise, only one flip-flop out of two hooked onto the outputs of the MUXCY components was selected as being part of the same cell. The second FF was placed in a totally different CLB. This is not exactly what I expected, since the application requires a very close matching of delays. Any idea why this happens ? Possible corrections ? Thank you beforehand.

Reply to
A Beaujean
Loading thread data ...

There may be other controls in your registers that make packing both registers in one slice illegal. There can only be one clock enable or set/reset for both registers in a slice.

You can extend your chain to twice the length and use one register per slice and everything should flow.

Reply to
John_H

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

Another thought: If you're instantiating the MUXCY primitives, you may need to add an XORCY between the MUXCY and the register. Take a look at the slice configuration - the Virtex functional data sheet illustration is more detailed than that found in the Spartan-II's - and you'll see that the MUXCY output from one "stage" of your carry chain feeds the XORCY of the register one half slice above.

Also, rather than instantiating 12 MUXCY and XORCY primitives, try using the

13-bit result from 13'h1fff+In where you may need to add some directives to keep a smart synthesizer from reducing your equation to an equivalent 1-bit result. Use the top 12 of the 13 bits for your "deterministic" delay and you're there. It may be cleaner and easier to implement in the end.

Reply to
John_H

OK: I had a bit more time working again on this idea. Your idea to define the result of say "111111" + ("00000"&Input) and register it is the most staightforward choice. Works fine. All FF's are now perfectly facing the corresponding carry logic. Time is now pratically deterministic.

Thanks.

Reply to
A Beaujean

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.