RF Measurement Devices

cancel
Showing results for 
Search instead for 
Did you mean: 

Piping VST-5646R IQ Data through 7976R and out second VST-5646R

Solved!
Go to solution

I'm new to VSTs and have a demonstration to setup for a customer. They want to use the RX side of one VST and pipeline the IQ data through to an 7976R FPGA then pipeline the processed IQ data to a second VST's TX side. They want to compare performance between on board and pipelined FPGA processing.

 

One thing that the customer told me is that they were warned against putting code into the VST FPGA because there was a chance that doing this could corrupt the on board functionality of the card. How valid a concern is this? Don't the soft panels download the required IP to the VST when they are running?

 

Thanks,

 

 

 

Drew

 

 

 

0 Kudos
Message 1 of 9
(5,599 Views)

Hi Drew,

 

You might want to start here: https://decibel.ni.com/content/docs/DOC-30516

 

I believe that the stream controller IP allows you to stream to another device (like the 7976R) instead of a host PC. You should be able to use the example IP for the VSTs in your demo, streaming to and from the 7976R.

0 Kudos
Message 2 of 9
(5,590 Views)

OK, that's what I figured. If I get a chance, I will upload the project for you guys to check out.

 

So is there any validity to the concerns with the basecard functions when writing FPGA code for the VST?

0 Kudos
Message 3 of 9
(5,581 Views)
Solution
Accepted by topic author Drew.Rankin

I don't think so. As long as you use the IDLs that ship with the VST (those on the FPGA interface palette), you should be safe. Nothing you can do with those will permanently mess up your VST configuration. Any corruption should be temporary. Like you mentioned, if you do begin to have problems or odd errors when working with custom bitfiles, opening and closing the RFSA/G front panel should give you a reset on any configuration settings.

Message 4 of 9
(5,578 Views)

So I confirmed that the IP is downloaded if the project IP does not match the card IP. This is good and I have been able to get signal from one card to the other; however, the signal appears to be degraded greatly. I am not sure if it is something I am NOT doing since I took out any processing from both the RX and the TX side of the application; however, I am not sur eif there is something on the card that should be configured.

 

I am very new to VST hardware and it has quite a lot of capability that is a bit beyond me since it's not a simple cRIO or FPGA device. Any help is apreciated.

 

-Drew

0 Kudos
Message 5 of 9
(5,512 Views)
Hi Drew,

How is the signal degraded? Are you using the bitfile that came with that example? Sorry, I'm away from my system and can't look at your code. That bitfile should stream the same data you get with an RFSA IQ unscaled data fetch.
0 Kudos
Message 6 of 9
(5,476 Views)

I figured it out by going back to the original sample project file. The DSP filtering that is included by default really is needed to get the signal out of the TX section. So far, I have routed a WLAN signal through the FPGA using Peer to Peer FIFOs. Right now I am working on a decimation filter that the customer wants to see running in the FPGA which is eventually going to be running processing for MIMO signals across several VST modules.

 

I know that the code exists in the VST to do decimated filters, but I can't find any iinformation to point me in the right direction using VI primitives. That will be another project; if what I have created works, the customer will be happy.

 

-Drew

0 Kudos
Message 7 of 9
(5,463 Views)

Hi Drew,

 

I'm glad you've got what you needed working. I got a chance to look through your code a little, and I noticed one thing that might have been degrading the output signal. This may be the same as what you found, but I wanted to point it out just in case.

 

In the FlexRIO code, I think you're passing the data from the RX VST to the TX VST at a lower rate than the TX VST needs. The TX code is running at 125 MHz on the 5646R. The FPGA pass through VI (for the FlexRIO) outputs at 100 MHz. The DSP VI is running in a normal while loop instead of a SCTL, which means it'll run even slower. When the TX FIFO underflows, it passes the idle vector to the output. If an idle vector is injected into the output stream every few samples, I imagine you'd see some odd behavior. You can check this by adding some latch and reset logic to the underflow indicator on the TX VST.

 

I think you can find some decimation filtering in LabVIEW\instr.lib\RF-RIO\DSP that could get you started.

0 Kudos
Message 8 of 9
(5,377 Views)

I was able to get the demonstration running; however, my attempts at filtering the baseband signal failed.

 

Since then, I have found the DFD toolkit to be very nice and have generated code for distributed algorithmic filters that run at 360+ MHz - more than adequate to filter the 250MHz baseband data rate.

 

The next step is a decent way to serialize the 5646R data so the stream runs at 250MHz instead of the 125MHz sample rate. I am fairly certain I can clock out the VST FIFO data by serializing the array. Has anyone done this successfully?

 

After that, the customer will want me to employ a filter to handle a 4x4 MIMO signal which will aggregate and filter the data at 100MB/s. My guess is that the data will just get wider and I will have to handle a data width of 128bits (4xU32). Would it be wise to filter each channel individually, or combine the data, filter it, decimate it, then send it back out on the respective channels?

0 Kudos
Message 9 of 9
(5,112 Views)