Hi Cedric,

I having this same issue trying to get the 10 Gbe tutorial working with my 
ROACH2. I'm not quite sure how you fixed it. Are you able to share your fix?

Thanks,
Molly

On Monday, October 14, 2019 at 3:06:51 AM UTC-7 cedric.viou wrote:

> Hi Danny,
>
> Your first comment (about gbe.setup() doing no write access to the FPGA) 
> was actually a nice hint along with that puzzling commented 
> fpga.tap_start(....) underneath setup().
> I couldn't find any casperfpga.tap_start(...) but there is a 
> casperfpga.tengbe.TenGbe.tap_start() -> gbe_rx.tap_start() that seems to do 
> the actual configuration and got me to observe the stream to loop back on 
> my ROACH2 -> NICE!
>
> However, no trace of a default gateway or subnet mask… Do I really need 
> that anyway?
>
> Thank you for your suggestions about configuring the 10G.
> However, I'm afraid I don't know well enough the CASPER history and the 
> content of all modules to have an opinion about missing code and what 
> should be put back on the libs.
>
> All: Nowadays, what would be the "natural" way to fully configure a TenGbe 
> with casperfpga, please?
> I'd be more than happy to sum this up in an update to tutorials_devel.
>
> Cheers,
>
> Cedric
>
>
>
> Le 09/10/2019 à 13:04, Danny Price a écrit :
> > 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 
> > <http://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] <mailto:[email protected]> (
> [email protected] <mailto:[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] <mailto:[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 <
> http://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] <mailto:[email protected]>" 
> group.
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an email to [email protected] <mailto:
> casper%[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
> .
> > 
>
> -- 
> 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/70f96b38-9f9e-462d-8a0b-9168863f02cen%40lists.berkeley.edu.

Reply via email to