WARP Project Forums - Wireless Open-Access Research Platform

Tomi · 2014-Nov-25 00:12:34

In 802.11 PHY-layer specifications, the largest frame size of 802.11 is 64KB. Can current WARP platform support this payload size?

The LTG payload size can be defined in python program. And I checked the MAC layer C source code, and found in wlan_mac_entries.h, there is a sentence:
#define MAX_MAC_PAYLOAD_LOG_LEN 1500
This defines the maximum payload which will be recorded.

If I do following modifications:
in wlan_mac_entries.h
#define MAX_MAC_PAYLOAD_LOG_LEN 64000
in Mango_802.11_RefDes_v1.0.0\Python_Reference\wlan_exp\ltg.py
LTG_PYLD_MAX = 64000

can I use node1.ltg_configure(wlan_exp_ltg.FlowConfigCBR(node2.wlan_mac_address, 64000, 0, 0), auto_start=True) to realize a 64KB frame size?

If I want to make currrent WARP to support even higher payload, e.g. 512KB, 1024KB, what kind of midofication do I need to do? Thanks.

Last edited by Tomi (2014-Nov-25 00:13:25)

murphpo · 2014-Nov-25 07:45:12

The current version of our PHY supports payloads up to 2048 bytes.

The 802.11a/g spec supports MPDUs up to 2048 bytes. Larger payloads are specified for 11n/ac.

murphpo · 2014-Nov-25 07:50:53

If I want to make currrent WARP to support even higher payload, e.g. 512KB, 1024KB, what kind of midofication do I need to do? Thanks.

These are very large payloads, probably not a good idea with the current PHY implementation. A few problems I can think of:
-The Rx equalizer uses channel estimates generated from the preamble. The estimates are not updated during the reception. For a very long-duration reception the actual channel coefficients will change. Some kind of channel estimate tracking would be required for good performance.
-The Rx CFO correction assumes the CFO is constant across a single reception. This is a very reasonable assumption for normal packet lengths at the 802.11a/g rates. But for much longer duration packets the CFO is likely to change (oscillator drift, Doppler changes). A more sophisticated CFO tracking scheme would be required.
-Our Rx PHY does not currently implement any sampling frequency offset correction. This is no problem for normal duration receptions - the impact of SFO is negligible over short time scales. But you would definitely need SFO correction for very long receptions.

Can you describe why your experiment requires such long packet payloads? Maybe we can help with alternate approaches that would facilitate the same measurements.

Tomi · 2014-Nov-25 09:16:31

murphpo wrote:
The current version of our PHY supports payloads up to 2048 bytes.
The 802.11a/g spec supports MPDUs up to 2048 bytes. Larger payloads are specified for 11n/ac.

Thanks for your reply. So if I want to make current WARP to support payload size defined in 11n/ac. What kind of modification should I make?

Except four WARPs, we also have two USRP (Universal Software Radio Peripheral), which can support 11n/ac. Current evaluation work showed that 64KB payload can be well supported by USRP. We want to check whether 64KB payload is also well supported by WARP.

Tomi · 2014-Nov-25 09:21:33

murphpo wrote:
If I want to make currrent WARP to support even higher payload, e.g. 512KB, 1024KB, what kind of midofication do I need to do? Thanks.
These are very large payloads, probably not a good idea with the current PHY implementation. A few problems I can think of:
-The Rx equalizer uses channel estimates generated from the preamble. The estimates are not updated during the reception. For a very long-duration reception the actual channel coefficients will change. Some kind of channel estimate tracking would be required for good performance.
-The Rx CFO correction assumes the CFO is constant across a single reception. This is a very reasonable assumption for normal packet lengths at the 802.11a/g rates. But for much longer duration packets the CFO is likely to change (oscillator drift, Doppler changes). A more sophisticated CFO tracking scheme would be required.
-Our Rx PHY does not currently implement any sampling frequency offset correction. This is no problem for normal duration receptions - the impact of SFO is negligible over short time scales. But you would definitely need SFO correction for very long receptions.

Can you describe why your experiment requires such long packet payloads? Maybe we can help with alternate approaches that would facilitate the same measurements.

As current WLAN are using small payload, we are trying to investigate the performance if WLAN system using very large payload. We already did some research on this topic. Now we need to implement and evaluate the research result. That's why I asked you this question.

