Hi, Sharat, On Sep 6, 2015, at 11:02 PM, Jack Hickish wrote:
> As the code suggests, the error comes because bit 1 of core 3 appears to > never be glitch free, no matter what the delay setting. It's not obvious to > me what could cause this. Just to expand on what Jack said, here are a few possible ideas (some of which are sheer speculation): 1. Verify the pinout of the ADC data pins in system_pad.txt. Revision 1 of the ROACH2 connected one of the ZDOK differential pairs to FPGA pins that were in a different bank than the others. This sub-optimal situation was "discovered" after a small number of the "rev 1" boards had been made. The design was quickly re-done for "rev 2". Virtually all ROACH2s now are "rev 2", but in the interest of advancing ROACH2 development (and their own development) SMA took delivery of the "rev 1" boards. It could be possible that you are using an mlib_devel that is targeting a "rev 1" board, but using the resultant BOF file on a "rev 2" board. 2. Try to compile your design for a slower clock setting. For example, maybe 2 or 3 Gsps instead of 5 Gsps. While this may not meet your application's needs, it could be a useful diagnostic. Different sample clock rates would result in different MMCM parameters. The MMCM is quite complex and sometimes the clock rates used result in internal MMCM parameters that are suboptimal. Although not directly relevant to the ADC5G, the following ADC16 write-up expands on this idea: https://casper.berkeley.edu/wiki/ADC16x250-8#ADC16_Sample_Rate_vs_Virtex-6_MMCM_Limitations Caveat: I am not vary familiar with the ADC5G's MMCM configuration, so this may not be an issue at all. 3. Swap the ADCs between the two ZDOK connectors and see whether the same bit(s) from the same core(s) fail(s) in the same way(s). If so, then the problem is probably on the ROACH2 side of things. 4. Find another ROACH2 with ADC5G cards on it and try your BOF file there. If it fails the same way then it is most likely a gateware problem and not a hardware problem. HTH, Dave
