On Tue, 20 Oct 2020, 9:42 am 'Benjamin Godfrey' via [email protected], <[email protected]> wrote:
> Hi Jack, > Thank you for all your suggestions. Really appreciate all the > troubleshooting help. Going through your suggestions in order: > > - EOF is going low with the final valid signal in simulation > As in, EOF pulses high for one clock, then goes low with valid? That sounds fine. - But valid is always high when I read the snapshot block, which is > unexpected (need to dig further to figure out why this is happening). EOF, > though, is still going high for one clock cycle at the expected time. > - Reading from the transmit full output reports false, but I don't really > understand this since the valid signal is always high. > Yeah, that seems strange. It's always worth checking there isn't something really wrong happening, like the core being locked in reset, or being disabled from software. I believe there is a "print_core_details" of some such, which will show you various internal core parameters. > I was having issues with the tap interface populating the ARP table with > correct addresses so I've now taken to populating it manually (using > set_arp_table, which I found in the docs). Furthermore, I've had problems > being able to ping the ROACH from the PC. I am now able to ping the PC > logged into the ROACH, but I am unable to ping the ROACH from the PC side. > Do you know why this may be the case? > Ping definitely won't work without the tap interface. But if it doesn't even work with that, I'm not sure I have any suggestions. I generally never used the tap interface and just micromanaged the core configurations as you are now doing. Cheers Jack > > I definitely have some paths to explore. > > Thanks, > Ben G. > > On Tue, Oct 20, 2020 at 12:56 AM Jack Hickish <[email protected]> > wrote: > >> Hi Ben, >> >> Before getting too far into the power PC software side, some basic checks >> in firmware which are probably worth doing - >> >> - does EOF go high with (not after) the last valid sample? >> - can you (using a snapshot block) verify that what is happening in >> firmware with the vld / EOF signals matches your simulation? >> - do you have the ability to read the Tge overflow outputs, which are a >> good indicator of something going awry? >> >> If you compile with the "enable core on startup" option on the The block >> checked, you should be able to transmit regardless of the software "tap" >> interface. The tap interface is needed to handle things like ARP, but even >> without it you should see packets coming out of your board on tcpdump, even >> if they all have the wrong destination MAC addresses. >> >> Good luck! >> >> Jack >> >> >> On Mon, 19 Oct 2020, 6:48 pm 'Benjamin Godfrey' via >> [email protected], <[email protected]> wrote: >> >>> Hi everyone, >>> I've been getting my feet wet the last little while introducing >>> myself to using the ROACH 2 toolset. After being unable to get Tutorial 2 >>> to work out of the box, I took a step back and am trying to just transmit >>> packets using the SFP+ port to my PC and read them out. My design is >>> heavily based on the one in the Roach 2 tutorial except that I am using the >>> katadc to generate data. What I've tried so far is detailed below: >>> >>> Right now, I am trying to send 64, 64-bit samples at ~390 kHz (feeding >>> in an 800 MHz clock) so I shouldn't be overfilling buffers. In simulation, >>> it looks like *tx_valid* and *tx_end_of_frame* are both being set as I >>> would expect, namely *tx_valid *goes high whenever I am sending data >>> and *tx_end_of_frame* goes high for one clock cycle at the end of when >>> I expect to send data. >>> >>> On the PC side of things, I also wasn't able to get the Python script to >>> work out of the box, so I modified it a little bit using suggestions from >>> the mail archives. The important details are below: >>> >>> *ip_base = 192*(2**24) + 168*(2**16) + 41*(2**8) * >>> *mac_base = (2<<40) + (2<<32)* >>> >>> *fabric_port = 60000* >>> *gbe_tx = casperfpga.tengbe.TenGbe(fpga, 'gbe0', ip_base+20, 512)* >>> *gbe_tx.setup(mac_base+20, ip_base+20, fabric_port)* >>> *gbe_tx.tap_start()* >>> >>> I am trying to write data to 192.168.41.1 (same subnet as the ROACH2), >>> on my PC, connected to the ROACH2 using an SFP+ cable. To do this, I've >>> used the socket library in Python configured to listen for UDP packets at >>> the required IP/port. However, I am unable to get any data from the ROACH2 >>> whatsoever. I've looked to see if I have any packets coming over the port >>> using Wireshark and I see nothing. >>> >>> Something that I've noticed, is that I am unable to ping the gbe port >>> (after writing the design to the board). When I look at ifconfig after >>> ssh-ing into the ROACH, I see the following: >>> >>> *gbe 0 Link encap: UNSPEC HWaddr >>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00* >>> * inet addr:192.168.41.20 P-t-P:192.168.41.20 >>> Mask:255.255.255.0* >>> >>> * UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1* >>> * RX packets:0 errors:0 dropped:0 overruns:0 frame:0* >>> * TX packets:0 errors:0 dropped:0 overruns:0 carrier:0* >>> * collisions:0 txqueuelen: 500* >>> * RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)* >>> >>> I think this looks reasonable other than the lack of packets being sent. >>> I'm now off playing with routing tables thinking that this may be my issue, >>> but I am honestly pretty in the weeds at this point. Do you guys have some >>> suggestions? I'm sure there are a few things I've fouled up along the way. >>> >>> Thanks for the help, >>> Ben G. >>> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/4634df92-fb67-4bf5-bcab-22478a4c952cn%40lists.berkeley.edu >>> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/4634df92-fb67-4bf5-bcab-22478a4c952cn%40lists.berkeley.edu?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKS%3D2h_S-rwBOJKSc%3D7-EXt8zDDeCeBC%2BYnKREuevOZJN9w%40mail.gmail.com >> <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKS%3D2h_S-rwBOJKSc%3D7-EXt8zDDeCeBC%2BYnKREuevOZJN9w%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 view this discussion on the web visit > https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAERfaAhVn0MBUMApKy%2BECvhp%2B-vbo_%2BxWTUh2VYSSvwZAbNPzQ%40mail.gmail.com > <https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAERfaAhVn0MBUMApKy%2BECvhp%2B-vbo_%2BxWTUh2VYSSvwZAbNPzQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 view this discussion on the web visit https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAG1GKSk%3D_CasM71sx2M2ZNuniu2u4naKGa6BueTjSqxovd1Kzw%40mail.gmail.com.
