Hi Amit, For what it's worth, you can always just run the ADC faster, but only use a subset of the yellow block outputs. Eg., clock the ADC at 1280MHz, and use every 8th yellow block output. This can be handy because 1. You get to avoid whatever edge cases exist which cause various blocks to break at super-low clock speeds. 2. You avoid interleaving ADC cores. 3. Your FPGA design will use far less logic and DSP since it will be running at a higher clock rate.
I guess the downside is that if you already have a design built which expects 16 parallel inputs from the ADC block you'll have to do some redesigning.... Just my $0.02 Jack On Fri, 17 Jun 2016 at 00:18 Amit Bansod <aban...@mpifr-bonn.mpg.de> wrote: > Hi Rurik, > > Sorry for opening an old thread. > > I am trying to run fpga on ROACH2 board (we have 2 ADC5g with 1:1 DEMUX > mode) at 160 MHz. I see the zdok1 snapshot data shows no data whatsoever > while snapshot from zdok0 is fine. The MMCM also fails for zdok1. > > Have you successfully ran fpga at lower frequencies ? > > Cheers, > Amit > > On 17-Jun-15 1:32 PM, Primiani, Rurik wrote: > > Hi Amit, > > The range of frequencies you are trying, is this a test tone going into > the IF? The MMCM calibration should be done using the ADC's test ramp > output mode not an external IF input. Are you setting both ADC's into test > ramp output mode before attempting the calibration? The procedure for > calibrating the ADC's should go like this in Python: > > from adc5g import * > set_test_mode(roach, 0) > set_test_mode(roach, 1) > sync_adc(roach) > opt0, glitches0 = calibrate_mmcm_phase(roach, 0, ['scope_raw_0_snap',]) > opt1, glitches1 = calibrate_mmcm_phase(roach, 1, ['scope_raw_1_snap',]) > unset_test_mode(roach, 0) > unset_test_mode(roach, 1) > > Best, > Rurik > > > On Wed, Jun 17, 2015 at 5:09 AM, Amit Bansod <aban...@mpifr-bonn.mpg.de> > wrote: > >> Hi Rurik, >> >> Thanks a lot for useful inputs on the adc calibration. >> >> We tried MMCM calibration for zdock=0,1 for a few range of frequencies >> (100 MHz, 150 Mhz, 187.5 MHz,200 MHz) and we observed that the MMCM >> fails for zdock=1 for frequencies: 100 & 150 MHz. >> >> I looked at the glitch profile for these two frequencies and there was >> no region with zero glitches. What would be a good strategy to debug >> this issue ? I can send you the glitch profiles and bit code if that is >> useful. >> >> Best Regards, >> Amit >> >> >> >> On 12-Jan-15 5:13 PM, Primiani, Rurik wrote: >> > Hi Amit, >> > >> > That sadly looks nothing like a sine wave. >> > >> > The adc5g package is some Python code I developed to operate the ADC5g. >> > Please see the Github link below: >> > >> > https://github.com/sma-wideband/adc_tests/ >> > >> > It is important to calibrate the MMCM clk-to-out phase using the >> > procedure outlined below. I think this may be why your output looks so >> > strange. >> > >> > Are familiar with Python and the corr package? >> > >> > Thanks, >> > Rurik >> > >> > >> > On Mon, Jan 12, 2015 at 10:51 AM, Amit Bansod < >> aban...@mpifr-bonn.mpg.de >> > <mailto:aban...@mpifr-bonn.mpg.de>> wrote: >> > >> > Hi Rurik, >> > >> > I am not using the ADC5g package. The fpga is running at 150 MHz. >> > >> > Earlier, I did not take care of offset binary output but it did not >> > solve the problem. >> > >> > By "not consistent with expected results", I mean some data points >> > were offset by large amount. I have attached the plot (first 128 >> > data-points) for reference. >> > >> > I have not done any core-to-core mismatch corrections. Do you think >> > that could be an issue ? >> > >> > Thanks & Regards, >> > Amit >> > >> > >> > >> > >> > On 12-Jan-15 4:05 PM, Primiani, Rurik wrote: >> > >> > Hi Amit, >> > >> > Could you please provide an example plot of what you mean by >> "not >> > consistent with expect results"? >> > >> > Questions: >> > >> > 1. What is your clock rate? >> > >> > 2. Have you calibrated the MMCM? >> > >> > 3. The ADC output is offset binary, are you correctly >> > interpreting it as >> > such? >> > >> > 4. If you are using the adc5g python package the BRAM output >> > needs to be >> > converted to signed binary before capture (by subtracting 128). >> > Have you >> > done so? >> > >> > 5. Have you done any core-to-core mismatch corrections? >> > >> > 6. Less importantly, is your clock generator reference locked to >> > your >> > test tone synthesizer? >> > >> > Thanks, >> > >> > Rurik >> > >> > >> > On Mon, Jan 12, 2015 at 9:58 AM, Amit Bansod >> > > <aban...@mpifr-bonn.mpg.de <mailto:aban...@mpifr-bonn.mpg.de> >> > <mailto:abansod@mpifr-bonn.__mpg.de > > >> > <mailto:aban...@mpifr-bonn.mpg.de>>> wrote: >> > >> > Dear All, >> > >> > I am trying to test the ADC output for a simple sinusoid >> input >> > signal (75 MHz, -6dBm) with the snapshot block. >> > >> > Many of the output values are not consistent with the >> expected >> > results. Do I need to do any post-processing on data after >> > reading >> > from Bram ? >> > >> > Regards, >> > Amit >> > >> > >> > >> >>
