About 433 slices for a minimum function?

[vitrion]

I designed a simple minimum function, which selects from two numbers the smallest. It needs a MUX and a comparator. When I compile this with LabVIEW FPGA, it generates me 433 Total Slices, 513 Slice Registers and 524 Slice LUTs. I cannot understand why those numbers. When I design it with VHDL in Xilinx I obtain less than 20 slices. Why so huge?

Thank you

[Intaris]

Have you tried the max and min function instead?  It's on the comparison palette.

What are your datatypes for the FXP controls?

Are there controls and indicators visible ont he FP of the VI you are compiling?

[.aCe. · Accepted solution]

LabVIEW adds bits and bobs on top of your code to enforce data flow. You can do things to optimise your code:

The following link may be useful:

http://zone.ni.com/reference/en-XX/help/371599H-01/lvfpgaconcepts/using_sctl_optimize_fpga/

Also

http://www.ni.com/white-paper/3749/en

http://digital.ni.com/public.nsf/allkb/311C18E2D635FA338625714700664816?OpenDocument

http://digital.ni.com/public.nsf/allkb/722A9451AE4E23A586257212007DC5FD

[Nick-C]

vitrion,

It's more than just data flow enforcement that is being added in the generation of intermediate files (VHDL). 

There's a certain amount of overhead for every application compiled for a National Instruments FPGA target. This includes defining blocks of logic for reserved resources like DMA transfer, PCI bus communication, SPI bus communication (for C-series modules) among other things. 

Compile a blank FPGA VI in the context of that project and it will give you an idea of what overhead you should expect in any FPGA VI you compile. That will also let you compare resource utilzation there to the utilzation of your mimimum function and you should get a more accurate estimate of how many slices are being used.

Best,

[vitrion]

I'd tried with that MINMAX function available in the Comparison Palette, but it's bigger. FXP data is 8-bit without fractional part. Both controls and indicators are visible on the FP.

[vitrion]

Thank you very much for the help.

[Intaris]

Having controls and indicators on the FP costs extra resources also because you can communicate directly with them.

[Hooovahh]

Several people have already mentioned why the slice count is so high but I figured I'd add my knowledge too.

When the compiler does it's thing it puts components down in a very inefficient way at first.  So adding a U32 indicator to the front panel in this example may take 100 slices.  But as you approach the 100% usage of the hardware the compiler goes back and tries to refactor the code to fit better.  It may take 100 slices to add the first front panel U32, but after you've added 60 you won't have used 6000 slices because the cost won't be linear.  I've seen complations that were over 130% full fit into 100% (well 99%) because of optimization in the compiler.  This refactoring will cost in time as the compilations I've seen will take several hours to get that 130% down to 100%.