UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor michielvb
Visitor
709 Views
Registered: ‎06-01-2018

LUT combining

Jump to solution

Hello,

 

I am undertaking an FPGA student project next year where throughput/area will be the main design goal. As I am relatively new to FPGAs, I figured a good way to start would be to study the Ultrascale+ CLB architecture to be able to create more optimal designs.

 

My question concerns the technique of LUT combining. After reading ug574 I implemented a simple 64bit AND, with registered output: y <= a and b. My expectation was for this to be implemented in just 32 LUTs, where each LUT implements two of the AND operation's bits, i.e. a single LUT implements y(0) <= a(0) and b(0) and y(1) <= a(1) and b(1). This would use four LUT inputs, outputs O5 and O6 and both output DFF Q and Q2. In default configuration however the tool uses 64 LUTS, with each LUT implementing one bit of the AND. AR# 52305 states that by default LUT combining is enabled and there is only the no_lc option to disable it.

 

After some testing, I found that with the AreaOptimized_high synthesis directive, the 32 LUTs get used as I first expected. This gives me the idea that there is an area-speed tradeoff related to LUT combining. However, relaxing timing constraints never resulted in a 32 LUT implementation. Could someone clarify what the drawback of this type of LUT combining is?

 

 

0 Kudos
1 Solution

Accepted Solutions
Scholar u4223374
Scholar
746 Views
Registered: ‎04-26-2015

Re: LUT combining

Jump to solution

Vivado's optimization strategy works very differently to how ISE did it, and it can cause some confusion.

 

ISE used to optimise everything as much as it could, then it'd try to place/route it and see what happened. As a result, it'd do things like LUT combining straight away.

 

Vivado tends to just place/route everything, check if it meets timing, and if it fails then it looks at optimization. If the design passes timing the first time, and the resource usage is within what the device can provide, then it just stops there - no point wasting CPU time on optimizations if the design already meets the requirements.

 

 

1 Reply
Scholar u4223374
Scholar
747 Views
Registered: ‎04-26-2015

Re: LUT combining

Jump to solution

Vivado's optimization strategy works very differently to how ISE did it, and it can cause some confusion.

 

ISE used to optimise everything as much as it could, then it'd try to place/route it and see what happened. As a result, it'd do things like LUT combining straight away.

 

Vivado tends to just place/route everything, check if it meets timing, and if it fails then it looks at optimization. If the design passes timing the first time, and the resource usage is within what the device can provide, then it just stops there - no point wasting CPU time on optimizations if the design already meets the requirements.