01-22-2008 03:21 PM
01-24-2008 01:39 PM
01-29-2008 07:08 PM
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.
01-30-2008 08:58 AM
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.
01-30-2008 01:32 PM
01-30-2008 01:33 PM
01-30-2008 01:37 PM
01-30-2008 02:26 PM
01-30-2008 02:53 PM
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.
02-05-2008 10:49 AM
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.