I need some help of creating shared ddr sdram memory

I did some measurements for random uncached SDRAM accesses.

IIRC the first 2 writes happen without significant delay. I suspect that the first one is actioned asynchronously, and the second is put into an SDRAM 'line' buffer (32 bytes ?) in case the next transfer is to the same SDRAM line.

It is also likely that SDRAM reads always read a memory line, and Avalon reads that match the buffered data (eg sequential access) are completed without doing an actual memory transfer.

However cache transfers should be faster since (I think) they get pipelined.

Unfortunately the nios cpu is missing the instruction to create a valid cache line without doing the memory read (useful when you know you are going to modify the entire line). I think there are some other missing cache functions that rather hurt attempts to run unix os.

Thank you for everyone's information.

So I think tight coupled memory would be a good choice .However, I wonder why I should use the dual-port mode?

If I have 2 processors , maybe configuring as dual-port mode is better because I can connect them to each processor.

However, if I have more than 2 processors and I want to have a common shared memory, I think dual-port mode is not necessary at all and I should connect all of the processors to the common slave of the memory and use mutex to coordinate the access.Right?

:D;)

That is correct, the reason for this is that tightly coupled memory cannot stall the processor pipeline, so the slave port cannot be shared as arbitration could cause waitstates.

From my own testing I find that worst case random access patterns to SDRAM will drop the performance down to 33% efficiency. Best case is around 97% but you would need something like a DMA to hit that. A cache I suspect should achieve around 90% as most SDRAM controllers have built in management for the rows/columns/banks (or whatever SDRAM people call those terms). Due to the mapping of the cache lines in the address space the first access will typically have some overhead but the next seven accesses (assuming 32B/L) should enter the controller efficiently assuming the arbitration share is set to 8 or greater so that other masters don't get in and start thrashing the memory.

Hi,

I have implemented the tightly coupled memory as the shared memory.

However ,I have found it is really difficult to implement the communication software program of the shared memory.

Originally I used the mailboxes core and the API mailbox_pend() can automatically block when there is no message and unblock when there is a message , which is very easy to be implemented in a process.

However , since now I use hardware mutex for the shared memory, there is no such API. The problem is that this is a 'mutex' not a 'samephore' which means it cann't be released by other processors! Since there is no samephore , I think I can not implment the communication in a while() loop as the classical producer&consumer problem. If Processor1 has put some data into the shared memory, Processor2 can't know when the data is ready.Even Processor2 knows, Processor1 will not know when Processor2 has finished reading the data.

Am I right? I am not a CS major so there might be some misunderstanding:(

Ummmmm I forget.... I haven't done this stuff since school but you can take a look at this to see if it gives you any ideas: http://www.altera.com/support/examples/nios2/exm-multi-nios2-hardware.html?gsa_pos=4&wt.oss_r=1&wt.oss=multi That design shares data between two CPUs using a Mutex and on-chip RAM

If I remember correctly the mailbox was essentially two mutexes, a 'binding' to some physical memory in your system, and some software protocol implemented in the driver for the component. Maybe looking at the driver will give you some ideas of what to do while you eliminate anything you don't need that might slow it down.

Hi, BadOmen,

Thank you for your reply. I am very familiar with the example you provided. Though it created a hardware mutex, it doesn't use it.All the communicaiton happens using the mailbox.

I will check the mailbox driver anyway:) It seems that there is no easy way to use mutex as convinent as mailbox. However, mutex should be faster:0

Yes. If I can use multiple semaphores,then it will work well because that's a generic producer/consumer problem.

However, different from semaphores, Mutex can only be released by the one who lockes it . So mutex can be used to protect the shared memroy ,howerver it can not be used to coordinate different task of different processors, in my opinion:(

You'll need to use Dekker's algorythm on uncached memory to do any form of inter-cpu synchronisation.

Generating a 'spin lock' is easiest, and, in fact, all the other synchronisation schemes are based on them.