I can understand your consideration. We already developed some strategies to overcome the CFO/SFO problem for large payload. Now we want to verify it on WARP. Though we have two USRP, we prefer to verify it on WARP. So the first step is to make WARP can support large payload, no matter the PER is good or not. After this step, we will implement our algorithm to decrease the PER.

Last edited by Tomi (2014-Nov-25 09:23:50)

murphpo · 2014-Nov-25 09:51:25

Apologies if my previous answer seemed dismissive- this was not my intent. It's great you've already considered these complications.

I have not attempted using very long payloads, but I can think of a few modifications that would be required:

-The Tx and Rx logic impose a maximum on the LENGTH value in the SIGNAL field. The maximum is programmable from software in increments of 1KB. The reference code sets both the Tx and Rx max to 2KB in wlan_phy_util.c with:

Code:

wlan_phy_rx_set_max_pkt_len_kB(2);
wlan_phy_tx_set_max_pkt_len_kB(2);

Those macros accept arguments in [1,15] (i.e. 4-bit non-zero value).

-In the 802.11 spec the LENGTH value in the SIGNAL field occupies 12 bits, limiting the maximum number of bytes to 4096. The Tx and Rx PHY logic use the LENGTH value to configure each Tx/Rx process. If you want to handle packets longer than 4096 bytes you need to modify the SIGNAL handling logic to interpret the LENGTH value differently. In 11n, for example, HT frames use the LENGTH value to specify the number of OFDM symbols.

-The Tx/Rx logic access the Tx/Rx packet buffers on 4KB boundaries. Each 4KB buffer is used for metadata (the tx_frame_info and rx_frame_info structs) and actual packet payloads. Thus the effective maximum payload is 4KB - sizeof(tx/rx_frame_info). To increase this you need to modify the packet buffer interfaces in the Tx/Rx models.

For Tx, look at the 'Bit Source/BRAM IF 64b' subsystem. The BRAM address is constructed from the current Tx bit address and the packet buffer index.

For Rx, look at the 'FCS & Pkt Buf/Pkt Buf Interface/BRAM IF 64b' subsystem. The address calculation is more complicated here, due to the PHY needing to write channel estimate values and received bytes for every frame. The 'pkt buf sel' input controls which packet buffer is accessed per Rx.

In both cases you need to reduce the number and increase the size of the packet buffers. The v1.0 design has 8 4KB buffers for Tx and 8 4KB buffers for Rx. For 4 8KB buffers each, for example, you would need to modify the Tx/Rx logic to use a 2-bit pkt buf sel value and use 1 extra bit for bit/byte addressing from the Tx/Rx pipelines.

Tomi · 2014-Nov-25 10:02:28

Thank you very much for your detailed reply. I will check those places and make corresponding modifications. If I have any problem, I will let you know. Thanks!

Tomi · 2014-Nov-28 08:29:07

With all the modifications, what will be the max length? It seems that the following modification at most expands length to 15 KB. Is my understanding correct?

murphpo wrote:
-The Tx and Rx logic impose a maximum on the LENGTH value in the SIGNAL field. The maximum is programmable from software in increments of 1KB. The reference code sets both the Tx and Rx max to 2KB in wlan_phy_util.c with:
Code:
wlan_phy_rx_set_max_pkt_len_kB(2);
wlan_phy_tx_set_max_pkt_len_kB(2);
Those macros accept arguments in [1,15] (i.e. 4-bit non-zero value).

murphpo · 2014-Nov-29 02:51:21

With all the modifications, what will be the max length? It seems that the following modification at most expands length to 15 KB. Is my understanding correct?

It depends on how you modify the packet buffer interfaces. In the v1.0 ref design the block RAMs used for Tx and Rx packet buffers are each 32KB. The ref design divides the 32KB into 8 4KB buffers. You could modify the PHY logic to access 1 32KB buffer.

Does your application require specific payloads in your long transmissions? If not, you might consider a different approach. You could modify the Tx PHY to ignore packet payloads in the RAM buffer and transmit packets of arbitrary length with "fake" payloads. You would probably want to use the packet buffer for the first 24 bytes to preserve valid MAC headers in your transmissions. But for bytes 25:end the PHY could stop reading the buffer and use a constant value. The scrambler would ensure the transmitted waveform was random-ish, even if most of the payload is constant. This modification would probably be easier than re-designing the interface between the PHY and packet buffers.

