Share one BRAM block between user logic and microblaze (Spartan3)

If you can live wiith single-port operation, then you can easily split the BlockRAM. The easiest to understand is a BRAM with the same width for both ports. Then you just ground one (arbitrary) address bit for one port, and tie the same (!) address bit High for the other port. Both now have half the memory space, eachhas its own half. You can also partition differently, not just 50/50. And you can assign different width to the two ports, but you have to study the address assignments. You can figure all this out with the data sheet and the back of an envelope... Peter Alfke

If you can live wiith single-port operation, then you can easily split the BlockRAM. The easiest to understand is a BRAM with the same width for both ports. Then you just ground one (arbitrary) address bit for one port, and tie the same (!) address bit High for the other port. Both now have half the memory space, eachhas its own half. You can also partition differently, not just 50/50. And you can assign different width to the two ports, but you have to study the address assignments. You can figure all this out with the data sheet and the back of an envelope... Peter Alfke

I dont want to split into two pieces. I want to attach one BRAM block to the OPB bus, so it is visible from uBlaze. Zolee

That's what a dual-port RAM does naturally. Since you use different widths for the two ports, look at the mapping info in the data sheet. You can use both ports as read or write, even write simultaneously on both ports. Watch out for two things: When both ports use the same port, and one is writing, observe the clock edges, so you do not read at the moment of writing. When both write, make sure that the clock edges are not occuring at the same time, since that would give an undefined result. You cannot harm the hardware, but you might get corrupted data. When the two addresses are different, there are no precautions necessary. Peter Alfke

Follow Peter's suggestions for the actual circuit. In order to implement it, you will need to instantiate the appropriate BRAM primitive (RAMB16sxx_sxx or if V4 RAMB16) out of the unisim library, as there are no synthesis tools that will infer it the way you want it.

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

The virtex2, virtex2p, etc. doesn't support byte-write enables on bram blocks. Though v4 does.

In the Edk world, processor memories on v2-families use 4 bramblocks to support the byte-write accesses.

Nonetheless, you can get around this requirement by modifying the opb_bram_if_cntlr that interfaces to the bram_block. The controller is a 32bit device so the datalanes match one for one. Read accesses haven't changed from the original bram cntlr so they continue to be 3 clks. Write accesses have been extending so now the access time to the bram to 3 clks. During a write access the cycles are as follows: - 1st clk presents address to the bram - 2nd clk reads data from the bram, decodes the BE signals, and muxes the matching data lanes. So the new data that contains a mix of orig. bram contents and opb write data is presented to the bram. - 3rd clk writes the new mux'd data to the bram and acks the opb bus.

H> I want to share one BRAM block (RAMB16_S9_Sxx) between microblaze and

Also, you should also consider constructing your own bram_block that support 32-bit PORTA and 8-bit PORTB. Since you're still relying on platgen to enumerate the bram_block, platgen will only deliver uniform width PORTA and PORTB, so 32-bit on both interface ports.

A modified bram_block that bypasses platgen enumeration that allows you to define 32-bit PORTA and 8-bit PORTB. In this flow, platgen does not generate a BMM for this modified bram_block.

If you need info about tapping into the PORTB interface ports, read

Paulo Dutra wrote: