Communication Error Host and FPGA (5640) / LabView crashes

[Simon_G]

Hi,

I'm running a PCI-5640R and a PCI-7833R on LabView 8.5. What I was trying to do is to synchronize the data read-in of the two cards via an RTSI cable. I essentially took one of the examples that come with the 5640 ('ni5640R Analog Input and Output') modified it such that I only have the input part and that the 5640 was sending a trigger signal to the 7833 via RTSI. In principle everything looks fine but I encountered two unexpected problems:

* after compiling the FPGA 5640 program (which goes smoothly) I want to start it and it gives me an error message saying that it can't communicate with the host and that I should check my clocks (I want to use the internal clock). For clarity I attach a screenshot of the error message!

* with the host VI of the 5640 I originally had a few troubles doing the typeref binding, which eventually worked. So in principle the host VI looks fine but everytime I run it LabView crashes... no idea what that is about. I'll also attach the full project...

 Any ideas are highly appreciated!

Thanks, Simon

[Speedy_Badger]

Hi Simon,

I took a look at your code and gave it a try. I had to transfer your VIs to a normal NI 5640R target since I did not have the VIs installed for FPGA AHD, however the functionality should be identical. I was also curious, are you planning on implementing your code using AHD in the future? I did not notice anything in your current project that required this type of target. Upon transfering your code to a new 5640R target I was able to recompile the code and run it via the FPGA VI successfully. See screenshot below of said VI in action. That being said, I was unable to recreate the error you were seeing in your screenshot.

 

The next step was to take a look at your Host side VI. I did notice something right off the bat that could potentially cause  issues. The ni5640R Configure RTSI VI you were using is actually from the ni5604R instrument driver, not the FPGA support. You can tell this by the fact that you had to unbundle the Execution Target path from the normal session wire. This can potentially cause a HW crash due to simultaneously attempting to run the 5640R in FPGA and instrument driver
mode. Fortunately, an identical VI is part of the FPGA library so it was an easy fix. This VI can be found in the ni5640R Template.lvlib included in the project already.

I did run into the LabVIEW crash you mentioned during my testing. One thing I noticed however, is that this did not occur when I put highlight execution on. From this I made an assumption that it might be crashing from an undetermined or unexpected call order. From this idea, I re-arranged the VIs in the case structure portion of Host 5640R Analog Input to ensure the calls were made when I wanted them to be. From this point on I was unable to recreate the LV crash.

I've included the project that I used on my end for your use. A reminder again, I used a normal NI 5640R target, instead of an NI 5640R-AHD target.

Regards,

Message Edited by Speedy Badger on 08-21-2008 05:31 PM

[Simon_G]

Hi Chris,

thanks for your reply. It did resolve all my problems and by now it seems like I finally managed to get the whole program working.

I have to admit that I didn't even think of the AHD - I just had the AHD VIs installed for playing around and didn't realize that this was causing a problem. Now after removing them I could include the card normally into my project and things work well.

One thing I am still puzzled about is the following: in my code there is a single cycle loop which reads in the analog data from the two inputs. This loop should run at the clock rate which I define in the project (which in my case is 5 MHz) and hence the sampling rate I get for the data should be 5 MS/s, right?! However, what I understood from the manual, etc the card always runs the acquisition at 100 MHz and that is what I actually see - despite the inputs being in the single cycle loop clocked at 5 MHz the data is acquired at 100 Ms/s - only if I change the decimation factor I can get lower clock rates... why does the input apparently ignore the single cycle loop completely? Any insights on that? What does that mean for my synchronized read-in of the 7833 card? Do I have to change the ADC clock rate to e.g. 6.25 MHz to actually always be synchronized?

Thanks again for the help Chris,

Simon

[Speedy_Badger]

Hello Simon,

The clock domain used in the single cycle time loop will determine how often data is read from the ADC. This does not directly correlate to or control the sample rate of the ADC itself. By default, in the Analog Input and Output example, the nominal or max frequency of ADC_0_Port_A_Clk, the clock domain you are controlling your loop with, is set to 25 MHz. This lines up directly to the maximum possible decimated sample rate of 25 MS/s when using the default 100 MS/s sample clock timebase. In general, you want to make sure that your single cycle loop can achieve the same rates as your decimated rate to prevent corrupted data. Setting this value to 5 MHz, a 5x reduction in rate, is not recommended unless you are decimating your sample timebase to rates of 5Ms/s or less.

To configure the sample rate that you require, your observations are correct. The methodology lies within decimation of the sample clock timebase, which in the case of the ADC is 100 MS/s by default. If the finite decimation possibilities do not achieve a rate you require, it is possible to use an external sample clock timebase which will then modify the corresponding possible decimated rates. The sample clock timebase is configured on the host level via the Config Timebase VI, located directly after the Open FPGA reference VI in your project. By default, this configures the VCXO, 200MHz rate, of the 5640R module to be the timebase with an initial decimation of 2 for the 100MS/s ADC sample rate, and a 1 for the 200 MS/s DAC sample rate.

One other observation that I made when looking back at your code was that you were reading from both ADCs in one single cycle loop, based on the PortA clock of the ADC 0. I would recommend that each ADC be read in its only loop and clock domain, to ensure there is no synchronization related sample error.

In summary, the rate of the single cycle time loop is determines the rate at which data is pulled from the ADC, and not the sample rate of the ADC itself.

Regards,