EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

Sharing a single general lookup table

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - VHDL Language - Sharing a single general lookup table


Guest

Wed Sep 28, 2016 3:33 am   



I am implementing the gamma correction LUT as in https://ptpb.pw/ZwYS

if I want to share a single combinatorial lookup table with multiple input, it is not possible, right ?

because in this case, the lookup table would just assign to one output reg

say all r, g and b channels want to use the same combinatorial lookup table, how would I do it ?

Someone suggested the following, could anyone advice ?
mux -> lut -> demux


But my friend told me the following instead:
A 256-sized table can be done in one slice, containing 4-luts--for every output bit. It will consume all 4 luts of the slice.

So ... we're talking about 8 slices, or 32-luts, per color.

96 LUTs is reasonable. Now, if you wished to somehow re-use those 96 LUTs to get your logic down to a smaller size, be prepared for the fact that it will cost logic to make any logic change--perhaps as much as the 96 LUTs that you would originally need.

rickman
Guest

Wed Sep 28, 2016 7:30 am   



On 9/27/2016 9:33 PM, user123random_at_gmail.com wrote:
Quote:
I am implementing the gamma correction LUT as in
https://ptpb.pw/ZwYS

if I want to share a single combinatorial lookup table with multiple
input, it is not possible, right ?

because in this case, the lookup table would just assign to one
output reg

say all r, g and b channels want to use the same combinatorial lookup
table, how would I do it ?

Someone suggested the following, could anyone advice ? mux -> lut -
demux


There is no need for a demux on the output. Typically the output would
go to all three circuits and only one would use it at any given time.
Worst case you would add registers at the three inputs to the following
circuits and only enable one at a time.


Quote:
But my friend told me the following instead: A 256-sized table can be
done in one slice, containing 4-luts--for every output bit. It will
consume all 4 luts of the slice.

So ... we're talking about 8 slices, or 32-luts, per color.

96 LUTs is reasonable. Now, if you wished to somehow re-use those 96
LUTs to get your logic down to a smaller size, be prepared for the
fact that it will cost logic to make any logic change--perhaps as
much as the 96 LUTs that you would originally need.


There are also block RAMs on most FPGAs which will hold your entire
table in one RAM or you can use three separate RAMs and skip the
multiplexers. Often they are dual port so you can look up two values at
once in the same RAM.

I'm not very familiar with gamma correction, but I thought this was
based on luminance. That is, the luminance gives you a gamma value that
then must be multiplied by each RGB component to get the output values.
If you do this in a lookup table, you would need to either combine the
luminance with the individual RGB signals which would give you at least
16 address inputs, not 8. Or you could generate the luminance signal
from the RGB values and use a lookup table to get the multiplier which
then is multiplied by each of the RGB color signals to get the result.
FPGAs often have hardware multipliers as well.

Or do I not understand what you are doing?

--

Rick C

iamalien
Guest

Thu Sep 29, 2016 12:09 am   



But do remember, if you use block ram then you will need a clock pulse for every read operation since its synchronous.

elektroda.net NewsGroups Forum Index - VHDL Language - Sharing a single general lookup table

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map