On Wed, Jun 28, 2017 at 7:56 PM, Jack Hickish <jackhick...@gmail.com> wrote:
> Here's a preview, which maybe someone more knowledgable with augment / > correct -- > > .. > > What tgtap does is start a process on the CPU which will read and respond to > packets from the interface which aren't addressed to the port the FPGA-side > of the interface is bound to. This is handy, because it means the CPU will > handle arp traffic, and will automatically discover the MAC addresses of > devices on the network so you don't have to handle the arp table yourself. Expanding on this: The tgtap functionality has moved into the tcpborphsever process itself on more recent roach2 builds. It uses the tap/tun driver of the linux kernel to make the fpga network devices available to the CPU. In addition to handling arp (noisily), it also becomes possible to handle multicast subscriptions and dhcp requests. And it it is even possible to ssh into the roach via the interfaces. None of that is particularly fast, as the interface is being polled. > I > actually don't know whether tgtap works with a 1GbE interface (I've never > tried), but if it doesn't manually configuring the core parameters is fairly > straightforward. Nor have I ... if the layout of the registers is the same (particularly the word sizes used to tell the core how to transmit data), then it should work. Otherwise there is some hacking required: See github.com/ska-sa/katcp_devel/tcpborphserver, in particular tg.c. From line 1700 onward, functions ending in _cmd are the ones which can be used from the network to drive the devices. regards marc -- You received this message because you are subscribed to the Google Groups "casper@lists.berkeley.edu" group. To unsubscribe from this group and stop receiving emails from it, send an email to casper+unsubscr...@lists.berkeley.edu. To post to this group, send email to casper@lists.berkeley.edu.
