WARP Project Forums - Wireless Open-Access Research Platform

INTERNAL_ERROR:Xst:cmain.c:3423:1.29 -  Process will terminate. For technical support on this issue, please open a WebCase with this project attached at http: //www.xilinx.com/support
ERROR:EDK - xst: unknown error occurred.
ERROR:EDK:546 - Aborting XST flow execution!
ERROR:EDK:440 - platgen failed with errors!

This error is something deep in the Xilinx tools - your addition of a register to the PHY core probably didn't cause this.

Can you build the reference design hardware project without modification? Try opening the original XPS project, select Hardware -> Clean Hardware, then Generate Bitstream.

What version of the Xilinx tools are you using? We strongly recommend using 14.4.

It seems these errors are caused by the added register. I check the XPS address block, wlan_phy_tx is allocated with (base address 0x78E00000, high address 0x78E0FFFF 64K). I thought these errors are due to the added 32bit register make wlan_phy_tx  overflow. So I tried to allocate more memory resource to wlan_phy_tx. But no matter how I click the wlan_phy_tx, I cannot make any modification. It seems that the memory allocation can not be modified manually.

Each pcore specifies the size of the memory address allocation it requires. This is part of the pcore's metadata (in <pcore>/data/<pcore>.mpd). System Generator cores default to 64KB; this is enough to address 16384 32-bit registers (i.e. adding one register does not require expanding the core's address space).

Tonight I applied XPS to generate the new bit stream successfully.

However, when I exported the design, I met a problem: two platforms exists in the SDK project! One is the new generated EDK_Projects_hw_platform, the other is the old Mango_802.11_RefDes_v1.1.0_hw_platform. Due to this problem, some blocks cannot be recognized by SDK.

Would you please give me some advice on how to deal with this problem? Thanks.

Last edited by Tomi (2014-Dec-21 08:50:22)

Thanks for your reply.

-Delete /EDK_Projects/SDK_Workspace/EDK_Projects_hw_platform/.

The directory location here is /EDK_Projects/EDK_Projects_hw_platform
rather than /EDK_Projects/SDK_Workspace/EDK_Projects_hw_platform



I checked the information in system.xml source:
  <PARAMETER ASSIGNMENT="CONSTANT" MPD_INDEX="9" NAME="C_MEMMAP_JUMBOTX_CONFIG" TYPE="integer" VALUE="0x800">
  <DESCRIPTION>C_MEMMAP_JUMBOTX_CONFIG</DESCRIPTION>
  <DESCRIPTION>C_MEMMAP_JUMBOTX_CONFIG</DESCRIPTION>
  </PARAMETER>
  <PARAMETER ASSIGNMENT="CONSTANT" MPD_INDEX="10" NAME="C_MEMMAP_JUMBOTX_CONFIG_N_BITS" TYPE="integer" VALUE="32"/>
  <PARAMETER ASSIGNMENT="CONSTANT" MPD_INDEX="11" NAME="C_MEMMAP_JUMBOTX_CONFIG_BIN_PT" TYPE="integer" VALUE="0"/>

It seems that XPS already successfully generated bit-stream containing JumboTx register.

However, in xparameters.h file, there is still no JumboTx register information!!!
I think this is because the directory of the generated "_hw_platform" folder is not under /EDK_Projects/SDK_Workspace/, the files in wlan_bsp_cpu_high and wlan_bsp_cpu_low folders cannot be updated??? How can I change the directory for generated "_hw_platform" folder?

Rename /EDK_Projects/ to /Mango_802.11_RefDes_v1.1.0_hw_platform/

After doing this, the generated one is Mango_802.11_RefDes_v1.1.0_hw_platform_hw_platform
Also under the directory of /EDK_Projects, rather than /EDK_Projects/SDK_Workspace/