Tomi · 2014-Nov-30 05:29:52

It depends on how you modify the packet buffer interfaces. In the v1.0 ref design the block RAMs used for Tx and Rx packet buffers are each 32KB. The ref design divides the 32KB into 8 4KB buffers. You could modify the PHY logic to access 1 32KB buffer.

Sorry, I cannot understand this very well. I read the source code in wlan_phy_util.c:
//Set the max Tx/Rx packet sizes to 2KB (sane default for standard 802.11a/g links)
wlan_phy_rx_set_max_pkt_len_kB(2);
wlan_phy_tx_set_max_pkt_len_kB(2);

According to the above sentences, it seems that the max Tx/Rx packet sizes can be at most expanded to 15 KB under current WARP. I cannot understand why this will be related to packet buffer interfaces…

Does your application require specific payloads in your long transmissions? If not, you might consider a different approach. You could modify the Tx PHY to ignore packet payloads in the RAM buffer and transmit packets of arbitrary length with "fake" payloads. You would probably want to use the packet buffer for the first 24 bytes to preserve valid MAC headers in your transmissions. But for bytes 25:end the PHY could stop reading the buffer and use a constant value. The scrambler would ensure the transmitted waveform was random-ish, even if most of the payload is constant. This modification would probably be easier than re-designing the interface between the PHY and packet buffers.

In this situation, how can we do decoding and PER calculation? Thanks.

Last edited by Tomi (2014-Nov-30 05:33:17)

Tomi · 2014-Dec-01 05:10:29

Does your application require specific payloads in your long transmissions? If not, you might consider a different approach. You could modify the Tx PHY to ignore packet payloads in the RAM buffer and transmit packets of arbitrary length with "fake" payloads. You would probably want to use the packet buffer for the first 24 bytes to preserve valid MAC headers in your transmissions. But for bytes 25:end the PHY could stop reading the buffer and use a constant value. The scrambler would ensure the transmitted waveform was random-ish, even if most of the payload is constant. This modification would probably be easier than re-designing the interface between the PHY and packet buffers.

If we want to use the approach you suggested, how can we realize the "fake" payloads in Tx/Rx sides? What kind of modification should we do in this situation? Thanks.

murphpo · 2014-Dec-01 09:30:32

To transmit or receive a packet with >4096 bytes you must modify the Tx/Rx PHY cores to change:
(1) The limitation of the 12-bit LENGTH value in the SIGNAL field
(2) The 4KB divisions of the Tx/Rx pkt buffers

The best way to achieve this depends on your application.

For (1)- if you require arbitrary packet lengths which change per-packet, you must figure out a way to convey length information in the SIGNAL field. If your application only requires fixed packet lengths, it would be easier to add logic to the Rx PHY to ignore the SIGNAL.LENGTH field and use a pre-programmed length (probably configured via a new register controlled from CPU Low).

For (2)- if you require arbitrary packet contents for packets >4KB, you will need to modify the Tx/Rx PHY packet buffer interfaces to support payloads >4KB. If your application would work with a simpler payload (i.e. all zeros), it would be easier to add logic to the Tx/Rx PHY to ignore the packet buffer and send a constant value for bytes past the MAC header (byte indexes >24). An all-zero payload is safe from a waveform perspective, as the 802.11 standard scrambler will "whiten" the bit sequence fed into the modulation/IFFT blocks, avoiding PAPR issues.

In this situation, how can we do decoding and PER calculation? Thanks.

The Rx PHY will attempt to decode any packet with a valid SIGNAL field, and will view the last 4 bytes of the payload as a FCS (checksum). As long as the transmitted payload has a valid FCS you can use the existing Rx PHY FCS good/bad flags to determine whether the packet was received without bit errors. The Rx PHY does not care what the payload bytes are (actual MPDU, all zeros, random bytes, etc).

The Tx PHY logic calculates the 4-byte FCS during transmission and inserts the FCS into the outgoing payload automatically. The FCS calculation/insertion logic does not care what the payload bytes are or how long the payload is.

