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 <[email protected]> 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 <[email protected]> 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 <[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]. >> > -- > 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].
