LUT4 INIT value to implement 2:1 MUX ?

PeterC schrieb:

think of the LUT as 16x1 bit RAM

I0=ADDR0 I1=ADDR1 ... for 2:1 mux RAM values should be

0 1 0 1

0

0 1 1

0

1 0 1

0

0 1 1

so you get INIT=CACA what happens to be the correct value as much as I recall from memory

Antti

LUT4 is a 16-1 look-up table. You can use the verilog equation below to calculate INIT, where init=INIT, i[0] = I0, i[1]=I1, i[2]=I2, i[3]=I3

reg [4:0] i; reg [15:0] init;

for (i = 0; i < 16; i = i+1) begin init[i] = i[2] ? i[1] : i[0]; end

HTH, Jim

Working in Verilog, I define parameters (or localparams) in my module as

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

and generate my inits directly:

LUT4 #( .INIT( I2 & I1 | ~I2 & I0 ) ) MyMux ( .I0(input1), I1(input2), I2(select), I3(1'b0) );

While a LUT3 primitive would work fine, some synthesizers don't like a

16-bit INIT provided for an 8-bit target so the 4th input of 0 works for more synthesizers. Plus, it's easier to "LOCK_PINS" to F4/G4 in a LUT3 if you actually instantiate a LUT4.

As Antti pointed out, the result would be 16'hcaca.

- John_H

Very elegant!

One question though, doesn't explicitly instantiating the LUT4 like this constrain the routing or is it smart enough to know that it can freely permute the pins with a suitable permutation of the initialization vector?

Also, this trick should generalize nicely to a Xilinx LUT6, but what about the Stratix II ALMs?

Tommy

The routing to the individual pins is free to move unless otherwise constrained. The LOCK_PINS constraint can be used to fix individual pins with a format like "INST MyMux LOCK_PINS=I1:A4;" to geep the .I1 signal on F4 or G4 or all four pins can be locked with the "... LOCK_PINS=ALL;" which I needed recently to keep the tools from optimizing a LUT used to select between two routing delays.

I haven't tried to instantiate an Altera ALM so I don't know if they have a similar INIT parameter. Your mileage may vary.

Thanks Antti, makes perfect sense.

I have written my code as follows, but FPGA Editor is telling me that the LUT4 function is:

= ((~A1*(A4*A3)) + (A1*(A4 + ~A3)))

This is clearly not a 2-input MUX!

Can anyone see any issues with the code below?

--------------------------------------------------------------- architecture ... attribute INIT : string; attribute INIT of i_lut4 : label is "CACA";

... begin i_lut4 : LUT4 generic map( INIT => x"CACA") port map(I0 => input1, I1 => input2, I2 => select, I3 => '0', O => output); ....

---------------------------------------------------------------

Oh dear, please don't crucify me for this, but obviously the function ((~A1*(A4*A3)) + (A1*(A4 + ~A3))) IS indeed a 2-input MUX, with select = A3.

I just wrote a MUX behavioural mode using a case statement, and FPGA Editor gave the same result as instantiating a LUT4 with INIT="CACA".

It is interesting (and probably obvious to someone else) that FPGA Editor would write the function in such a convoluted (non-minimal POS or SOP) form.