Hi David, As far as I'm aware there is nothing unusual about this clocking scheme; however I did not write them so I don't know for sure. Is there a way to take the .bof file and 'open it up' to see how it was built?
In any case, since it appears the ROACH is working correctly and this is an important eventual step, I will try moving forward by writing the DAQ .bof code myself so that I do understand everything that is going on. Best, Eric ________________________________________ From: David MacMahon <dav...@berkeley.edu> on behalf of David MacMahon <dav...@astro.berkeley.edu> Sent: Friday, July 15, 2016 8:51 AM To: Miller, Eric H. Cc: Marc Welz; To: casper@lists.berkeley.edu Subject: Re: [casper] ROACH status queries Hi, Eric, It sure sounds like your second BOF file is not being properly clocked. I think even roach1 designs include a built-in register (maybe named "says_clk_counter") for estimating the FPGA clock frequency. The python corr package has a function named something like est_clock_freq() (I'm not on my computer right now so I can't check the exact name) that reads this register, sleeps 1 second, and reads the register again. The difference in register counts divided by time interval provided the estimate of the FPGA clock frequency. When you run one BOF file, "set things up", and then run a different BOF file, the loading of the second BOF file reinitializes everything inside the FPGA that got setup with the first BOF file. It is possible in some scenarios for the first BOF file to configure resources external to the FPGA. In that case the settings of the external resources can persist from one BOF to the next BOF. Is there anything unusual about your clocking scheme? Have you verified that the init_clock design and the "take data" design are clocked the same way (eg ADC0 clock)? Thanks, Dave > On Jul 14, 2016, at 12:59, Miller, Eric H. <eric.mil...@sdsmt.edu> wrote: > > Thanks all for the replies and suggestions. > > "?listdev" does indeed show a number of register names, so it looks like the > ROACH was programmed successfully, and that "program" was an indication of > success rather than an error. > > Currently I am unable to take data (attempts return only zeros). Perhaps > more significantly, the clock returns \x00\x00\x00\x00. > > Some additional information: > I am using roach1. > tcpborphserver2 is running on the ROACH. > I have been controlling the ROACH through the Casper python interface on the > control computer. > I have input a clock signal at 746 MHz through the digitization card. > I can successfully read and write to any registers on the ROACH after it is > programmed. > My first step is to load and run a .bof file called init_clock. After > loading this, clock values increment reasonably. > My second step is to load and run a .bof file to take data. This appears to > load correctly, but bram registers are all zeros after forcing a trigger, and > the clock value sits at zero always. > > This system had been run previously with success using the same python > operations and .bof files. It's possible that there are required packages > that are not installed on the ROACH, because the USB drive had been loaded as > read-only (so packages installed previously may now be absent). > > Best, > Eric Miller > > > ________________________________________ > From: Marc Welz <m...@ska.ac.za> > Sent: Tuesday, June 28, 2016 1:52 AM > To: Miller, Eric H. > Cc: To: casper@lists.berkeley.edu > Subject: Re: [casper] ROACH status queries > > What does > > "?listdev" (issued via telnet roach-ip 7147, discard the quotes) have > to say after a program ? If there are lots of register names, then it > probably programmed successfully. > > You don't specify if you are using a roach1 or roach2... Generally > you can telnet to the roach on port 7147 via a separate connection > which you can keep open indefinitely, and it should give you some > feedback on what it is attempting to do. If you issue a "?log-level > debug" or even "?log-level trace" you should get even more detailed > feedback. Programming on a roach1 happens in a subprocess, so that is > one of the cases where there is a bit less detail... common problems > include that the executable in the bof file doesn't match the > libraries installed on the roach. > > regards > > marc > > >> On Mon, Jun 27, 2016 at 3:45 PM, Miller, Eric H. <eric.mil...@sdsmt.edu> >> wrote: >> Hello ROACHers, >> >> >> I'm having some trouble operating a ROACH I've inherited, which used to >> work. Currently, after loading a .bof file via progdev, a status query >> returns "program." I understand this to be an error message of some sort, >> but cannot find any documentation explaining what the various status errors >> mean. Can anyone shed some light on this, or point me to where these error >> messages are detailed? >> >> >> Thanks, >> >> Eric >
