Christian, CHDR packets are encapsulated in UDP/IP between Host and USRP. See the attachment.
PHY+ MAC functionality live under the x300_sfpp_io_core. However these blocks do not encapsulate/decapsulate the network packets. All the ethernet/IP/UDP framing fields are added by chdr_eth_framer on egress, and will be removed on ingress by etc_dispatch (if needed). -Ian
protocol_layout_64bit_v3.pdf
Description: Adobe PDF document
> On Nov 5, 2017, at 5:55 AM, Christian Lenz via USRP-users > <usrp-users@lists.ettus.com> wrote: > > Hey Sugandha, > > thanks for your help. I apologize for the incredible delay from my > side, but back to my question. > > We want to port a hole IP solution from some proprietary hardware to > the USRP and evaluate the costs (mainly development time) of migrating > our IP to RFNoC vs. a custom image. > The crux is, we already have a complete implementation of both FPGA > infrastructure (mostly auto-generated VHDL) and the corresponding > software running on a connected PC. However, on the currently used > hardware platform, the PC is connected via USB. > That's why I'm interested in the effort to get the Ethernet connection > running. > > 1. You wrote that eth_dispatch and chdr_eth_framer blocks handle MAC, > IP etc., but I thought we are only talking about PHY+MAC > implementation. So does the Ethernet Core actually implement IP layer > too? > 2. For the packte based communication you said that as long as it is a > chdr paket, the FPGA would handle it. The structure of such a chdr > paket can be found here: > http://files.ettus.com/manual/page_rtp.html#rtp_chdr. Related to point > 1, the chdr structure must be present in the payload of an Ethernet > frame or is this already the (adapted) Ethernet frame structure itself? > Do you know if i can transmit a chdr paket to the USRP utilizing a so > called "Raw-Ethernet socket" (what seems to be a solution for > MAC-layer Ethernet communication w/o TCP/IP). For isntance, raw > ethernet sockets are availably in Python. > 3. Is the code of the UHD part available that interfaces the network > device and drops of the chdr pakets? > > Thanks again, > Christian > > Zitat von Sugandha Gupta <sugandha.gu...@ettus.com>: > >> Hi Christian >> >> It would be good if you could explain your application and need to have a >> custom image. From your questions, it looks like you would be redoing a lot >> of the infrastructure already present in the X3x0. In your application, if >> you want to add new blocks to the existing code to offload SW tasks, you >> can use the existing RFNoC framework >> <https://kb.ettus.com/Getting_Started_with_RFNoC_Development>. >> >> See inline for the answers. >> >> Let me know if you have any further questions. >> >> Cheers >> Sugandha >> >> >> On Tue, Apr 4, 2017 at 6:54 AM, Christian Lenz via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Hi, >>> >>> I’m currently evaluating the effort/feasibility of running a custom FPGA >>> image in a USRP X3x0. One thing left is the connection Host PC <—> FPGA >>> to exchange control/status information (neither high throughput nor low >>> latency needed here). >>> To achieve this, I have the idea of using the provided IP to interface one >>> of the SFP+ ports on the FPGA side and connect to a host PC using the SFP 1 >>> Gigabit Ethernet Interface Kit. >>> Related to this are the following questions: >>> >>> 1. I traced down the signals, beginning from the SFP+ FPGA pins. The main >>> ethernet functionality (PHY+MAC) is included in the ‘x300_sfpp_io_core’, >>> correct? >>> >> >> Yes. >> >>> Additionally, do I need to incorporate also the ‘eth_interface’ included >>> in ‘x300_core/bus_int’, which somehow translates the AXI data streams >>> coming from the ‘x300_sfpp_io_core’? >>> >>>> The eth_interface has 2 parts >> - eth_dispatch - It routes the incoming packets appropriately based on >> the MAC, IP, chdr (or not?), etc. >> - chdr_eth_framer - It re-constructs the chdr packets coming back >> from the crossbar -> adds the MAC and IP. >> So, I guess you would need it. >> >>> >>> 2. I want to use the ‘x300_sfpp_io_core’ for a single SFP+ port with >>> protocol “1GbE”. I did found all the required source files except for the >>> modules ‘one_gig_eth_pcs_pma_support’, located in the ‘one_gige_phy’ and >>> the ‘axi64_8k_2clk_fifo’, located in the ‘simple_gemac_wrapper’. There are >>> only some references in related makefiles but I can not find the verilog >>> source files where the modules are described in. Am I misleaded at some >>> point? >>> >>>> These files are generated during the build process. >> Look in : >> <fpga-repo>/usrp3/top/x300/build-ip/<part-number>/one_gig_eth_pcs_pma_example/one_gig_eth_pcs_pma_example.srcs/sources_1/imports/example_design/support/* >> >> >>> 3. This question may also apply to the plain UHD FPGA design: Let’s assume >>> I get the SFP+ core running within my custom FPGA design. How do I >>> communicate with the FPGA using an ethernet-connected host PC? >>> >>>> That is what you have a existing UHD code for. >> >> Since the provided cores included in ‘x300_sfpp_io_core’ implement PHY + >>> MAC functionalities, do I need additional cores to implement IP and TCP/UDP >>> or in which way do you transfer data between Host and FPGA using Ethernet >>> (see also my question 1.)? The target would be to establish a packet based >>> communication over Ethernet and having AXI streams for sending/receiving on >>> the FPGA side. >>> >> >> If it is a chdr packet, then the current FPGA design handles it. >> >>> >>> Hopefully, my questions are not too far away from the oridnary USRP use >>> case. >>> >>> Thanks for the help, >>> Christian >>> >>> _______________________________________________ >>> USRP-users mailing list >>> USRP-users@lists.ettus.com >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >>> >> >> >> -- >> Sugandha Gupta >> Staff Software Engineer >> Ettus Research > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