Tomi · 2014-Dec-03 08:09:26

The Rx PHY will attempt to decode any packet with a valid SIGNAL field, and will view the last 4 bytes of the payload as a FCS (checksum). As long as the transmitted payload has a valid FCS you can use the existing Rx PHY FCS good/bad flags to determine whether the packet was received without bit errors. The Rx PHY does not care what the payload bytes are (actual MPDU, all zeros, random bytes, etc).

The Tx PHY logic calculates the 4-byte FCS during transmission and inserts the FCS into the outgoing payload automatically. The FCS calculation/insertion logic does not care what the payload bytes are or how long the payload is.

Thanks for your reply. Now I'm working on creating a 64KB fake payload. As you suggested, I will use the packet buffer for the first 24 bytes to preserve valid MAC headers. And for bytes 25:end, I will make the PHY stop reading the buffer and use a constant value.

In this case, should I make modification on matlab code, or just on C code?

As the FCS calculation/insertion logic does not care what the payload bytes are or how long the payload is, I think I only need to modify the Tx side, and there is no need to modify the Rx side. Is my understanding correct? Thanks.

Last edited by Tomi (2014-Dec-03 08:11:21)

murphpo · 2014-Dec-06 12:15:23

Increasing the max packet size to >4KB will require changes to the wlan_phy_tx_pmd and wlan_phy_rx_pmd cores. You cannot achieve this change with only C/m changes.

Tomi · 2014-Dec-11 05:53:46

Thanks for your reply. Now I'm modifying wlan_phy_tx_pmd to realize 64KB fake payload.

wlan_phy_tx_pmd -> Bit source block -> Addr Gen block:

I want to modfify the structure here to make the PHY stop reading the buffer and use a constant value for bytes 25:end, but I cannot understand some of the values well. Would you please give me some information? Thanks.

(1)As illustrated in the figure, this step makes DATA starts at byte[8].
Why DATA should start from byte[8]?

(2)As illustrated in the figure, why "SIGNAL_LENGTH" needs to subtract 4 bit?

(3)What is the meaning of this step?

(4)As illustrated in the figure, what is the difference between "DATA" and "SIGNAL"? According to my understanding, 24 stands for the 24 bit SINGAL field of one OFDM symbol. Then the "DATA" here is the PSDU, which contains 24 bytes MAC header and the net the payload. Is it correct?

murphpo · 2014-Dec-12 10:11:56

This logic is defined by the layout of data in each Tx pkt buffer. Each pkt buffer is 4KB. The 8 buffers are implemented in a 32KB dual-port block RAM. One port is tied to the Tx PHY, the other to the AXI interconnect for CPU Low.

The layout of each 4KB pkt buffer (by byte index):

Index Size Desc
0 M tx_frame_info - MAC metadata for the Tx packet
M 8 PHY header - SIGNAL and SERVICE fields, with padding
M+8 * MPDU - Actual MAC payload

M here represents sizeof(tx_frame_info), the space occupied by the MAC metadata. The MAC configures the PHY to ignore this area of each pkt buffer via the 'wlan_phy_tx_pkt_buf_phy_hdr_offset(X)' macro. This macro configures the Tx PHY logic to use 'X' as the base address for accessing the PHY header and MAC payload. The PHY does not access the metadata (the tx_frame_info).

The PHY header contains the 3-byte SIGNAL field and 2-byte SERVICE field, each padded to 4 bytes.

The MPDU contains the full MAC payload, starting at the first byte of the MAC header (typically the frame_control_1 byte).

The MAC payload also includes 4 placeholder bytes for the FCS. The SIGNAL.LENGTH field specifies the total number of bytes in the MAC payload, including FCS. However our Tx PHY design calculates and inserts the FCS automatically. Thus the MAC software must include the length of the FCS when calculating the SIGNAL.LENGTH field.

So, with that background:

(1)As illustrated in the figure, this step makes DATA starts at byte[8].
Why DATA should start from byte[8]?

This is the PHY logic accessing the first byte of the MPDU - after the PHY header.

(2)As illustrated in the figure, why "SIGNAL_LENGTH" needs to subtract 4 bit?
(3)What is the meaning of this step?

