Hi Weiwei, Unfortunately, there are many different reasons that script can fail, the primary reason being that it's not very robustly written (this is my fault).
The script outputs two values, an optimal phase (in this case None) and a "glitch profile" which is just a list with a count of total glitches per phase. A plot of the glitch profile should show regions with zero glitches (where the test vector is captured perfectly) and a peak where the clock fails at correctly capturing the data. The script picks the phase that's in the direct center of the biggest zero region; this sometimes fails if this occurs at the boundaries. This will also fail if the data going into the snapshot is not properly converted to signed two's by the gateware; in this case the glitch profile will have no zero region whatsoever. Can you send me a plot of the glitch profile for your bitcode (perhaps external to the mailing list to avoid spamming people)? Best, Rurik On Fri, Jan 31, 2014 at 1:11 PM, Weiwei Sun <[email protected]> wrote: > Thanks Jack and Rurik, > > When I calibrated mmcm phase, it didn't find the optimal mmcm phase. Why is > that? and any ideas of how to correct it or what I should look at to fix the > problem? Thanks! > > Weiwei > > > On Thu, Jan 30, 2014 at 4:04 PM, Jack Hickish <[email protected]> wrote: >> >> On 30 January 2014 23:56, Primiani, Rurik <[email protected]> >> wrote: >> > Hi Weiwei, >> > >> > Have you calibrated the MMCM phase using test vectors? The following >> > repository hosts Python/corr code that may be helpful to you: >> > >> > https://github.com/sma-wideband/adc_tests >> > >> > I've recently updated the README, please see the "Calibrating the >> > data-to-clk" for instructions on how to use the code. I believe this may >> > correct the bit errors you're seeing. Note: this code assumes that your >> > bitcode has a snapshot hooked up to your raw ADC output _after_ it's >> > been >> > converted to signed two's. >> > >> > Alternatively there is some code out there (I believe written by Jack >> > Hickish) that adjusts the IODELAYs on each data bit to correct for >> > capture >> > errors. >> > >> >> Just to say, this code is in a fork of the sma repo, at >> https://github.com/jack-h/adc_tests >> But you won't need to calibrate per-bit unless you're running the adc >> near full speed, and even then, you could probably get by without. >> >> > Lastly, please keep in mind that this ADC has four interleaved cores >> > each >> > with their own phase, bias, and gain differences. These may need to be >> > adjusted as well depending on your application. >> > >> > Best, >> > >> > Rurik >> > >> > On Jan 30, 2014 6:36 PM, "Weiwei Sun" <[email protected]> wrote: >> >> >> >> Hi Rurik and Casparians, >> >> >> >> I have a problem with the data out of the adc5g yellow block and 2's >> >> complementary change and captured by a snapshot. It seems there is bit >> >> errors during the transmission, or it could be some other problem. This >> >> is >> >> roach2 with an adc5g clocked at 1400MHz, 2-channel, Nondemux (1:1) >> >> mode. >> >> >> >> I tested it with a 175MHz sinusoid wave generated by a signal >> >> generator. >> >> The samples are predicted to be constant for every stream of the total >> >> 8 >> >> output streams with amplitude 32 within range (-128, 127), but I saw a >> >> lot >> >> of bit errors (bit flip? ). Attached are the time series of the 8 >> >> streams. >> >> Has anyone experienced this weird data? I'm appreciated of your >> >> attention >> >> and advice! Thanks! >> >> >> >> Weiwei >> >> >> > > >
