You are not logged in.
Hi,
I have couple of questions on ofdm_pktDetector_mimo.mdl and its interface to the opb bus and some basic concepts on sheared memory between ofdm_pktDetector_mimo_opbw and Power-PC.
1. Is there any design document on ofdm_pktDetector_mimo_opbw modeling and its HW interface? I am trying to understand how packet detector works based on the RSSI from the RF boards. For example in case of MIMO, it should get multiple RSSI values from multiple RF daughter cards. From those multiple RSSI values how the packet dtetection algorithm desides the first level of packet detection? Even in SISO case how it works? In the available SIMULINK model with release v8, I am not able to find out the input port for RSSI to the model. How it is mapped to the FPGA pins?
2. In carrier sense model (for csma mac), the packet detection has to detect the power in the channel over DIFS period. How the algorithm is implemented? I can see there are multiple inputs from the csma mac through input registors. Do you have any test model to varify the algorithm performance only in SIMULINK?
3. Are these input registors mapped to the sheared memory? If yes where these shered memories are physically located? Is it in PPC or FPGA frabic? My understanding of sheared memery is feeble. Reference to relevent documents will be of great help.
Thanks
Atanu
Offline
The file "ofdm_pktDetector_mimo_unconverted_backup.mdl" in "OFDM_ReferenceDesign_v08_public\pcores\ofdm_pktdetector_mimo_opbw\mdlsrc" is the System Generator model source before the sysgen2opb tool is applied to attach it to the OPB.
In that file, you'll see four subsystems: Detection1 through Detection4. Each of these is a separate energy detector for potentially four different radio paths. There is some logic after those four subsystems that allows the user to OR/AND any combination of those outputs. Inside "Detection1," you'll see a Xilinx Gateway In block named "RSSI1." This gets mapped to a top-level HDL port in the peripheral that is connected to one of the RSSI outputs of the radio bridge from within the EDK tool. It does not get mapped to a pin on the FPGA directly (RSSI is funneled through the radio bridge).
The CSMA functionality is lumped into the packet detection simply out of convenience (since the averaged RSSI values are easily accessible). You can find the blocks associated with this functionality below Detection1 through Detection4. The user provides a threshold in their C-code by writing a value to an address which maps to the "From Register" named "csma_avgThresh." This flow between C-level code and hardware designs is covered in the lab exercises. The threshold is used to create instantaneous "busy" and "idle" triggers, which feed some counting logic that makes sure that the "idle" output of the system only goes high if the medium has been idle for an entire DIFS period.
Offline
Thnaks for the details.
So if I do not want to use all the 4 antennas, I have to set the appropriate control register for antenna selection.
Another question I have is, in warpmac_sendOfdm(), there is a code section which is as follows:
//Copy the header to the PHY packet buffer, filling exactly NUM_HEADER_BYTES bytes
// The rest of the packet (its payload) will be copied by DMA later
memcpy((unsigned char*)warpphy_getBuffAddr(controlStruct.txBuffIndex), (unsigned char*) packet, (size_t)NUM_HEADER_BYTES);
My question on the DMA transfer comment: isn't the packet's payload already copied to the PHY TX buffer by DMA through XEmac_FifoRecv() in emacRx_int_handler() function? Or it is done elsewhere? I couldn't find anything after the function warpmac_sendOfdm() which does DMA.
Offline
You're right- by the time sendOFDM() has been called, the Ethernet packet has been copied (via the EMAC DMA) to the PHY buffer. That comment is really old, left over from our pre-DMA designs.
Offline
thnaks a lot.
Continuing, in the 'while' loop of the main function (csmamac.c), under DEBUG_MENU, there are functions which does CFO correction (warpphy_set_B_KPPlus, warpphy_set_B_KPMinus, warpphy_set_B_KIPlus, warpphy_set_B_KIPMinus) and other PHY related options.
So are these problems expected (problems in CFO etc or AGC gain correction algorithm performance etc.) while testing for the PHY-MAC in the HW? How did you choose all those values passed to these functions?
Offline
We use these debug functions to try difference magic numbers for the CFO loop filters. Using an analog board to observe the residual CFO in the receiver, we can tweak the coefficients interactively. The best values we've found are the current default values.
Offline