Avoiding FPGA Arrays

[PghFool]

I am performing some calculations on the FPGA with similar data inputs, so I have been using arrays to communicate parameters to the FPGA from my host system.  However, NI recommends avoiding front panel arrays in FPGA code, and it's not clear to me how to implement them in, say, block memory.  I'm having some trouble because my data processing loop usually takes 150 cycles to complete, but occasionally it jumps up to 3800 cycles, and I think it's messing up my processing.  The loop reads raw data from one target-scoped FIFO, and sends the results to a different target-scoped FIFO.  I use a few arrays of processing parameters that I store in global variables.  The processing loop is the only place they are read, and I write to them in a separate front-panel-monitoring loop, but only when an update flag is set to true.  Do globals sometimes fight for access to different variables on the same global.vi?  

What is the best practice for communicating an array of 15 parameters (that change only occasionally) down from the RT to the FPGA?  If I store them in block memory, does my processing algorithm read them out in a loop and create an internal array, which I then index?  

I am enclosing a self-contained subVI that exemplifies the kind of processing I do.  And my global.vi.  Thank you for any advice.

PS.  Whether I browse to a file and select it, or drag and drop, I don't see a list of attachments.  Hopefully, they are there anyway.

[PghFool]

Here are the files that wouldn't attach to my original post.

[Terry_ALE]

Fifteen elements is not too much to write as registers.  How many do you expect this to grow to?

The nondeterminism on the FPGA is the most concerning than anything else here.

[DerrickB]

You didn't attach all the relevant code so it's impossible to say exactly what the issue is. You're using a global variable that presumably is being updated somewhere else in the fpga code; this could cause periodic hiccups if it's being updated somewhere else while your normalization code is also trying to access it.

Generally for higher bandwidth applications the idea is to use a DMA FIFO down to the FPGA, do some processing, and DMA FIFO it back to the host. DMA FIFOs are single element but if you know you have 15 elements, as an example, you just always read/write in groups of 15. If there is variable counts then you decide on the largest size you'd need, implement the FPGA based on that max size, and have another control that specifies how many elements there are, or as the first element in a group of data.

[PghFool]

Thank you for the feedback.  I have five different sets of parameters that go into the calculation.  Are you suggesting 75 different individual registers?  I don't expect to need more than 15 parameters in each set.  I was thinking of storing them in a memory block, but then I'd need a loop to get them out, build an array, and then index the array, which would waste quite a bit of time.  

I agree that the nondeterminism is disturbing.  The only other access to the shared parameters is done only when the parameters need to change at the start of an experiment.  During a run they shouldn't change at all.  I'm not sure how to track down what's happening.

[DerrickB]

Instrument everything. Track timestamps of whenever things are updated, push loop periods in dma FIFOs so they can be charted from the host.

Arrays builds and index array are no-ops on FPGA; they're just syntactic sugar except at FPGA boundaries as they need to be double-buffered to ensure entire array consistency during updates. It's one of the reasons arrays can't be dynamically sized on FPGA as it directly allocates resources to hold each element; it's not a CPU trying to allocate contiguous blocks of RAM.

Post more of your code and we'd be able to make more suggestions. Without knowing what else that global is doing (and why it's a global) it's hard to be specific. If it's not used elsewhere then why doesn't it only exist in the scaling loop?