LabVIEW
Read multiple memory items simultaneously in LabView FPGA
@rolfk wrote:
wiebe@CARYA wrote:
But you can have the write loop execute before the read loop.
That would also prevent conflicts, and the need for arbitration.
You can but that would be mostly like a constant defined at program start. Not impossible and may be useful for some designs, but most FPGA programs I have created so far are typically a number of parallel (single-cycle) loops that do various things and transfer data between them through memory, registers, FIFOs and/or handshakes. And then the FP items which work as registers between the RT application and the FPGA. Everything but the host FIFOs and sometimes LUT tables is usually read and written to from different loops.
I've done a 'VM' like that:
1) 'program' the instructions (set the memory in the first loop) and\or wait for start
2) execute the instructions (get memory in the 2nd loop) until done
3) repeat.
Instructions included a simple loop\repeat, setting an output, reading an input and sending it over a FIFO. This was very useful for figuring out how a serial interface to a ADC should be used. Turned out the delay caused by cable lengths was a problem.
Search LabVIEW like a graph! 
That can work and I have done similar things in the past. But usually I end up with more complex designs where there are parallel loops that do motor control or data processing semi-synchronously and then arbitration comes into play somewhere.
It only works without arbitration if the read and write nodes are inside the same loop and clearly sequential in time.
@rolfk wrote:It only works without arbitration if the read and write nodes are inside the same loop and clearly sequential in time.
Or if the loops are clearly sequential in time. (Or does it refers to "more complex designs"?)
Simply put: turn arbitration on OR don't read\write simultaneously OR get problems.
@JustinZZJ wrote:
I want to avoid any delay in reading these memory blocks since that will make my linear interpolation inaccurate. From your conversation, this is problematic if I do not have any arbitration setting? Or is it better just to use LUT in my case?
You might not be able to avoid a delay when using one memory block.
If the nodes are sequential, you have a delay. If they're not, you probably need arbitration, and you get a delay.
I don't know how the delays relate, if one is smaller then the other.
You can try some trickery, and use two memory blocks, to avoid reading from the same block.
@JustinZZJ wrote:
I want to avoid any delay in reading these memory blocks since that will make my linear interpolation inaccurate.
I'm not sure how a delay will make the interpolation less accurate?
It might effect throughput (sample rate) of course.
If at all possible, and it usually is although it can be hard, I put all my FPGA code in a Single Cycled Timed Loop. Then I know for sure I get one cycle per FPGA clock. If you don't, cycle times might vary between compiles, even after small changes. Avoiding that kind of uncertainty is exactly why I use an FPGA.
I'd start with simply using the two reads sequentially, no arbitration, in a SCTL. It might just work, and you'd be done.
Can't try it out, I don't have any FPGAs atm.
BTW. Perhaps it's time to post some code, or even an image of the relevant part(s)?
Hi wiebe@CARYA,
Thanks for the reply. I have copied the interpolation code here:
You can see that I am reading from four LUTs (or I can also use memory blocks) here to get upper and lower interpolation bounds. I don't plan to use arbitration. I don't think this will cause any delay/jitter right? Do you mean putting all these code in a single-cycle loop? Thanks.
I have 0 experience with those LUT functions. I usually roll my own.
I always put my code in a SCTL, if at all possible. It's simply a deterministic way to knowing exactly how fast my code is running. It's probably not necessary, especially if you have loop times of us or ms.
I also always consider if code has to live on the FPGA. Often, not always, things like scaling can be done on a host, and I don't see any point on doing it on the FPGA. This goes against the common recommendation to put as much stuff on the FPGA as possible. Everything added to the FPGA will add complexity and compile time, so I put only critical routines on the FPGA, and nothing else.
I would not go as far as saying that everything possible should be done in FPGA. Things like floating point arithmetic is definitely not something you should have in there, even if it can be done. Even more complex integer mathematics shouldn't necessarily be put in the FPGA, unless you have the resources to spare anyhow. They do gobble up gates very fast.
As to using SCTLs, yes as much as possible! I rather get a somewhat more complex pipelined logic in a SCTL that I know exactly how fast it will execute, than a seemingly linear code that executes in a normal loop and may take turnabouts under the hood that can change the execution time significantly between executions.
Of course if your FPGA only is used to do very slow operations on digital IO with no timing requirements whatsoever, then this might be all overkill but then you should probably have gone with cDAQ hardware instead of cRIO! 😀
