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].
