FPGA Array Comparison by element wierdness

[Drew.Rankin]

I have an application where I am comparing limits to the input values from two strain cards (NI-9237) inside an FPGA which is doing some signal conditioning for a sub-system in a larger machine.

Process limits are sent from the RT as an array and compared against an input array of "raw" data-

Input Data-

Limit Comparison-

I am doing a by element to "OR array" and I realize that this may or may not be more effiecient as a compare aggregates; however, the strange thing that is happening is that the sixth element in the limit array is triggering a "Load Error" for the fifth element in the input array. 

I am sending the limit directly from the FP of the RT-

Notice that the calculation checked by reading back the value that was set in the FPGA. This set and get seem to line up here. IE, if you set element 3 in either MaxLoad% or LCNominal(mV/V), it is validated on the FPGAMaxLoad output. I am wondering if this has anything to do with the implicit conversion between single floating point to fixed point?

If anyone else has experienced this, I would appreciate the feedback on what is happening.

I really don't want to go down the DMA route since this is a very small array of six elements an it seems over kill to use up a DMA channel just for this operation.

Thanks,

Drew

[nathand]

Hi Drew - maybe it's just me, but I'm having trouble understanding your post. Could you simplify it to just the part that causes a problem, then post the entire VI (instead of fragments) and phrase your issue as a clear question?

From what I can interpret of your post, it sounds like might not have set the array sized properly. Arrays on the FPGA are fixed-size, and when you configure an array control on the FPGA front panel you need to specify that size. Is it possible that the limit array is the wrong number of elements?

[Drew.Rankin]

Nathan,

Sorry, it is a bit hard to explain. I am having a hard time understanding just what could be happening. I have attached the RT and FPGA files with just the code that is giving the issue.

What appears to be happening is that the compare in the FPGA is processing one of the arrays out of order. I'm fairly certain it is not the build array from the module data since I have another function that outputs data based on this array; however, I have not included it in the attached to keep things simple.

I did double check the array size on the FP of the FPGA and it is correclty sized at 6 elements.

Thanks,

Drew

[nathand]

I assume you've already checked the obvious - that the array is wired in order? Every once in a while with a build array I find I've accidentally swapped two input terminals but that the crossed wires are hidden under the build array.

Unfortunately I'm on LabVIEW 2012 right now and can't open your archive. If you can save it back a version I'd be happy to take a look now, otherwise I'll try to remember to open it later on a computer that does have 2013 installed.

Have you tried running your VIs in simulation (set the execution to run on the development computer), then probe the wires to make sure the data comes through in the correct order? When running in simulation, it may help to wire constants in place of the analog inputs. Another debugging approach that perhaps you've already tried is to open the FPGA's front panel while it's running, and see the values that are passed back and forth to the host.

In your initial post, you wrote "the strange thing that is happening is that the sixth element in the limit array is triggering a "Load Error" for the fifth element in the input array." Where are you seeing this? I don't see an indicator in any of your screenshots where you could determine this, but maybe I'm missing something.

[Drew.Rankin]

Nathan,

Crossed wires in the build array was one of the first things I checked to make sure I wasn't going crazy.

The sixth element I refer to is as in, there are six channels of data acquired and that data is compared to an array of the same size. The weird thing is that the last two elements of the array used in the comparison seem to be swapped. The data array seems to be fine.

Here is the simplified FPGA block diagram:

I have confirmation that the build array is correct since in another version of this code, I am retransmitting the signal over an analog output correctly. My suspicion is something is happening to "MaxLoad" in the RT side. I will have to get down in front of the machine to run the code directly and watch what is being sent to the FPGA FP to see if the array is in the right order or not.

Here is the code in V12. Thanks.

[Dragis]

A couple other things to try. Move the portion of code that is failing into a subVI and test it separately without I/O or anything else. This will ensure the code is working as expected on some target. Also, if you carve out the I/O, you could more easily perform a cycle-accurate FPGA simulation using pseudo-data.

