Hi Sharat, The disentangle(!) branch at https://github.com/jack-h/adc_tests/tree/disentangle has my calibration code. If you check out that branch and install it (cd adc5g; python setup.py install) then the test_cal.py script is a simple template for calibrating. If it doesn't work it should also print/plot various helpful things that will help figure out what's wrong. Turns out I don't actually have a working adc5g here, except in demux 1:2 configuration, so I haven't been able to test the code with your boffile. Having said that, with the 2:1 demux card, it seems to behave sanely for the bits that one would expect to work.
Cheers, Jack On Fri, 4 Sep 2015 at 04:48 sharat varma <va...@hku.hk> wrote: > Hi Rurik, > > Yes. I used the boffile ver2. I also generated bof using model file and > tried using it. I checked both the ADCs using -z option. I get the same > error. > > Thanks and regards, > Sharat > On 4 Sep 2015 18:37, "Primiani, Rurik" <rprimi...@cfa.harvard.edu> wrote: > >> Hi Sharat, >> >> Are you using the revision 1 or revision 2 version of the test suite >> bitcode and does this match the version of the board that you have? By >> default it uses revision 2 which is probably what you have but just to make >> sure. To use the other bitcode you would need to use the -b flag with >> test_adc5g.py. >> >> The adc_test provided bitcode and test script *should* work out of the >> box. Have you tried running the test on ZDOK 1, you can use -z 1 for that. >> >> Best, >> Rurik >> >> >> On Fri, Sep 4, 2015 at 12:01 AM, sharat varma <va...@hku.hk> wrote: >> >>> Hi, >>> >>> Thanks for the reply and sorry for the delayed response. >>> Yes, the x-axis represent the time and y-axis represents the signed 8 >>> bit output. The negative bias is due to the nature of the input. >>> >>> I was trying to use the files in the link you mentioned, but I keep >>> getting the error shown below. I am using the bof file provided for roach2. >>> >>> test roach connectivity ... ok >>> check if requested bof is available ... ok >>> test roach pingability ... ok >>> program the requested bof ... ok >>> estimate clock rate, should be within 1 MHz of expected ... ok >>> confirm the design has the ADC SPI controller ... ok >>> confirm the design has the needed scope ... ok >>> test if calibration finds optimal MMCM phase ... FAIL >>> >>> ====================================================================== >>> FAIL: test if calibration finds optimal MMCM phase >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "test_adc5g.py", line 107, in test_optimal_solution_found >>> self.assertIsNotNone(self._optimal_phase) >>> AssertionError: unexpectedly None >>> >>> ---------------------------------------------------------------------- >>> Ran 8 tests in 7.230s >>> >>> FAILED (failures=1) >>> >>> Please let me know if I am doing anything wrong or where could be the >>> problem. >>> >>> For your information: >>> >>> System: roach2 >>> >>> ADC : ASIAA ADC5G ADC >>> >>> Clock : 2500MHz. >>> >>> Thanks and regards, >>> >>> Sharat >>> >>> >>> On 1 September 2015 at 23:01, Primiani, Rurik <rprimi...@cfa.harvard.edu >>> > wrote: >>> >>>> Hi Sharat, >>>> >>>> The plot you provided has no labels or units so I will assume the >>>> x-axis represents time in samples and the y-axis represents signed 8-bit >>>> sample values. I'm not sure why there is such a negative bias but perhaps >>>> that's particular to your instrument. >>>> >>>> Please, at the very least, run the MMCM calibration described at >>>> https://github.com/sma-wideband/adc_tests to reduce glitches on the >>>> interface. I believe Jack also has a more sophisticated approach which >>>> adjusts the IODELAY for each individual data line; sadly I don't have a >>>> link handy for that. >>>> >>>> Although you may not see these glitches with a sine wave, a noise-like >>>> signal will cause more transitions on each bit and thus more glitches with >>>> an uncalibrated interface. >>>> >>>> Thanks, >>>> Rurik >>>> >>>> >>>> >>>> On Tue, Sep 1, 2015 at 2:54 AM, sharat varma <va...@hku.hk> wrote: >>>> >>>>> Hi Jack, >>>>> >>>>> Thanks for the reply. >>>>> >>>>> I did not run mmcm calibration. Actually, we checked the ADC by >>>>> feeding it a low frequency sine wave from a function generator and it >>>>> works >>>>> fine. >>>>> >>>>> The problem with spikes occurs when we feed the ADC with the >>>>> photo-detector output. >>>>> >>>>> Regards, >>>>> Sharat >>>>> >>>>> >>>>> On 1 September 2015 at 13:52, Jack Hickish <jackhick...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi Sharat, >>>>>> >>>>>> Are you running the adc mmcm calibration routine after programming >>>>>> your roach? >>>>>> >>>>>> Cheers, >>>>>> Jack >>>>>> >>>>>> On 31 August 2015 at 22:41, sharat varma <va...@hku.hk> wrote: >>>>>> >>>>>>> >>>>>>> Hi Casper, >>>>>>> >>>>>>> I am working as a post-doc working under guidance of Dr. Hayden So >>>>>>> at The University of Hong Kong. >>>>>>> >>>>>>> We are using ROACH2 to capture data from optical cytometry. We are >>>>>>> using ASIAA ADC5G ADC to capture data at 4 to 5 Gsps. >>>>>>> >>>>>>> We basically use the following parameters. >>>>>>> >>>>>>> Block parameter: two-channel, ZDOK0, demux 1:1 . >>>>>>> System: roach2, clock source:adc0_clk, clock rate: 300 MHz. >>>>>>> >>>>>>> We are connecting the output of a photo-detector 1544-B from Newport >>>>>>> Corp (the spec is attached) to the ADC input using SMA. >>>>>>> We find that noisy spikes are introduced when we capture the data >>>>>>> through the ADC (see attached fig). We double checked if the source had >>>>>>> problems using a oscilloscope, but on the oscilloscope we do not see >>>>>>> any of >>>>>>> these spikes. >>>>>>> >>>>>>> We would be grateful if you could let us know if we are doing >>>>>>> anything wrong. >>>>>>> >>>>>>> Rgards, >>>>>>> Sharat >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
