WARP Project Forums - Wireless Open-Access Research Platform

I check the source code you delieverd:

​Mango_802.11_RefDes_v1.1.0.zip: There is NO /rx_sigs folder in Mango_802.11_RefDes_v1.1.0.zip\pcores\wlan_phy_rx_pmd_axiw_v2_04_g\mdlsrc
​Mango_802.11_RefDes_v1.0.0.zip: There is a /rx_sigs folders in Mango_802.11_RefDes_v1.0.0.zip\pcores\wlan_phy_rx_pmd_axiw_v2_04_d\mdlsrc

I think you maybe forget the /rx_sigs folder in the latest release　v1.1.0.

You can copy the rx_sigs folder from We use the mdlsrc folder to save a copy of the .mdl and .m files necessary to re-generate the pcore. The rx-sigs folder is only used in simulation, so we don't usually copy it to mdlsrc. You can always get the current rx_sigs folder from /ReferenceDesigns/w3_802.11/sysgen/wlan_phy_rx_pmd in svn.

I cannot understand the meaning of PPDU_words. Why PPDU_words is generated according to MAX_NUM_BYTES, rather the actual payload length?

The Tx PHY implements a read-only interface for the BRAM which provides the packet buffers. The actual BRAM is external to the PHY; the XPS project instantiates a dedicated bram_block for the Tx packet buffers. Because this BRAM is external it is not available for simulation of the Tx PHY model. Thus the Tx PHY model implements a simulation-only memory block that contains the packet payload specified in the .m init file. This block is in the 'Bit Source/BRAM IF 64b/Sim RAM' subsystem.

The sim-only RAM mimics the BRAM interface- it accepts a byte address on an 8-byte boundary and outputs the corresponding 8-byte word 1 cycle later. The RAM contents are initialized by the variable PPDU_words. PPDU_words has length (MAX_NUM_BYTES/8) - the max number of 64-bit words in a packet buffer. The init script creates the PPDU_words array from the user-specified packet payload and pads the rest with zeros. The reshaping is required to transform the user-specified array of payload bytes into an array of 8-bytes words. This reshaping is only required for simulation.

(3) in wlan_phy_rx_pmd/MAC Outputs:
What is the difference between DSSS_SIGNAL_LENGTH and OFDM_SIGNAL_LENGTH?

The Rx PHY implements two Rx pipelines- DSSS and OFDM. The DSSS pipeline only processes 1Mb receptions, typically management frames from Wi-Fi clients. The OFDM pipeline handles all OFDM receptions. The Rx pipelines share the packet buffer interface and MAC control outputs. Only one pipeline is active at any given time. The mux above selects which LENGTH value (OFDM or DSSS) drives the SIG_LENGTH output to the MAC. There are similar muxes for the other MAC outputs and the packet buffer interface logic.

What is the meaning of RX_END_OFDM_LAST_SAMP?

This is an internal control signal that asserts when the Rx PHY has processed the final sample of an OFDM reception. The control logic above uses this signal to switch between DSSS and OFDM control of the MAC outputs.

The Tx PHY starts when the MAC core asserts the PHY_TX_START output. The Tx PHY runs until it has processed the specified number of bytes. In normal operation this number is set by the SIGNAL.LENGTH field. When the Tx PHY finishes processing the last byte it asserts the MAC's PHY_TX_DONE input. The Tx duration is never explicitly calculated- the Tx PHY runs as long as necessary to generate the waveform for the specified rate and length.

The Rx PHY operation is similar- it starts when a new packet is detected. It attempts to decode the SIGNAL field. If a valid SIGNAL field is found, the Rx PHY runs until SIGNAL.LENGTH bytes have been decoded. Again, the duration is not calculated explicitly- the Rx pipeline just runs until it is finished. The PHY notifies the MAC core of its status via the PHY_RX_START and PHY_RX_END signals.

The MAC core controls switching between Tx and Rx modes. The MAC core uses the Tx/Rx status signals described above to manage the mode switches. The actual control the radio hardware is implemented in the Tx PHY 'Start Ctrl' subsystem. The RC_USR_RXEN and RX_USR_TXEN* signals drive the radio_controller core's Tx/Rx enables to set the mode of the corresponding MAX2829 transceivers.

Now I implemented the JUMBO TX function into the wlan_phy_tx_pmd_axiw successfully. And the simulation result of simulink showed that the TX pcore can work correctly to generate JUMBO messages.



Corresponding JumboTx register parameters have been generated in xparameters.h, and related macros are added into the .c files, and I can use C code to control the ON/OFF of JUMBO mode successfully. However, I found that WARP cannot transmit anything in JUMBO *Enable* mode.

Reason 1:
All the USRP and WARP are set to the same frequency. I applied one USRP to plot the radio raw sample, no matter it is 802.11 standard waveform or not, USRP can plot the waveform of the radio raw sample.
1-1) this USRP can detect the *JUMBO* radio waveform transmitted from other USRP successfully
1-2) this USRP can detect the transmitted WARP radio waveform when WARP is in JUMBO disable mode.
       However, this USRP detect nothing in the air when WARP is in JUMBO *enable* mode, it seems no data is transmitted.

Reason 2:
I also applied two WARP, one as AP, one as STA. It showed that AP-STA can associate successfully (as control/management messages are in JUMBO disable mode), but they did not transmit anything in JUMBO *Enable* mode, even I set the JUMBO payload into 1400 bytes or less.

As the simulink result showed pcore can generate JUMBO messages, and I can control the ON/OFF of JUMBO mode in C source code, then why WARP cannot transmit anything in JUMBO *enable* mode? Will the MAC impact the transmission? Do you have any ideas about this? Thanks.

