Jump to content

any RIO/ FPGA users out there?


mrak1

Recommended Posts

Are there any NI-RIO/FPGa users out there intested in discussing issues regarding this product?

=]

matt hill

1979[/snapback]

Hi Matt,

I'll repost our earlier email Q&A:

On Monday, September 27, 2004, at 10:05 AM, Hill, Matt wrote:

I'm acquiring PCM encoded streams and decoding them and sending the results to an RT target in real time. (The decoded data must be sent every 2.5 ms.) I'm trying to implement this routine as many times as I can on a single board. Basically I'm running out of space. I'm trying to determine what coding techniques are the most efficient. And there doesn't seem to be any way to isolate a bit of code and benchmark how much of the FPGA it occupies, so it's a difficult process.

>>Are you using single-cycle loops? They save a lot of space on the FPGA. Also watch out for the extra logic added by DIO arbitration.

Also, I'm trying to achieve high speed in my processing. In this area I can isolate code and test it, but benchmarking every available coding option is a bit tedious. It would be nice to have some general guidelines.

>>I use: single-cycle loops, pipelining, a digital line as a flag to verify and benchmark execution on a scope, avoid deeply nested logic, pipeline execution whenever possible.

Here are some examples of the questions I have:

1. It seems that the fastest way to send data from the FPGA to the RT target is to use a single IRQ on the FPGA, and then to post data word by word in a synchronous indicator. A synchronous indicator only updates once it has been read by the RT target. This technique is undocumented by NI, but one of their FPGA people showed it to me. I have found this to yield the highest transfer rates. It would be nice to understand why this is faster than sending the data in an array.

>>Under LV 7.0 the max data rate I could achieve was 4.2 Mbits/sec. I stored data into on-chip memory in one loop and read it out in another. The read-out loop would place the data into an array and flag an interrupt. I haven't tried this with the synchronous indicator - just found out about it Thursday. Interrupt driven transfers worked, but even on our monster machine, the CPU was bogged down handling interrupts.Forget about placing a graph on the front panel to display the data. My solution was to complain loudly to NI and route the byte-aligned data in parallel out the external connector to a 6534 DIO card. It's a horrible kludge but it gets the data in the PC.

2. I have problems where my FIFOs become unlinked with the program and return random data, but there is no error. This I believe this unlinking is a bug that occurs when you rename an FPGA vi or copy it. Has anyone else experienced this?

>> I haven't.

3. When storing data temporarily, I use FIFOs. These can be created as flip-flops, look up table or block memory. I would like to know the trade off between speed and FPGA space when comparing flip-flops to block memory.

>> Don't know

4. What is the penalty incurred for creating a subvi within FPGA code, both is terms of time and space?

>>I was told none. Everything is treated as one monilithic program by the compiler.

5. How does saving data in a shift register compare with saving it in a fifo?

>>Shift registers are mapped directly into logic gates. Not sure what overhead is added by fifos.

6. If I have a Boolean constant linked to 5 data sinks, should I separate this into five constants, thinking it will require less signal routing in the fpga, or link all sinks to the same constant?

>>Don't know, but I think this would be something the compiler would optimize.

7. If I send a U8 source into a U32 sink, I get the grey dot indicating a data type mismatch and Labview changes the data to the correct type for me. Is it more efficient to let labview perform the conversion, or should I insert a conversion node myself.

>>Don't know, but I would guess it's the same

8. To what lengths should I go to avoid using case structures?

>>I use them wherever I need them. I avoid deeply nested case structures, and try to minimize the number of cases. In the next issue of LabVIEW Technical Resources is a short article on LabVIEW FPGA that you might find interesting.

The FPGA code has its own rules and there seems to be very little documentation available to explain the optimal way of approaching common tasks. Any little tips and tricks that anyone has discovered would be very appreciated.

>>What are yours? Richard

Link to comment

I'm migrating this thread to LAVA from the Info-Labview list so that others can follow it...

I'm acquiring PCM encoded streams and decoding them and sending the results to an RT target in real time. (The decoded data must be sent every 2.5 ms.) I'm trying to implement this routine as many times as I can on a single board. Basically I'm running out of space. I'm trying to determine what coding techniques are the most efficient. And there doesn't seem to be any way to isolate a bit of code and benchmark how much of the FPGA it occupies, so it's a difficult process.

Also, I'm trying to achieve high speed in my processing. In this area I can isolate code and test it, but benchmarking every available coding option is a bit tedious. It would be nice to have some general guidelines.

Here are some examples of the questions I have:

1. It seems that the fastest way to send data from the FPGA to the RT target is to use a single IRQ on the FPGA, and then to post data word by word in a synchronous indicator. A synchronous indicator only updates once it has been read by the RT target. This technique is undocumented by NI, but one of their FPGA people showed it to me. I have found this to yield the highest transfer rates. It would be nice to understand why this is faster than sending the data in an array.

