Hi Jack, Indeed you are right: it wasn’t anything to do with the cal routines. It looks like a sync pulse had come out of alignment which was causing the spectrum to offset erroneously.
A post-programming cal routine is just what I’m working towards. I think I’ve pretty much got it, however there’s one last thing which I’m a little confused by. The “original” cal facility includes a script which requires a 10MHz tone, however it looks like your disentangle branch removes this requirement. Is it definitely the case (and it looks this way from the scripts and functions) that both the IODelay cal and MMCM can take place with the adc5g in test mode, not requiring an input tone? Thanks Michael From: Jack Hickish [mailto:jackhick...@gmail.com] Sent: 08 December 2016 23:26 To: Michael D'Cruze; Primiani, Rurik; casper@lists.berkeley.edu Subject: Re: [casper] adc5g stuck in test mode Hi Michael, cc. List, Do you see glitches if you leave the adc in test ramp mode and grab lots of samples? If not, the problem isn't related to IO calibration. I might be misinterpreting your email, but just to be clear, you must recalibrate the MMCMs (or iodelays, or both) every time you program. These settings are not persistent over programming cycles. If you really wanted you could calibrate the MMCMs once and then each time you reprogram load in the same phases, but personally I don't see why this would be preferable to just making calibration part of the post-programming routine. If you're talking about adc core calibration delays, that's a different kettle of fish.... Cheers Jack On Thu, 8 Dec 2016, 15:08 Michael D'Cruze, <michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>> wrote: Hi Rurik, That’s interesting.. Jack: could you comment on the effect I’m seeing, having performed the IODelay cal? I’ve confirmed now that it’s not a property of the analogue signal. In a 4k-channel spectrometer design, following the IODelay cal, glitches appear towards the top end of the spectrum. These are not present in the same design scaled up to 8k channels, to which a slightly different set of delay values are applied. Rurik: it sounds as though you are adopting a similar approach regarding MMCM cal as myself. In my case, my board is running 24/7 in a temperature-controlled environment, although the board is reprogrammed fairly frequently. In this case would you agree that infrequent MMCM cals (say, once a week or even less than that) should be sufficient? Thanks Michael From: Primiani, Rurik [mailto:rprimi...@cfa.harvard.edu<mailto:rprimi...@cfa.harvard.edu>] Sent: 08 December 2016 00:07 To: Michael D'Cruze Subject: RE: [casper] adc5g stuck in test mode Hi Michael, I'm not sure which delays you mean. Do you mean the IODELAYs? Is calibrate_all_delays part of Jack's fork of adc_tests? Sadly I'm not familiar with this function. Although I added the IODELAY elements to the adc5g gateware code we don't actually use them at SMA. We get by with only the MMCM calibration and the interleaving corrections. When we first program our bitcode we do a MMCM calibration with a sync, this one we call a "cold" cal., then after the chip has had a chance to warm up to its operating temperature (for us ~80 C) we run a "warm" cal. which is just another MMCM calibration but this time without a sync. For us this procedure has been enough to eliminate most of the spurs we see due to glitches in the interface. For now we have not bothered to do IODELAY calibration but we have the benefit of spurious components generally getting washed out by our Walshing (and to some extent our fringe rates). The major source of spurs for us is the Fs/4 spur due to the interleaving errors. These we measure and store generally once and remain quite constant with time. Best, Rurik On Dec 7, 2016 6:28 PM, "Michael D'Cruze" <michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>> wrote: Hi Rurik, Just as an aside (it sounds like you’re pretty hot with the adc5g cal facility?), how reliable is the set of delays that are written into the cores? I only ask since the spectrum I’m getting since performing the cal looks like it has some glitches in. It could well be the analogue signal has these glitches and I’ll find out with a spec an tomorrow, but I’m sure these weren’t there before… Cheers Michael From: Primiani, Rurik [mailto:rprimi...@cfa.harvard.edu<mailto:rprimi...@cfa.harvard.edu>] Sent: 07 December 2016 17:17 To: Michael D'Cruze Cc: casper@lists.berkeley.edu<mailto:casper@lists.berkeley.edu> Subject: Re: [casper] adc5g stuck in test mode Hi Michael, Which version (git commit and fork) of mlib_devel did you use to compile your bitcode? Which version (git commit and fork) of the adc5g library are you using? What does the output of the following command show for the affected ADC after test mode has been unset? >>> adc5g.get_spi_control(roach2, zdok_n) Where roach2 is the FpgaClient instance and zdok_n is the ZDOK number of the affected ADC. Thanks, Rurik On Wed, Dec 7, 2016 at 11:28 AM, Michael D'Cruze <michael.dcr...@postgrad.manchester.ac.uk<mailto:michael.dcr...@postgrad.manchester.ac.uk>> wrote: Dear all, I have a somewhat serious issue in that my adc5g seems to have become stuck in test mode… I’ve messed around a bit with the very many functions within the calibrate_all_delays top-level function, and can see that the spi_registers are acknowledging set_test_mode and unset_test_mode, but in any case the output time stream indicates unset_test_mode is ineffective beyond this. I’d be grateful for any suggestions to remedy this – I can’t see this issue discussed on the mailing list. Cheers Michael
