Hello again,

Now that my clocks are working, I've run into the next problem in my yellow
block.  I have the adc/dac board sending a ramp, which I see on the roach2
side, but there are periodic glitches (see attached).  ​
 zdok_ctr_ramp2.tiff
<https://drive.google.com/file/d/0B6vM_l0m98k9MmQtVEp5SS1SeWs/view?usp=drive_web>

The data is coming over four 14-bit buses aligned to a 500 MHz clock from
the adc/dac board, at DDR.  The glitches happen when the value coming
through is a round number in binary, i.e. whenever several bits flip at
once.  It seems that at each glitch, one or more bits fail to flip when
they should, though they usually arrive at the right value one cycle later.

I saw in the mailing list archive that people have had problems
<https://casper.berkeley.edu/wiki/ADC16x250-8#ADC16_Sample_Rate_vs_Virtex-6_MMCM_Limitations>
with glitches when using MMCMs in LOW bandwidth mode.  I've tried both LOW
and HIGH modes and see the same thing.  (For the HIGH mode I slowed my
clock from 500 MHz to 350 MHz.  To use exactly 500 MHz as I want, I'm stuck
with LOW mode.)

I'm guessing that IODELAYs are the solution to this?  Do I put the delays
at the inputs of my OSERDESs?  Any recommendations?

Thanks,
Matt​

On Wed, Apr 20, 2016 at 6:47 PM, Matt Strader <[email protected]>
wrote:

> I found my mistake.  I did not have feedback input and output ports of the
> mmcm (CLKFBOUT,CLKFBIN) connected correctly.
>
> Matt
>
> On Tue, Apr 19, 2016 at 12:10 PM, Matt Strader <[email protected]>
> wrote:
>
>> Hello Casperites,
>>
>> I am working on a roach2 yellow block for a new 12bit,  2.0 Gsps ADC/DAC
>> board designed at Fermilab.  I am having trouble with clocks.  The ADC/DAC
>> board is providing me with a 500 MHz clock over a particular zdok pair.  My
>> yellow block takes this into an mmcm and divides it down to 250 MHz to be
>> used as the fabric clock.
>>
>> When testing it, I set the adc/dac clock running, then program the
>> roach2.  When I call KatcpFpga.estimate_fpga_clock() it returns 167 MHz
>> instead of the expected 250 MHz.
>>
>> I have attached what I think are the relevant snippets from my yellow
>> block.  The rest of it can be found at
>> https://github.com/mstrader/mlib_devel
>> Any ideas what could be the problem?
>>
>> Thanks,
>> Matt Strader
>>
>
>

Reply via email to