Hi Jack, Thanks for the input. Actually that's what I am doing. I am taking every 4th output to get Nyquist bw of 320MHz.
Is this clock rate is too low for the FPGA? Cheers, Amit On 19 June 2016 00:35:25 CEST, Jack Hickish <[email protected]> wrote: >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 <[email protected]> >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 ><[email protected]> >> 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 < >>> [email protected] >>> > <mailto:[email protected]>> 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 >>> >> > <[email protected] ><mailto:[email protected]> >>> > <mailto:abansod@mpifr-bonn.__mpg.de >> >> >>> > <mailto:[email protected]>>> 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 >>> > >>> > >>> > >>> >>>
