To follow up and finish this thread: I figured out that my main problem was in how I was generating the ramp on the ADC/DAC board, which was sensitive to timing problems. I fixed this and now I get very nice looking eye patterns, even when the data comes in at 500MHz DDR.
Also, after seeing a hint in the mailing list archive <http://www.mail-archive.com/casper%40lists.berkeley.edu/msg04631.html>, I managed to use the mmcm in high bandwidth mode with a 125 MHz pfd freq. When I instantiate the mmcm I tell it the pfd freq will be 135 MHz, CLKIN1_PERIOD=7.407, and then give it 125 MHz instead. Thanks for your help, Jack and John. Matt On Fri, Apr 29, 2016 at 5:56 AM, John Ford <[email protected]> wrote: > Hi all. > > >From the work that Matt's done on the IODELAY and such, and the orginal > description of the problem, i.e. a simultaneous switching of several bits > at once, this sounds like a ground bounce problem or decoupling problems > on the ADC/DAC board, and not a firmware or ROACH problem. > > John > > > Matt, > > > > No good ones -- > > > > Are the bits that fail hardware / boffile specific? > > Are all the timing constraints correctly set up? > > Are all the IODELAY blocks suitably configured with resets, etc? > > > > That's all I got :( > > > > The ADC5g does 1.25Gb/s per ZDOK pair perfectly happily (I have 18 boards > > running them, and I don't remember the last time they failed to link up > > properly), so I don't think there's any fundamental problem from the > > ROACH2 > > side. > > > > Jack > > > > > > On Thu, 28 Apr 2016 at 20:46 Matt Strader <[email protected]> > > wrote: > > > >> 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 > >>>>>> > >>>>> > >>>>> > >>>> > >> > > > > >
