LabVIEW
Read multiple memory items simultaneously in LabView FPGA
Hi everyone,
I have created four memory items and I want to simultaneously read these four items using Read Memory Method in LabView FPGA. I am wondering whether this can be achieved, or there will be jitter/latency? I know reading the same memory item simultaneously can have jitter, so I created four memory items, hoping it will solve this issue.
I have attached a picture to illustrate what I am trying to do.
Thank you!
I wouldn't expect jitter.
You can turn off the synchronization, as they are separate memory items anyway.
Search LabVIEW like a graph!
@JustinZZJ wrote:However, what do you mean by turning off the synchronization?
I don't have an FPGA or FGPA toolkit installed atm, but IIRC the memory nodes have synchronization options. These can be used to read and write in parallel loops, without causing race conditions. If these options are on, they will cause jitter. The node in one loop will have to wait for the other loop.
If you turn the synchronization off, there won't be jitter, but the nodes might not function properly. However, if you make separate memories, this will solve the synchronization in a different way.
@Intaris wrote:
wiebe@CARYA wrote:
I don't have an FPGA or FGPA toolkit installed atm, but IIRC the memory nodes have synchronization options. These can be used to read and write in parallel loops, without causing race conditions. If these options are on, they will cause jitter. The node in one loop will have to wait for the other loop.
If you turn the synchronization off, there won't be jitter, but the nodes might not function properly. However, if you make separate memories, this will solve the synchronization in a different way.
I think you mean arbitration. It will only be used if required typically.
Ah, yes, arbitration.
So I thought OP was afraid that turning this on could cause jitter. Although it shouldn't (unless used), if all memory is split up, (s)he might turn it off.
wiebe@CARYA wrote:
@Intaris wrote:
wiebe@CARYA wrote:
I don't have an FPGA or FGPA toolkit installed atm, but IIRC the memory nodes have synchronization options. These can be used to read and write in parallel loops, without causing race conditions. If these options are on, they will cause jitter. The node in one loop will have to wait for the other loop.
If you turn the synchronization off, there won't be jitter, but the nodes might not function properly. However, if you make separate memories, this will solve the synchronization in a different way.
I think you mean arbitration. It will only be used if required typically.
Ah, yes, arbitration.
So I thought OP was afraid that turning this on could cause jitter. Although it shouldn't (unless used), if all memory is split up, (s)he might turn it off.
A memory that is only read is usually not very useful. 😀 So there will almost certainly be some write operation somewhere else and then arbitration logic will be added no matter what. And then it depends where this is placed. Inside a single cycle loop, arbitration will be such that reading the items will always happen within a single clock cycle but there will be a configurable read latency of at least 1. This means the actual value from the memory location will only be available in the next (or later iteration if the read latency is configured higher than 1) and you have to account for that delay. In a normal loop the Read Node will internally arbitrate until the value can be returned and that will certainly cause jitter.
@rolfk wrote:
wiebe@CARYA wrote:
@Intaris wrote:
wiebe@CARYA wrote:
I don't have an FPGA or FGPA toolkit installed atm, but IIRC the memory nodes have synchronization options. These can be used to read and write in parallel loops, without causing race conditions. If these options are on, they will cause jitter. The node in one loop will have to wait for the other loop.
If you turn the synchronization off, there won't be jitter, but the nodes might not function properly. However, if you make separate memories, this will solve the synchronization in a different way.
I think you mean arbitration. It will only be used if required typically.
Ah, yes, arbitration.
So I thought OP was afraid that turning this on could cause jitter. Although it shouldn't (unless used), if all memory is split up, (s)he might turn it off.
A memory that is only read is usually not very useful. 😀 So there will almost certainly be some write operation somewhere else and then arbitration logic will be added no matter what. And then it depends where this is placed. Inside a single cycle loop, arbitration will be such that reading the items will always happen within a single clock cycle but there will be a configurable read latency of at least 1. This means the actual value from the memory location will only be available in the next (or later iteration if the read latency is configured higher than 1) and you have to account for that delay. In a normal loop the Read Node will internally arbitrate until the value can be returned and that will certainly cause jitter.
But you can have the write loop execute before the read loop.
That would also prevent conflicts, and the need for arbitration.
It seems we need to know more details...
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.
