# Verilog memory designs with multiple read/write ports - poor circuit performance when synthesized?

I am interested in designing (with verilog) some memory structures that have multiple (let's say 3) read/write ports. I've been doing some studying on architecture and what I've heard is that these are not trivial hardware implementations, and can create a lot slower circuits.

With behavioural verilog I would imagine it's quite simple, something along the lines of:

always @ (posedge clk) begin
end
//something similar if I want multiple writes
end


Assuming it synthesizes, will I have a crappy and slow circuit, and why? Can it be alleviated by going with a more custom design using gates instead of behavioural coding?

Thanks

• Multiple writes is tricky: you need to prioritize the case where more than one port is writing to the same address. If you just need one write port and N read ports, you can just use N regular dual-port RAMs that have all their write ports tied together. In other words, you actually store N copies of the data, each copy of which can be independently addressed. – Dave Tweed Dec 9 '12 at 21:00
• Is what you're referring to the same as "banking"? – JDS Dec 10 '12 at 19:46
• Um, no, I've never heard that term applied to this. Usually, "banking" refers to having multiple memories that contain different data that can be switched into the same physical address space, one at a time. – Dave Tweed Dec 10 '12 at 21:30

Firstly, are you synthesizing to an FPGA?

This paper from Cypress shows a dual-port RAM as a block diagram. It's not quite clear from there, but the dual-port array in the middle is an array which has a double set of lines: 2 row selects, 2 write column sets, 2 read column sets.

Scaling beyond 2 is difficult because then you need 3, 4 etc sets of wires, and your RAM density goes down as you run out of space for wires.

If you write Verilog which implies more than 2 ports, the synthesis tool will build it out of flops with multiplexors on the front, consuming far more space than RAM cells.

Why do you actually need multiple ports? How large a RAM do you want? Building a memory arbitrator on the front of a normal RAM may be the solution you want.

• Hi, yes this is for an FPGA. Eventually I want to make an instruction cache where I can fetch 4 entries at a time. But perhaps my issue is simpler, because the input will be PC, but coming out I will always expect the words located at [PC], [PC+4], [PC+8], [PC+12]. So, not totally random access. – JDS Dec 10 '12 at 19:48
• Are you actually going to be issuing four instructions per clock, then? The normal solution is to make the memory or cache wider so you have a cache line of 64 or 128 bits. – pjc50 Dec 11 '12 at 13:12
• So you're saying just burst out more data at a time because it will be sequentially located? That makes sense. My only concern then is what happens if 3 instructions are in one cache block, while the last is on the other side of the boundary, in another block. Thanks for telling me what the normal solution is, these are the things I don't know and am trying to learn =) – JDS Dec 12 '12 at 5:05
• You can burst them out into some sort of local buffer or FIFO, so they're always ready in advance ("prefetch"). Could you confirm that you're executing four instructions per cycle, every cycle? – pjc50 Dec 12 '12 at 9:52
• Well I can't confirm, it's just an idea I'm exploring for a research project. I would like to fetch 4 instructions per cycle, every cycle, to try and feed an out-of-order superscalar CPU. I suppose it doesn't have to be 4 every cycle - bad events like i-\$ misses can slow me down. – JDS Dec 12 '12 at 19:13