Hi Andrew Thanks for your reply. Can this also be an impedance matching issue, where at lower frequencies the 50 ohm match is bad and there are reflections? When you talk about pipeline length are you referring to the 10 clock cycle latency that has been hard-coded? Is there a systematic way to determine the required pipeline length at a specific frequency?
JP On Fri, May 22, 2015 at 4:28 PM, Andrew Martens <and...@ska.ac.za> wrote: > Hey JP > > Sorry about my lack of contact regarding your design, been sick most of > this week and trying to catch up. Will try soon > > The QDRs do seem to have a sweet spot for reliable operation. The physical > track lengths match roughly with a certain number of clock cycles for a > range of clock frequencies. Going outside of these frequencies changes this > pipeline length, and the core assumes a fixed number. A lower clock > frequency would be fewer clock cycles. > > Cheers > > On Fri, May 22, 2015 at 3:40 PM, 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 >> >> >