This subtraction is SIGNAL.LENGTH-4 bytes. The comparison is between (LENGTH-4) and the current payload byte index. This is how the Tx PHY logic knows when to switch from payload bytes to FCS bytes. The payload bytes come from the packet buffer. The FCS bytes come from the checksum calculation block.

(4)As illustrated in the figure, what is the difference between "DATA" and "SIGNAL"? According to my understanding, 24 stands for the 24 bit SINGAL field of one OFDM symbol. Then the "DATA" here is the PSDU, which contains 24 bytes MAC header and the net the payload. Is it correct?

Right. We call SIGNAL+SERVICE "PHY Header" in the MAC code. This isn't technically accurate - the SERVICE field isn't really PHY-specific, but because its length is not included in SIGNAL.LENGTH, we inclue it in the "PHY Header" length for our length calculations.

Tomi · 2014-Dec-13 07:08:11

Thanks for your detailed explanantion. Now I understand the backround better.

It seems that DATA/SIGNAL/FCS value achieved in Addr Gen block are all BOOL values, which stands for the address of these parts, rather than the actual bit. Those values are deliverd to "Data Sel 64b" block, and the actual bit are genereted there.

Data Sel 64b block:

(1) What is the difference between "RAM 64b" and "RAM Valid"? It seems that actual transmitted data is generated from RAM 64b, and CRC bits are generated from DATA bool address and RAM Valid.

(2) For this selector, when FCS/PAD/TAIL=FALSE, then the selected result is d0, which means the transmitted data.
when FCS=TRUE, then the the selected result is d1, which means the CRC bit.
when PAD/TAIL=TRUE, then the selected result is d2, which are all one bit.

According to this mechnisim, if I change the DATA address value in Addr Gen block, from 4KB to 64KB, then here I can get a 64KB transmitted data automatically, which means I don't need to insert the fake payload by myself. Is my uncerstanding correct? Thanks.

Addr Gen block:
In Addr Gen block, the length of DATA bool value is controlled by SIGNAL_LENGTH. Is this the value defined in wlan_phy_tx_set_max_pkt_len_kB() function? If yes, then I will apply a 64KB value to instead of using SIGNAL_LENGTH value here. Then I can get a 64KB payload. Is my understanding correct? Thank.

Last edited by Tomi (2014-Dec-13 07:13:23)

murphpo · 2014-Dec-13 14:46:40

(1) What is the difference between "RAM 64b" and "RAM Valid"? It seems that actual transmitted data is generated from RAM 64b, and CRC bits are generated from DATA bool address and RAM Valid.

The 'RAM 64b' signal is the 64-bit output of the block RAM which implements the Tx pkt buffers. The Tx logic takes this 64-bit value and extracts individual bytes (in 'Byte Sel'), then individual bits (in 'Bit Sel') for actual transmission.

The 'RAM valid' signal asserts for 1 cycle for each bit that is used from the RAM contents. The CRC calculation is implemented to consume 1 byte at a time. The 'CRC Byte En' logic ensures the checksum is only updated once per new payload bytes.

(2) For this selector, when FCS/PAD/TAIL=FALSE, then the selected result is d0, which means the transmitted data.
when FCS=TRUE, then the the selected result is d1, which means the CRC bit.
when PAD/TAIL=TRUE, then the selected result is d2, which are all one bit.

The mux d2 input is driven by a constant 32-bit zero (not sure why your screenshot shows "1"). The 802.11 spec requires 6 TAIL bits of unscrambled zeros, followed by 0 or more PAD bits of scrambled zeros to fill any unused subcarriers in the final transmitted OFDM symbol.

Addr Gen block:
In Addr Gen block, the length of DATA bool value is controlled by SIGNAL_LENGTH. Is this the value defined in wlan_phy_tx_set_max_pkt_len_kB() function? If yes, then I will apply a 64KB value to instead of using SIGNAL_LENGTH value here. Then I can get a 64KB payload. Is my understanding correct? Thank.

The 'SIGNAL_LENGTH' flag is set in the 'SIGNAL Capture' block. This block interprets the fields in the SIGNAL field written by the MAC code to the PHY header of the pkt buffer. The 'wlan_phy_tx_set_max_pkt_len_kB()' macro sets the 'regTx_SIGNAL_MAX_LENGTH_KB' flag in the 'SIGNAL Capture / SIGNAL Slice' block. This flag is compared to the MAC-supplied SIGNAL.LENGTH value. If the MAC attempts a transmission longer than the max, the Tx PHY logic resets.

