can't write data to 5640r FIFO/memory

[ksalexander]

I've been having a significant issue with getting data from my host pc to the target card.

I've tried using a host to target DMA FIFO, but the FIFO in the target is not getting the data.  I've tried transfering a 188 element array, and a 1 element array, but it doesn't make it to the board.  I've tried putting the FIFO in a single cycle time loop, outside the time loop, in a for loop.  I've got the FIFO started and configured in the host before i try to write to it.  I have a timeout for 500ms for the FIFO.  I also can not get data to the board using memory WRITE blocks.

The part that really is confusing, is that i can READ information using READ blocks, and i get get information from FIFO's from the target to the host.

Is there something about the 5640r that i don't know like any host to target information doesn't work, or do i have to do FIFO writes differently than FIFO reads and memory writes differently than memory reads.

[Mauricio Capistran-Garza]

Can you please post which version of the IF-RIO driver are you using, as well as which version of LabVIEW? DMA's from host to target were not supported in the 1.0 release of IF-RIO, so that could be the issue. Also, to read the data, the FIFO (in the FPGA VI) must be inside a loop (it could be a while, for, or Single-cycle) so you read one element at a time.
Here are some tips you can use to debug the problem:
1) FPGA VI: Connect an indicator to the FIFO Empty terminal of the FIFO. Also, you can add a counter that increments every time you read the FIFO  AND  it's not empty. That way you can monitor if it ever gets data and how many samples you've read.
2) FPGA VI: Put the FIFO Read inside a case structure which can be controlled from the host. This way you won't accidentally read all the samples as soon as you write them from the host.
3) Configure the FPGA FIFO depth to 100 (it will  coerce this number, so from now on I'll refer to it as FPGA_FIFO_SIZE)
4) Host VI:
  a) Configure the FIFO for 1000 elements
  b) Set the control to the case strucutre in the FPGA VI so that the FIFO is not read
  c) Write an array of 2*FPGA_FIFO_SIZE elements to the FIFO.
  d) Add a wait for 50 ms
  e) Write an array of 0 elements and check the "Elements Remaining". The elements remaining tells you how many spaces, out of the 1,000 that you configured for the FIFO, are still available for you to write data. Now, the tricky thing is that as soon as you wrote the first time, the FIFO in the host started to DMA the data to the FIFO in the FPGA. Now, since the FPGA will not be reading data out of the FIFO, it will get full once that FPGA_FIFO_SIZE elements have been transfered. At that point the Host FIFO will pause sending any more elements. Since we already waited 50 ms, we can safely assume that the FPGA FIFO is full. Hence, the elements remainig should be equal to 1000-FIFO_FPGA_SIZE.

This should give you a good starting point to debug your communication.

Also, another thing that I should have mentioned early is that you should take a look at the examples. There are a couple of examples that use FIFOs to DMA data to the FPGA.

- Mauricio

[ksalexander]

So here is an update on the status of the issue.

We're using driver 2.1.1, and labview 8.2.1

When we put a Host to Target FIFO with absolute depth 255 and configured depth 10 in a case statement that we could turn on and off, that was also in a time loop.  We passed in an array of 10 elements.  When the case was off, we got expected indicator output with "empty" defaulting to false.  However, when the case was on, we got unreliable output, where "empty" would sometimes indicate true, and sometimes indicate false depending on the run.  We're unclear as to why it would do this, but when we put an indicator on the time loop iteration we'd get values ranging from 4300-5700 executions, so the amount of time needed to do the task did not seem consistant.  And in fact is kind of suspect because if the FIFO reads 1 32bit value every cycle, then i'd only expect the loop to execute 10 times at most.  Our time loop requested clock is 20Mhz.

What would be nice is if we could use numeric controls, so we just pass our data via a 188 element array of numbers to a FPGA array of controls.  But, while FPGA will compile with numeric controls, it will not let us use them, meaning it would not "take" the values.  Nor could we use an array of boolean controls.

We looked at the analog input/output example, and best we can tell we're not doing anything differently.

[Mauricio Capistran-Garza]

Hi,