2. I have problems where my FIFOs become unlinked with the program and return random data, but there is no error. This I believe this unlinking is a bug that occurs when you rename an FPGA vi or copy it. Has anyone else experienced this?

3. When storing data temporarily, I use FIFOs. These can be created as flip-flops, look up table or block memory. I would like to know the trade off between speed and FPGA space when comparing flip-flops to block memory.

4. What is the penalty incurred for creating a subvi within FPGA code, both is terms of time and space?

5. How does saving data in a shift register compare with saving it in a fifo?

6. If I have a Boolean constant linked to 5 data sinks, should I separate this into five constants, thinking it will require less signal routing in the fpga, or link all sinks to the same constant?

7. If I send a U8 source into a U32 sink, I get the grey dot indicating a data type mismatch and Labview changes the data to the correct type for me. Is it more efficient to let labview perform the conversion, or should I insert a conversion node myself.

8. To what lengths should I go to avoid using case structures?

The FPGA code has its own rules and there seems to be very little documentation available to explain the optimal way of approaching common tasks. Any little tips and tricks that anyone has discovered would be very appreciated.

=]

matt

-----Original Message-----

From: Richard Jennings [mailto:Richard_Jennings@sandia.gov]

Sent: Monday, September 27, 2004 7:48 AM

To: Hill, Matt

Subject: Re: any NI-RIO/FPGA users out there interested in sharing

experiences?

Hi Matt,

What are you trying to do. I've been using LV FPGA for almost a year.

Richard

On Friday, September 24, 2004, at 09:37 AM, Hill, Matt wrote:

> Hi. I've been using NI's FPGA module (PXI-7831R Reconfigurable I/O)

> for 3 months now and it's definitely got it's own set of quirks.

> Anyone else out there using this product who's interested in

> discussing issues surrounding it?

> =]

> matt hill

> Denver, CO

> USA

>

>

>

Link to comment
  • 11 months later...
  • 1 month later...
Here are some examples of the questions I have:

1. It seems that the fastest way to send data from the FPGA to the RT target is to use a single IRQ on the FPGA, and then to post data word by word in a synchronous indicator. A synchronous indicator only updates once it has been read by the RT target. This technique is undocumented by NI, but one of their FPGA people showed it to me. I have found this to yield the highest transfer rates. It would be nice to understand why this is faster than sending the data in an array.

For LabVIEW to read an array from the FPGA VI front panel it needs to read every array element individually across the 32-bit PCI bus. In addition it needs to perform a few cycles of overhead operations before being able to retrieve the data so it will take a bit longer to read an array than reading the same number of element individually from a synchronous display indicator.

In LabVIEW 8 you should use DMA to transfer data from the FPGA to the host.

3. When storing data temporarily, I use FIFOs. These can be created as flip-flops, look up table or block memory. I would like to know the trade off between speed and FPGA space when comparing flip-flops to block memory.
The Flip-Flop setting uses FPGA real estate to store the data in the FIFO; block memory uses the additional user memory on the FPGA. In most application you should use block memory to reduce the amount of FPGA real estate required by your VI.
4. What is the penalty incurred for creating a subvi within FPGA code, both is terms of time and space?

In general there is no penalty for using a subVI. You do need to consider the difference between reentrant and non-reentrant. Reentrant will create multiple copies of the subVI on the FPGA, but they can run in parallel (faster, more space required). Non-reentrant only makes one copy of the VI that needs to be shared between multiple callers.

5. How does saving data in a shift register compare with saving it in a fifo?
I would only use a shift register for a very small number of elements as it will use up FPGA real estate. FIFOs can be used between different loops and different subVIs. (their main purpose)
6. If I have a Boolean constant linked to 5 data sinks, should I separate this into five constants, thinking it will require less signal routing in the fpga, or link all sinks to the same constant?

I have not tried this but I would think one constant should be fine.

7. If I send a U8 source into a U32 sink, I get the grey dot indicating a data type mismatch and Labview changes the data to the correct type for me. Is it more efficient to let labview perform the conversion, or should I insert a conversion node myself.
It should not make a difference.
8. To what lengths should I go to avoid using case structures?

Case structures are very efficient on the FPGA and should be used where appropriate.

Link to comment
  • 10 months later...

It's been a while since I did cRIO (it was in LV71), but I'm sure I'm not the only one reading here..

Just shoot..

Hi,

I see that the last post is kind of old.

I am pretty new in LabView and i'm trying to use a cRIO and I have some isues to discuss. I just what to now if anyone's still wathing the topic.

Manny thanks,

Yannis

Link to comment
It's been a while since I did cRIO (it was in LV71), but I'm sure I'm not the only one reading here..

Just shoot..

Hi Jeffrey,

My application is to log data on the host. I want to control the acquisition frequency too. The application I found in the FPGA courses are basic and for the one line handshaking one it appears to get blocked at one frame so I can't store the data in a file.

