[casper] 2 Gsample/sec ADC
Dear Casperites, I have an analog to digital converter boards ADC2X1000-8, which can digitize two streams at 1 Gsample/sec or a single stream at 2 Gsample/sec. I would like a spectrometer with a stream at 2 Gsample/sec using ADC interleave mode, but I think use blocks with 8 streams o inputs: pfb_fir_real, 8 streams o inputs: fft_wideband_real, 4 streams o inputs : quant, vacc and brams. Where are these blocks or libraries? Has anyone worked with these? Cheers Katty
Re: [casper] ROACH 2 ARP
Correction: this is indeed a problem, but my description is not quite correct. It seems the "poll interval" is 10 ms and the burst logic looks to see if there's more than one packet in a poll inteval. The BEE2 on the network is sending ARP packets every ~4ms so a burst is perpetually detected. So I need to increase the number of packets per poling itnerval to count as a burst. I'm just going to disable the burst checking for now. Glenn On Tue, Dec 18, 2012 at 2:08 PM, G Jones wrote: > Well I think I located the problem: > in tcpborphserver3/tg.c > The main do-while loop has a burst variable that's supposed to keep > the ROACH from broadcasting ARPs if the network is busy. burst is > initialized to zero at the start of the program, but from that point > on, it is only incremented. The ARP "spamming" as it's called only > occurs if burst < 1, so once a "burst" is detected, it will never > again spam ARP packets. In our case, the network is being spammed by > the BEE2 on the net and other devices, so it never gets a chance to do > it's ARP broadcast. > > I'll try to fix this myself, but someone more familiar with the code > should look at it and decide what the right thing to do is. > > Glenn > > On Tue, Dec 18, 2012 at 1:57 PM, G Jones wrote: >> Looking through the tcpborphserver3 code, I saw there is a tap-info >> command. When I run that I get: >> >> ?tap-info >> #log info 2212751 raw peer\_10:10:10:10:10:11\_at\_18000 >> #log info 2212751 raw peer\_02:02:0a:11:00:40\_at\_0 >> #log info 2212751 raw current\_iteration\_0 >> #log info 2212751 raw buffers\_arp=0/rx=0/tx=0 >> #log info 2212751 raw polling\_interval\_10 >> #log info 2212751 raw address\_10.17.0.64 >> #log info 2212751 raw gateware\_port\_is\_6 >> #log info 2212751 raw tap\_device\_name\_tap0\_on\_fd\_29 >> !tap-info ok >> >> The 10:10:10 MAC is a BEE2 on the network happily blasting arps as >> usual, and the 02:02:0A... MAC is this ROACH2 itself. So it seems like >> it is receiving and interpreting ARPs OK. It's just not sending them >> itself... >> >> Any ideas? >> >> Thanks, >> Glenn >> >> On Tue, Dec 18, 2012 at 10:58 AM, G Jones wrote: >>> Hi, >>> In the last couple of days our ROACH2's have decided to stop sending >>> ARP packets after tapstart'ing. As a result, the default ARP table >>> values cause all UDP packets to be sent to the broadcast MAC address >>> (all F's). Any ideas what could have caused this and how to fix it? My >>> best guess is that we changed uImage files a while ago to try to deal >>> with the TBS3 write/wordwrite bug and perhaps the ROACH2's weren't >>> rebooted until later so we didn't see the change until recently. But >>> I'm not sure. >>> >>> The tge details look fine: >>> >>> GBE0 Configuration... >>> My MAC: 02 02 0A 11 00 40 >>> Gateway:0 0 0 1 >>> This IP: 10 17 0 64 >>> Gateware Port: 6 >>> Fabric interface is currently: Enabled >>> XAUI Status: 007E >>> lane sync 0: 1 >>> lane sync 1: 1 >>> lane sync 2: 1 >>> lane sync 3: 1 >>> Channel bond: 1 >>> XAUI PHY config: >>> RX_eq_mix: A >>> RX_eq_pol: 4 >>> TX_pre-emph: 0 >>> TX_diff_ctrl: 7 >>> >>> >>> Thanks, >>> Glenn
Re: [casper] ROACH 2 ARP
Well I think I located the problem: in tcpborphserver3/tg.c The main do-while loop has a burst variable that's supposed to keep the ROACH from broadcasting ARPs if the network is busy. burst is initialized to zero at the start of the program, but from that point on, it is only incremented. The ARP "spamming" as it's called only occurs if burst < 1, so once a "burst" is detected, it will never again spam ARP packets. In our case, the network is being spammed by the BEE2 on the net and other devices, so it never gets a chance to do it's ARP broadcast. I'll try to fix this myself, but someone more familiar with the code should look at it and decide what the right thing to do is. Glenn On Tue, Dec 18, 2012 at 1:57 PM, G Jones wrote: > Looking through the tcpborphserver3 code, I saw there is a tap-info > command. When I run that I get: > > ?tap-info > #log info 2212751 raw peer\_10:10:10:10:10:11\_at\_18000 > #log info 2212751 raw peer\_02:02:0a:11:00:40\_at\_0 > #log info 2212751 raw current\_iteration\_0 > #log info 2212751 raw buffers\_arp=0/rx=0/tx=0 > #log info 2212751 raw polling\_interval\_10 > #log info 2212751 raw address\_10.17.0.64 > #log info 2212751 raw gateware\_port\_is\_6 > #log info 2212751 raw tap\_device\_name\_tap0\_on\_fd\_29 > !tap-info ok > > The 10:10:10 MAC is a BEE2 on the network happily blasting arps as > usual, and the 02:02:0A... MAC is this ROACH2 itself. So it seems like > it is receiving and interpreting ARPs OK. It's just not sending them > itself... > > Any ideas? > > Thanks, > Glenn > > On Tue, Dec 18, 2012 at 10:58 AM, G Jones wrote: >> Hi, >> In the last couple of days our ROACH2's have decided to stop sending >> ARP packets after tapstart'ing. As a result, the default ARP table >> values cause all UDP packets to be sent to the broadcast MAC address >> (all F's). Any ideas what could have caused this and how to fix it? My >> best guess is that we changed uImage files a while ago to try to deal >> with the TBS3 write/wordwrite bug and perhaps the ROACH2's weren't >> rebooted until later so we didn't see the change until recently. But >> I'm not sure. >> >> The tge details look fine: >> >> GBE0 Configuration... >> My MAC: 02 02 0A 11 00 40 >> Gateway:0 0 0 1 >> This IP: 10 17 0 64 >> Gateware Port: 6 >> Fabric interface is currently: Enabled >> XAUI Status: 007E >> lane sync 0: 1 >> lane sync 1: 1 >> lane sync 2: 1 >> lane sync 3: 1 >> Channel bond: 1 >> XAUI PHY config: >> RX_eq_mix: A >> RX_eq_pol: 4 >> TX_pre-emph: 0 >> TX_diff_ctrl: 7 >> >> >> Thanks, >> Glenn
Re: [casper] ROACH 2 ARP
Looking through the tcpborphserver3 code, I saw there is a tap-info command. When I run that I get: ?tap-info #log info 2212751 raw peer\_10:10:10:10:10:11\_at\_18000 #log info 2212751 raw peer\_02:02:0a:11:00:40\_at\_0 #log info 2212751 raw current\_iteration\_0 #log info 2212751 raw buffers\_arp=0/rx=0/tx=0 #log info 2212751 raw polling\_interval\_10 #log info 2212751 raw address\_10.17.0.64 #log info 2212751 raw gateware\_port\_is\_6 #log info 2212751 raw tap\_device\_name\_tap0\_on\_fd\_29 !tap-info ok The 10:10:10 MAC is a BEE2 on the network happily blasting arps as usual, and the 02:02:0A... MAC is this ROACH2 itself. So it seems like it is receiving and interpreting ARPs OK. It's just not sending them itself... Any ideas? Thanks, Glenn On Tue, Dec 18, 2012 at 10:58 AM, G Jones wrote: > Hi, > In the last couple of days our ROACH2's have decided to stop sending > ARP packets after tapstart'ing. As a result, the default ARP table > values cause all UDP packets to be sent to the broadcast MAC address > (all F's). Any ideas what could have caused this and how to fix it? My > best guess is that we changed uImage files a while ago to try to deal > with the TBS3 write/wordwrite bug and perhaps the ROACH2's weren't > rebooted until later so we didn't see the change until recently. But > I'm not sure. > > The tge details look fine: > > GBE0 Configuration... > My MAC: 02 02 0A 11 00 40 > Gateway:0 0 0 1 > This IP: 10 17 0 64 > Gateware Port: 6 > Fabric interface is currently: Enabled > XAUI Status: 007E > lane sync 0: 1 > lane sync 1: 1 > lane sync 2: 1 > lane sync 3: 1 > Channel bond: 1 > XAUI PHY config: > RX_eq_mix: A > RX_eq_pol: 4 > TX_pre-emph: 0 > TX_diff_ctrl: 7 > > > Thanks, > Glenn
Re: [casper] Getting started with ROACH2 boards
Hello > I am able to access and write to software registers. Also, I can verify > that this simple design is working as expected. > > So is it not necessary to get #fpga prompt ? There isn't a prompt, but recent revisions of tcpborphserver3 generate unsolicited #fpga inform messages when the fpga changes status from unprogrammed to programmed and vice versa (like a log message, but easier to parse). You might have a slightly older version... but don't update just yet, as there is still a bugfix pending for problems with the ?write operation > Also, upload command does not copy the design to /usr/bof/ directory. Yes. > Also, then > is progdev command redundant if one is using upload? If you (by other means) get a file into /usr/bof, then you can still use progdev. And as Dave mentioned, it can be used to deprogram the fpga. regards marc
Re: [casper] Getting started with ROACH2 boards
Hi, Nimish, I don't use the corr package much so I don't know about its status, but I share your understanding that the upload command is not present in publicly available (i.e. pushed to github or elsewhere) corr packages. Dave On Dec 18, 2012, at 9:23 AM, Nimish Sane wrote: > Ok. > > And as Jason mentioned earlier, just to reconfirm "upload" command has not > made it to corr package yet, right? > > Thanks, > > Nimish > > On Tue, Dec 18, 2012 at 12:14 PM, David MacMahon > wrote: > Hi, Nimish, > > On Dec 18, 2012, at 8:12 AM, Nimish Sane wrote: > > > Also, upload command does not copy the design to /usr/bof/ directory. > > ?listbof does not list anything. Is this an expected behavior? Also, then > > is progdev command redundant if one is using upload? > > Yes, that's how I interpret the README. ?upload programs the FPGA directly > and does NOT store the bof file in the ROACH2 filesystem. > > If only using ?upload, then ?progdev is still useful since (I think) it can > be used without a filename to de-program the FPGA. > > Dave > > > > > -- > Nimish Sane > > Center for Solar-Terrestrial Research > New Jersey Institute of Technology > University Heights > Newark, NJ 07102-1982 USA > Tel: (973) 642 4958 > Fax: (973) 596 3617 > nimish.s...@njit.edu >
Re: [casper] Getting started with ROACH2 boards
Ok. And as Jason mentioned earlier, just to reconfirm "upload" command has not made it to corr package yet, right? Thanks, Nimish On Tue, Dec 18, 2012 at 12:14 PM, David MacMahon wrote: > Hi, Nimish, > > On Dec 18, 2012, at 8:12 AM, Nimish Sane wrote: > > > Also, upload command does not copy the design to /usr/bof/ directory. > ?listbof does not list anything. Is this an expected behavior? Also, then > is progdev command redundant if one is using upload? > > Yes, that's how I interpret the README. ?upload programs the FPGA > directly and does NOT store the bof file in the ROACH2 filesystem. > > If only using ?upload, then ?progdev is still useful since (I think) it > can be used without a filename to de-program the FPGA. > > Dave > > -- Nimish Sane Center for Solar-Terrestrial Research New Jersey Institute of Technology University Heights Newark, NJ 07102-1982 USA Tel: (973) 642 4958 Fax: (973) 596 3617 nimish.s...@njit.edu
Re: [casper] Getting started with ROACH2 boards
Hi, Nimish, On Dec 18, 2012, at 8:12 AM, Nimish Sane wrote: > Also, upload command does not copy the design to /usr/bof/ directory. > ?listbof does not list anything. Is this an expected behavior? Also, then is > progdev command redundant if one is using upload? Yes, that's how I interpret the README. ?upload programs the FPGA directly and does NOT store the bof file in the ROACH2 filesystem. If only using ?upload, then ?progdev is still useful since (I think) it can be used without a filename to de-program the FPGA. Dave
Re: [casper] Getting started with ROACH2 boards
Hi Marc: On Tue, Dec 18, 2012 at 10:16 AM, Marc Welz wrote: > Hello > > > I do not get #fpga prompt. I get many #log prompts that indicate file > > transfer status. The final three prompts are as follows: > > > > #log info 947013966875 unknown uploaded\_19590582\_bytes > > #log info 947013966876 raw attempting\_to\_empty\_fpga > > #log info 947013966896 raw > > > attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config > > Try doing a ?listdev after that, if you see lots of names things > should have programmed the fpga, then try ?wordread sys_scratchpad 0 > I did this and it seems to work fine. Here is the log: ?fpgastatus #log info 946685224671 raw fpga\_programmed\_and\_mapped\_with\_ !fpgastatus ok ?listdev #listdev count #listdev counter_arm #listdev counter_period #listdev counter_reset #listdev sys_board_id #listdev sys_clkcounter #listdev sys_rev #listdev sys_rev_rcs #listdev sys_scratchpad !listdev ok I am able to access and write to software registers. Also, I can verify that this simple design is working as expected. So is it not necessary to get #fpga prompt ? Also, upload command does not copy the design to /usr/bof/ directory. ?listbof does not list anything. Is this an expected behavior? Also, then is progdev command redundant if one is using upload? > regards > > marc > > Thanks a lot. -- Nimish Sane Center for Solar-Terrestrial Research New Jersey Institute of Technology University Heights Newark, NJ 07102-1982 USA Tel: (973) 642 4958 Fax: (973) 596 3617 nimish.s...@njit.edu
[casper] ROACH 2 ARP
Hi, In the last couple of days our ROACH2's have decided to stop sending ARP packets after tapstart'ing. As a result, the default ARP table values cause all UDP packets to be sent to the broadcast MAC address (all F's). Any ideas what could have caused this and how to fix it? My best guess is that we changed uImage files a while ago to try to deal with the TBS3 write/wordwrite bug and perhaps the ROACH2's weren't rebooted until later so we didn't see the change until recently. But I'm not sure. The tge details look fine: GBE0 Configuration... My MAC: 02 02 0A 11 00 40 Gateway:0 0 0 1 This IP: 10 17 0 64 Gateware Port: 6 Fabric interface is currently: Enabled XAUI Status: 007E lane sync 0: 1 lane sync 1: 1 lane sync 2: 1 lane sync 3: 1 Channel bond: 1 XAUI PHY config: RX_eq_mix: A RX_eq_pol: 4 TX_pre-emph: 0 TX_diff_ctrl: 7 Thanks, Glenn
Re: [casper] Getting started with ROACH2 boards
Hello > I do not get #fpga prompt. I get many #log prompts that indicate file > transfer status. The final three prompts are as follows: > > #log info 947013966875 unknown uploaded\_19590582\_bytes > #log info 947013966876 raw attempting\_to\_empty\_fpga > #log info 947013966896 raw > attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config Try doing a ?listdev after that, if you see lots of names things should have programmed the fpga, then try ?wordread sys_scratchpad 0 regards marc
Re: [casper] Getting started with ROACH2 boards
Hello: On Tue, Dec 18, 2012 at 3:02 AM, Marc Welz wrote: > Hello > > On Mon, Dec 17, 2012 at 4:40 PM, Nimish Sane wrote: > > > 1. The file system on the Roach2 is read-only. I am not able to create a > > directory /boffiles. There is none right now. I believe there was some > > discussion about keeping it read-only system. I want to know what > options we > > have. > > There should be a symlink from /bof -> /usr/bof, which is readwrite on > roach2 > I have /usr/bof and it is RW. Thanks! > > > 2. nc does not have -q option. In anyways, the upload command with nc is > not > > working as expected. > > So it turns out there are two implementations of nc, you probably have > the other one. Essentially what we are trying to say is: "once you > have sent the file to the socket, close it, don't wait", otherwise nc > waits indefinitely > >From what I understand: -q N specifies that wait for N seconds after the file is sent instead of closing it immediately. The default is -q 0. I am just ignoring the -q switch. > > > I get lot of log messages followed by messages like: > > "raw attempting to empty fpga" and "raw attempting to program bitstream > of > > bytes to device /dev/roach/config. > > Then you should almost be there, actually if you see the #fpga > messages on the katcp co, the fpga should be programmed and the > registers available, just nc hasn't exited ... > I do not get #fpga prompt. I get many #log prompts that indicate file transfer status. The final three prompts are as follows: #log info 947013966875 unknown uploaded\_19590582\_bytes #log info 947013966876 raw attempting\_to\_empty\_fpga #log info 947013966896 raw attempting\_to\_program\_bitstream\_of\_19586188\_bytes\_to\_device\_/dev/roach/config If it may help, I am trying to upload the following .bof file. -rw-rw-r-- 1 observer observer 19586299 Dec 14 13:35 roach2_test_2012_Dec_14_1328.bit -rwxrwxr-x 1 observer observer 19590582 Dec 14 13:35 roach2_test_2012_Dec_14_1328.bof > regards > > marc > Thanks! -- Nimish Sane Center for Solar-Terrestrial Research New Jersey Institute of Technology University Heights Newark, NJ 07102-1982 USA Tel: (973) 642 4958 Fax: (973) 596 3617 nimish.s...@njit.edu
Re: [casper] ROACH-2 NFS filesystems
If you are booting multiple boards of the same version that is fine, but the init files and kernels are different for different versions so it's better to keep them separate. Regards Alec On Fri, Dec 14, 2012 at 7:56 PM, John Ford wrote: > Hi all. Can these root filesystems be shared between roach boards? > > John > > >
Re: [casper] Getting started with ROACH2 boards
Hello On Mon, Dec 17, 2012 at 4:40 PM, Nimish Sane wrote: > 1. The file system on the Roach2 is read-only. I am not able to create a > directory /boffiles. There is none right now. I believe there was some > discussion about keeping it read-only system. I want to know what options we > have. There should be a symlink from /bof -> /usr/bof, which is readwrite on roach2 > 2. nc does not have -q option. In anyways, the upload command with nc is not > working as expected. So it turns out there are two implementations of nc, you probably have the other one. Essentially what we are trying to say is: "once you have sent the file to the socket, close it, don't wait", otherwise nc waits indefinitely > I get lot of log messages followed by messages like: > "raw attempting to empty fpga" and "raw attempting to program bitstream of > bytes to device /dev/roach/config. Then you should almost be there, actually if you see the #fpga messages on the katcp co, the fpga should be programmed and the registers available, just nc hasn't exited ... regards marc
