Nesting arrays

[kakemoms]

Hi

I have a few arrays of 256 bytes that are defined like this:

Code: [Select]

reg [7:0] array1 [0:255]
reg [7:0] array2 [0:255]
and so on..

Now, I refer one array inside another for certain conditions to occur (and I do this several places):

Code: [Select]

(array1[array2[somepointer]]==validvalue)?Yes:No;
The thing is that my fpga code gets huge unless I limit the array size. So it seems its not a good idea.. but why does this happen? Its only 256 bytes per array.. but it consumes like 20000+ LUT4's.

[Daixiwen]

You can use the RTL viewer to see what kind of logic is generated from your code, but the main problem is probably that the synthesizer can't use the hardware RAM blocks in the FPGA and have to implement the arrays using LUTs only. It means already one LUT per bit, so 4096 LUTs plus the address decoding logic. If you do this in several different places, and they each run in parallel, each implementation will have its own set of address decoding logic LUTs. And if it gets too complicated, the synthesizer may in addition be required to duplicate some logic to meet the timing requirements.

If you need to reduce LUT usage you'll have to look into using the RAM blocks to store the arrays. Depending on the synthesizer you use, you may have to write your code in a certain way (for example register the input and/or the output, and limit access to two ports or less) or use a pre existing RAM ip block that you instantiate in your code. You will probably have to redesign your code around those lines, to adjust to the extra latency from the input/output registering, and try to centralize access instead of spreading it in several places.

[SiliconWizard]

HDL is not like (sequential) software programming.

If you're addressing "arrays" in naive ways, it gets extremely expensive very fast, because basically what you wrote expresses a combinatorial access to memory.

One way of doing this much better is to pipeline it. Pipelining will also enable synthesis to possibly infer block RAM, while as expressed here, it will never infer that.

Pipeling here will consist in registering 'array2[somepointer]' and use that register to address 'array1'. Of course this will introduce a 1-clock latency which you need to account for. And all this needs to be put inside a clocked process.

[kakemoms]

Thank you for good answers.

I used this as a part of a state machine, so pipelining is already there... then you want to accomplish something, and just enter it without too much thought about what is actually going on... 

Looks like I have to analyze his thoroughly before I reimplement the arrays (in an unnested form).

Thanks again!