Thanks, Jack. I added IODELAYs to all my data bits. I used my ramp input to check for glitches in all the bits for each step in IODELAY value. Also, I found that having the mmcm in low bandwidth mode is indeed a bad idea, and switched to high bandwidth mode and slightly slower clocks.
I find a reasonable eye to calibrate with, except there are 4 bits that glitch no matter what value I use for their IODELAY. I lowered the clock rates quite a bit more, with the same result. Any more recommendations? Thanks, Matt P.S. Here's what my eyes look like for 475 MHz DDR (1 indicates a bit glitches for the delay value). Notice that data2 bits 1,5,8, and 9 are ones all the way down the column. dly : data0_bits data1_bits data2_bits data3_bits 0 : 101100000000 000000000000 101100100010 110110001000 1 : 001100000000 000000000000 101110100010 110010001000 2 : 001100000000 000000000000 101110100010 110000001000 3 : 000100000100 000000000100 111110100010 110000001000 4 : 000000000100 000000000100 111111100010 110000000000 5 : 000001001110 000011001100 111111101010 110001100000 6 : 000001011110 000011101100 111111111110 110001110010 7 : 000001011110 000011111110 111111111111 110001110111 8 : 010011111110 010011111111 111111111111 110001110111 9 : 010011111111 010111111111 001100100010 111001110111 10 : 010011111111 101100000000 101100100010 001110011101 11 : 010011111111 101000000000 101100100010 011110001000 12 : 110011111111 001000000000 101100100010 010110001000 13 : 101100000000 000000000000 101100100010 110110001000 14 : 101100000000 000000000000 101100100010 110110001000 15 : 001100000000 000000000000 101110100010 110000001000 16 : 001100000100 000000000000 101110100010 110000001000 17 : 000100000100 000000000100 111110100010 110000000000 18 : 000001001110 000001000100 111111100010 110000000000 19 : 000001011110 000001001100 111111111010 110001100010 20 : 000011011110 000011111100 111111111110 110001110010 21 : 010011111110 000011111111 111111111111 110001110111 22 : 010011111111 000011111111 111111111111 110001110111 23 : 111110110011 010111111111 101100100011 111001110111 24 : 111100100001 101100000000 101100100010 111111111111 25 : 101100100001 101000000000 101100100010 011110001000 26 : 101100000001 001000000000 101100100010 110110001000 27 : 101100000000 000000000000 101100100010 110110001000 28 : 001100000000 000000000000 101110100010 110110001000 29 : 001100000100 000000000000 101110100010 110110001000 30 : 000100000100 000000000100 111110100010 110000000000 31 : 000000000100 000000000100 111111100010 110000000000 On Tue, Apr 26, 2016 at 4:55 PM, Jack Hickish <[email protected]> wrote: > 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 <[email protected]> > 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 <[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 >>>> >>> >>> >>