Open XPS and re-export the project. This export should be fast (i.e. it won't re-synthesize the hardware design).

Even though re-export the project, the xparameters.h file didnot contain the added register. I think this is because the directory of the generated "_hw_platform" folder is not under /EDK_Projects/SDK_Workspace/, so related files cannot be updated.

So up to now, although XPS can generate the bitstream with JumboTx register information, I cannot export it correctly to SDK.

Last edited by Tomi (2014-Dec-22 02:01:29)

First, Patrick had a typo: 

Rename /EDK_Projects/ to /Mango_802.11_RefDes_v1.1.0_hw_platform/

should have been:

Rename /EDK_Projects/ to /Mango_802.11_RefDes_v1.1.0/

because the "_hw_platform" is appended on the export.

Second, when exporting the design from XPS (i.e. select "Export Design" and then "Export & Launch SDK"), it will bring up a "Workspace Launcher" dialog when starting the SDK.  At that point, you should select the appropriate "SDK_Workspace" folder (i.e. you should select "/Mango_802.11_RefDes_v1.1.0/SDK_Workspace")  This will cause the hardware project to be exported to "/Mango_802.11_RefDes_v1.1.0/SDK_Workspace/Mango_802.11_RefDes_v1.1.0_hw_platform".  It looks like during the export, you are only selecting:  "/Mango_802.11_RefDes_v1.1.0/" and not "/Mango_802.11_RefDes_v1.1.0/SDK_Workspace".

In order to get the register to appear in the xparameters.h, you then need to re-build the BSP.  In the SDK, you should be able to just right click on the BSP and select "Clean Project" which will cause the BSP to re-build.  If that doesn't work, then you will need to delete that BSP and create a new BSP with the same settings.

In order to get the register to appear in the xparameters.h, you then need to re-build the BSP.  In the SDK, you should be able to just right click on the BSP and select "Clean Project" which will cause the BSP to re-build.  If that doesn't work, then you will need to delete that BSP and create a new BSP with the same settings.

Now I can export the hardware project "_hw_platform" to the directory "/Mango_802.11_RefDes_v1.1.0/SDK_Workspace/Mango_802.11_RefDes_v1.1.0_hw_platform", and confirmed that JumTx register can be successfully generated by XPS.

However, as you mentioned, I right clicked on the BSP and selected "Clean Project" to re-build the BSP, however, it doesn't work. The JumboTx register still does not appear in the xparameters.h.

Would you tell me the procedure for deleteing the BSP and creating a new BSP with the same settings? Thanks.

Last edited by Tomi (2014-Dec-22 17:47:21)

Yes, I changed the pcore wlan_phy_tx_pmd_axiw from v2_01_b to v2_01_c.
I checked the BSP Settings -> Drivers, but there is no item named as wlan_phy_tx_pmd_axiw. How can I select a new pcore? Thanks.

Last edited by Tomi (2014-Dec-22 18:32:18)

murphpo wrote:

That screenshot is for wlan_bsp_cpu_high - check the wlan_bsp_cpu_low settings. The WLAN cores are all attached to the peripheral bus of the CPU Low MicroBlaze.

Thank you very much. Now it worked. JUMBOTX register information is displayed in xparameters.h!

/* Definitions for peripheral WLAN_PHY_TX */
#define XPAR_WLAN_PHY_TX_MEMMAP_STATUS_N_BITS 32
#define XPAR_WLAN_PHY_TX_MEMMAP_STATUS_BIN_PT 0
#define XPAR_WLAN_PHY_TX_MEMMAP_JUMBOTX_CONFIG_N_BITS 32
#define XPAR_WLAN_PHY_TX_MEMMAP_JUMBOTX_CONFIG_BIN_PT 0
#define XPAR_WLAN_PHY_TX_MEMMAP_TIMING_N_BITS 32
#define XPAR_WLAN_PHY_TX_MEMMAP_TIMING_BIN_PT 0
#define XPAR_WLAN_PHY_TX_MEMMAP_CONFIG_N_BITS 32
#define XPAR_WLAN_PHY_TX_MEMMAP_CONFIG_BIN_PT 0
#define XPAR_WLAN_PHY_TX_MEMMAP_PKT_BUF_SEL_N_BITS 32
#define XPAR_WLAN_PHY_TX_MEMMAP_PKT_BUF_SEL_BIN_PT 0
#define XPAR_WLAN_PHY_TX_MEMMAP_OUTPUT_SCALING_N_BITS 32
#define XPAR_WLAN_PHY_TX_MEMMAP_OUTPUT_SCALING_BIN_PT 0
#define XPAR_WLAN_PHY_TX_MEMMAP_TX_START_N_BITS 32
#define XPAR_WLAN_PHY_TX_MEMMAP_TX_START_BIN_PT 0
#define XPAR_WLAN_PHY_TX_MEMMAP_FFT_CONFIG_N_BITS 32
#define XPAR_WLAN_PHY_TX_MEMMAP_FFT_CONFIG_BIN_PT 0
#define XPAR_WLAN_PHY_TX_DEVICE_ID 0
#define XPAR_WLAN_PHY_TX_BASEADDR 0x78E00000
/******************************************************************/

/* Definitions (address parameters) for peripheral WLAN_PHY_TX */
#define XPAR_WLAN_PHY_TX_MEMMAP_STATUS 0x78E0081C
#define XPAR_WLAN_PHY_TX_MEMMAP_JUMBOTX_CONFIG 0x78E00800
#define XPAR_WLAN_PHY_TX_MEMMAP_TIMING 0x78E00804
#define XPAR_WLAN_PHY_TX_MEMMAP_CONFIG 0x78E00808
#define XPAR_WLAN_PHY_TX_MEMMAP_PKT_BUF_SEL 0x78E0080C
#define XPAR_WLAN_PHY_TX_MEMMAP_OUTPUT_SCALING 0x78E00810
#define XPAR_WLAN_PHY_TX_MEMMAP_TX_START 0x78E00814
#define XPAR_WLAN_PHY_TX_MEMMAP_FFT_CONFIG 0x78E00818

I have successfully created the bit definitions of JumboTx register in wlan_phy_util.h.

(1)
#define wlan_phy_rx_set_max_pkt_len_kB(d) Xil_Out32(WLAN_RX_REG_CFG, (Xil_In32(WLAN_RX_REG_CFG) & ~WLAN_RX_REG_CFG_MAX_PKT_LEN_MASK) | (((d) << 17) & WLAN_RX_REG_CFG_MAX_PKT_LEN_MASK))

#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))

For the above two functions, what is the meaning of 17 and 8?
As the maximum payload is limited to 4KB, the maximum of d is 4. Then d is always less than 17 or 8. Why d<<17 and d<<8 should be added here? Thanks.

(2)
If I enable the jumbo message selection in wlan_phy_init() in wlan_phy_util.c, then the hardware will generate an expected payload. However, all the messages, not only data message, but also control message, management message become jumbo… which makes AP and STA cannot communicate with each other…
I only need data message to be jumbo, and control/management messages keep as before, so that AP and STA can communicate as before.
Do you have any suggestion on this issue? Thanks.

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

The 17 and 8 represent the bit shifts for those fields in the target registers. In both cases the max_pkt_len fields are sliced from 32-bit registers. Both registers contain other control values, which are preserved by the read-modify-write behavior of these macros.

Thanks for your reply. I check the register information of tx/rx max_pkt_len fields.
For tx max_pkt_len field, it is using the bit [8:11], so the bit shift here is 8, that is d<<8
For rx max_pkt_len field, it is using the bit [17:20], so the bit shift here is 17, that is d<<17

For jumbo pkt_len field, it is using the  bit [0:19], so the bit shift here is 0, so I should write the function as:
#define wlan_phy_tx_jumbo_pkt_len_kB(d) Xil_Out32(WLAN_TX_REG_JUMBOTX, (Xil_In32(WLAN_TX_REG_JUMBOTX) & ~WLAN_TX_REG_JUMBOTX_PKT_LEN_MASK) | (((d) << 0) & WLAN_TX_REG_JUMBOTX_PKT_LEN_MASK))

As d is always larger than 0 here, applying d<<0 looks strange here. Is the above function correct? Thanks.

To interoperate with 802.11 devices you must en/disable jumboTx mode per-packet. This is why having control of jumboTx mode from software in CPU Low is important. You need to modify the code in CPU Low (wlan_mac_low_dcf.c) to implement this behavior. I think you only need to modify frame_transmit(). The code in CPU Low has access to the full packet contents, including the packet type. Your custom code can check the packet type, enable jumboTx mode if necessary, trigger the MAC Tx, wait for the Tx to finish, then disable jumboTx.

Thanks. In frame_transmit(), I added a sentence to check the packet type and enable/disable jumboTx mode.

  if((header->frame_control_1) == MAC_FRAME_CTRL1_SUBTYPE_DATA){
        REG_SET_BITS(WLAN_TX_REG_JUMBOTX, WLAN_TX_REG_JUMBOTX_EN); //Enable JumboTx
  } else{
        REG_CLEAR_BITS(WLAN_TX_REG_JUMBOTX, WLAN_TX_REG_JUMBOTX_EN);
  }

Last edited by Tomi (2014-Dec-24 01:16:55)

(1) As now the register "regTx_SIGNAL_MAX_LENGTH_KB" is set to 10-bit long, so it can reach a value up to 1000KB.
The value can be defined in:
#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))

Here, the value d should be hexadecimal or decimal? For example, if I want to set "regTx_SIGNAL_MAX_LENGTH_KB" to 64KB, then d is 0x40 or 64? Thanks.

(2) The simulink simulation showed that the jumbo payload is realized in pore. Now I want to check the actual transmitted payload size.

In the past, I can use python program to get the payload size. However, the information from the TX/TX_LOW/TX_LTG/TX_LOW_LTG log entries are recorded by program written in C source code, as for jumbo message we only modified the pore, I doubt whether these log entries could reflect the jumbo payload size. If they cannot reflect the jumbo payload size, how can I check the transmitted radio data is actual jumbo message or not? How can I get the log information of pore PHY? Thanks.

Last edited by Tomi (2014-Dec-29 07:58:34)

......

Last edited by Tomi (2014-Dec-29 18:28:32)

The above TX CONFIG macro names are created optionally?

How can the macro names WLAN_TX_REG_CFG_SET_RC_RXEN, WLAN_TX_REG_CFG_RESET_SCRAMBLING_PER_PKT, WLAN_TX_REG_CFG_ANT_A_TXEN be mapped to the register WLAN_TX_REG_CFG? Just because they have some part in common, i.e, they all contain "WLAN_TX_REG_CFG" part?

Using named macros in place of "magic" numbers is not required. We do this to make the reference code cleaner.

All macros in wlan_phy_util.h are defined manually - we wrote these to make code in wlan_phy_util.c cleaner. The values for the WLAN_TX_REG_CFG* macros match the bit slice assignments in the Tx PHY model. If you change the meaning of register bits in the model you must update any corresponding macros in the .h file. The names of these macros are arbitrary (i.e. you could change the "WLAN_TX_REG_CFG_" prefix to "ABC_" and it would still work - the compiler doesn't know anything about the register names in the System Generator model).