Handling read/write conflicts

[ZoltanMTS]

Hi,

I have a question regarding the FPGA CAN module: if I connect the CAN reader block to a timed while loop, is there any protection to handle read/write conflict?

In details:

I read the CAN in a while loop, without delay timer, according to the example. My guess is that, it is an event driven block, so as the CAN message arrives, the block delivers the message.

I also have other signals, which I read in the main while loop, which delay timer. I channel through the CAN messages (as clusters, if it matters) to the main while loop.

In situations like this, when there are two loops, a potential issue is the read/write exclusion: if there is no exclusion, it is possible that, while one loop updates the values, another loop start reading them, so it ends up with an incorrect number, which typically causes sparks.

Screenshots (CAN_reading.png and CAN_to_FIFO_full.png) are attached, the code works fine, but now I am refining it.

So my question is this: do I have to add some safeguarding to handle this data transfer, or is it handled by Labview? Thanks.

Regards,

Zoltan

[AJost · Accepted solution]

Hi Zoltan,

There are a couple of things to consider, but in my opinion you should be save.

Your code is running on an FPGA which is in HW, so most of the terms you are using are not existing anymore. There is no event driven programming on an FPGA and data transfer is handled quite differently than on a CPU.

1) On the CAN message read, it's implemented as a FlipFlop with an enable chain. In simplified words: The module produces the data which is handed over to a flipflop. When it is done, it will send an enable bit to the flipflop to indicate that the data is ready. Your code on the FPGA is then checking with every clock cycle if the flipflop is enabled and is reading the data.

It is essentially a polling method, but this is fine as there are no performance costs connected with polling on an FPGA.

2) Local variables are also implemented as FlipFlops on an FPGA and LabVIEW automatically implements a handshaking mechanism. This ensures coherency within a datatype. LabVIEW also guarantees coherency within a cluster you are save that your CAN messages remain intact.

3) However, there is no guarantee for coherency between CAN0data and CAN1data. If they are changing at the same time, it can happen that you will get an update where one is already changed and the other not. For that you would need to ready them in one while loop and bundle them to one cluster or array

4) Variables on an FPGA have the same problem as variables everywhere: They only show the newest update (not like a FIFO). If that is fine for you it's perfect, but you should be aware of this when using them.

To summarize: LabVIEW takes care of data-coherency WITHIN one cluster and you should not need to worry in your current implementation.

I hope this answers your questions

Andreas

[ZoltanMTS]

Hi Andreas,

Thanks, it is a very good and useful explanation of the FPGA.

Regarding point 3, the coherency between CAN0data and CAN1data:

You suggest having 'one while loop and bundle them to one cluster or array'

I have added a screen shot – I presume that is the way to sort it out.

Regarding point 4, variables only show the newest update (not like a FIFO):

If the timed loop reads out the flipflops faster than the fastest CAN message, then I presume it is not an issue.

Regards,

Zoltan

[AJost]

Hi Zoltan,

You are welcome.

Regarding point 3, this is exactly what I meant. The cluster tells LabVIEW that you want to treat both messages as a unit. The nice thing about FPGA is that bundling and unbundling cluster doesn't add any ressources.

I would be careful with the error wiring. Error wires consume a lot of ressources on an FPGA, so I would only use them when really necessary (this is quite different from normal LabVIEW on Windows)

Regarding point 4: Indeed, but it will produce a lot of duplicate messages on the FIFO. Depending on your design this is completely ok, but I wanted just mention it because this behavior is sometimes not desirable 😉

Andreas

[ZoltanMTS]

Thanks, your help and extra info are really appreciated.

Zoltan