7966R - DSTARA Clock and AT-1120

[NYUWIRELESS]

What is the reason for the DSTARA clock being 124.98 MHz on the 7966R, but 125 MHz on all other similar FlexRIO devices. 

Also if anyone has used the AT-1120, can the SCTL in the FPGA VI for sending data to the CLIP inputs on the 16 channels for output, be anythnig other than the 125 MHz I/O module clock? That is can the effective rate of this digitizer be reduced to achieve other sampling rates? 

Thanks for your help. 

[Ben_S]

NYUWIRELESS,

Good questions!

Q1: What is the reason for the DSTARA clock being 124.98 MHz on the 7966R, but 125 MHz on all other similar FlexRIO devices. 

Essentially, telling labview you are using a 124.98 MHz clock is a workaround that allows you to compile and in the end is correct. The clock you are actually sending through DSTAR can be 125MHz and should be 125MHZ. Read below for more details.

The reason the AT manual instructs you to put 124.98 MHz in the clock properties dialog box is due to how the LabVIEW backend generates the timing constraints for the compile. Essentially, if you tell LabVIEW you are going to have a 125MHz clock on DSTAR A with an accuracy of 100(ppm) ( you can't tell labview 0ppm), a period constraint of 7.99ns will be generated (instead of 8.00ns). For most cases, this cautious constraint is fine. However, in our case, we are passing DSTAR into a PLL that is creating a 500MHz clock from it. When we do this, the PLL instead thinks it is going to be creating a 500.25MHz clock which violates the switching limits for BUFG components in some of the FlexRIO FPGA targets who's switching limit is 500MHz.  

If you tell LabVIEW to compile for a DSTARA rate of 124.98MHz, the additional padding added ends up causing the actual correct constraint we want to be created to be generated. In this case, that is for a 125MHz clock.

Q2: Can the sampling rate of the AT-1120 be reduced? Has anybody tried this?

The hardware and software theoretically support this configuration and functionality. However, it was not testing or validated at any sampling rate other than 125MHz. It is for this reason that a range of possible input for the sampling clock is not listed in the documenation. I am not aware of anybody doing this, but I would encourage you to try it. If the hardware initalizes, that is a good first step! From there you can characterize the performance of the hardware and determine if it is suitible for your application's needs.

I hope this helps!