In place array element modification in FPGA

[raphschru]

Hi,

While making a code that modifies a cluster from a cluster array, I noticed the "In Place Element Structure" was not available for my FPGA target (NI 9145).

So I am wondering if the in place modification for arrays is done implicitly by the compiler or if this operation is simply not supported for FPGA.

In my example, I have a cluster array from which I want to modify one element. Is there a better way than using "Index Array" followed by "Replace Array Subset" ?

My idea was the following, but I find this is a bit ugly, and I am not even sure it improves performance / resource utilization:

Any idea on how to improve this code ?

Regards,

Raphaël.

[Terry_ALE]

"In Place Element Structure" is not supported on any of the NI FPGA targets that I have ever worked with.

Does what you have below compile?  LabVIEW FPGA will flag functions or configurations where it thinks the array is dynamic.  This looks like it is good.  And btw, not sure if it can be improved from what I can see.

[AndersSekanina]

Hi

I would expect the top one is most efficient, because you only have one copy of the fixpoint value. 

You could optimize more by replacing the loop "Get available results from another module" to a single cycle timed loop. 

[raphschru]

@Terry_ALE

Too bad, I don't see why it wouldn't be implemented on FPGA (at least for index/replace array element).

And yes my example compiles, the editor itself is smart enough to know that all arrays are of fixed size [24].

@AndersSekanina

After compilation tests, it appears the top one takes indeed less FPGA slices.

Sheer speculation, but maybe the compiler is smart enough to reuse the dynamic addressing of the array for the index and the replace ?

Since my cluster is quite big (~200 bits in total), I initially supposed it would be worse than just having a copy of the FXP values in another array.

Regards,

Raphaël.

[Terry_ALE]

---

@raphschru wrote:

@Terry_ALE

Too bad, I don't see why it wouldn't be implemented on FPGA (at least for index/replace array element).

---

In place elements are about memory management.  FPGAs are a hardware device and memory management is a software concern.  On FPGAs, memory is not allocated the way it is in software.  On FPGAs we allocate the resources at compile time and they are more or less fixed.  For more information, I recommend reviewing the FPGA technology itself as it works behind the scenes.

[Intaris · Accepted solution]

---

@raphschru wrote:

@Terry_ALE

Too bad, I don't see why it wouldn't be implemented on FPGA (at least for index/replace array element).

And yes my example compiles, the editor itself is smart enough to know that all arrays are of fixed size [24].

@AndersSekanina

After compilation tests, it appears the top one takes indeed less FPGA slices.

Sheer speculation, but maybe the compiler is smart enough to reuse the dynamic addressing of the array for the index and the replace ?

Since my cluster is quite big (~200 bits in total), I initially supposed it would be worse than just having a copy of the FXP values in another array.

Regards,

Raphaël.

---

Programming on FPGA is different than on Windows or RT. There are some functions in code which LOOK expensive, they take up a lot of screen real-estate but actually cost nothing on the FPGA. The opposite is also true, there are sometimes functions or features which are easily overlooked which have big side-effects on code.

Indexing an array and replacing part of it is very interesting on FPGA. In the example shown, the concept of the cluster doesn't actually exist in FPGA with respect to the "replace array elements". The unbundle, change and bundle essentially codes down to a no-op. The code works out which bits of your cluster are affected and simply overwrites them. This is the impact of the "unbundle". It simply tells the compiler what you're replacing. The rest is essentially constant folded. It's not actually a dynamic operation, even if the code makes it look like it. In VHDL, the actual "code" being executed will actually be more like a "Replace array element, but only this part of the cluster". The "unbundle" is only required to tell you which part of the cluster. Of course LV doesn't HAVE such a function, so we need to create it in the way you have shown. But the compiler understand what we're doing and only does what is neccessary, nothing more. But after conversion to VHDL, the parts of the "decisions" which are constant mostly become no-ops.

It takes some time to understand what's actually going on under the hood with LV FPGA code. But when it clicks, you realise there are all kinds of operations you can use which on Windows look expensive but are free on FPGA and vise versa.

[Terry_ALE]

Well said @Intaris.

Additionally, if one checks the LabVIEW FPGA help for these specific functions it will indicate that.  Quotient Remainder is a good example of a very resource intensive function. Join and Split are good examples of free functions.

[Intaris]

---

@Terry_ALE wrote:

Well said @Intaris.

Additionally, if one checks the LabVIEW FPGA help for these specific functions it will indicate that.  Quotient Remainder is a good example of a very resource intensive function. Join and Split are good examples of free functions.

---

Exactly, and my new favourite "search and destroy" target is a coercion dot. A coercion dot can cause rounding and / or saturation logic to be implemented. Sometimes we want this, sometimes we don't. Using terminals with certain datatypes to do automatic conversion SEEMS like an easy way to get data we require, but that little red dot can often lead to some expensive code being executed to perform the function we have (perhaps inadvertently) told it to do. I always try to keep control of my saturation and rounding options myself. I DO still use simple coercion, but I will always put a comment on the terminal highlighting the fact.

Oh, and sometimes "non-diagram component" cans imply refer to work being done by a coercion dot. The coercion dot is not technically part of the source code, it's not an entity of its own, it's an IDE hint, so that's always one place to check if you're getting trouble with "non-diagram component" timing violation errors.