Hi Rurik,
thanks a lot, this makes perfect sense. In the first instance I used IODELAY calibration and afterwards MMCM calibration. I also experimented with moving the clock edge within the window. It appears as if moving the edge to a later time (3/4 instead of 1/2 of the window) improves signal quality. Cheers Guenter From: Primiani, Rurik [mailto:rprimi...@cfa.harvard.edu] Sent: Freitag, 26. August 2016 13:01 To: Guenter Knittel Cc: Jack Hickish; casper list Subject: RE: [casper] Glitches in ADC-data Guenter, At slower speeds it may be necessary to do both or just the MMCM cal since the IODELAYs may not provide the full range needed to sample the data window. You may need to experiment with this. There is no BITSLIP implemented. The ADC words are presented in parallel not in serial. Thus the deserialization is really more of a demultiplexing. The SERDES are synced with a single reset pulse. This is described in the ADC data sheet which has timing diagrams. If you want this level of understanding you can look at the VHDL code yourself in mlib_devel/xps_base/XPS_ROACH2_base/pcores/adc5g_dmux1_[...]. Not very well documented but some attempts were made. Rurik On Aug 26, 2016 6:05 AM, "Guenter Knittel" <gknit...@mpifr-bonn.mpg.de> wrote: Hi Jack, thanks for explaining. I got your code running and I’m in the process of testing. Allow me two more questions: - there is no need to do both calibrate_all_delays AND calibrate_mmcm_phase, or is it? - Who is actually taking care of word alignment at the SERDES (issuing Bitslip-commands as needed)? Thanks a lot Guenter From: Jack Hickish [mailto:jackhick...@gmail.com] Sent: Donnerstag, 25. August 2016 17:05 To: Guenter Knittel; Primiani, Rurik Cc: casper list Subject: Re: [casper] Glitches in ADC-data Hi Guenter, The adc calibration code I use is at https://github.com/jack-h/adc_tests/blob/disentangle/adc5g The disentangle branch should work with normal casper snapshot blocks (this is probably the branch you want). I used the code for a 5GHz clock, be warned that it may or may not behave effectively at lower rates. Calibration commands are as-per the github readme file, though you'll need to do a listdev to figure out what the appropriate snapshot names are, and replace "scope_raw_0_snap" as approriate in the code snippet below. -- ####### from adc5g import * set_test_mode(roach, 0) set_test_mode(roach, 1) sync_adc(roach) # Calibrate IO delays per bit (necessary at 5GSps) delays0 = calibrate_all_delays(roach, 0, ['scope_raw_0_snap',]) delays1 = calibrate_all_delays(roach, 1, ['scope_raw_1_snap',]) # Sweep MMCM phase with the same settings for all bits (probably adequate for slower speeds, I think this is all most of the ADC5G users do) #opt0, glitches0 = calibrate_mmcm_phase(roach, 0, ['scope_raw_0_snap',]) #opt1, glitches1 = calibrate_mmcm_phase(roach, 1, ['scope_raw_1_snap',]) unset_test_mode(roach, 0) unset_test_mode(roach, 1) ####### Cheers, Jack On Thu, 25 Aug 2016, 06:44 Guenter Knittel, <gknit...@mpifr-bonn.mpg.de> wrote: Hi Rurik, thanks, that was the kind of background information that I needed. I’ve got the code working, on to more testing… Cheers Guenter From: Primiani, Rurik [mailto:rprimi...@cfa.harvard.edu] Sent: Donnerstag, 25. August 2016 14:52 To: Guenter Knittel Cc: casper list Subject: Re: [casper] Glitches in ADC-data 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
