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
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
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??
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
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.
Try also adding "LOCK_PINS" constraint to the LUTs.
Jim snipped-for-privacy@yahoo.com (remove capital letters)
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
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
Have something to add? Share your thoughts — no account required.
Ask the community — no account required