Hi Matt, The usual way to deal with this is IODELAY blocks as you suggest. The adc5g core has an example of the correct instantiation of the IODELAY primitive and some controller code to talk to them. IIRC, the delay goes straight after the input buffer, prior to the SERDES (or presumably immediately before the output buffers for the DAC).
Cheers Jack On Tue, 26 Apr 2016 at 16:02 Matt Strader <mstra...@physics.ucsb.edu> wrote: > 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 <mstra...@physics.ucsb.edu> > 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 <mstra...@physics.ucsb.edu >> > 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 >>> >> >> >
