Simultaneous Write/Read to on chip dual port RAM

FYI: We just ported the design to Quartus 8.0 SP1. Under that version there is now an option in the Component Editor for Old Data / Don't Care under a dual Port RAM.

So Altera has updated the Component in this latest version to eliminate the problem of having to set the parameter manually as described earlier.

Thanks for all your help.

Although there is an 'old data' / 'don't care' option, I think we've discovered (the hard way) that this gets ignored (in 9.1sp2 at least) because both clocks are specifed - even when they are identical.

Quartos 12 has an extra 'tick box' for 'single clock operation'.

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

is just a lame excuse!

If you request OLD_DATA then it shouldn't be discarded, but constrain the types of memory that can be used.

Without OLD_DATA you get the old or new copy of each bit, changing randomly with different silicon and different builds of exactly the same vhdl.

Hi, sry for digging out this rather old thread. But I think it might be the most suitable thing to do. My problem:

I have a EP4CE55 FPGA. On there I have a DPRAM attached to a NIOS with cache. From the other side I'd fill the ram with new process dataas its coming in using a DMA. For performance reasons I'd lke to attach it as tightly-coupled memory - only supported for dual-clock mode. But then the DPRAM doesn't support the "OLD DATA" option for read-during write access. Will the tightly coupled memory increase performance significantly? In any case to access this area of data I will bypass cache (alt_remap_uncached).

Is the decision really only between NEW_DATA and OLD_DATA or is it possible to really get garbage?

Further on scanning the Altera Documentation a I found the following on page 3-17 of the Cyclone IV Device Handbook:

--- Quote Start ---

For mixed-port read-during-write operation with dual clocks, the relationship

between the clocks determines the output behavior of the memory. If you use the

same clock for the two clocks, the output is the old data from the address location.

However, if you use different clocks, the output is unknown during the mixed-port

read-during-write operation. This unknown value may be the old or new data at the

address location, depending on whether the read happens before or after the write.

--- Quote End ---

This would imply that I can just use it in Dual Clock Mode, connect the same clock and get the OLD_DATA behaviour? Or am I getting this one wrong?

Thanks!

With M9K we got garbage - well the old or new value of each bit, not of the whole word.

The error rate varied by device and by build. Minor changes to the logic caused different chips to fail.

The Nios cpu reads tightly coupled memory every clock cycle, discarding the data if the instruction isn't a memory read or if the address doesn't match the memory block.

If the instruction pipeline stalls (eg on an Avalon cycle) it needs to keep the data even though the address has been updated. On M9K this is done by deasserting clken (dual clock mode) or asserting 'address hold' (single clock mode).

I don't know anything about DPRAM blocks.

However if you are filling in buffers using dma then you probably don't want to process a mixture of the old and new data for an entire buffer - so a corrupt byte in the middle of such a buffer won't be read anyway.

Using tightly coupled memory will give better performance, how significant it is depends rather on what your code is doing.

Thanks for the answer. This is the problem I'm trying to solve just now. How can a implement a mechanism that allows me to only process complete buffers. I thought about having a control structure in the DPRAM that manages a page flipping mechanism. But again within this control structure I could get corrupted data.

A avalon mutex could be used to handle this problem. I could also retreat to using a single port ram. In this case the avalon arbitration would handle the accesses - of course not being able to implement it as tightly coupled memory.

The CPU is basically performing closed-loop control tasks. The data in the dpram will for example contain the desired value for the controllers. This comes down to one acces per process variable per cycle. The target control frequency would be something around 3kHz. I can not judge how much in this case the performance would be in/decreased using tightly-coupled memory.

Thanks!

You can safely detect 'changed' on a word even without OLD_DATA. In the simplest case if the word changes from 0 to 1 (and back) I don't believe you'll ever read an illegal value.

So you could, for example, detect the last word of the buffer being changed by writing a reserved value to it, and waiting for it to change.

But why not put the control bit somewhere outside the shared memory - like a PIO bit in the avalon slave with the control registers for your logic that is writing the buffers?

Then your control loop polls the pio slave to determine when the buffer is available.

Once again thanks for your answer!

Actually my slave is another NIOS that is interfacing two Ethernet MACs and handling UDP communication. If a relevant packet arrived it is copied to the DPRAM using a DMA. The idea was to avoid another copy on the application side - eg in the attached sdram - and use the data in the dpram. So it boils down to inter-cpu communication mechanism.

I have a whole control data block in the beginning of the dpram that handles this communcation - but little of it is really critical.

I also considered the PIO alternative as a mean of async communication. I should run the PIOs in the same clock domain as the CPUs- not slower - otherwise I'll build a bottleneck?!?

Will the PIO solution outperform a mutex based solution?

I have that feeling that there's a nifty (and easy) solution for it by somehow juggling with the possible bit change states as you suggested above.

I didn't quite get what you meant with that:

--- Quote Start ---

The Nios cpu reads tightly coupled memory every clock cycle, discarding the data if the instruction isn't a memory read or if the address doesn't match the memory block.

If the instruction pipeline stalls (eg on an Avalon cycle) it needs to keep the data even though the address has been updated. On M9K this is done by deasserting clken (dual clock mode) or asserting 'address hold' (single clock mode).

I don't know anything about DPRAM blocks.

--- Quote End ---

Can you point me to the documentation where this is elaborated?

Thanks a lot!

If you just detect a change to a memory location it wont matter if the value is being updated at the same time.

If you need the new value, keep reading it until you get the same value twice.

I don't think the way the nios accesses tightly coupled memory is documented anywhere. We worked it out from signaltap traces.