Simultaneous Write/Read to on chip dual port RAM

--- Quote Start ---

Obviously simultaneous writes will cause problems.

In our case, one Avalon Master is reading while the other Master is writing.

So, the question is, will simultaneous write and read of the SAME address cause problems. It does not matter if I read "old" or "new" data as long as the write is successful and I don't read garbage or a combination of "old" and "new".

The Master that writes also uses other portions of the RAM and I'm hoping to avoid the arbitration delays with a single port RAM.

Thanks,

--- Quote End ---

What about (a) using a 2x faster clock for read and write but 1x clock for addressing (b) reading before writing. That way from the same address you first read and then write. Also (c) make the logic such that the enables for read and write are mutually exclusive i.e. when read is enabled, write is not and vice versa. That way, when the same address is on the bus, you can only do one of the two operations.

When you create an altsyncram component using the megawizard, you are given the option to specify that you want the old contents to appear on a read during write operation. It's found on the output tab under the group box entitled "Mixed Port Read During Write for Single Input Clock Ram"

This option is available for M512, M4K, and M9K blocks but not for M-RAM.

Of course for a dual-clock RAM, you're out of luck.

Jake

I'm using the on-chip RAM component under SOPC Builder. Everything is off the same clock.

Jake - I see the option you list if I add the altsyncram. It's unfortunate that SOPC Builder does not have a similar option.

There are a couple of workarounds.

1 - The write-during read behavior is just a parameter passed to the altsyncram instance (which is all the SOPC builder instantiated memory is). In Quartus on the Heirarchy tab, you can browse to the altsyncram instance in your SOPC system and view the current parameter settings. If you then right click on the altsyncram instance and click Locate->Locate in Assignment Editor; you can add or override any of the parameter settings for that altsyncram instance by adding a "Parameter" assignment. So you would add a parameter assignment where the parameter name is "READ_DURING_WRITE_MODE_MIXED_PORTS" and set the value of that assignment to "OLD_DATA".

2 - Create your own custom SOPC component that just acts as a wrapper around an altsyncram instance. Then you can set it up how you want.

Personally, I'd do number 1. Take about 10 seconds.

EDIT:

You may also want to check out this:

http://www.altera.com/support/kdb/solutions/rd04172006_685.html?gsa_pos=2&wt.oss_r=1&wt.oss=altsyncram%20parameters

as an explanation for why they do things the way they do.

Jake

--- Quote Start ---

I'm using the on-chip RAM component under SOPC Builder. Everything is off the same clock.

Jake - I see the option you list if I add the altsyncram. It's unfortunate that SOPC Builder does not have a similar option.

--- Quote End ---

You don't need that option.

The option is only for selecting the "read during write behavior", old data or new data. But you are saying you don't care. You only care about not getting garbage or a mixed result. This will never happen.

Jake,

Thanks, I agree that# 1 looks best and will try that and the link was very helpful.

Considering that I'm in a Cyclone part without MRAM it's kinda funny they don't have that as an option since there are no MRAM blocks.

I tried a web and forum searches but forgot about the knowledge database :mad: . Interestingly, various web searches I just tried didn't turn up that link you posted in the first handful of results pages although I was able to find it by searching for a quoted phrase on the page.

vjAlter,

From the Altera link "It will always set the altsyncram's parameter READ_DURING_WRITE_MODE_MIXED_PORTS to "DONT_CARE" which will result in unknown outputs when reading from the same memory location that is being written to by the other port." This parameter can be NEW_DATA, OLD_DATA, or DONT CARE

I interpreted "Unknown outputs" as garbage values.

You're saying that DONT CARE effectively means you don't care if you get NEW or OLD DATA. I'm guessing that the actual result (new vs. old) will then be part/optimizer/compiler specific. And yes, it doesn't matter whether I get new or old data.

That does eliminate some fears about changing SOPC Builder and accidentally losing the setting.

Thanks

From the cyclone II datasheet (same rules apply for other families):

--- Quote Start ---

Mixed-Port Read-During-Write Mode

This mode applies to a RAM in simple or true dual-port mode, which has

one port reading and the other port writing to the same address location

with the same clock.

In this mode, you also have two output choices: old data or don't care. In

Old Data Mode, a read-during-write operation to different ports causes

the RAM outputs to reflect the old data at that address location. In Don't

Care Mode, the same operation results in a "don't care" or unknown value

on the RAM outputs.

--- Quote End ---

There are accompanying waveforms as well. Unknown means unknown folks. It does not mean "New Data." If you are going to write and read from the same address at the same time, it had better be because you "Don't Care" what the read data is.

Jake

--- Quote Start ---

From the cyclone II datasheet (same rules apply for other families):

There are accompanying waveforms as well. Unknown means unknown folks. It does not mean "New Data." If you are going to write and read from the same address at the same time, it had better be because you "Don't Care" what the read data is.

--- Quote End ---

After re-reading the datasheet, I see you are right. However, it doesn't make any sense to me. May be you or somebody else could elaborate.

What's the purpose of having a hardware configuration mode that doesn't give you anything, except uncertainty? Why not making the "OLD_DATA" the only option, let alone the default one?

If "Don't care" would give you something, more performance, less power consumption, or whatever, then it would make sense. But none is mentioned in the datasheet. So this mode seems even silly.

The option at the MegaWizard does make some sense. It might be useful when porting the design to a different family, or changing the RAM type. But at the hardware level, I cannot understant its purpose.

It requires extra circuitry to provide the "old data" option. So there are two reasons for giving the option:

1 - The "old data" option is not available for M-RAM blocks (available in Stratix series). So if you select the "old data" option and have chosen "Auto" as the RAM type, you are restricting the synthesis tool as to what types of RAM blocks it can use. You are taking away some flexibility from the compiler as it can no longer use M-RAM.

2 - Under certain circumstances you can get a performance decrease when using the "old data" option. For most designs, this data path will not be the limiting factor.

Jake