My question would be what shoud I use to transfer the values from the cRIO to the host takeing into account that my process takes 2 seconds an it is cyclic.

Regards

Yannis

Link to comment
  • 2 weeks later...
Hi Jeffrey,

My application is to log data on the host. I want to control the acquisition frequency too. The application I found in the FPGA courses are basic and for the one line handshaking one it appears to get blocked at one frame so I can't store the data in a file.

My question would be what shoud I use to transfer the values from the cRIO to the host takeing into account that my process takes 2 seconds an it is cyclic.

Regards

Yannis

I'm not sure if I understand what you mean exactly.. I take it that you just want to send data from your cRIO to your host and log it there. You are not controlling (e.g. sending setpoints) from host to cRIO are you?

What you probably should use here is an RT program on the cRIO controller that has one DAQ loop for your acquisition and another parallel loop for communication with the host. Now, if you are using LV8 or higher, the comm. with the host could be simply done with shared vars. Otherwise you probably want to implement some basic tcp/ip communication here or maybe use VI-Server.

Link to comment

Hi Jeffrey,

Indeed, that's what I want to do, only acquisition without any control. I did that and it works, and the data is tansmited to the host through a FIFO, if that can be cosiderated shared variables. By the way, can you indicate some good books for LabView and more than that, which will contain information about FPGA? I couldn' find to many tutorial in this field and for most of the books I can't see the summary.

The logged data contains a column that shows the increment of the loops. Does that increment coresponds to the value of the loop timer?

Many thanks,

Yannis

Link to comment
  • 4 weeks later...
......

The logged data contains a column that shows the increment of the loops. Does that increment coresponds to the value of the loop timer?

.....

Be careful when using the loop timer from a while loop in LabVIEW FPGA. Depending on the speed of your FPGA VI, the iteration terminal could top out quickly. In other words, the iteration terminal counts from 0 to 2 E+9 but does NOT roll over. The loop will continue to iterate but the iteration terminal will always put out the same number after reaching 2 E+9.

Also, I have used DMA for fast data transfer from the FPGA to the cRIO RT controller. In my project, I was only interested in a particular amount of data following a digital trigger.

- the RT would have a separate state machine that indefinately waits for an interrupt from the FPGA

- FPGA would wait for a trigger ( analog trigger, digital, etc) coming from an input card

- Once the trigger was received => buffer the data in the DMA FIFO and generate an interrupt to the RT

- The RT state machine would then wake-up and begin emptying the DMA buffer ( empty until completely empty)

- Start from the top again....

This architecture allowed me to do the majority of the processing on the FPGA and only transmit the important data to the RT and ultimately to the Host.

Good Luck...

Mike

Link to comment
Be careful when using the loop timer from a while loop in LabVIEW FPGA. Depending on the speed of your FPGA VI, the iteration terminal could top out quickly.

This architecture allowed me to do the majority of the processing on the FPGA and only transmit the important data to the RT and ultimately to the Host.

Good Luck...

Mike

Hi Mike,

can you be more specific with regards to the way you transmited data from the RT to the Host? I am realy confused an I couldn't find a good example. I would realy appreciate if you can provide an example.

I face a strange problem. fpga application is set to acquire at 1000 Hz and the logged file looks like it does but only for a couple of seconds. I wired at the input a function generator so I am sure of how the signal should look like.

I know is something I'm missing, but I don't know what.

Yannis

Link to comment
Hi Mike,

can you be more specific with regards to the way you transmited data from the RT to the Host? ........Yannis

Hi Yannis,

I cannot give you a simple example because what I have done has always been part of a large applicaiton. However, I can

give you some tips:

- Have the FPGA application only place data on the DMA buffer when a change has occurred ( if possible) ( see the Buffered DMA Acquisition example from NI for ideas)

- Monitor the DMA buffer on RT => when it has some data in it => send it immediately via TCP to the Host

- On the host, keep the file reference opened and continuously add data as it comes in. You would do this with the TCP read VI and transferring the string directly to a file. If your file needs to be in a specific file format, you may want to do this after the acquisition is complete. (There are several streaming to disk examples from NI)

Good Luck!

Mike

Link to comment
  • 1 month later...

I have now to choose between different technical ans software solution for the following application

A) acquisition of an Hammatsiu camera line ( 1024 pixel =1024 ADC conversion to do in function of a trigger which is generated by timers I have to generate

B) Driving a four independent axis motor (Parvex servoamplifier and servomotors) and management of 32 Digital input end 16 Digital output

(Before it was driven by an APRIL 5000 PLC With axis control boards)

the 2 functions have to be managed by two independant controller

Q1) which hardware solution would you advise for need A ans B

CFP, CPXI or CRIO?

Q2) has anybody done such application with one of these hardware solution

Do you think LV RT is needed

Do you think LV FGPA is needed

Thank for your advices

Regards

Thibaut

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.