You are not logged in.
It is really great that the new reference design is up. We have been waiting for this to study how to use DMA. Some questions are listed in the following.
A) Hardware/Software support and sysgen design flow for DMA
1. What is BRAM Interface Controller used on the custom pcore side? Block RAM Block (v1.00a) data sheet says LMB, OPB, PLB and OCM. While ofdm_txrx_mimo_opbw***.mpd defines BUS_STD = XIL_BRAM, BUS_TYPE = INITIATOR
2. What is the datawidth of the BRAM? Using XEmac_FifoSend/XEmac_FifoRecv, the data from EMAC is in Xint8 type. In EDK, the datawidth is autocomputed. But we have to define the datawidth inside any pcore connect to PortB.
3. How to build such an interface to interface PortB in a custom pcore using system generator and sysgen2opb?
B) Why you still need an intermediate PPC buffer for packets from ethernet to OFDM PHY? In the post http://warp.rice.edu/forums/viewtopic.php?id=65,
Ethernet -> OFDM still requires an intermediate buffer to handle the case of the wireless MAC needing to transmit an ACK while in timeout (i.e. sending an ACK before attempting to re-transmit a previous data packet).
1. Why in this protocol you need to send an ACK before re-transmit a previous packet (timeout in waiting ACK)?
2. It is still not clear to me why you have difficult avoiding the intermediate buff in this version. It seems to me that the intermediate buff (txpacket->data) can only hold one packet, as shown by RxStatus = XEmac_FifoRecv(EmacPtr, txPacket->data, &length) in emacRx_int_handler. A new packet will overwrite the old one. In fact, you disabled the ethernet interrupt after getting one packet from ethernet. So, anytime you only have one packet to transmit in WARP. Thus, it should be possible to use BRAM (OFDM_TXRX_MIMO_TXPKTBUFFER_BASEADDR) to store the packet during the period of waiting ACK.
Thank you very much.
Last edited by zrcao (2007-Jun-14 23:15:20)
Offline
The PLB BRAM memory used in EDK projects is actually composed of two cores. The first is the PLB BRAM controller (plb_bram_if_cntlr), which implements two bus interfaces: PLB slave and BRAM initiator. The BRAM initiator interface connects to the second core, the memory block itself.
The memory block (bram_block) is built using dual-port RAMs in the FPGA. The PLB BRAM controller only uses one port (PORTA); the second port (PORTB) is exposed in the bram_block pcore but is generally left floating. We implemented a BRAM initiator interface in our OFDM TxRx model and connect it to PORTB. This way, the OFDM core has direct access to a block of memory which is also mapped into the PLB address space. As a result, the OFDM core benefits from DMA-driven Ethernet<->PLB BRAM transfers without actually implementing a PLB slave interface in Sysgen.
The BRAM initiator interface is very simple and is built entirely from Sysgen blocks. Look at the OFDM Sysgen model in the reference design for the details (/pcores/ofdm_TxRx_mimo_opbw_v1_24_a/mdlsrc/ofdm_TxRx_mimo_unconverted_backup.mdl). The gateways representing the BRAM interface are in the top-level block 'BRAM Interface'.
sysgen2opb / OPB Export Tool don't handle the BRAM initiator interface automatically. You have to edit the pcore's MPD file manually to add the BRAM PORTB directives. Again, look at the OFDM core in the reference design for a good example.
Offline
The intermediate Tx buffer is still required to handle this situation:
1) Receive an Ethernet packet
2) Transfer the packet to the OFDM PHY and transmit it
3) While waiting for an ACK, receive a data packet
4) Transmit an ACK, overwriting data packet in OFDM Tx buffer
At this point, without an intermediate Tx buffer, the original data packet is lost (it's not in the Ethernet FIFO anymore, and it was just overwritten in the OFDM Tx buffer).
Offline
Picking up this old topic. Here are a few questions.
(1) You have two PLB_BRAM pcores in your design. The second one is for DMA data buffer. What is the first used for? I have the impression that this is to expand the memory space for power PC. But I couldn't find from where I got this understanding. Am I right? If so, it is for data memory or instruction memory?
(2) In power PC, can we indicate the memory address of the PLB_BRAM, to and from which a packet can be written and read using DMA or the memory bus between the BRAM and txrx pcore?
Last edited by zrcao (2007-Jul-18 22:31:17)
Offline
1) Right on both counts- one bram_block is dedicated to the PHY packet buffers. It is imporant that the PowerPC not use this block for data or instructions. The other is for extra program/data space.
2) You set the addresses of the blocks in the Addresses tab of System Assembly View in XPS. The software project's linker script is responsible for assigning whatever sections of data/instructions to memory blocks. This is where you have to confirm that nothing is assigned to the PLB BRAM used for PHY packets. The packet buffer addresses are hard-coded in the OFDM driver header (really they're referenced to the parameterized base address of the PLB BRAM controller). In ofdm_txrx_mimo.h:
#define OFDM_TXRX_MIMO_RXPKTBUFFER_BASEADDR (XPAR_PLB_BRAM_IF_CNTLR_2_BASEADDR + 0x0) #define OFDM_TXRX_MIMO_TXPKTBUFFER_BASEADDR (XPAR_PLB_BRAM_IF_CNTLR_2_BASEADDR + 0x1000)
The offset of the Tx buffer (0x1000) is hard-coded in the PHY's BRAM interface in Sysgen.
Offline