Hi all, I'm responding to this thread for documentation purposes. In the end, what it worked for me is initializing the ADC with the '--demux 2' option in the adc16_init.rb script. I don't know if it is the standard behavior, but at least for me it removed the data duplication phenomenon I was experiencing in the sampling process. In this mode the FPGA clock rate is half the ADC clock. The only drawback is that (I think) I'm not sampling at the maximum sampling rate the ADC allows, but at least I'm not getting useless data repetition, and I have enough bandwidth for my application, so I'm using this solution.
Regards, Franco On Mon, Apr 8, 2019 at 12:38 PM Franco <francocuro...@gmail.com> wrote: > Hi Jack, > > Thank you for the help. I tried the code, but I've got the same result, > both for my model and the one from the CASPER page :(. > > Franco > > On Sun, Apr 7, 2019 at 6:58 AM Jack Hickish <jackhick...@gmail.com> wrote: > >> Hi Franco, >> >> Can you try this software with the model you compiled? >> https://github.com/jack-h/casper_adc16 . >> >> Cheers >> Jack >> >> >> On Fri, 5 Apr 2019 at 19:34, Franco <francocuro...@gmail.com> wrote: >> >>> Hi Matt, >>> >>> I'm not sure what you mean by 'ADC IC test pattern'. I'm looking into >>> using the ADC in the different demux modes by following this guide: >>> https://casper.ssl.berkeley.edu/wiki/images/4/4c/ADC16_user_guide.txt >>> >>> For what I understand, I have to make a new model and change the "User >>> IP clock Rate", and certain 'demux factor' parameter: >>> >>>> >>>> For the ADC16 yellow block one must specify the "User IP Clock Rate" >>>> as shown above *and demux factor in the XSG block*. "adc0_clk" must be >>>> selected as the "User IP Clock Source". The demux factor is due to >>>> how the Hittite ADC chip supplies the data to the FPGA as a function >>>> of the number of analog inputs to sample. >>> >>> >>> I don't have that option in my XSG block (and I find it weird that that >>> option would be in that block). Was that parameter developed in a different >>> branch of the mlib_devel library? >>> >>> Thanks, >>> >>> Franco >>> >>> On Thu, Apr 4, 2019 at 8:20 PM Matt Dexter <mdex...@berkeley.edu> wrote: >>> >>>> What happens when the ADC IC test pattern modes are used? >>>> This includes the fixed value patterns. >>>> >>>> What happens when the higher bandwidth modes of >>>> 2 channel/ADC IC and/or 1 channel/ADC IC are used ? >>>> (as Dave has already warned, the correct clock rate for the mode >>>> must be used) >>>> >>>> On Thu, 4 Apr 2019, Franco wrote: >>>> >>>> > Date: Thu, 4 Apr 2019 20:12:00 -0300 >>>> > From: Franco <francocuro...@gmail.com> >>>> > Reply-To: casper@lists.berkeley.edu >>>> > To: Casper Lists <casper@lists.berkeley.edu> >>>> > Subject: Re: [casper] adc16x250-8 duplicated samples >>>> > >>>> > Thanks for the info! I tried using the design from the CASPER page >>>> and got the same results using the >>>> > adc16_plot_chans.rb script. I even print (puts) the snapshot data to >>>> verify it wasn't a visual effect of >>>> > the plot, and effectively the data repeats every two samples. So now >>>> I'm out of ideas. For now I think I >>>> > can leave with the penalty of the error (in the end it just halves >>>> the usable bandwidth), but I'm very >>>> > interested if someone comes with a theory or a possible test to debug >>>> the phenomenon. >>>> > >>>> > Franco >>>> > >>>> > On Wed, Apr 3, 2019 at 7:09 PM David MacMahon <dav...@berkeley.edu> >>>> wrote: >>>> > The adc16 scripts that you are using will work with the >>>> adc16_test design (all adc16 designs >>>> > really). The adc16 yellow block includes built-in snapshot >>>> functionality so all adc16 >>>> > designs can get ADC snapshots using the built-in snapshot >>>> functionality. The adc16_test >>>> > design has an extra (much larger) snapshot block, but you don't >>>> have to use it. >>>> > HTH, >>>> > Dave >>>> > >>>> > On Apr 3, 2019, at 14:27, Franco <francocuro...@gmail.com> >>>> wrote: >>>> > >>>> > Yes, it happens in the 16 inputs. Unfortunately, I don't have another >>>> adc board. I have >>>> > another ROACH2 but it is used for the moment. I'll try testing in the >>>> other ROACH2 when it >>>> > gets available. >>>> > I notice that there is a sample compiled bof in: >>>> > https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 , maybe >>>> I could try testing that >>>> > model to see if it is a problem with my compilation tools, but I >>>> haven't found the script >>>> > that performs the data acquisition to the pc. Does such script exists? >>>> > >>>> > Thanks, >>>> > >>>> > Franco >>>> > >>>> > On Wed, Apr 3, 2019 at 4:52 PM David MacMahon <dav...@berkeley.edu> >>>> wrote: >>>> > Does this symptom appear on all 16 inputs? Do you have another >>>> adc16x250-8 card >>>> > and/or another ROACH2 you could try instead? >>>> > Dave >>>> > >>>> > On Apr 3, 2019, at 11:51, Franco <francocuro...@gmail.com> >>>> wrote: >>>> > >>>> > Hi Jack, >>>> > >>>> > To answer your questions: >>>> > - Yes I'm using the latest version of mlib_devel, roach2 branch. >>>> > - No, the initialization script doesn't suggest any error. Here is >>>> the script >>>> > output: >>>> > >>>> > Connecting to 192.168.1.13... >>>> > Programming 192.168.1.13 with adc16snap.bof.gz... >>>> > Design built for ROACH2 rev2 with 4 ADCs (ZDOK rev2) >>>> > Gateware supports demux modes (using demux by 1) >>>> > Resetting ADC, power cycling ADC, and reprogramming FPGA... >>>> > ZDOK0 clock OK >>>> > Calibrating SERDES blocks...ABCD >>>> > SERDES calibration successful. >>>> > Selecting analog inputs... >>>> > Using default digital gain of 1... >>>> > Done! >>>> > >>>> > - I plotted the adc output with adc16_plot_chans.rb, and it seems to >>>> present the >>>> > same data duplication. Here is an image of the plot: >>>> > <Screenshot from 2019-04-03 15-11-28.png> >>>> > >>>> > - Yes, the User IP Clock is correctly set to adc0_clk. >>>> > >>>> > I also tried with a different model and a different clock rate >>>> (200MHz/MSPS), and >>>> > using the initialization code from here: >>>> > http://w.astro.berkeley.edu/~davidm/gems/ and I had the same result. >>>> It seems the >>>> > I stumbled into some mysterious behavior of the ADC board. Has >>>> anybody else >>>> > experienced this behavior? >>>> > >>>> > Thanks, >>>> > >>>> > Franco >>>> > >>>> > >>>> > On Wed, Apr 3, 2019 at 2:02 PM Jack Hickish <jackhick...@gmail.com> >>>> wrote: >>>> > Hi Franco, >>>> > >>>> > Sorry, I missed your note in your first email where you already said >>>> you >>>> > used the ruby init code with demux 1. This is correct for the 16-input >>>> > configuration you are using. In this configuration, the FPGA and ADC >>>> should >>>> > both run at the same clock rate. >>>> > If you put in a 140MHz clock and est_brd_clk() returns ~140 that is a >>>> good >>>> > sign. >>>> > I assume you're using the latest roach2 branch on >>>> > github.com/casper-astro/mlib_devel? >>>> > Does the ruby initialization script suggest anything is wrong in the >>>> > initialization? >>>> > In the same repository as the adc16_init script, there is also a >>>> script to >>>> > plot adc outputs -- adc16_plot_chans.rb . Does this give the same >>>> sample >>>> > duplication you see in your snapshots? >>>> > I assume that the User IP Clock source in your design is correctly >>>> set to >>>> > adc0? (not user_clk/sys_clk?) >>>> > >>>> > >>>> > Thats all I can think to check right now... >>>> > >>>> > Good luck! >>>> > Jack >>>> > >>>> > On Wed, 3 Apr 2019 at 16:57, Franco <francocuro...@gmail.com> wrote: >>>> > Hi David and Jack, >>>> > >>>> > Interesting. Yes I'm using a 140MHz clock (I'm injecting a 140MHz >>>> > tone into the adc clock input). I'm sure the FPGA is running at >>>> > 140MHz because I checked it with fpga.est_brd_clk(). Also, the data >>>> > duplication occurs for all 16 inputs, so my guess is that is a >>>> > problem at the adc board level. I'm using the adc_init.rb code with >>>> > the '--demux 1' flag (I understand that this is the 16 in mode), >>>> > however I copied this code from someone else, so maybe is an old >>>> > version. I'll try to use the latest version to see if that is the >>>> > problem. I'll also try a different (valid) sampling frequency. >>>> > >>>> > Thanks for the suggestions, >>>> > >>>> > Franco >>>> > >>>> > On Wed, Apr 3, 2019 at 9:07 AM Jack Hickish <jackhick...@gmail.com> >>>> > wrote: >>>> > Hi Franco, >>>> > In addition to Dave's advice-- how are you configuring your >>>> > board? After programming the FPGA, you'll need to appropriately >>>> > configure the ADC to operate in the right mode. The code seems >>>> > to be linked here >>>> > -- https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2 >>>> > >>>> > Cheers >>>> > Jack >>>> > >>>> > On Wed, 3 Apr 2019 at 00:53, Franco <francocuro...@gmail.com> >>>> > wrote: >>>> > Hi Casperites, >>>> > >>>> > I'm working in some project that uses a ROACH2 and an >>>> > adc16x250-8 ADC board. When I check the raw data from the >>>> > ADC using a snapshot block I see this weird effect where >>>> > two consecutive samples have always the same value, as >>>> > shown in this image: >>>> > >>>> https://my.pcloud.com/publink/show?code=XZMRx67Zpj7XjnkE5PypVuuDCB9Mhu8IJJ37 >>>> > >>>> > According to an ex-coworker, this is the expected >>>> > behavior of the adc16x250-8 board in 16 input mode, >>>> > because of some constraints in the communication between >>>> > the ADC and the FPGA, the FPGA must run at twice the >>>> > speed to correctly receive the sampled data. However, >>>> > couldn't find any explicit mention of this phenomenon in >>>> > the CASPER website or mailing list. Can someone confirm >>>> > this is the correct behavior so I can get peace of mind >>>> > :)? >>>> > >>>> > Some info of my test: >>>> > - Board: ROACH2-rev2 >>>> > - ADC: ADC16x250-8 coax rev2 >>>> > - ADC mode: 16 inputs (demux 1, using David Macmahon >>>> > initalization code) >>>> > - User IP Clock Rate: 140 MHz >>>> > - Actual clock frequency used in the adc board: 140MHz >>>> > >>>> > Thanks, >>>> > >>>> > Franco Curotto >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to >>>> > the Google Groups "casper@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails >>>> > from it, send an email to >>>> > casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to >>>> > casper@lists.berkeley.edu. >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the >>>> > Google Groups "casper@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails from >>>> > it, send an email to casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to casper@lists.berkeley.edu. >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> > Groups "casper@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> > send an email to casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to casper@lists.berkeley.edu. >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups >>>> > "casper@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an >>>> > email to casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to casper@lists.berkeley.edu. >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups >>>> > "casper@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email >>>> > to casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to casper@lists.berkeley.edu. >>>> > >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups >>>> > "casper@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email to >>>> > casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to casper@lists.berkeley.edu. >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups >>>> > "casper@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email to >>>> > casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to casper@lists.berkeley.edu. >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups >>>> > "casper@lists.berkeley.edu" group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email to >>>> > casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to casper@lists.berkeley.edu. >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> Groups "casper@lists.berkeley.edu" >>>> > group. >>>> > To unsubscribe from this group and stop receiving emails from it, >>>> send an email to >>>> > casper+unsubscr...@lists.berkeley.edu. >>>> > To post to this group, send email to casper@lists.berkeley.edu. >>>> > >>>> > >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "casper@lists.berkeley.edu" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to casper+unsubscr...@lists.berkeley.edu. >>>> To post to this group, send email to casper@lists.berkeley.edu. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "casper@lists.berkeley.edu" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to casper+unsubscr...@lists.berkeley.edu. >>> To post to this group, send email to casper@lists.berkeley.edu. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "casper@lists.berkeley.edu" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to casper+unsubscr...@lists.berkeley.edu. >> To post to this group, send email to casper@lists.berkeley.edu. >> > -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
