WARP Project Forums - Wireless Open-Access Research Platform

It looks like you did everything right; I'm not sure what the problem is.

Try this- in the mss file, remove the line " PARAMETER emac_instname = Ethernet_MAC". Then open the Software Platform Settings window, select OS and Libraries and expand WARPxilnet. In the drop-down for emac_instance, is Ethernet_MAC an option?

In your WARPxilnet MLD file (sw_services/WARPxilnet_v2_00_a/data/WARPxilnet_v2_1_0.mld), does the "PARAM name = emac_instname" line include "xps_ethernetlite" (like the latest version in the repository)? This line tells XPS which EMAC cores satisfy the library's requirements.

Double check that XPS is reading the copy of WARPxilnet you think it is (by renaming the folder or changing the library version number). Maybe it's reading a different copy that doesn't have xps_ethernetlite as an option?

Though the compilation problem is fixed, I am going to continue on this thread because there is an issue with the situation I had described in the first post. As I stated, I am integrating parts of warplab and the ref design. From a PC I load up data generated from matlab to either node's txbuffer and I initiate data transmission from MATLAB. I added shared memories to the ofdm sysgen model which store the channel estimates, and I can read that into MATLAB from either node. In effect the MAC does not do carrier sensing, it just polls the ethernet and responds to various commands (i.e. load tx data, txstart, read channel estimates).

I am seeing through chipscope that whenever I initiate a wireless transfer the bad header interrupt asserts and the payload is corrupted. Through chipscope the I/Q data coming out of the ADC is really low in amplitude (i.e. 0.08 peak). The channel estimates from the receiving node look pretty bad as well. I have ruled out a lot of factors (agc, radios, init code) and I am thinking maybe it's the way I load the MATLAB data into the ofdm phy txbuffer. I use the warplab_writeSMRO/warplab_pktSend matlab routines to load up the txbuffer (the data is scaled to [-1 1], and cast converted) and then in the FPGA I use the following command to copy it over:

memcpy((u8 *)warpphy_getBuffAddr(controlStruct.txBuffIndex)+NUM_HEADER_BYTES, (unsigned int *)(receivePtr32 + 3), (bytesReceived));

Do you see any problem with this? Maybe it overwrites some of the header data and/or training symbols? Or even maybe the casting done in the phy is incorrect? I try to add a printf to read the bytes that I am storing in the buffer but it doesn't print anything to the screen.

SH

The txBuffer is the usual xps_bram_block from the reference design. I call warphy_init and I set the numFullRateSymbols register before initiating the transmission, by calling the following three warpmac_xmit functions that are usually called in the emac rx interrupt handler.

Here's a weird observation. If I send header-only packets (ACK) then I get the good header interrupt. Normally I would be satisfied with only using header packets since I am only interested in channel estimates but I find that the shared memory block I use to store the channel estimates gets overwritten with bad data after the packet has been processed. I confirm this by comparing estimates seen on chipscope to those I read into MATLAB.  I am pretty sure it is not the memory itself since I simulate the model and confirm that the estimates are stored correctly. I am thinking maybe the write enable signal I have going into the memory gets asserted for some reason after the packet has been processed. A colleague of mine who is doing something similar mentioned that it is better to use data packets for this since the I can read the estimates in the goodHeader interrupt handler and can still be certain that they will be correct since the PHY needs the estimates to process the rest of the payload.

Now, if I send data packets then I get the bad header interrupt and the estimates are overwritten anyways since the PHY resets after a bad header interrupt. After some debugging I confirm that I am correctly copying the header and payload into the tx packet buffer correctly (using memcpy and printf's). One thing I did is I probed the contents of the header from the tx packet buffer before and after wireless transmission for both ACK and DATA packets. Before transmission the header contents for both ACK&DATA packets were all zeroes for all 24 bytes. This is to be expected I guess. After transmission though it gets a little interesting.

The ACK packets were setup the following way:

ackPacket.header.length = 0;
ackPacket.header.pktType = ACKPACKET;
ackPacket.header.fullRate = QPSK;
ackPacket.header.codeRate = CODE_RATE_NONE;

The ACK header contents are below:
header[0] = 2
header[1] = 3
header[2] = 0
header[3] = 18
header[4..23] = 0

The DATA packets were set up the following way:

txBuffer.header.length = bytesReceived-12;
txBuffer.header.fullRate = pktFullRate;
txBuffer.header.codeRate = pktCodeRate;
txBuffer.header.pktType = DATAPACKET;
txBuffer.header.currReSend = 0;

The DATA header contents are below:
header[0] = 2
header[1] = 3
header[2] = 0
header[3] = 18
header[4] = 1
header[5..23] = 0

I don't see where the length field is set for the DATA packet, the only difference between the header contents is header[4], which I presume is for packet type. I don't exactly know how the header fields are formed into the packet, so can you please tell me is you see anything fishy with the DATA header contents.

Thanks,
SH