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 <[email protected]> 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 <[email protected]> > > Reply-To: [email protected] > > To: Casper Lists <[email protected]> > > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > > 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 "[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]. > > > > > > -- > > 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]. > > > > > > -- > > 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]. > > > > > > -- > > 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]. > > > > > > -- > > 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]. > > > > > > > > -- > > 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]. > > > > > > -- > > 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]. > > > > > > -- > > 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]. > > > > -- > > 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]. > > > > > > -- > 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]. > -- 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].
