flexRIO 5781 adc/dac delay

[Kitten]

I am experiencing very long acquisition delays with flexRIO adc and dac board.

I have a pxi chassis with a pxi-7953 flexRIO fpga board and a pxi-5781 adapter module that I want to use inside a feedback loop: acquire input stream of data with the adc, apply some filter on the data on the fly, write back the output on the dac.

Since this system would be inside a feedback loop, everything has to be real-time, overall delay has to be small, and furthermore I want it to run at 100MHz sampling frequency.

I have made a very simple template program with a single cycle timed loop where I directly connect the adc output to the dac input.

When I run the program on the fpga, I measure a total delay between adc input and output of 480ns, equivalently 48 cycles.

This 48 cycles delay is too long for my application and I want to reduce it as much as possible.

I read the doc of the adc and dac chips used in the 5781 but I cannot find a reason for such a long delay.

Therefore I believe it is either related to:

1) bad configuration of the fpga clock

2) bad configuration of the 5781 CLIP api

3) bad programming practice in Labview.

4) some properties I don t know about and I have to set to reduce the delay.

I tried to tinker the program a bit, like using two parallel loops for writing and reading, tried to introduce explicit pipelining, or tried to run the program at different frequencies, but the delay always gets longer.

I am looking for a way to solve that problem.

Thank you for your time and help.

[Kitten]

I found out that if I set the "synchronizing registers" option of the adc input line from "auto" to "0" I could save 2 cycles.

So my best delay so far is 46 cycles @ 100MHz

[mhsu]

Hi Kitten

What clock are you running your single cycle time loop on? Is it the ADC, DAC or FPGA clock?

It is my understanding that you should only use I/O clock 0 only with the ADCs and I/O clock 1 only with the DACs. Perhaps you could use FIFOs in separate single cycle timed loops to pass data between the ADC and DACs?

However, it is quite likely that there a > 400ns delay since I suspect the ADC data goes through the FPGA somehow... After all it needs compilation on the FPGA.

I know this doesn't help but I am just throwing out some ideas. I am having issues with outputting a decent sine signal on my DAC, with the sine signal generated on the FPGA..

[Kitten]

First I tried to run one SCT loop with reading and writing inside the loop running on the fpga clock.

In that case I have a 460 ns delay.

Then I tried to use two loops: one for reading the adc with running on the adc clock, and one to write to the dac running on the dac clock. 

Both clocks where set at 100MHz compilation.

To pass the value between loops I used first a local variable, and I get the same 460 ns delay.

Then I tried to use a fifo, and the delay is increased by 8 cycles.

I don't do any particular configuration of the SPI registers (actually I am not sure what should be done there)

Lastly when I run two SCT loops with the two different clocks I have a one cycle jitter at the output (the delay is not stable)

[mhsu]

I didn't design these systems but I highly suspect that the delay is unavoidable. My understanding is that the ADC is wired to the DAC, via the FPGA. I think there's a minimum delay due to this and I don't think this can be reduced..

[Kitten]

So I understood that I was running the dac with the default interpolation factor x4 which does induce some delay.

In the datasheet the two quoted delays for round trip adc -> dac loop are 550ns with and 350ns without interpolation.

My best number with interpolation was 460ns which 9 cycles better than the quoted 550ns figure.

For sure after removing the interpolation I could get the delay down to only 260ns which is the above 350ns minus the previous 9 cycles improvements.

I think indeed it is not possible to get faster than that without modifications to the CLIP program of the ni5781 module itself.

Is this possible to have access to the source of the CLIP or to program my own CLIP to overcome that problem ?

[TylerDurden]

Hi,

we're facing the same problems. We want to use the 5781 as a high-speed AI/AO device for controlling a laser diode. Problem here is that there is nothing in the technical specification which points to that issue. This information is only in the web-based data sheet on the NI website. You can find on page 18 a hint that there's an fixed 7th order elliptical filter implemented where you can estimate that this can some time. Currently we have no real idea.

All over not very satisfying.

Tyler

[Dave.T]

Hello Tyler, 

The datasheet specs the ADC to DAC delay to be 350 ns or 550 ns depending on DAC interpolation in the "Application Areas" section.  Is this the information you were looking for? 

[TylerDurden]

Hi Dave,

thank you for your link. We already found that information in the datasheet after talking with the NI guys at Munich, but there's no information that can be found in the user guide and technical specification revision January 2010. We are now aware of this issue, but prior using hardware and building up a system design we normally refer to the technical specification and not to the web based datasheet. What we're trying to do is building up a high speed controller with about 10MHz. Do you have an idea for a feasible workaround?

Thanks

Tyler

[Dave.T]

I agree that that information should be included in the manual and I'm sorry that its omission has cause you trouble.  I've made a request to have the specifications document amended to include that information. 

When you say 10 MHz, do you mean you want the latency to be less than 100 ns, or you want the system to run at 10 MHz?  

If you want the system to run at 10 MHz, that shouldn't be a challenge, you're just going to have the latency between the ADC to the DAC.  

Unfortunately there are 12 cycles of latency inherent to the ADC alone.  On top of that, there is some latency in the FPGA associated with serializing the data.  Does the 350 ns latency exceed the requirements for your system?