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

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?

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.

Reply via email to