---------- Forwarded message ---------- From: Jack Hickish <[email protected]> Date: Tue, Mar 14, 2017 at 10:37 AM Subject: Re: Interfacing 64-channel ADC with ROACH-2 To: Kaushal Buch <[email protected]> Cc: casper <[email protected]>, Kaushal Dipak Buch < [email protected]>
Great stuff! Thanks Kaushal. Good luck with the rest of the experiment. Cheers Jack On Mon, 13 Mar 2017, 21:55 Kaushal Buch, <[email protected]> wrote: > Hi Jack, > > The updates have been added to the following page: > https://casper.berkeley.edu/wiki/X64_adc > > > > Thanks & Regards, > > Kaushal > > On Sat, Mar 11, 2017 at 2:25 AM, Jack Hickish <[email protected]> > wrote: > > > > On Fri, 10 Mar 2017 at 02:24 Kaushal Buch <[email protected]> wrote: > > Dear all, > > Just wanted to close this thread which I opened last year. The reply is in > continuation to the last thread in this context. However, the solution is > for ROACH-1 board. > > The following is the summary of what happened in this activity which may > be of use to CASPERites. We are now able to successfully use the 64-channel > ADC with ROACH-1 and are also building and testing a multi-input correlator > and beamformer. > > As the GPIO pin voltage from ROACH-2 was not sufficient to drive ADC, we > tried interfacing64-channel ADC with ROACH-1. We could get digitized data > successfully from ROACH-1 as GPIO(0) provides 3.3V. > > We have to make sure that we are using appropriate GPIO [A/B] (pin 0) to > connect reset pin of ADC through a jumper. We can control the reset to the > ADC using a pulse from the software register. To use the onboard clock, > the yellow block should be specified 50MHz and XSG_core_config clock as > 200MHz set to 'adc0_clk'. We have not tried SPI interface in ADC parameter. > These methods are working as expected for all ROACH-1 based designs so far. > > Calibration script is used to align data from different chips as mentioned > on the x64 ADC wiki page. There is a problem while running this script as > is. While running the version available in the repository, we got an error: > unknown'x64_adc_ctrl' variable > > We fixed this problem (with inputs from Jack Hickish) by adding the > following line to the local repository > mlib_devel/blob/master/xps_base/XPS_ROACH_base/core_info.tab > > #IF# strcmp(get(b,'type'),'xps_x64_adc')#x64_adc_ctrl 3 10000 100 > > Also, we removed the following line of calibration script which is no > longer supported by 'corr' package and it seems this line was meant for > just debugging. > > fclk_sampled = self.bit_string((val0&0x0fff),12) > > > Hi Kaushal, > > > It would be useful to update this information in the x64_adc wiki page. > > > It looks like you have an account on the wiki -- so you can have the > honour of updating it! > > :) :) > > Jack > > > *Hi Jack,* > > *The changes have been made to the following page: > https://casper.berkeley.edu/wiki/X64_adc > <https://casper.berkeley.edu/wiki/X64_adc>* > > *Thanks & Regards,* > > *Kaushal * > > > > > Thanks & Regards, > > > Kaushal Buch & Atul Ghalame > > > > On Fri, Jul 8, 2016 at 8:11 PM, Jack Hickish <[email protected]> > wrote: > > > > On Mon, 4 Jul 2016 8:08 pm Kaushal Buch, <[email protected]> wrote: > > Hi Jack, > > We tried the steps mentioned by you in the earlier email with 64-channel > ADC connected to ROACH-2 board. The following are the details of the design > and test. > > #Design: > x64_adc output was provided to MUX where it selects between counter or > ADC input and gives to ten_gbe_v2 block. Following parameters are set: > -XSG_core_config has been set to sys_clock 100MHz > > > This should probably by adc0 clock, at a rate 4x the adc sample clock. > > > -Packet size is 4K for the 10GbE packetizer > -ADC reset has been tried through the software register, jumper from > GPIO(0), jumper from external source. > > #Tests: > i. When MUX selects the counter input, it shows proper UDP packets > showing the counter value as observed on Wireshark. > ii. When MUX selects ADC data, and adc_rst of the yellow block is set > via software register, it shows reset mode output i.e. -1(all ff...) in > Fix_12_11 format. Packets observed were WOL(Wake-On-LAN) instead of UDP. > iii. When GPIO(0) signal is given to reset pin of ADC by jumper > connection, it gives reset mode output on Wireshark with WOL packets. > iv. When the external voltage of 2.4 V is provided to the reset pin of > the ADC by jumper connection, it gives the same output as the reset mode > output. > > > We have the following queries with respect to the ADC board and the > testing that was carried out. > > 1. For connecting a jumper to the reset pin of the ADC board, which pin > should be used from the ROACH-2 board? 1.5V from GPIO is not sufficient to > drive the reset pin of ADC. How to use the GPIO(0) pin in this case? > > > Good point. I suppose you'll need to change the levels using your own > hardware. Roach1 didn't have this problem. > > > > 2. Do we need an external supply voltage to reset the ADC board? If so, > what should be the voltage level? > > > I think for roach2 you'll need to get the levels up to what they were on > roach 1 (3.3V?). The adc schematics, if online, should confirm the correct > level. > > > 3. What should the clock selection be for XSG_core_config settings, > sys_clock or adc_clock, or both possible? > > > adc_clk0. The FPGA has to be synchronous with the ADC. > > > 4. WOL packets indicate power-down mode of ADC, so is there a way to > check the digitized output at the ZDOK connector? > > > There's no way to check, unless you mess with the interface verilog. All > -1's signify a reset problem though, so I would expect that is genuinely > what's coming over the zdok. > > J > > > > > > Thanks & Regards, > > Kaushal > > On Wed, Jun 8, 2016 at 11:33 PM, Jack Hickish <[email protected]> > wrote: > > Hi Kaushal, cc. CASPER, > > All good here (Berkeley), thanks. Hope you are well too. > > It's been a long time since I've used that ADC, but from what I remember... > > - Yes, you need to appropriately drive the ADC's reset through the jumper. > If things aren't working and you're debugging with a probe, note that this > reset is active low. > - the yellow block uses GPIO[0] for the ADC's reset. On ROACH, you had the > choice between gpio banks A and B. On ROACH2, this option on the yellow > block doesn't do anything. > - If you're using the SPI interface, the yellow block uses GPIOs 1,2,3 for > data, clk, and cs_n, respectively. > - The ADC reset is controlled by the active high reset input on the yellow > block, which is inverted and drives GPIO[0]. I suggest tying this to a > software register. > > There are more details at https://casper.berkeley.edu/wiki/X64_adc > > Don't forget there's some link calibration stuff you need to do -- details > are on that wiki page. > > Let me know if you have other questions, > > Cheers > > Jack > > > On Wed, 8 Jun 2016 at 06:07 Kaushal Buch <[email protected]> wrote: > > Dear Jack, > > Hope you are doing good. > > We have recently purchased 64-channel ADC boards and are planning to use > them with ROACH-2. We have a basic design developed for packetizing the > data and sending it on 10GbE port. > > I have gone through the available literature for this on the internet. > However, I need some additional confirmation with reference to the > 64-channel ADC board: > > 1. Is it mandatory to reset the ADC through jumper ? If yes, which pin > should it be connected to on the ROACH-2 board ? > > 2. Can we reset the ADC via software register or GPIO ? In this case, how > to configure the GPIO ? > > > > Thanks & Regards, > > Kaushal > > > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected].
