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