P.S. We really wanna use WARP for future research, as USRP cannot realize real-time TX/RX verification... We tested WARP JUMBO reception function, and the result showed that WARP JUMBO reception function can receive standard 802.11 packets and USRP JUMBO packets successfully, even if we ignore the SIGNAL_LENGTH field. Now the problem is WARP JUMBO transmission side can not work correctly...

Last edited by Tomi (2015-Jan-14 02:47:07)

Thanks for your reply.

Changes I have made to the C code base are in wlan_mac_low_nomac(CPU_LOW), there is NO changes made in wlan_mac_high_ap or wlan_mac_high_sta (CPU_HIGH). And wlan_phy_set_tx_signal() is called in JUMBO TX mode.

For JUMBO TX, chaneges made to the C code are:

In wlan_phy_util.h:

#define WLAN_TX_REG_JUMBO_PKT_LEN_MASK        0xFFFFF //bit [0:19]
#define WLAN_TX_REG_JUMBO_EN                            0x80000000 //bit [31]

//Register renames
#define WLAN_TX_REG_JUMBO            XPAR_WLAN_PHY_TX_MEMMAP_JUMBOTX_CONFIG

//PHY Macros
//regTx_SIGNAL_MAX_LENGTH_KB  bit [8:17]
#define wlan_phy_tx_set_max_pkt_len_kB(d) Xil_Out32(WLAN_TX_REG_CFG, (Xil_In32(WLAN_TX_REG_CFG) & ~WLAN_TX_REG_CFG_MAX_PKT_LEN_MASK) | (((d) << 8) & WLAN_TX_REG_CFG_MAX_PKT_LEN_MASK))

//bit [0:19]
#define wlan_phy_tx_set_jumbo_pkt_len_kB(d) Xil_Out32(WLAN_TX_REG_JUMBO, (Xil_In32(WLAN_TX_REG_JUMBO) & ~WLAN_TX_REG_JUMBO_PKT_LEN_MASK) | (((d) << 0) & WLAN_TX_REG_JUMBO_PKT_LEN_MASK))

In wlan_phy_util.c:

void wlan_phy_init() {

    //Assert Tx and Rx resets
    ......

    /************ PHY Rx ************/

    //Enable DSSS Rx by default
    ......

    //Set the max Tx packet sizes
    wlan_phy_tx_set_max_pkt_len_kB(10);

    //Set the payload size of jumbo packet
    wlan_phy_tx_set_jumbo_pkt_len_kB(4);
    ......

In wlan_mac_nomac.c:

int frame_transmit(u8 pkt_buf, u8 rate, u16 length, wlan_mac_low_tx_details* low_tx_details) {
    //This function manages the MAC_DCF_HW core.

    ......

    //Write the SIGNAL field (interpreted by the PHY during Tx waveform generation)
    wlan_phy_set_tx_signal(pkt_buf, rate, length);

    mac_header_80211* header = (mac_header_80211*)(TX_PKT_BUF_TO_ADDR(pkt_buf) + PHY_TX_PKT_BUF_MPDU_OFFSET);
    if((header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_DATA){
        REG_SET_BITS(WLAN_TX_REG_JUMBO, WLAN_TX_REG_JUMBO_EN);//Enable JumboTx
        xil_printf("TX jumbo length %d\n\r", length);
    } else{
        REG_CLEAR_BITS(WLAN_TX_REG_JUMBO, WLAN_TX_REG_JUMBO_EN);//Disable JumboTx
        xil_printf("TX length %d\n\r", length);
    }

    ......

    //Wait for the MPDU Tx to finish
    do{
      ......
       
    } while(tx_status & WLAN_MAC_STATUS_MASK_MPDU_TX_PENDING);

    REG_CLEAR_BITS(WLAN_TX_REG_JUMBO, WLAN_TX_REG_JUMBO_EN);//Disable JumboTx

    return -1;

}

There is no other chaneges made to the C code for JUMBO TX.

Last edited by Tomi (2015-Jan-15 08:31:36)

//NEW CODE
#define WLAN_TX_SIGNAL_CALC(rate, length) (((rate) & 0xF) | (((length)&0xFFF)<<5) | (WLAN_TX_SIGNAL_PARITY_CALC(rate,length)))
#define WLAN_TX_SIGNAL_PARITY_CALC(rate, length) ((0x1 & (ones_in_chars[(rate)&0xF] + ones_in_chars[(length)&0xFF] + ones_in_chars[((length)&0xF00)>>8]))<<17)

Thanks for your reply. I changed the WLAN_TX_SIGNAL_PARITY_CALC(rate,length) macro, but it doesn't work.

If this does not fix the issue, it would be helpful to know results from a few other tests:
-Do you see the same behavior for other rates?
-What about other lengths? Try varying the length ±8 bytes in steps of 1 byte.
-Does the node transmit if you enable JumboTx but specify a short jumbo length? If so, what is the largest jumbo length that works?

I tested different rates and lengths, the results are all the same. It seems no data transmitted in the air. No matter how long I set the jumbo length, 1K or 2K or 3K, there is still no transmitted data.

As there is totally no data transmitted in jumbo mode, I doubt there is something leading the Tx PHY pipeline to reset immediately. However, in simulink simulation, the output shows jumbo message can be generated successfully...

-Do you see any activity on the Tx LED (green LED near RF A) when your code is attempting transmission? Try enabling a fully-backlogged traffic flow and observing the LED- I would guess it is blinking very briefly per Tx.

Eight LEDs (4 green, 4 red) are arranged in 2 columns in the user I/O section of the board. Both the green and the red ones are blinking.

RF A is used.
Two LEDs (1 red, 1 green) are mounted near the RF A interfaces. Only the red one is on, and the green one is always off.

Last edited by Tomi (2015-Jan-19 08:59:37)