Hi, I'm glad to hear that starting with the reset pulse cleared up the issue. Thanks for letting me know. Regarding the timing for the digital inputs: as you can see in the datasheet the SPI registers let you add delay to the data lines in steps of approximately 80ps per step up to about 640ps max, and/or add delay to the clock signal in steps of approximately 80ps each up to a max of about 650ps. For a max clock rate of 500Msps, the clock period is 2000ps. The LVDS timing can be moved about in a window of approximately 1300ps. This range of adjustment should be enough to get a good timing relationship at the DAC with just about any timing relationship as seen at the FPGA pins. If the clock is well centered in the data as it leaves the FPGA then the clock and data delay can be set to preserve this relationship. If the clock leaves the FPGA aligned with the data then the range of adjustment should be plenty to allow for timing closure at the DAC. For your much lower clock rate of 140Msps, the clock period 7143ps is much larger than the range of adjustment available by the clock and data delay, but that is okay. You don't need to have the same amount of setup time as hold time - as long as you have *enough* setup time you can have lots of hold time and vice versa. I would say start with looking at your timing as it leaves your FPGA as the starting point. Then look for one of the pairs of delay settings listed in the timing section of the datasheet that fits best with the timing you see from the FPGA. Then enable the FIFO alarms and over many power cycles look to see if you ever see the 2-away alarm being set. 2-away does not mean there has been a FIFO error - no data has been lost - but 2-away can be though of as an early warning. If you *were* operating at max sample rate then I would say keep increasing the delay on clock until you see a 2-away error, then move the other way until you can see a 2-away error and then you can pick a delay combination that is well centered. But at 140Msps you may never be able to get a 2-away error. But that is good. That would mean you could expect to never have data lost due to the FIFO. I am reviewing final edits to the datasheet now. Some information is particularly thin such as the description of the delay fields. In Config3 there are three-bit fields for the 8 delay settings. datadlya controls delay on 7 of the 14 LVDS pairs and datadlyb controls delay on the other 7 pairs. If you are using full word mode, put the same value in for both of these fields as you are using all 14 bits. clkdlyba is the delay setting for the SYNC input which I think you would not be using, but this field is called this because of the dual-bus mode where the SYNC pin could become a clock for the 7bit bus for channel A. If you *were* using the SYNC input it would get the same delay as any other databit. clkdlyB is the delay for your clock input. It is called clkdlyb only because of the dual-bus mode where this input could be the clock for the 7bit channel. The figures in the new datasheet will attempt to make this less confusing. You would use clkdlyb for any clock delay if needed, and the other fields would all get the same value for data delay, if needed. Regards, Richard P.
↧