Transfer data through Ethernet in WRPC

Dear all,

We are making WRPC work on our hardware platform, which is based on Kintex-7.

Thank you for your help, and we have made it work.

Now, we want to transfer data through the Ethernet(use the SFP module) .

I got some information from the user manual:

1.     "If built with CONFIG_IP=y, wrpc-sw implements the following udp-based network services"---from Netwrok Service;

2.    "all the traffic from VIDs 10, 11, 20 is forwarded and available on the WR PTP Core external fabric interface."--from VLAN Support;

So I do an “echo test” as follow:

1. In FPGA design(wr-core and wrpc-sw):

    1.1    WRF Source is connected to WRF Sink directly;

    1.2    g_fabric_iface => PLAIN;

    1.3    VLAN is on;

    1.4     configure the IP manually;

2. In PC:

    2.1     install VLAN module to make PC send the VLAN frame, and configure the VID to 10, which has been confirmed by wireshark;

    2.2     add the IP and MAC address to the ARP list;

    2.2     send test data through UDP(I'm not sure what the port is, and I set it to 123);

    2.3     monitor the data flow by wireshark(Enable promiscuous mode);

Screenshot%20from%202019-02-24%2018-39-52
I think wireshark will get some information from the VLAN interface, if everything is right.

However, there is nothing from the VLAN interface.

How can I finish the “echo test” through UDP?

Is my understanding incorrect?

Thank you!

Best,

wei

Hi Wei,

to loopback your traffic it’s not enough to short WRF Source with Sink, you also need to swap destination with source MAC address for each received frame.

For such a simple test you can connect xwrf_loopback HDL module (modules/fabric/xwrf_loopback in wr-cores repository) to WRF Source and WRF Sink. It does MAC swapping and also exposes some configuration registers and counters where you can enable/disable loopback, see how many frames were forwarded etc. I wrote it some time ago to stress-test WRPC.

Cheers,
Greg

Hi greg,

Thank you for your reply.
I have tried xwrf_loopback HDL module as you mentioned(it was added in xwrc_board_clbv2.vhd):
cmp_xwrf_loopback: xwrf_loopback
generic map(
g_interface_mode => CLASSIC,
g_address_granularity => WORD)
port map(
clk_sys_i => clk_pll_62m5,
rst_n_i => rst_62m5_n,
wrf_snk_i => wrc_frabic_src_o,
wrf_snk_o => wrc_frabic_src_i,
wrf_src_o => wrc_frabic_snk_i,
wrf_src_i => wrc_frabic_snk_o,
wb_i => wrc_aux_master_o,
wb_o => wrc_aux_master_i);
However, I still didn’t get any reply from our board,which is based on Kintex-7 and referred to CLBV2. wireshark got the information as follow:
Screenshot%20from%202019-02-27%2010-54-24
The NTP data frame is sent by me, and other LLDP data frame is replied by our board continuously.
I don’t know what happened…what may cause it?

Thank you!

best,
wei

Hi greg,

you mentioned:
“there are some configuration registers and counter where you can enable/disable loopback, see how many frames were forwarded etc.”
So do I need to configure these registers for enabling loopback?
How can I configure them?

Thank you!

best,
wei

Hi Wei,

yes, there is a configuration bit (MCR_ENA) that you need to set to enable the loopback function. The configuration registers are accessible through wishbone interface of the loopback module. Alternatively you can modify its sources to have it always enabled:

diff --git a/modules/fabric/xwrf_loopback/xwrf_loopback.vhd b/modules/fabric/xwrf_loopback/xwrf_loopback.vhd
index ec423dde..2bc4d60d 100644
--- a/modules/fabric/xwrf_loopback/xwrf_loopback.vhd
+++ b/modules/fabric/xwrf_loopback/xwrf_loopback.vhd
@@ -249,9 +249,9 @@ begin
         
         case lbk_rxfsm is
           when IDLE =>
-            if(regs_fromwb.mcr_ena_o='1' and wrf_snk_i.cyc='1' and ffifo_full='0' and sfifo_full='0') then
+            if(wrf_snk_i.cyc='1' and ffifo_full='0' and sfifo_full='0') then
               lbk_rxfsm <= PAYLOAD;
-            elsif(regs_fromwb.mcr_ena_o='1' and wrf_snk_i.cyc='1') then
+            elsif(wrf_snk_i.cyc='1') then
               drp_cnt_inc <= '1';
               lbk_rxfsm <= DROP;
             end if;

Hi greg,

Thank you so much!

I found this bit yesterday afternoon, and I made the changes as follow:

  1. replace “regs_fromwb” to “regs_fromwb_fake” on the HDL module U_WB_SLAVE, and set the related bits of regs_fromwb to ‘1’. I think the loopback is enable.
    U_WB_SLAVE: lbk_wishbone_controller
    port map(
    rst_n_i => rst_n_i,
    clk_sys_i => clk_sys_i,
    wb_adr_i => wb_in.adr(2 downto 0),
    wb_dat_i => wb_in.dat,
    wb_dat_o => wb_out.dat,
    wb_cyc_i => wb_in.cyc,
    wb_sel_i => wb_in.sel,
    wb_stb_i => wb_in.stb,
    wb_we_i => wb_in.we,
    wb_ack_o => wb_out.ack,
    wb_stall_o => wb_out.stall,
    regs_i => regs_towb,
    regs_o => regs_fromwb_fake);

regs_fromwb.dmac_h_o <= regs_fromwb_fake.dmac_h_o;
regs_fromwb.dmac_l_o <= regs_fromwb_fake.dmac_l_o;
regs_fromwb.dmac_h_load_o <=‘1’;
regs_fromwb.mcr_ena_o <= ‘1’;
regs_fromwb.mcr_fdmac_o <=‘1’;

(it’s in xwrf_loopback.vhd)

  1. check the generic map of HDL module cmp_board_common in xwrc_board_clbv2.vhd, and found:
    g_interface_mode => PIPELINED,
    g_address_granularity => BYTE,
    so I change the generic map of HDL module cmp_xwrf_loopback(I added it in xwrc_board_clbv2.vhd):
    cmp_xwrf_loopback: xwrf_loopback
    generic map(
    g_interface_mode => PIPELINED,
    g_address_granularity => BYTE)
    port map(
    clk_sys_i => clk_pll_62m5,
    rst_n_i => rst_62m5_n,
    wrf_snk_i => wrc_frabic_src_o,
    wrf_snk_o => wrc_frabic_src_i,
    wrf_src_o => wrc_frabic_snk_i,
    wrf_src_i => wrc_frabic_snk_o,
    wb_i => wrc_aux_master_o,
    wb_o => wrc_aux_master_i);

(Is the port map above right? wrf_snk_i=>wrc_frabic_src_o and so on)

After that, I tested it, and used wireshark to monitor the ethernet interface of my PC.
I found the board sent LLDP frame to my PC periodically(about one frame per second ).

When I sent UDP frame to the board with VID=10, the board still had no response.(I think the loopback is enable, and we can get what we sent).

Is there anything wrong with the periodical LLDP frame from the board?
or does the board wait for some response from my PC?

Thank you again!

best,
wei

Actually you should only drive mcr_ena_o <= ‘1’ the rest of the bits (dmac_h_load_o and mcr_fdmac_o) shall be left at ‘0’ - they are used if you would like to force some arbitrary destination MAC address for your looped back frames.
Please see https://ohwr.org/project/wr-cores/blob/proposed_master/modules/fabric/xwrf_loopback/doc/xwrf_loopback.html for the description of registers.

By default vlans are compiled-in but turned off when WRPC starts (for backwards compatibility). This might be a reason why your VID=10 traffic is dropped. I’m sorry if the manual is confusing in this regard, we’ll improve it. You can enable VLANs using WRPC shell command “vlan set” e.g. “vlan set 1”.
You can also send some regular (untagged) frames to see if loopback works for them.

Hi greg,

Thank you for your reply!

  1. i have set mcr_ena_o to ‘1’, and other bits to ‘0’.
  2. VLAN is enable.
    I still got no response.
    I sent udp frames with python, and make the frames go through VLAN interface of my PC.
    I got the LLDP frames like this, and I thought wireshark recognized VLAN frames:
    Screenshot%20from%202019-02-28%2015-54-31
    Is there anything wrong with it?

you suggested me to send some regular frames.
How does wrpc know that the frames are sent to frabic interface with out VID?
The user manual doesn’t give any information about it…

Thank you.

best,
wei

Hi greg,

Thank you so much!

It works now!
I tried to recompile the wrpc-sw to make vlan on by default before, but it seems I made some mistakes with it.
I used the wrc_phy16.bram, and it works now!
Thank you for your help!

Could you please tell me where I can the source code of wrc_phy16.bram?
Maybe we need to make some change on it.
Thank you very much!

best,
wei

Hi Wei,

I’m glad you made it working! Regarding the *.bram files, these are all compiled from the same sources stored in wrpc-sw repository. The only difference between wrc_phy8.bram and wrc_phy16.bram is that the latter is compiled for 16-bit PCS (“Compile for 16-bit PCS” option is enabled is .config). All the rest configuration options are identical.

Cheers,
Greg

Hi greg,

I use menuconfig, and select compile for 16-bit PCS.
It works!
Screenshot%20from%202019-03-01%2010-44-30
Thank you so much!

best,
wei