V4 not packing registers into IOBs

Hello Group,

I'm having difficulty convincing Xilinx ISE (8.1SP1 WebPack) PAR to pack some of my signals into the IOBs of an XC4LVX25-FF668. A simple demonstration case is the MIG 1.4 dimm72 VHDL design for the ML461 memory eval board. The FPGA editor shows that most of the DDR command bus outputs correctly push their registers into the IOBs; however the DDR_CS and DDR_ODT output get registered within the fabric. The resulting skew between DDR_CS and the rest of the command bus outputs becomes fatal when generating cores for DDR systems with multiple ranks (chip-selects). The skew of 2ns or so is clearly visible in timing simulations, and my DDR2 model throws a tantrum about invalid setup time on DDR_CS.

I have tried seducing ISE into pushing the DDR_CS registers to the IOBs by setting XST "Pack I/O Registers into IOBs" to both "Auto" and "Yes". I have set XST register balancing to "No" and to "Yes" with Move First/Last Flip-Flop Stage disabled. I am also enabling the MAP option to Pack I/O Registers/Latches into IOBs. I am new to Xilinx FPGAs. With Altera I would enable Fast Inputs/Outputs in Quartus, and all the registered I/O would get pushed to the pads. Am I missing something obvious?

One thing I did notice: DDR_CS (and ODT) is different from the rest of the command bus in that it is directly fed a combinatorial term, whereas the rest of the command outputs are just relatches of signals registered on previous clocks. Should this make a difference? It seems to me that a combinatorial term could be routed from a slice to an I/O register, just as easily as a registered signal could...

Any thoughts or meditations are appreciated,

-Peter

Reply to
Peter
Loading thread data ...

Hi Peter,

I haven't worked with V4 yet, but in my V2 designs I usually found that the tools will pack into IOB registers if it is possible. The problem is finding out why it isn't possible, when they don't. In one case the problem was routing. In V2 (and possibly V4) IOB's come in pairs with some shared routing resources. In this case you may have all of the required register resources available in an IOB, but no way to route to them because of routing usage in the adjacent IOB. The acid test is usually to instantiate the IOB registers and look at error messages when the register cannot be packed as assigned.

Another problem I found was limited set/reset routing capability among the IOB registers. Often set/reset terms are not important for one register and you can fix the problem by sharing them with another register or removing them (no set/reset term still means the register gets initialized at configuration time, though).

H> Hello Group,

Reply to
Gabor

Hi Peter

it seems that you need to ask mr Lakshmi Gopalakrishnan what the means with his comment:

// added for deep designs "

the CS FF could be in IOB only if registers are duplicated, otherwise defenetly not as the outputs of those regs are used again in the design as inputs. as long as register duplication does not work there is no hope to see the CS output flops in IOBs

--
Antti Lukats
http://www.xilant.com
Reply to
Antti Lukats

Yes this may shed some light on the problem. If you have feedback from an output signal, ISE sill not pack the register into the IOB, because feedback through the pin is much slower. If you can find the feedback path and create a duplicate signal in the design for feedback, you may get lucky and have the register pushed into the IOB. This only works if the duplicate register isn't optimised away during synthesis. You may need to change some settings for this, or another approach is to make the "duplicate" signal not exactly the same by providing a different async reset term than the original.

Reply to
Gabor

Thank you Gabor/Antti,

You hit the nail on the head. The DDR_CS term was being used to generate the DDR_ODT (On-Die Termination) output. I edited the MIG-generated source to explicitly duplicate registers, and now all my outputs are registered in the IOB's. I opened a tech-support case to inform Xilinx of the issue.

Thanks again,

-Peter

Reply to
Peter

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.