Per the standard, the LENGTH value is a 12-bit number which specifies the number of bytes in the MAC frame (MAC header + payload + FCS). You will need to modify this logic to allow LENGTH values larger than 12 bits. I suggest adding a new software-controlled register to control your modifications. The register would contain a new LENGTH field (>12 bits). It would also have a configuration bit to control whether the Tx PHY logic uses the SIGNAL.LENGTH value (the default) or the custom LENGTH value (your change) for a given transmission. This configuration bit could drive a new mux in the 'SIGNAL Slice' block that selects which LENGTH value to use.

Tomi · 2014-Dec-15 07:33:19

---

Last edited by Tomi (2014-Dec-15 08:20:17)

Tomi · 2014-Dec-15 07:54:11

Addr Gen block:
In Addr Gen block, the length of DATA bool value is controlled by SIGNAL_LENGTH. Is this the value defined in wlan_phy_tx_set_max_pkt_len_kB() function? If yes, then I will apply a 64KB value to instead of using SIGNAL_LENGTH value here. Then I can get a 64KB payload. Is my understanding correct? Thank.
The 'SIGNAL_LENGTH' flag is set in the 'SIGNAL Capture' block. This block interprets the fields in the SIGNAL field written by the MAC code to the PHY header of the pkt buffer. The 'wlan_phy_tx_set_max_pkt_len_kB()' macro sets the 'regTx_SIGNAL_MAX_LENGTH_KB' flag in the 'SIGNAL Capture / SIGNAL Slice' block. This flag is compared to the MAC-supplied SIGNAL.LENGTH value. If the MAC attempts a transmission longer than the max, the Tx PHY logic resets.

Per the standard, the LENGTH value is a 12-bit number which specifies the number of bytes in the MAC frame (MAC header + payload + FCS). You will need to modify this logic to allow LENGTH values larger than 12 bits. I suggest adding a new software-controlled register to control your modifications. The register would contain a new LENGTH field (>12 bits). It would also have a configuration bit to control whether the Tx PHY logic uses the SIGNAL.LENGTH value (the default) or the custom LENGTH value (your change) for a given transmission. This configuration bit could drive a new mux in the 'SIGNAL Slice' block that selects which LENGTH value to use.

Thanks for your reply.
For experiment, today I made following modifications to check whether I can generate the large payload on simulink pcore.

The designed largest layload is 1024KB, so
before after
SIGNAL_LENGTH 12bit 20bit
regTx_SIGNAL_MAX_LENGTH_KB 4bit 10bit
SIGNAL filed 24bit 32bit

SIGNAL Capture

SIGNAL Slice

Addr Gen

(1)
In wlan_phy_tx_init.m, I changed MAX_NUM_BYTES from 4096 to 1024000
(2)
SIGNAL_LENGTH
in SIGNAL Slice block, set the width of slice from 12 to 20
so b[3:0] RATE
b[5:24] LENGTH
b[26:31] TAIL
(3)
As the LENGTH field is changed from 12 to 20, so the SIGNAL length will be changed from 24 to 32.
(4)
regTx_SIGNAL_MAX_LENGTH_KB
in Registers block, set the width of slice from 4 to 10
so from register5,
b[7] regTx_TxRunning_Output_Sel
b[17:8] regTx_SIGNAL_MAX_LENGTH_KB
b[31] regTx_RESET

And then I check the simulink simulation result, and found that only SIGNAL bool equals to one, and all the others are zero.

I don't know how this error could happen. The SIGNAL length should be 32. I cannnot understand the meaning of the yellow part. Does this error related to the yellow part? Would you please give me suggestion if I miss any thing? Thanks.

Last edited by Tomi (2014-Dec-15 09:00:41)

murphpo · 2014-Dec-15 15:12:51

Modifying the definition of the SIGNAL field isn't a good approach- this will directly affect the Tx PHY's ability to generate standards-compliant waveforms.