There are a couple of things I'd like to clarify. First, there is no version 2.1.1 for the IF-RIO driver. The only available versions for the IF-RIO driver are 1.0, 1.1 and 1.2. I guess you looked at the NI-RIO driver. The IF-RIO dirver doesn't show up in MAX, so, to find out the version you have to go to Add/Remove programs, then find National Instuments and click on "Change" and then find the NI-5640R entry (the official name for the driver is NI-5640R by the way). Now, since you have LabVIEW 8.2.1 and NI-RIO 2.1.1, I think it's safe to assume you have the 1.1 version of the NI-5640R driver. Please indicate if that's not the case.

Now, the erratic behavior you're seeing on the indicator can be caused by an unproperly configured clock, which is my best guess up to this point. In which clock domain are you running your single cycle loop? Is it in one of the ADC or DAC clocks? If so, I've seen many people get confused as to how are those configured, so that may very well be the problem. The easiest thing to try is to run the SCTL in the "Configuration Clk" domain, just for ruling that out. The tricky thing with the other clocks is that the value that you specify in the "properties" dialog for clock is NOT in fact what the clock is configured to run at. What that number specifies is the "Maximum clock rate" at which the design will be able to run without violating timing constraints. So, in other words, the number that you put in that dialog tells the compiler which is the max speed that you intend in running your design, so the compiler makes sure to place all the gates  and flip-flops close enough to each other to acccomodate that speeed. However, you still have to confiugre the clock to run at that speed. If you don't, you can see the erratic behavior you're talking about. 

So, just to avoid going back and forth, could you also post screenshots of the block diagrams of your FPGA and Host VIs? There might be something else that is causing the issue and I might be able to identify it by looking at the diagrmas.

About using arrays, I'm surprised it won't take the values. I've used them a few times "without issues". And I quote "without issues" becuase if you start using large arrays (and 188 numeric elements is getting right in the limit of what I would call large) your compile times exponentially increasy and eventually fail. So, even when possible, I discourage you to use arrays whenever you don't absolutly need them.

- Mauricio

[ksalexander]

The IF-RIO driver does not show up in our Add Remove programs (see attached images).

So, a lack of this driver would prevent us from using Host to Target FIFO communications.

[ksalexander]

Here are our block diagrams.

[ksalexander]

It appears from our software sources we have 1.1 installed, i'm currently downloading 1.2 and will install that

[Mauricio Capistran-Garza]

Hi,

About the IF-RIO driver, it should show un in Add/Remove programs INSIDE Naitional Instruments. You must select National Instruments and then click in "Change". It will show you a new dialog where the NI-5640R driver should be listed.

Now, about the FPGA VI screenshot, since the is nothing guarding (like a case structure) the FIFO Read, as soon as you put data in it from the host, it will read it out at 20 MHz. Therefore, by the time you get to the Read/Write node in the Host VI to read the value of "Element", the FIFO is most likely already empty, in which case it will read "0". You should definitely add a case structure around the FIFO Read, as well as have an indicator for the "Empty" flag. Have you tried what I suggested in my first post?

- Mauricio

[ksalexander]

Yes we tried that, we had it protected with a case as you suggested, it gave us unreliable results when we turned it on, sometimes empty, sometimes not empty, but it never gave us the data back we put in.  Likely because we gave it 10 elements and the loop executed 5000+ times, giving us zeros back.

I gave the screens this way because it is the most basic form.  If i don't have that right, i wanted to know.

I'm going to take a few things i gleened from here and see if i can't get it to work by forcing it to read only X times, i'll get back with updates.

[ksalexander]

After further testing, i think the issue maybe due to timing.  Meaning we're getting the data to the FPGA, but we're not reading it at the right time.  What we'd like to know is when actual execution starts (when the first cycle is executed on the FPGA) in reference to the HOST VI.  The other question we have is, if execution is immediate, is there a way to delay it so that we can wait until our data is ready before actually running the FPGA, or is there a programmatic way you can think of using the FIFO to prevent the time loop from running.

My idea is that the time loop could wait on the empty indicator on the FIFO, so that when we put data into the FIFO, the FIFO stops being empty, the time loop starts, and then when it's empty, execution stops.