[SOLVED] Inquiry about implementing RAM model in VHDL

Hello everyone

I have some questions about implementing RAM in VHDL.

first can we generate a RAM with to different address, one for writing and the other is for reading?

second which is better, using the IP core to generate RAM or programming it by my own code?

Serwan Bamerni said:

first can we generate a RAM with to different address, one for writing and the other is for reading?

Click to expand...

Yes

second which is better, using the IP core to generate RAM or programming it by my own code?

Click to expand...

There are advantages and disadvantages either way, choose based on some of the criteria mentioned below.
- If you write your own, you can typically use it with parts from any FPGA supplier
- Using an IP core generator is usually fairly quick and straightforward and typically it does work
- Using an IP core generator usually means you can't use that core if you are using a different device manufacturer
- Memory cores are particularly easy to write (actually copy). Pick up the user's guide for your tool and flip to the section where they describe exactly how to write the code. Memory cores will typically be about a dozen lines of code for the implementation.

Kevin Jennings

The primary advantages are:
1.) you can use generics for sizing.
2.) you can use other vendors (usually).

The primary disadvantages are:
1.) failure to infer RAM can result in very long builds. failure to infer RAM is not always obvious.
2.) you must provide simulation warnings for read/write conflicts, which are not always obvious.
3.) not all supported features can be inferred.

In terms of addressing, FPGAs often provide both "simple dual port" -- 1 read 1 write as well as "true dual port" -- 2 reads, 2 write or 1 read+1 write.


disadvantage #1 can be overcome by ensuring BRAM is inferred. disadvantage #2 is more concerning, as r/w conflicts can result in simulation mismatch and the definition of a conflict might be confusing.

vGoodtimes said:

2.) you must provide simulation warnings for read/write conflicts, which are not always obvious.
...
disadvantage #2 is more concerning, as r/w conflicts can result in simulation mismatch

Click to expand...

If you have this issue, you have a more fundamental design problem. When there is a simultaneous read/write, the memory will work just fine. It will read back what was in memory and return it, no issues. If the reader is reading something that is multiple addresses then yes there might be an inconsistency if one address has been updated the other one(s) have not. However, this is not an issue for the memory to detect or solve. The issue is that the reader is reading something that is not ready. The solution is that the writer needs to signal the reader when it has completed writing and it is OK to be read.

and the definition of a conflict might be confusing.

Click to expand...

I'd be interested to hear what your definition of a conflict could be and how any sort of simulation memory warnings would be of benefit. It could be we're talking about different things.

Kevin Jennings

vGoodtimes said:

.
2.) you must provide simulation warnings for read/write conflicts, which are not always obvious.

....disadvantage #2 is more concerning, as r/w conflicts can result in simulation mismatch and the definition of a conflict might be confusing.

Click to expand...

Afaik, both altera and xilinx now allow inference of read before write or write before read behaviour depending on whether you use a signal or a shared variable as the storage. (Non-blocking or blocking in Verilog). Xilinx has supported this for much longer.

But Im with Kevin - read/write conflicts are more a design issue than ram problem. But having the asserts is only going to help diagnose the problem.

Perhaps you can't infer a BRAM with a read port and a write port in write-first/no-change modes (sync), or read-first mode (async). The latter is the one that is really bad -- a conflict occurs if a read and write occurs to the same range of addresses, not just the exact same address. These are for Xilinx parts.

In some cases, it is valid to assume a read and write to the same address will return defined data -- either the newly written data or the previously written data. The read-write conflicts I am talking about are the ones that matter from a device level, where this expectation isn't correct.

thank you for your fruitful answers and discussions
it is look that I will go for using the IP core to implement the memory