NEVER ARBITRATE option for the same memory in both cases on FPGA in SCTL

[Riv]

Hello,

I'm writing some code on FPGA and I wonder about one thing. Maybe someone knows the answer:

Situation (example img attached): I have simple case structure in SCTL. In TRUE case I read elements from Memory. In FALSE case I read elements from the same Memory, too. There is only one output from the case structure. Memory has Never Arbitrate read option so I can compile the code.

Question: As, on FPGA, both cases executes, both memory instances try to get data from the resource and give some output. In such a situation it is good to put both Memory instances in separate windows in flat sequence structure so there would be no hazard (remember: Never Arbitrate option). So, do I get correct data while switching between cases? Or maybe, because of some hazard, it is possible that I get incorrect data?

Thank you

[crossrulz]

Typically, if I have every case of a case structure accessing the same resource, I will take that access out of the case structure.  It simplifies things quite a bit.  Could you give a much better representation of what your code is?  Your current example should not even have a case structure.

[Riv]

I constantly read and write data from Memory A (and do operations on it) while emptying Memory B. After a while I start to constantly read and write data from Memory B (and do operations on it) while emptying Memory A. This is why I need Never Arbitrate method and why I try to use Case Structure.

Of course there is other way to solve the problem, using flat sequence structure, but I need my SCTL to work fast and I am woried about timing violation. So I wonder what would happen If I use case structure. 

Bests

[nathand]

I recommend structuring your code so that you always read from both memory blocks on every cycle, and discard the data if you don't need it. I don't know exactly what you're trying to do but it's rare that you need a sequence structure to force execution order.

[Dragis · Accepted solution]

The Never Arbitrate option was designed specifically for designs that use the pattern you show here where there are multiple calls to the same method on the same resource but where the code is written to ensure no two calls will be active at the same time. The hardware implementation generated by the compiler is simplified to expect only one active call that uses fewer resources. As long as only a single call is active at a time, the inactive calls will not be affected by or affect the active call.

That said, and as others have mentioned, for this particular simple example pulling the call out of the case structure is definitely a better option. But there are plenty of cases where that might not be a viable option such as the example you gave where the initialization of the resource has to be in a logically different location.

[Riv]

Dragis, thank you very much! As, using case structure, I ensure that no two calls will be active at the same time, I guess that's what I was looking for.

Today I found other satisfying solution (withous cs), but I'm glad to know the answer. I've been thinking about it for quite a long time but I've never found complete information.

Bests

[GregSands]

Do note however that if you are reading a particular Analog Input (with Never Arbitrate) rather than a memory block, then having two calls in different cases will slow down the acquisition rate, even if it is impossible for both to occur at the same time - I found this out the hard way!  So it is probably best to get in the habit of having a single access to any FPGA resources.  Here's the page from the manual.

Not sure if this is card/version specific, but I had this issue with the PXI-7854R and LabVIEW 2012.

[Dragis]

Greg, the notes from your linked thread mention that Never Arbitrate is not supported for Analog Input, is that not the case now? The other arbitration options will indeed impact performance since those arbiters are designed to handle multiple simultaneous accesses.

[GregSands]

---

@Dragis wrote:

Greg, the notes from your linked thread mention that Never Arbitrate is not supported for Analog Input, is that not the case now? The other arbitration options will indeed impact performance since those arbiters are designed to handle multiple simultaneous accesses.

---

Yes, you are correct.  Ignore everything I said, sorry!

As far as I know that hasn't changed in later versions of FPGA, but if it has, that would be a good reason to upgrade.