Re: [casper] QDR ROACH2: clocking at 145 MHz

[Jack Hickish]

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

Re: [casper] QDR ROACH2: clocking at 145 MHz

[Juan-Pierre Jansen van Rensburg]

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

Re: [casper] QDR ROACH2: clocking at 145 MHz

[Juan-Pierre Jansen van Rensburg]

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

Re: [casper] QDR ROACH2: clocking at 145 MHz

[Wesley New]

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