A better approach would be a separate source for the LENGTH value that could be selected programatically. I built a simple demo of this - see wlan_phy_tx_pmd_jumboTx.zip. This is a modified version of the v1.1 Tx PHY and init script that supports "jumbo Tx" mode, up to 2^20 bytes per packet. I added a mux to the 'SIGNAL Capture' subsystem that selects between SIGNAL.LENGTH and a software-controlled register LENGTH value. This mux is controlled by a register bit, so the low-level MAC can select between normal and jumbo mode at run time. The software-controlled jumbo length and jumbo en/disable are controlled by a new register in the 'Registers' subsystem. I have not tested this modification in hardware.

Tomi · 2014-Dec-16 05:38:12

Thank you very much. This software-controlled jumbo length and jumbo en/disable mechanism is much better than modifying the SIGNAL field directly. Now the simulink simulation result showed that DATA/SIGNAL/FCS/PAD/TAIL parts are all available. Under this mechanism, the SIGNAL field is bypassed and useless for jumbo message.

For Rx part, the LENGTH value in the SIGNAL field is always 12 bits, limiting the maximum number of bytes to 4096, no matter it is ordinary payload or jumbo payload. Will this impact the decoding, i.e. the decoder just work on the first 4096, and then cut off the rest of the payload?

Under this mechanism, Tx buffer becomes useless for jumbo payload. For Rx, will Rx buffer be occupied for decoding operation? Or I can also bypass the Rx buffer? Thanks.

murphpo · 2014-Dec-16 17:45:54

For Rx part, the LENGTH value in the SIGNAL field is always 12 bits, limiting the maximum number of bytes to 4096, no matter it is ordinary payload or jumbo payload. Will this impact the decoding, i.e. the decoder just work on the first 4096, and then cut off the rest of the payload?

In the Rx PHY the SIGNAL field is demodulated/decoded and the LENGTH value is extracted. The Rx pipeline continues processing OFDM symbols until LENGTH bytes have been decoded. Thus, in the current design, the maximum duration of a reception will be when LENGTH = 2^12-1 bytes.

You will need to modify the Rx model to support processing waveforms containing more than 2^12 bytes. I would suggest a similar approach as the Tx model above - a mux to override the SIGNAL.LENGTH value (i.e. "jumbo" mode) which is controlled from software. The SIGNAL interpretation logic is in "wlan_phy_rx_pmd/Detect & Decode/Decode/SIGNAL Decode".

Tomi · 2014-Dec-18 05:40:46

Thanks for your reply. Now I finished the modification of pcores, and started to implement jumbo message on hardware.

In order to implement on hardware, I have to modify the C source code correspondingly.

Take "Tx config" for example, in Matlab, "Tx config" register is created by xilinx blockset, and in C source code, the related definitions are:
wlan_mac_low_dcf
in wlan_phy_util.h
//TX CONFIG
#define WLAN_TX_REG_CFG_SET_RC_RXEN 0x001
#define WLAN_TX_REG_CFG_RESET_SCRAMBLING_PER_PKT 0x002
#define WLAN_TX_REG_CFG_ANT_A_TXEN 0x004
#define WLAN_TX_REG_CFG_ANT_B_TXEN 0x008
#define WLAN_TX_REG_CFG_ANT_C_TXEN 0x010
#define WLAN_TX_REG_CFG_ANT_D_TXEN 0x020
#define WLAN_TX_REG_CFG_USE_MAC_ANT_MASKS 0x040
#define WLAN_TX_REG_CFG_DELAY_DBG_TX_RUNNING 0x080
#define WLAN_TX_REG_CFG_MAX_PKT_LEN_MASK 0xF00

//Register renames
#define WLAN_RX_REG_CFG XPAR_WLAN_PHY_RX_MEMMAP_CONFIG

//PHY Macros
#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))

in wlan_phy_util.c
wlan_phy_tx_set_max_pkt_len_kB(2);

wlan_bsp_cpu_low
in xparameters.h
/* Definitions (address parameters) for peripheral WLAN_PHY_TX */
#define XPAR_WLAN_PHY_TX_MEMMAP_CONFIG 0x78E00804

(1) how the register defined in C source code can be connected to the corresponding register defined in the pcore? The address defined in wlan_phy_util.h, such as 0x001, 0x002..., are written manually, or generated by the program automatically?

