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 >>>>> >>>> >>>> >>> >
