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 > <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] > <mailto:[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] >> <mailto:[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/ >> <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] >> <mailto:[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 >> <http://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] >> <mailto:[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] >> <mailto:[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 >> <https://casper.ssl.berkeley.edu/wiki/ADC16x250-8_coax_rev_2> >> >> Cheers >> Jack >> >> On Wed, 3 Apr 2019 at 00:53, Franco <[email protected] >> <mailto:[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 >> <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] <mailto:[email protected]>" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected] <mailto:[email protected]>" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected] <mailto:[email protected]>" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected] <mailto:[email protected]>" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "[email protected] <mailto:[email protected]>" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. > > > -- > You received this message because you are subscribed to the Google Groups > "[email protected] <mailto:[email protected]>" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[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].