(2) The address in the xparameters.h(0x78E00804) is written manually, or generated by the program automatically? I applied SysGen to create a new pcore, and then applied this new pcore in XPS to generate bitstream, however, no jumboTx register related address is automatically generated in xparameters.h. So I don't how to map the simulink register into C source code.

Thanks.

welsh · 2014-Dec-18 09:28:09

xparameters.h is generated automatically as part of the BSP creation. xparameters.h will give you the register locations within the memory map but not the meaning of any bits within the register. Therefore, you have to create the bit definitions manually. You can see how we did this in wlan_phy_util.h.

When you created your pcore, did you add the registers to the EDK processor block. In general, the procedure to add new register bits to a pcore is:
1) In the Matlab consol window, make sure all the necessary variables are defined (i.e. all the initialization values for the registers)
2) Delete the current EDK processor block.
3) Right click and select "Add Xilinx Block"; In the new dialog, select the "EDK Processor" processor block (you can type EDK in the search bar and it will bring up the block)
4) Open the EDK Processor block; On the "Basic" tab, Click the "Add" button to add all of the registers. Check that all the appropriate registers are added in the "Memory Map" dialog. Then select "OK".
5) Open the EDK Processor block; Select the "Implementation" tab. Select the "Register Read-Back" option. Click "OK"

There are some quirks in the EDK processor block and we have found that procedure works all the time (i.e. if you try to do steps 4 and 5 without closing and re-opening the dialog, then the Register Read-Back option might not be actually selected).

If all the registers are in the "Memory Map" of the pcore, then they will show up in the parameters.h when you re-build / export the XPS project.

WARP Project Forums - Wireless Open-Access Research Platform

#1 2014-Nov-25 00:12:34

Largest Packet Size Supported by Current WARP

#2 2014-Nov-25 07:45:12

Re: Largest Packet Size Supported by Current WARP

#3 2014-Nov-25 07:50:53

Re: Largest Packet Size Supported by Current WARP

#4 2014-Nov-25 09:16:31

Re: Largest Packet Size Supported by Current WARP

murphpo wrote:

#5 2014-Nov-25 09:21:33

Re: Largest Packet Size Supported by Current WARP

murphpo wrote:

#6 2014-Nov-25 09:51:25

Re: Largest Packet Size Supported by Current WARP

Code:

#7 2014-Nov-25 10:02:28

Re: Largest Packet Size Supported by Current WARP

#8 2014-Nov-28 08:29:07

Re: Largest Packet Size Supported by Current WARP

murphpo wrote:

Code:

#9 2014-Nov-29 02:51:21

Re: Largest Packet Size Supported by Current WARP

#10 2014-Nov-30 05:29:52

Re: Largest Packet Size Supported by Current WARP

#11 2014-Dec-01 05:10:29

Re: Largest Packet Size Supported by Current WARP

#12 2014-Dec-01 09:30:32

Re: Largest Packet Size Supported by Current WARP

#13 2014-Dec-03 08:09:26

Re: Largest Packet Size Supported by Current WARP

#14 2014-Dec-06 12:15:23

Re: Largest Packet Size Supported by Current WARP

#15 2014-Dec-11 05:53:46

Re: Largest Packet Size Supported by Current WARP

#16 2014-Dec-12 10:11:56

Re: Largest Packet Size Supported by Current WARP

#17 2014-Dec-13 07:08:11

Re: Largest Packet Size Supported by Current WARP

#18 2014-Dec-13 14:46:40

Re: Largest Packet Size Supported by Current WARP

#19 2014-Dec-15 07:33:19

Re: Largest Packet Size Supported by Current WARP

#20 2014-Dec-15 07:54:11

Re: Largest Packet Size Supported by Current WARP

#21 2014-Dec-15 15:12:51

Re: Largest Packet Size Supported by Current WARP

#22 2014-Dec-16 05:38:12

Re: Largest Packet Size Supported by Current WARP

#23 2014-Dec-16 17:45:54

Re: Largest Packet Size Supported by Current WARP

#24 2014-Dec-18 05:40:46

Re: Largest Packet Size Supported by Current WARP

#25 2014-Dec-18 09:28:09

Re: Largest Packet Size Supported by Current WARP

Board footer