[ToeCutter]

The way you have it wired, if your value are LESS than maxload you get a load error. Is that really what you want? The variable names are misleading if so.

[Drew.Rankin]

MaxLoad is correct, this is a compression load on a bridge sensor so higher load is more negative. Confusing? Absolutely!

[MrQuestion]

This is just an observation, but I see (what i assume is the RT code) that you are writing to MaxLoad, and then immediatly reading MaxLoad.

If this variable "MaxLoad" is read only on the FPGA resource the only good that this code will do is confirm that the FPGA got the data you sent. (redundant since the write node will not finish untill the FPGA IP confirms the data is sent)

In general this is a bad idea. LabVIEW FPGA treats the front panel elements as shared locked resources. 

So there is IP on the FPGA that communicates to the backplane. National Instruments does a very good job of hiding this IP from you so that you don’t need to worry about this.

Other traditional FPGA programmers  (VHDL or Verilog) would need to work the backplane communication IP on methods to get that data from registers in the FPGA to the backplane to be sent to the host target.

Your RT code may get unexpected results caused from a chase condition. (I can almost garentee that you will be getting unexpected results on the read MaxLoad if MaxLoad is being changed by the FPGA)

That is because you send the “MaxLoad” data. The LabVIEW node on your host works with the FPGA IP to transfer this data.

 You then immediately request to read “MaxLoad”. The IP to read this data is parallel to everything else in your code.

So, your FPGA code may be writing to the “MaxLoad” variable, but you will not get this FPGA data. Instead you will be getting the data of MaxLoad at the time of your host request.

If you are using front panel elements in a SCTL things get a little bit more complex.

I don’t know if this is related to your problem.

I only have LV 2012 installed at the moment and I can’t see the posted VI.

If you are not going to use DMA I strongly suggest using some type of syncing mechanism to ensure that the data you read is the data created by the FPGA.

[Drew.Rankin]

---

@MrQuestion wrote:

This is just an observation, but I see (what i assume is the RT code) that you are writing to MaxLoad, and then immediatly reading MaxLoad.

If this variable "MaxLoad" is read only on the FPGA resource the only good that this code will do is confirm that the FPGA got the data you sent. (redundant since the write node will not finish untill the FPGA IP confirms the data is sent)

In general this is a bad idea. LabVIEW FPGA treats the front panel elements as shared locked resources. 

So there is IP on the FPGA that communicates to the backplane. National Instruments does a very good job of hiding this IP from you so that you don’t need to worry about this.

Other traditional FPGA programmers  (VHDL or Verilog) would need to work the backplane communication IP on methods to get that data from registers in the FPGA to the backplane to be sent to the host target.

Your RT code may get unexpected results caused from a chase condition. (I can almost garentee that you will be getting unexpected results on the read MaxLoad if MaxLoad is being changed by the FPGA)

That is because you send the “MaxLoad” data. The LabVIEW node on your host works with the FPGA IP to transfer this data.

 You then immediately request to read “MaxLoad”. The IP to read this data is parallel to everything else in your code.

So, your FPGA code may be writing to the “MaxLoad” variable, but you will not get this FPGA data. Instead you will be getting the data of MaxLoad at the time of your host request.

If you are using front panel elements in a SCTL things get a little bit more complex.

I don’t know if this is related to your problem.

I only have LV 2012 installed at the moment and I can’t see the posted VI.

If you are not going to use DMA I strongly suggest using some type of syncing mechanism to ensure that the data you read is the data created by the FPGA.

---

So is this a problem if you are writing an array of 6 elements that are defined as single floating point into a 24bit fixed point array? Is the implicit conversion on the RT going to have strange affects? There are no SCTL involved since the conversion time of the input card is 800 clock ticks.

The write then read seems to work pretty well, there is not a lot happening as far as front panel interface. Writing setpoints directly to FPGA registers does have some merit that would take some extra effort on the RT side of things, but wouldn't be too bad.

Thanks.