Hi Cedric,

I was actually looking at the casperfpga code recently, and was puzzling
about the ethernet setup. It seems to me it doesn’t actually program the
10GbE core.

Looking just at the tutorial, in the program script (roach2_tut_tge.py) it
calls fpga.gbes.[gbe_name_here].setup():

    print 'Configuring receiver core...',
    sys.stdout.flush()
    gbe_rx = fpga.gbes[rx_core_name]
    gbe_rx.set_arp_table(mac_base+numpy.arange(256))
    gbe_rx.setup(mac_base+13,ip_base+13,fabric_port)
    #fpga.tap_start('tap0',rx_core_name,mac_base+dest_ip,dest_ip,fabric_port)
    print 'done'


But in the casperfpga code,
https://github.com/casper-astro/casperfpga/blob/master/src/gbe.py#L104, it
doesn’t seem to do anything that communicates with the fpga:

    def setup(self, mac, ipaddress, port):
        """
        Set up the MAC, IP and port for this interface
        :param mac: String or Integer input
        :param ipaddress: String or Integer input
        :param port: String or Integer input
        """
        self.mac = Mac(mac)
        self.ip_address = IpAddress(ipaddress)
        self.port = port if isinstance(port, int) else int(port)

I thought that this function might be overloaded in the tengbe.py code, but
it doesn’t look like it is. (There is a bit of commented out code that is
suspicious
https://github.com/casper-astro/casperfpga/blob/master/src/tengbe.py#L144)
– but this was commented out two years ago!

So unless I’m missing some magic, casperfpga it isn’t actually programming
the 10gbe core with the setup function, it's just setting some python
variables. It’s also suspicious that setup doesn’t ask for a default
gateway or subnet mask…

Compare this to the older way of programming, using the
katcp_wrapper.FpgaClient -
https://github.com/UCBerkeleySETI/snap_control/blob/master/snap_control/katcp_wrapper.py#L242

   def 
config_10gbe_core(self,device_name,mac,ip,port,arp_table,gateway=1,subnet_mask=0xffffff00):
        """Hard-codes a 10GbE core with the provided params. It does a
blindwrite, so there is no verifcation that configuration was
successful (this is necessary since some of these registers are set by
the fabric depending on traffic received).
           @param self  This object.
           @param device_name  String: name of the device.
           @param mac   integer: MAC address, 48 bits.
           @param ip    integer: IP address, 32 bits.
           @param port  integer: port of fabric interface (16 bits).
           @param subnet_mask  integer: Subnet mask (32 bits).
           @param arp_table  list of integers: MAC addresses (48 bits ea).
           """
        ctrl_pack=struct.pack('>QLLLLLLBBH',mac, 0, gateway, ip, 0, 0,
0, 0, 1, port)
        subnet_mask_pack=struct.pack('>L',subnet_mask)
        arp_pack=struct.pack('>256Q',*arp_table)
        self.blindwrite(device_name,ctrl_pack,offset=0)
        self.blindwrite(device_name,subnet_mask_pack,offset=0x38)
        self.write(device_name,arp_pack,offset=0x3000)

This is writing values to a control register after packing them into a
bytestring. If I’m right, the quickest way to fix the tutorial code is to
add this config_10gbe_core function, calling it as:

config_10gbe_core(fpga,gbe_rx.name,mac_base+13,ip_base+13,fabric_port,arp_table,gateway=1,subnet_mask=0xffffff00)

If this functionality is indeed missing, then it should really be added
ASAP as it’s pretty fundamental. I’ve created a fork of casperfpga with a
possible implementation, up at https://github.com/telegraphic/casperfpga/.This
adds a gateway+subnet mask to the setup call, and then adds a
configure_core() function to communicate with the FPGA, e.g.

r = casperfpga.CasperFpga(PI_IP, 7147)

...

r.gbes.gbe1.setup(mac, ipaddress, port, gateway, subnet_mask)
r.gbes.gbe1.configure_core()


Not sure this is the best way to do it, so subject to change/input. Also
not sure how/why this hasn’t been spotted before (maybe I’m looking at the
wrong code branch or something?).

Cheers,

Danny

On 9 October 2019 at 9:10:59 pm, 'Cedric Viou' via [email protected]
([email protected]) wrote:

Hi Casperites,

Thank you Jack for bringing up this subject.
I encountered some 10GbE issues with tutorial 2.
It could be a soft/firm/hard-ware version mismatch issue and I was
wondering if I could get some hints to fix it.

I did compiled and setup this version :
-
https://github.com/casper-astro/tutorials_devel/tree/workshop2019/roach2/tut_tge
- https://github.com/casper-astro/casperfpga

But I got little success with it:
- Data was flowing out (gbe0_tx_cnt was rapidly increasing), which is good.
- But no data was received (gbe1_rx_frame_cnt=0)
- Script died on 'gbe_tx.read_txsnap()' -> AttributeError: 'str' object has
no attribute 'read'

I was suspicious about my DAC/AOC cables but they seem fine since I can
wireshark the output stream on my server.
>From what I saw, the python script doesn't seem to have any effect on the
tx interface (keeps the default values) :
Ethernet II, Src: 12:34:56:78:00:00 (12:34:56:78:00:00), Dst:
MS-NLB-PhysServer-02_01 (02:02:00:00:00:01)
Internet Protocol Version 4, Src: 192.168.5.20, Dst: 192.168.10.13
User Datagram Protocol, Src Port: 10000, Dst Port: 60000

Any hints on that, please?


I'm also wondering if the gbe?_linkup led/registers are fully functionnal
since the leds are still ON when I pull the SFP cables from the cages and I
got those warnings after programming the FPGA:
WARNING:192.168.40.96:192.168.40.96:gbe0: odd register name gbe0_linkup
under Gbe block
WARNING:192.168.40.96:192.168.40.96:gbe1: odd register name gbe1_linkup
under Gbe block

Many thanks for your help,

Cedric


-- 
Cedric Viou <[email protected]>

Ingénieur de recherche

Station de Radioastronomie de Nançay,
Observatoire de Paris, PSL Research University, CNRS, Univ. Orléans, OSUC,
18330 Nançay, France
http://www.obs-nancay.fr/

phone : +33 (0) 248 51 8609
fax : +33 (0) 248 51 8318

www.openstreetmap.org/?mlat=47.381848&mlon=2.194415&zoom=18

-- 
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/56d039a9-adbf-51c4-ddd6-69f37a586f6a%40obs-nancay.fr.

-- 
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/CAAtMgqmivAKGRQUbEJC6-ESSHahKmrbQGF50ou9w3FQ40%2BL%3Dxw%40mail.gmail.com.

Reply via email to