Hey Guys, Just to give you a bit of history on this issue. Normally the QDRs have take a clock input and then return this clock aligned with the data out. The QDRs on ROACH 2 were routed without this clock and with out th data valid line to save pins on the FPGA. This would have been ok if the QDR data and address lines werent routed to a wide range of FPGA banks, making it hard to align up the data upon return to the FPGA. This is why we need to calibrate and do all this trickery to get it working.
We have gotten it to work for the range of frequencies that we most commonly use, between 200 and 240ish. Jack has pushed this up to around 300MHz, but the problem is that the large change in frequencies means that the delay changes by more then a full cycle and thus calibration fails. (Calibration is only shifting in 1/32 parts of the 200MHz clock period) Jack has made a number of changes. One being that shifting the clock by 180 degrees so that the calibration range shifted by half a clock cycle and this helped with getting it to calibrate at 300+MHz. I would assume you would need to do the same but in the opposite direction. Wes Wesley New South African SKA Project +2721 506 7300 www.ska.ac.za On Mon, May 25, 2015 at 8:04 AM, Juan-Pierre Jansen van Rensburg < jvrensburg...@gmail.com> wrote: > Hi Jack > > I'm using the latest mlib_devel on the ska-sa git repo (commit 0d5c582), > and I built against it, but with the changes of commit 72d879c. > > JP > > On Sat, May 23, 2015 at 2:20 AM, Jack Hickish <jackhick...@gmail.com> > wrote: > >> Hi JP, >> >> What mlib_devel are you using? Did you actually build against commit >> 72d879c? I noticed you emailed a link to my repository which I specifically >> tweaked for my higher (312MHz) work, which I'm sure breaks *everything* at >> 145. >> >> Cheers, >> Jack >> >> On Fri, 22 May 2015 at 06:41 Juan-Pierre Jansen van Rensburg < >> jvrensburg...@gmail.com> wrote: >> >>> Hi all, >>> >>> I'm trying to get the QDR on the ROACH-2 to work reliably at a clock >>> speed of a 145 MHz. I'm assuming this is possible, since it has been >>> pointed out in an earlier message >>> <http://www.mail-archive.com/casper%40lists.berkeley.edu/msg05736.html> >>> that the QDR should work above 120 MHz? >>> >>> I'm running the software calibration for the QDR (qdr_cal() in the >>> qdr.py script) and the calibration seems to be successful, however after >>> the calibration I write test patterns to the QDR but the data I read back >>> is incorrect. What is strange is that it doesn't do it for all the test >>> patterns, mainly for the walking 0's and pseudo random numbers, and QDR0 >>> and QDR1 seem to be the main culprits for failure. I also don't have any >>> QDR glitches at higher clock speeds (for instance at 200 MHz). >>> >>> I have been digging around and found this >>> <https://github.com/jack-h/mlib_devel/commits/ami-devel?page=8> >>> possible solution (see commit 72d879c). The REFCLK for the IDELATCTRL is >>> set to a 100 MHz instead of the recommended 200 MHz. I have tried this, but >>> I still get errors. I'm not sure if this is relevant but with this >>> suggestion I have only found errors so far on QDR1? >>> >>> Does anyone have any suggestions? >>> >>> Thanks, >>> JP van Rensburg >>> >>> >
