Jump to content

Labview FPGA issue


Dvido

Recommended Posts

Hi all,

I am new to LabView. I have a very urgent project (which seems to be very simple) but it's not working.

I'm using the PXI-7831R board (will use the 7851R) and LabView 2010.

The goal of my project is to continuously read TDMS files from the computer hard-drive and transmit them using 5 analog output channels. All the channels should be perfectly synchronized. First of all, since I'm working with very large data files, I'm parsing them into smaller files (offline, before the actual transmission). BTW I'm currently working on a version that will perform the parsing on-line - it's not ready yet but from what I see it won't solve the issues that I'm talking about.

In order to transmit all the files simultaneously, I'm using a single DMA FIFO. I'm concatenating every value from the 5 files into an array, transmitting it to the FIFO and then on the FPGA side I'm sending each sample to a different analog output.

I've encountered the following issues:

1. Transmission rate: Though the board spec (7831R) says that the transmission rate is up to 1M, I'm unable to transmit with a rate higher then ~550K without distorting the signal. For example, I use a 75KHz sine sampled at 500KS/sec rate. In that case, if I transmit the sine @1M I should see a 150KHz signal but what I actually see is a ~80KHz signal.

2. When I analyze the transmission spectrum (with MATLAB), I can clearly see 2 spikes at +/-7Hz around the signal. These spikes are extremely bad for my project. I analyzed the files that I recorded (before the transmission) and the spikes aren't there which means that they're caused by the DAC. I managed to get rid of the spikes by not limiting the FPGA clock, but in that case, as I mentioned earlier the signal frequency is wrong.

I think that the 7Hz noise occurs due to the fact that the FPGA buffer is emptied and re-filled. When analyzing the transmission with MATLAB I can clearly see that every ~150ms some samples are missing from the transmission. I tried it change the FIFO size but it didn't help.

My project is attached - please tell me what am I doing wrong.

I will also appreciate a working example of transmitting at 1M (or any other rate) that was verified and prooved to be working fine.

Thanks in advance

DMA output - 5 channels working.zip

Link to comment

I'm not an FPGA expert but I think I can help with clearing up a few things.

First I think your technique is right. You want to read the large TDMS file on the host, parse it, then send down a large chunk of data to the FPGA and then say to the FPGA (maybe with a boolean) RUN. Then the FPGA will execute the large buffer of data that it was sent synchronizing along the way. While this is happening I don't know if you plan on repeating the signal, or sending more data to the FPGA but that part doesn't matter.

If you want to test the rate of your card, just write a simple VI that has a timed loop in it which is set the maximum frequency of the card. Then have the iteration count determine the output of a few AO channels. Say take iteration and divide by 10, then take the remainder and set that as the voltage output. So then it should go from 0V to 9V as fast as it can.

If you aren't using a timed loop this could be your problem with synchronization. Keep in mind that adding code to read the new setpoints from the buffer will take some time and you may not be able to achieve that 1MS/s.

Link to comment
  • 1 month later...

Hey Dvido,

I would try verifying the FPGA code seperately. I think the issue probably lies in the host VI. The looping structure is doing a lot and running the FPGA code each time that I think may be causing undesired behaviour. Try a host first which is just a signal generator passing data into the FIFO and benchmark it to make sure its keeping up.

The other think to do is then benchmark the FPGA code. Put in some code to measure the loop rate and see what its achieving. If its too low then try benchmarking just the FIFO code and make sure it is reading fast enough, if not you could add another FIFO so you can perform some reads in parallel.

Finally if it is your host code that is the problem then try simplifiying it. Off the top of my head you can read only part of the TDMS file using the offset and length inputs on the top of the read so you don't have to load the whole file in. You could use single files again, open and close out of the loop and open a set length on each iteration. Then increment the offset with the iteration counter.

Will be interested to hear how it goes.

Regards,

Mac

Link to comment

1. Transmission rate: Though the board spec (7831R) says that the transmission rate is up to 1M, I'm unable to transmit with a rate higher then ~550K without distorting the signal. For example, I use a 75KHz sine sampled at 500KS/sec rate. In that case, if I transmit the sine @1M I should see a 150KHz signal but what I actually see is a ~80KHz signal.

2. When I analyze the transmission spectrum (with MATLAB), I can clearly see 2 spikes at +/-7Hz around the signal. These spikes are extremely bad for my project. I analyzed the files that I recorded (before the transmission) and the spikes aren't there which means that they're caused by the DAC. I managed to get rid of the spikes by not limiting the FPGA clock, but in that case, as I mentioned earlier the signal frequency is wrong.

I think that the 7Hz noise occurs due to the fact that the FPGA buffer is emptied and re-filled. When analyzing the transmission with MATLAB I can clearly see that every ~150ms some samples are missing from the transmission. I tried it change the FIFO size but it didn't help.

Hi

A others already have stated, the host VI is probably where you can gain the most performance by simplifying the code. The FPGA VI seem to be pretty straight forward, but as Hooovahh said it depends on if you are planning on repeating a specific signal, having On/Off functionality etc..

Comments to simplify the code;

1. why store each AO waveform in separate files? TDMS is well suited to have multi-channel measurements in one single file. If you can have a single file instead, you'll gain a lot of file reading performance since only one file pointer is managed, and data is correctly formated directly out of the TDMS-Read function

2. why are you configuring the FIFO in each loop iteration, this should be done before you enter the loop

3. the same goes for the FPGA start, this should be done before the loop starts.

4. don't split the files in smaller chunks, this will get you a lot of overhead opening and closing files all the time. Instead you should read smaller chunks of data and while you are reading the next chunk to be transmitted, you write to the FIFO in parallel, i.e. you can use pipelining in Windows as well as on the FPGA (as sachsm linked to).

5. When reading the TDMS files you can specify the data type directly, this will clean up your diagram and get rid of a number of nodes.

6. The code currently autoindexes the error output constantly growing an error array, this will also decrease your performance. Instead use a shift register to pass around the error, and act on the error correctly.

/J

Link to comment

As Mellroth already suggested, I would certainly remove the call to configure the FIFO from the loop. According to the LabVIEW Help:

"Before the new depth is set, LabVIEW empties all data from the host memory and FPGA FIFO."

It doesn't specify whether the method checks that the new depth is different than the current programmed depth, but i wouldn't risk it...

-Brian

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.