WARP Project Forums - Wireless Open-Access Research Platform

You are not logged in.

#1 2017-Mar-20 00:56:55

harryzwh
Member
Registered: 2016-Jul-04
Posts: 8

Using both ETH_A and ETH_B in WARPLab Ref

Hi

I am not considering reduce the latency by using both ETH_A and ETH_B for IQ samples transmission (i.e. ETH_A handle RFA and RFB only and ETH_B handle RF_C and RF_D) when using WARPLab reference design 7.7.0. In the original wl_common.h, only WL_USE_ETH_A  is set to 1 while WL_USE_ETH_B is 0 which means only ETH_A is used.

My question is

1) To use both ETH_A and ETH_B in the same time, can I simply set WL_USE_ETH_B to 1? Assuming I can modify the M-code so that it can communicate with subnet 10.0.1.x as well.

2) In addition to the modification in 1), is there any further modifications are needed? For example, changing the addresses of buffer and DMA when moving data from Ethernet cache to the main memory.

3) Is the design of ETH_B identical to ETH_A? For example, support the same packet size of jumbo frame, have the same buffer length and so on.

Thanks and regards

Offline

 

#2 2017-Mar-20 09:55:50

chunter
Administrator
From: Mango Communications
Registered: 2006-Aug-24
Posts: 1212

Re: Using both ETH_A and ETH_B in WARPLab Ref

The WARP IP/UDP library supports using both ETH_A and ETH_B, but we have never used both simultaneously (ETH_A is used for the WARPLab Reference Design and ETH_B is used for the 802.11 Reference Design).

Using both to form a link aggregate is feasible, but would require substantial changes on both the C side as well as the Mex transport side on the host PC.

Offline

 

#3 2017-Mar-26 21:34:52

harryzwh
Member
Registered: 2016-Jul-04
Posts: 8

Re: Using both ETH_A and ETH_B in WARPLab Ref

chunter wrote:

The WARP IP/UDP library supports using both ETH_A and ETH_B, but we have never used both simultaneously (ETH_A is used for the WARPLab Reference Design and ETH_B is used for the 802.11 Reference Design).

Using both to form a link aggregate is feasible, but would require substantial changes on both the C side as well as the Mex transport side on the host PC.

Thanks Chunter.

I have modified the C code so that both ETH_A(10.0.0.1) and ETH_B(10.0.1.1) can respond to PING command and I want to use ETH_A to handle the sample transmission of RF_A and RF_B while  ETH_B to handle RF_C and RF_D
However, only one of the ETH will respond to WARPLab commands and it depends on the sequence of initialization. i.e. if I init ETH_A then ETH_B by using

Code:

if (WL_USE_ETH_A) {
        status = transport_init(WL_ETH_A, init_transport);
        init_transport = 0|WL_USE_ETH_B;
    }

    if ((status == XST_SUCCESS) && WL_USE_ETH_B) {
        status = transport_init(WL_ETH_B, init_transport);
        init_transport = 0;
    }

then only ETH_B can respond to WARPLab commands while if init ETH_B first

Code:

if (WL_USE_ETH_B) {
        status = transport_init(WL_ETH_B, init_transport);
        init_transport = 0|WL_USE_ETH_A;
    }

    if ((status == XST_SUCCESS) && WL_USE_ETH_A) {
        status = transport_init(WL_ETH_A, init_transport);
        init_transport = 0;
    }

then only ETH_A can respond to WARPLab commands.

Since both ETH interfaces respond to PING command, that means the basic UDP/IP functions are enabled for both interfaces. Could you tell me where I should modify further? I guess there should be a variable that records only one device ID while the packets from another interface will be dropped when they are passed to the application layer. Or  do you use another mechanism to avoid illegal packets in application layer?

Offline

 

#4 2017-Mar-27 10:14:12

murphpo
Administrator
From: Mango Communications
Registered: 2006-Jul-03
Posts: 5159

Re: Using both ETH_A and ETH_B in WARPLab Ref

We have never built the dual-interface WARPLab extension you're describing, so we cannot provide step-by-step instructions. I would guess it's related to the 'init_transport' argument, which (when 1) triggers the initialization of the IP/UDP library via warp_ip_udp_init(). The library should only be initialized once per boot.

Offline

 

Board footer