05-25-2016 02:57 AM
Dear all,
I have a question concerning indexing an array on FPGA. Concretly I have a constant 1D array of size M and want to index chunks of size N of it. Unfortunatelly, when trying to compile I get the error message: Arrays with variable sizes at run-time are not supported. Is there a nice work-around for that?
Cheers
Solved! Go to Solution.
05-31-2016 03:52 PM
Hi
Steve
I have a question.
Do you put a block "arraysubset" into one "clock-driven Loop"?
I think that problem it's
regards
Leo
06-01-2016 02:21 AM
Hey Leo,
yeah the array subset is in a single cylce timed loop. Why is this a problem?
I think the problem here might be that the "compiler" cannot resolve the size of the array for a changing index. Althoug I declared the size of the stored array as a multiple of 40(I also take array subsets of 40), the compiler might think, that the changing index might lead to smaller arrays.
06-01-2016 05:16 AM
Hello there
I guess you're looking for this:
-Select the array you want to fix the size
-Go on the Configure ribbon and click Dimension and Size
-In the Array Dimensions pop-up be sure to check the Fixed size option.
A side note though, if your array is worth more than some 100s of bytes, I advise you to consider BRAM clocks instead, as big arrays are really hungry in LUTs/FF (FPGA ressources).
If you need even more than severak 100s KB, go for DRAM up to 2Go on USRP-RIO I guess.
Regards
Victor F. | Systems Engineer
Certified LabVIEW Developer | Certified TestStand Architect
National Instruments Budapest
06-02-2016 02:48 AM
Hey,
thanks. Yeah I selected this option actually. But I figured out, that after all the problem is a different one.
The problem happens, if I use the array subset later on in a function, output, or a SubVI with fixed input size. An example of this is attached as .PNG.(Here, eg., I chose the size of the output "sub" to be 40 elements)
The compiler might think, that by changing the array index it can happen that I index a part of the array where I just don't have enough elements left so that I have an array with variable size. But for my case I indexed arrays that have sizes that are multiples of the index, that means e.g. if I index 40 elements in each iteration and change the index accordingly, than the 1D array of fixed size would be 40*N, with N the number of possible index positions.
Has this already been noticed or is this known? Maybe I overlooked something? Would there be an workaround for this.
And yes I am thinking about implementing this into a BRAM, DRAM. But actually, as far as I know, for now you cannot choose that fixed size arrays are implemented in BRAM. Maybe this comes with a new version of LVCS.
Cheers,
steve0
06-02-2016 08:38 AM
Hello
Okay, I didn't get at first that you were playing dynamicaly with the Index input from the Subset Array function.
This is not supported in an SCTL, so that's expected behavior.
There is multiple workarounds for this, depending on how you're building your design.
1. Point by Point approach (as we usualy do in FPGAs), using an Index Array function on the RefArray, and with the use of counters, keep track of the Index, and evantualy count each sample retrieved.
That means that on each cycles, you have a sample that has to be processed, you're not working with an array anymore at the output.
2. Same as 1, but using a BRAM with I32 element as interface, from the screenshot you gave, I understand that your array worth several KBs, that can be a concern in the long run for your design.
3. Using an FPGA IP, you could build something like this:
You can use a For loop within the FPGA IP context that auto-index the RefArray, to pick up the samples you want, into your SubArray.
That means you can still work with an array at the output, but the cost will be that you can't get the SubArray out on each clock cycle. (use the Estimate function to see actual throughput)
4. You can explicity implement a big MUX, using a case structure. In each case, you provide the SubArray desired.
That's actually what LV FPGA would do if you where using a standard while loop. Ugly yes, but no way around it if you want a subArray out, on each clock cycle.
5. The BRAM/DRAM can work with an interface of up to 1024 bits, 32x32bits elements for ex, so you could have used that up to 32 elements in you case (using I32 elemnts)
So! I would recommend in your case that you use option 5 if possible:
-Consider BRAMs, your array as is start to be eager on Slices
-Use up to a 1024 bits interface on BRAM for a subArray, do you really need more than 1024 bits/subArray ?
If you don't see how to go from there, I would need more info on what you're trying to do + Throughout needed and amont of data stored and their data type
Bye
Victor F. | Systems Engineer
Certified LabVIEW Developer | Certified TestStand Architect
National Instruments Budapest
06-02-2016 08:43 AM
Hello Steve
I do you design for see you error, but for my sorprise
my design no error.
I suggest delete and start again
attached my desing
regards
06-03-2016 02:53 AM
Hello Leonardo
Thanks for trying to help, but here what I've stated before stays true.
Having a dynamic Index for the Array Subset function is not supported in Clock Driven Logic.
So, one of the workaround proposed is the solution.
@steve, please feel free to provide feedback and mark the correct answer as needed. Also do not forget Kudos 😉
Regards
Victor F. | Systems Engineer
Certified LabVIEW Developer | Certified TestStand Architect
National Instruments Budapest
06-03-2016 02:57 AM - edited 06-03-2016 03:00 AM
Hey Victor,
thank your very much for the detailed answer! This helps a lot in understanding. I had not yet time to work through the suggestions though, but I will come back to you! And also many thanks to Leo!
On a side note: I am actually working with FXP numbers, but nothing really changes here.
Cheers,
steve
06-06-2016 12:53 AM - edited 06-06-2016 01:03 AM
Hi Steven,
Here's an approach you can use to get ArraySubset with variable index working and get results on every cycle.
Your example is close to working but the compiler needs a hint as to the index + length beeing in range, so inserting an in range and coerce right before it, although redundant, will get things working.
See what I mean in the attached png.
Cheers,
Radu