luts are optimized away

Hi.

I made a programmable lut delay. Xilinx ise thinks it may optimize some luts away how can i prevent this.

I use synplicity for synthesis.

I already tried: keep keep_architecture syn_noprune syn_keep syn_preserve.

Changing the lut init by making an other design will change the number of luts it will optimize but it should be possible to say dont touch the luts??

Bram

Reply to
van de Kerkhof
Loading thread data ...

Howdy Bram,

A LUT delay? How much of a delay, and how did you attempt do this? Unless you are using an SRL, you are probably not getting what you are wanting.

Use FF's or SRL's.

Unless you instantiate the LUTs and Fx muxes, I could see it being very hard to keep a good synthesis tool from doing its job. After all, 99% of the users want the synthesis tool to optimize the LUTs as much as possible. It typically leads to faster designs and lower utilization.

Good luck,

Marc

Reply to
Marc Randolph

It is ment for dqs delay in a ddr design.

synthesis is ok the delay line is still there but ISE is deleting them.

Bram

syn_preserve.

of

luts??

Reply to
van de Kerkhof

try specifying a location for the LUTs in the constraints file to stop it being optimized away. Place the LUTs near the DQS pad to get a small delay

Reply to
Steven Archibald

You will probably need to instantiate the LUT1 primitive(s) in the design to get the LUT into the netlist. Then you need an attribute attached in the Xilinx constraint file: perhaps a "KEEP" or net "S" constraint will give you what you want - check the constraints guide.

As for the DQS... Are you looking at "matching" the delays for the DQS and data? If you're just looking for a delay, realize that the LUT delay can be a very sloppy value. Changes over PVT (process, voltage, temperature) will give you varying delays.

A more appropriate method of dealing with DDR memory in the pre-Virtex-4 devices may be to use the main clock and the guaranteed timing relative to that clock for appropriate access. If you use an external route to match the feedback clock delays to the clock/data delays, you have an extremely well-matched system. If you have a DCM available just for clocking in the data, you could phase-shift there instead.

this.

Reply to
John_H

Try also adding "LOCK_PINS" constraint to the LUTs.

Jim snipped-for-privacy@yahoo.com (remove capital letters)

formatting link

Reply to
Jim Wu

Hi

If you just need to delay dqs to capture the ddr data then maybe you can infer IBUF DELAY on dqs by giving contrainst in UCF. For Virtex2 devices the delay infered is arround 3ns.

Tia

Reply to
Tia

Hi

If you just need to delay dqs to capture the ddr data then maybe you can infer IBUF DELAY on dqs by giving contrainst in UCF. For Virtex2 devices the delay infered is arround 3ns.

Tia

Reply to
Tia

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.