Hi Guenter, You do not need any additional interface units. All you should need is the code.
The error implies that it cannot write to the "s_ctrl" register. Does this register exist in your design? I suspect this is part of a snapshot block, called "s", and Jack's code is attempting to grab ADC data from the snapshot so it can measure glitches in the test vector data. Presumably you have a proper snapshot attached to the ADC in the Simulink design since you mentioned you were able to successfully calibrate the MMCM phase. You will need to either pass that snapshot name to Jack's code or edit the code to have the correct name. Hope this helps, Rurik On Thu, Aug 25, 2016 at 7:57 AM, Guenter Knittel <gknit...@mpifr-bonn.mpg.de > wrote: > 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 > > > > > > >
