Hi Rurik,
thanks for the pointer. I have found Jack’s code and tried to use it. However,
I get
the following error:
… katcp_wrapper.py", line 196, in _request
% (request.name, request, reply))
RuntimeError: Request write failed.
Request: ?write s_ctrl 0 \0\0\0[1]
Reply: !write fail.
So I guess I need some more provisions for using this method. I checked using
planAhead
if there are IODELAYs in the FPGA design, and indeed there are, but maybe I
need some
additional interface units?
Thanks
Guenter
From: Primiani, Rurik [mailto:rprimi...@cfa.harvard.edu]
Sent: Mittwoch, 24. August 2016 15:05
To: Guenter Knittel
Cc: casper list
Subject: Re: [casper] Glitches in ADC-data
Hi Guenter,
At the SMA we also see glitches sampling at ~4600 MHz. Interestingly we do not
see any glitches at all when switched to test ramp mode even when looking at
very long snapshots. For us running a second MMCM calibration after both the
ADC and FPGA chips get a chance to warm up seems to get rid of most of them
(though not all). Note: if you do choose to do a second MMCM cal. do not issue
a sync to the ZDOK 0 ADC as this will disturb your FPGA clock.
As you rightly point out it would be better to adjust delay lines per data bit.
In fact there are IODELAYs on all data bits and these can be controlled over
the OPB. However, Python code for this isn't currently in the default adc5g
library.
Jack Hickish has written some code to adjust those delay lines which I'm sure
he'd be happy to share with you. However, this has been discussed (a few) times
before on this mailing list so you might be able to find a link in the archives.
Best,
Rurik
On Aug 24, 2016 8:44 AM, "Guenter Knittel" <gknit...@mpifr-bonn.mpg.de> wrote:
Hi all,
we have a number of Roach2 units each with 2 ASIAA 5Gsps ADCs. We are operating
the ADCs at 4GS/s (external sample clock is 2GHz), in single-channel mode.
The FPGA gateware meets timing for 250MHz.
Unfortunately I'm observing glitches on the data from the ADCs. Of course I'm
using
MMCM and OGP calibration, but the glitches won't go away.
Most often they occur on the ADC which is connected to ZDOK1.
I saw in the Python scripts that apparently all SERDES capture the signals as
they
arrive to a common clock (from the MMCM). So, are there no IODELAYs used to
center the signals individually? Could this be the root of my problem?
Thanks
Gunter
MPIfR Bonn
