Chain of LUTs is being removed during par

Hi, I want to test what kind of delay is introduced by having an input go through 1000 LUT1 primitive in a Spartan3E FPGA. I am using ISE 9.1 to synthesize this but during map, it seems that it is optimizing the LUTs out although these were instantiated as primitives. Is there any way to force ISE to keep these. The design is as follows:

 library IEEE; use IEEE.STD_LOGIC_1164.all;

-- Synthesis TRANSLATE_OFF library SPARTAN3E; use SPARTAN3E.VPKG.all; use SPARTAN3E.VCOMPONENTS.all;

-- Synthesis TRANSLATE_ON

entity delay_luts is port( input : in STD_LOGIC; output : out STD_LOGIC ); end delay_luts;

--}} End of automatically maintained section

architecture delay_luts of delay_luts is

CONSTANT number_of_delay : INTEGER := 1000; component LUT1 is generic(INIT : bit_vector := X"0");

port( O : out std_ulogic; I0 : in std_ulogic); end component;

signal internal_signal : STD_LOGIC_VECTOR(number_of_delay-1 downto 0); begin delay_element_first : LUT1 generic map(INIT => X"2") port map( O => internal_signal(0), I0 => input );

-- enter your statements here -- delay : for N in 0 to number_of_delay-2 GENERATE delay_element_middle : LUT1 generic map(INIT => X"2") port map( O => internal_signal(N+1), I0 => internal_signal(N) ); end GENERATE delay;

delay_element_last : LUT1 generic map(INIT => X"2") port map( O => output, I0 => internal_signal(number_of_delay-1) ); end delay_luts;

Thanks, Amish

Reply to
axr0284
Loading thread data ...

Since it looks like you're instantiating the LUTs, two things: 1) Use the LOCK_PINS=ALL constraint to force the mapper to keep the LUTs; check the constraints guide for the current syntax. 2) To avoid pulse-width compression (different delays for opposite transitions) invert the signal at each LUT so the end result is normal but every-other LUT is inverted.

axr0284 wrote:

Reply to
John_H

Thanks for the answer. I used the following to force ISE to keep the LUTs: attribute keep : string; attribute keep of internal_signal: signal is "true";

I am this "pulse width compression" and I am wondering why that occurs. Is it possible to give me a more in depth explanation or point me to some website that has the info. Thanks. Amish

Reply to
axr0284

I don't have references, only experience. The Tphl and Tplh numbers for a digital element (Time of Propagation for High-to-Low or Low-to-High transitions) are slightly different given the nature of asymmetric slew rates, DC logic levels, and switch points. It's only noticeable in high-speed logic or when many elements are chained together. In your case, a 4 ns pulse traveling through your 1k LUT chain will probably either come out as no pulse or as 10s of ns.

If you search for tphl and tplh, you might find hits on data sheets that specify the two values or a difference between the two.

Reply to
John_H

Among the many thousands of tests performed on every chip before it leaves the factory, are propagation delay tests of highly concatenated LUTs. So, you are in good company... Peter Alfke, Xilinx Applications

Reply to
Peter Alfke

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.