Xilinx/Synplicity LUT Placement

Folks,

Does anyone know if either Xilinx or Synplicity have provided a mechanism to explicitly place an inferred LUT?

I can produce LUTs that only feed a keep_buf but don't maintain the same LUT name across compiles for RLOCing. I can guarantee the net name for Place & route with the keep_buf but can't associate the net with the LUT's placement.

I'd love for the Xilinx tools to propagate a location constraint back to the primitive that drives it since Synplicity hasn't come up with a nice way to guarantee a net driver's name.

Any help is appreciated,

- John_H

Reply to
John_H
Loading thread data ...

John, no I haven't found a way to do this for inferred LUTs without making them a separate entity. If you keep your logic to 4 inputs, then the PAR software will generally place the LUT with the flip-flop, so you can usually get away with just placing the flip-flop and letting the inferred LUT follow it. For my commonly used IP blocks, I have a library of lut functions, each in its own entity. Synplicity lets you put an xc_map=LUT property on it that makes it into a LUT component. For example:

--FMAP'd or2 library IEEE; use IEEE.std_logic_1164.all;

entity fmap_or2 is port ( a, b : in std_logic; z : out std_logic); end fmap_or2; architecture rtl of fmap_or2 is attribute xc_map : STRING; attribute xc_map of rtl : architecture is "lut"; attribute syn_hier: string; attribute syn_hier of rtl:architecture is "hard"; begin z

Reply to
Ray Andraka

Thanks, Ray.

I've been instantiating LUT4 primitives and INITing the LUTs with the appropriate equations. Maybe I can get creative and figure a way to get the xc_map=lut attribute to parameterize well in Verilog.

I appreciate the help,

- John_H

Reply to
John_H

John, a long while back (>5 years), someone wrote a VHDL function and posted it here for creating the INITs for LUTs. As I recall, it accepted a boolean equation as a string for input and returned the hex string for the LUT init as the output. The advantage, of course, is that it makes your code a heck of a lot more readable and less error-prone. If you can't get the xc_map to work out for verilog (not sure how much good it does in verilog anyway because you can't generate the RLOC values with a verilog generate without some sort of pre-processor), then perhaps you can use a boolean equation to INIT string parser function to do that conversion. That is my back-up position should synplicity ever take away the xc_map attribute.

I gotta say, instantiating LUTs and using the INITs directly is not a fun way to do any design. I guess you get pretty good at memorizing the hex strings for common function, but Oh, the pain!

Reply to
Ray Andraka

I actually do things rather well with the existing INIT, I'd just like to do it cleaner.

localparam I0 = 16'haaaa; localparam I1 = 16'hcccc; localparam I2 = 16'hf0f0; localparam I3 = 16'hff00;

LUT3 #( .INIT( I0 & I1 | ~I0 & I2 ) ) MyMux( .O(Y), .I0(Sel), .I1(Ahi), .I2(Blo) );

I put the localparams at the head of the Verilog module I'm creating and the rest flows. I end up with 120 characters of width to instantiate a dozen LUTs each in a single line so it isn't as pretty a simple 4-input equation but it works. I can sometimes work it in for arrays of instances.

Thank goodness I don't have to memorize the INIT tables. I just need to avoid using the conditional operator (I0 ? I1 : I2) because it's really

16 bit numbers in that init, not 1-bit ports. Using 16-bit numbers for the 8-bit INIT in the LUT3 example above is harmless with a simple truncation providing the functionality I need. I think I may have started that coding style after one of your posts about 3 years ago.

I look forward to the far-off day when the primitive driving a wire is named after that wire in some predictable way.

- John_H

Reply to
John_H

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.