You are not logged in.
We are studying how to use DMA with plb_BRAM for packet data. Here is a few questions regarding the implementation in Rice's reference design V05.
1. From the mpd file of plb_bram_if_cntlr_2_bram, we found that
PARAMETER C_PORT_DWIDTH = 32, DT = integer, BUS = PORTA:PORTB, RANGE = (32, 64, 128)
But it seems to me that the Data width between the bram and OFDM pcore in the reference model is 64-bit. How come the auto compute ends up with 64 bit?
2. How can we change the Data Width? It seems to me what defined in mpd, 32, is overwritten by the auto computed 64 somewhere in the project.
3. In the ports of System assembly view of the V05 project, there are two ports --- BRAM_CLK_B and BRAM_EN_B. The connections are different from that defined in the mpd file. So the connection defined in mhs will overwrite the connection defined in mpd, right?
4. In your OFDM model, for received packets (from OFDM pcore to bram buffer), it seems to me that you repeated each bytes 8 times to make it 64-bit before being written in the buffer. Is this understanding right? If so, where do you get grid of the extra bits before DMA back to the FIFO in plb_EMAC?
Last edited by zrcao (2007-Aug-13 21:59:36)
Offline
1-2) The data widths of BRAM blocks match their host bus (32-bit for OPB, 64-bit for PLB in the V2Pro). The assignment of this width is handled deep in the EDK's HDL generation. As best I can tell, the BRAM cores are special- they get handled by code in the EDK binaries that we can't see. You can see the result in the VHDL wrapper for the BRAM block (<EDK project>/hdl/plb_bram_if_cntlr_1_bram_wrapper.vhd); the "C_PORT_DWIDTH => 64" generic mapping is near the bottom.
3) The connections in an MPD file are defaults and can always be overridden in the MHS file. In this case, the OFDM core doesn't drive the clock and enable signals specified in the standard BRAM interface, so we explicitly tie them to valid top-level signals in the MHS.
4) The OFDM PHY always writes to the BRAM block 1 byte per cycle (with many idle cycles between bytes). The PHY repeats each byte 8 times to fill the 64-bit bus, and uses the 8-bit BE (byte-enable) signal to specify which BRAM byte should actually be written. The BRAM_ADDR and BRAM_BE outputs are decoded in the Sysgen model from the PHY's internal byte counter.
When transferring a packet to the Ethernet MAC, the DMA always starts at a 64-bit aligned address and reads an integral number of 64-bit words over the PLB. The EMAC knows how many valid bytes there are (one of the parameters passed to the XEmac_FifoSend function), so it simply ignores 0-7 bytes in the last 64-bit word it receives.
Offline
Thanks for the reply and introduction. I would like to follow up on your answers to (4).
The OFDM PHY always writes to the BRAM block 1 byte per cycle
Can I say this is a design choice you made for your model, not mandated by the EDK and BRAM pcore? In other words, I could also wait until all 8 bytes are ready and write in in one cycle by setting all 8 bits of WEn be 1 in one cycle, and all zeros for the waiting cycle. Or any other possible combinations ( 2 1's for 4 writings, 4 1's for 2 writings).
Last edited by zrcao (2007-Aug-14 14:29:48)
Offline
The 1-byte-per-cycle was definitely a design decision. The PHY already had a packet constructor that output 1 byte at a time, assembled from arbirtary combinations of detected modulated symbols. Mapping this system to the BRAM interface was easy using the 8-bit WE signal. The BRAM interface itself supports any WE value per cycle. The BRAM block itself is built from 8 16kbit BRAM primitives, 1 for each byte of the 64-bit bus. Each bit of the WE signal ties to the WE of one BRAM primitive. This is why the minimum BRAM block size is 16KB (8 x 16kbit).
Offline
The MHS file of Reference design V05 contains the following section:
BEGIN plb_bram_if_cntlr PARAMETER INSTANCE = plb_bram_if_cntlr_2 PARAMETER HW_VER = 1.00.b PARAMETER c_plb_clk_period_ps = 10000 PARAMETER c_include_burst_cacheln_support = 1 PARAMETER c_baseaddr = 0x00300000 PARAMETER c_highaddr = 0x00303fff BUS_INTERFACE SPLB = plb BUS_INTERFACE PORTA = plb_bram_if_cntlr_2_port END
Should the c_clk_period_ps = 12500?
Offline
Yes, it should; that's a bug from copying that block of code from the v04 design. Thankfully it doesn't matter. That parameter gets pushed down to the PLB IPIF at the core of the controller. The PLB IFIF datasheet says "C_PLB_CLK_PERIOD_PS: This is a reserved parameter for this version of PLB IPIF. It is currently not used."
Offline
For the packets from a host PC to air, we noticed that a tx buffer is realized in SRAM and the data is transfered from EMac FIFO to SRAM through DMA. (We've discussed the necessity of this buffer in this forum. ) In the end, the data are copied from SRAM to BRAM using mimo_ofdmTx_copyPayload.
But this last step is not DMA, right?
Offline
zrcao wrote:
But this last step is not DMA, right?
Right. For transmitted packets, this step is still a memcpy.
So far, we've relied on the EMAC DMA, which can't handle this non-EMAC transfer. The latest release of the EDK finally added a stand-alone PLB DMA controller that would be capable automating this transfer, but we haven't tried integrating it yet.
An alternative that we'll probably try first is to use multiple packet bufers for the Tx PHY. For Ethernet packets, the maximum size is 1500 bytes. But the BRAM we use for the packet buffer is 16KB, enough for 10 separate EMAC packets. The PHY already has a register that sets the address offset for the Tx and Rx packet buffers inside the larger BRAM. By adjusting this offset, the PHY can read/write packets to arbitrary sub-buffers in the BRAM, avoiding the overwriting situation we talked about before. We're still working on the WARPMAC updates to implement this.
Offline