LabVIEW Communications System Design Suite

cancel
Showing results for 
Search instead for 
Did you mean: 

will labview communications RIO work with an x310?

We have an x310 with the ubx-160 daughter cards. We're hitting the wall in throughput with NI-USRP & labview & it looks like Labview Communications Suite for USRP RIO might help by offloading some of the signal processing functions to the fpga. But buying a RIO USRP-2943 is no longer an option. I know from other posts that the x310 doesnt have to hooks needed for iq imbalance & dc offset correction (a remarkable oversight) but can I use the RIO suite to compile to the fpga in the x310 ? What would I lose?

Thanks

0 Kudos
Message 1 of 9
(6,484 Views)

Hello apchar,

 

Sadly, the UBX-160 is not an explicitly supported daughterboard in the NI-USRP driver. Because of this, I do not know if you will be able to use LabVIEW FPGA/Communications to interface with it. In general, you can use the X310 with LabVIEW FPGA/Communications, but with the supported daughterboards.

 

In general, the experience of modifying the FPGA of the USRP RIO/X310 is very different than using the standard USRP API. The USRP RIO Streaming Project that is available in both LabVIEW and LabVIEW Communications allows you to modify the data pipeline to include in-line digital signal processing. This can greatly increase the efficiency of your system by offloading filtering, FFTs, modulation schemes, etc. In order to implement these behaviors, you will need to have a good understanding of High-Throughput LabVIEW FPGA. I recommend reading the following Developer's Guide. It will provide guidance on implementing custom signal pathways.

 

https://www.ni.com/en/support/documentation/supplemental/11/an-introduction-to-high-throughput-dsp-i...

 

I recommend downloading an evaluation of either LabVIEW FPGA or LabVIEW Communications to take a look at the Streaming Example.

 

This thread might also provide a little more information on the difference between the USRP RIO and the X310:


http://forums.ni.com/t5/LabVIEW-Communications-System/Application-Frameworks-on-Ettus-x310/td-p/3163...

 

Regards,

Thomas C.
FlexRIO Product Support Engineer
National Instruments
0 Kudos
Message 2 of 9
(6,464 Views)

Hi apchar,

 

I agree with all TCAP's guidance.

 

When you say you are hitting the wall in throughput, can you clarify what you mean? What are you currently programming in, and are you currently doing any FPGA programming or would this be your first foray into FPGA programing? 

 

Cheers,

Rahul B.
0 Kudos
Message 3 of 9
(6,427 Views)

I'm using labview & the NI-USRP drivers. By wall I mean I'm getting a maximum throughput of about 1 MHz. Beyond that I get underflows. There's nothing much to the block diagram but a simple loop back. Just the niUSRP Fetch Rx Data (poly) VI directly feeding the niUSRP Write Tx Data (poly) VI in a while loop. No graphs or any other feedback to slow things down. I tried putting a buffer between them but it didnt help.

0 Kudos
Message 4 of 9
(6,397 Views)

Hello apchar,

 

Can you please explain to me your overall application? It sounds like you are creating a repeater of some kind.

 

If you would like to have deterministic timing between reading in a value and outputting the next value, I recommend using FPGA modification. This will allow you to connect the RX to the TX with a fixed delay in the order of nanoseconds.

 

If you are implementing this loopback behavior on the Windows system, you will have much lower performance. This is because there is no way to ensure that the communication from the USRP to the PC back to the USRP will happen within 100s of ms. To compensate for this non-determinism, I recommend increasing the sizes of your buffers, reads, and writes. But, you still might run into underflow errors. This could be the limitation of the Windows system.

 

Regards,

Thomas C.
FlexRIO Product Support Engineer
National Instruments
0 Kudos
Message 5 of 9
(6,387 Views)

It is indeed a repeater (with a variable delay on the order of microseconds and frequency offset.)

I've maxed out the packet size. What buffer? We're using the 1gbit ethernet interface now. We'll soon upgrade to 10 gbit. Hopefully that will help.

To modify the FPGA (a Xilinx Kintex 7) I need to write new verilog or vhdl for the chip. I'm new to verilog. I dont know much vhdl either. And it would have to work with the NI-USRP driver on the PC which I know checks the fpga for compatability. Is the code for the fpga image that came with NI-USRP available for perusal? It would be a good starting point. I guess I could modify it. If so, what HDL is it written in? If not, how would I write a new fpga image that would get along with the NI-USRP PC driver ? I assume I'll need vivado (ISE doesnt support the kintex-7.)

How much of this would Labview-FPGA do ? Does it support the kintex-7 ? Would I still need Vivado ?

questions...questions.

A

0 Kudos
Message 6 of 9
(6,342 Views)

Hi Apchar,

 

You actually do not need to write any Verilog or VHDL, as LabVIEW Communications and LabVIEW FPGA allow you to program the FPGA in the environment.

 

If you want to use LabVIEW Communications, under the "File" » "Learn" » "FPGA Programming", there are some getting started tutorials so that you can program in Communications.

 

Alternatively, you can program the USRP with LabVIEW FPGA, this will link you to the FPGA Getting Started guide. https://learn.ni.com/learn/article/getting-started-with-fpga

 

Both of these methods will allow you to program the Kintex 7 that exists on the USRP and will work along side our USRP driver. You will still need Vivado, as it is the compiler that we utilize to get the LabVIEW code down to the FPGA.

 

Thanks,

BeenCoughin

0 Kudos
Message 7 of 9
(6,317 Views)

Just a caveat, you only have to use Vivado if you'd like to do local compiling, you have additional options as explained here: https://www.ni.com/en/shop/electronic-test-instrumentation/add-ons-for-electronic-test-and-instrumen...

 

BeenCoughin

0 Kudos
Message 8 of 9
(6,302 Views)

Hello apchar,

I would like to offer some clarification. LabVIEW FPGA uses an NI Version of the Vivado Compiler in order to create the FPGA bitfiles. This does not require a license to the Xilinx Software.

 

Some of the limitations of the LabVIEW FPGA approach are the following:


1) The USRP Drive does not support the UBX daughterboard, so there is no guarantee that you can modify the FPGA using LabVIEW with that board. It is surprising that you can use the non-FPGA USRP Driver. If you want to modifying the FPGA with 100% support, you will not be able to use LabVIEW. I recommend looking into Ettus Documentation. This probably requires a license to Vivado. Keep in mind that LabVIEW FPGA is significantly easier than VHDL/Verilog programming.

 

2) If you are planning on modifying the USRP FPGA with LabVIEW, you will need to interface the X310 using the MXI Express port. FPGA Programming isn't currently supported over Ethernet.

 

3) You cannot start with the current USRP HDL code, but we do offer a few examples to help get started, such as streaming data in and out of RX and TX at the desire frequency and power. Your entire application is doable in LabVIEW FPGA and would not require any VHDL or Verilog programming.

 

Advantage:


Using the FPGA, you can guarantee deterministic timing, so that your repeater can have a controllable delay with very high precision. You can store the data in the on-board memory to prevent any indeterministic FPGA to Host communication. With your current setup, it is impossible to have a known and controllable amount of delay.

 

With regards to your other questions:


Sorry I mentioned a buffer, I was thinking of a different product line. The USRP does not have a configurable size buffer (FPGA mode does). The Network connection could help with the throughput, but it is still being hosted by a Windows computer, which does not have any determinism. This makes it impossible to control the delay.

 

Let us know if you have any other questions.

 

Thomas C.
FlexRIO Product Support Engineer
National Instruments
Message 9 of 9
(6,279 Views)