Hi, everyone:), My system is like this : Using NEEK, I created 2 processors both running in the ddr sdram. Processor1's reset vector offset is 0x100 and exception vector offset is 0x120. Processor2 's reset vector is 0x1000000 and exception vector offset is 0x1000020. As you can see, I didn't use the first 0x100 memory address space because I want to use it as the shared memory. Then in my software of processor2, I created a float pointer pointing to the address DDR_SDRAM_BASE defined in the system.h and write some value to it. Processor1 will read and print the value pointed by address DDR_SDRAM_BASE in its program. I think by doing this, processor2's change of the sdram should be reflected by processor1. Howerer, processor1 always print out 0.000 no matter what processor2 writes. I feel confused :confused: Can anyone help?

If your CPUs have a data cache it is possible that they won't detect changes in the main RAM, when the value to read is already crached. Either change your pointers to non cached, using the alt_remap_uncached() function, or use the IORD/IOWR macros to acces the shared memory. Those macros always bypass the cache.

You'd be better of allocating a M9K block and dual porting it to both cpu as 'tightly coupled data memory' and using that as the shared space (just make sure you don't do concurrent writes to the same address). In either case you'll need to use something like Dekker's algorythm for mutual exclusion.

1. Thank you for 'Daixiwen' 's answer. Right. If I remove the data cache, it works well. 2.For 'dsl',I am always feel confused about the difference between tightly coupled memory and the normal on-chip ram. Tighly coupled memory need to be connected to the tight coupled master port of the cpu while the normal on-chip ram can be connected directly to normal master port.Right ? Can I use the normal on-chip ram as the shared memory in my design? Thanks

Tightly coupled memory is a regular on-chip memory configured to be 32-bit wide, read latency of 1, and connected to only a single tightly coupled master. This gives a deterministic access time of 0 cycles for writes and 1 cycle for reads. Other memories in your system might be multi-mastered or accessed by the cache both of which will cause non-deterministic access times. The nice thing about using tightly coupled memory for shared memory is that a) it's the fastest memory you can use b) accesses to it bypass the cache. So you could dual port an on-chip memory, connect a tightly coupled data master from each CPU to it, and use some sort of algorithm/hardware to prevent data hazards. You could use the mutex hardware component for example to make sure both CPUs don't attempt to access the same memory. I on the other hand prefer to use FIFOs to move data between processor cores since the data hazards are not a problem that way. This method doesn't scale when you have a lot of processors that need to communicate with each other since you have to use a lot of FIFOs to do that. I recommend you get your software up and running first and if you need more speed then determine if other shared data mechanisms may be needed.

Hi, BadOmen, Exactly. Originally I used the mailbox core to do the on-chip shared memory communication. I think the mailbox is kind of like the FIFO as you said. Howerver , it is very slow. The speed is about one tens of the Ethernet communication!( I am not sure whether I have done something wrong). So now I am thinking using the shared memory and hardware mutex core. On-chip memory is a limited resources. I am thinking whether I can use the ddrsdram or the sram to build the shared memory. So you mean if I use the regular on-chip memory connecting to the regullar master port of the processor, it will not bypass the cache.Rihgt?

I need some help of creating shared ddr sdram memory

23 Replies

Altera_Forum
Honored Contributor
15 years ago
If your CPUs have a data cache it is possible that they won't detect changes in the main RAM, when the value to read is already crached.
Either change your pointers to non cached, using the alt_remap_uncached() function, or use the IORD/IOWR macros to acces the shared memory. Those macros always bypass the cache.
Altera_Forum
Honored Contributor
15 years ago
You'd be better of allocating a M9K block and dual porting it to both cpu as 'tightly coupled data memory' and using that as the shared space (just make sure you don't do concurrent writes to the same address).

In either case you'll need to use something like Dekker's algorythm for mutual exclusion.
Altera_Forum
Honored Contributor
15 years ago
1. Thank you for 'Daixiwen' 's answer. Right. If I remove the data cache, it works well.

2.For 'dsl',I am always feel confused about the difference between tightly coupled memory and the normal on-chip ram. Tighly coupled memory need to be connected to the tight coupled master port of the cpu while the normal on-chip ram can be connected directly to normal master port.Right ? Can I use the normal on-chip ram as the shared memory in my design?

Thanks
Altera_Forum
Honored Contributor
15 years ago
Tightly coupled memory is a regular on-chip memory configured to be 32-bit wide, read latency of 1, and connected to only a single tightly coupled master. This gives a deterministic access time of 0 cycles for writes and 1 cycle for reads.

Other memories in your system might be multi-mastered or accessed by the cache both of which will cause non-deterministic access times. The nice thing about using tightly coupled memory for shared memory is that a) it's the fastest memory you can use b) accesses to it bypass the cache. So you could dual port an on-chip memory, connect a tightly coupled data master from each CPU to it, and use some sort of algorithm/hardware to prevent data hazards. You could use the mutex hardware component for example to make sure both CPUs don't attempt to access the same memory.

I on the other hand prefer to use FIFOs to move data between processor cores since the data hazards are not a problem that way. This method doesn't scale when you have a lot of processors that need to communicate with each other since you have to use a lot of FIFOs to do that. I recommend you get your software up and running first and if you need more speed then determine if other shared data mechanisms may be needed.
Altera_Forum
Honored Contributor
15 years ago
Hi, BadOmen,

Exactly. Originally I used the mailbox core to do the on-chip shared memory communication. I think the mailbox is kind of like the FIFO as you said. Howerver , it is very slow. The speed is about one tens of the Ethernet communication!( I am not sure whether I have done something wrong). So now I am thinking using the shared memory and hardware mutex core.

On-chip memory is a limited resources. I am thinking whether I can use the ddrsdram or the sram to build the shared memory. So you mean if I use the regular on-chip memory connecting to the regullar master port of the processor, it will not bypass the cache.Rihgt?
Altera_Forum
Honored Contributor
15 years ago
That's correct, the mailbox component is similar to a FIFO only parts of it are implemented in software which is why it's slow when sending small messages back and forth. The good part is that it's scalable to any memory in your system. Using the FIFO approach I either drain the FIFOs until they are empty or map the FIFO 'used' signal so that I know ahead of time how much data I can safely read out of it if I don't want to end up blocking the processor when the FIFO is empty. Sometimes I make this interrupt based as well.

The on-chip memory if it's connected directly to the (regular) Nios II data master when the data cache is enabled will be cacheable. Think of the tightly coupled master and caches being in parallel inside the processor, the decode to determine if the access is tightly coupled, cacheable, or uncacheable happens concurrently. Just remember that the Nios II JTAG debugger can't download instructions into tightly coupled memory unless there is a data master connection to the tightly coupled memory (regular or tightly coupled).

If you decide to make the on-chip RAM cacheable you can carve out some of that memory and remap it to be uncacheable so that you don't need to use IOWR/IORD to access the shared data. If you do this use the HAL calls that remap the pointer and don't explicitly flip the MSB of the pointer manually since there is some cache considerations that the HAL takes care of.
Altera_Forum
Honored Contributor
15 years ago
Dear BadOmen,

Thanks for your explanation.

I think it makes no sense to have a cacheable shared memory between processors,right?

So if I understand correctly, I only have the following 3 choices:

1. Remove the data cache;
2.Use tight coupled memory;
3. Use regular on chip memory or other memory(e.g., SDRAM,SRAM) and use nono-cacheable instructions(like IOWR/IORD or remap the memory as uncacheable as you said)

Am I right? Then I think I will see how much resource do I have and choose between choice 2 and choice 3 :)
Altera_Forum
Honored Contributor
15 years ago
Alse remember that alt_remap_uncached() doesn't flush the cache for the addressed area, nor can it ensure (and it doesn't error) that the area contains entire cache lines.
Both these can lead to unexpected read/write transfers from the cache to the memory.
Altera_Forum
Honored Contributor
15 years ago
If you want the fastest memory transfer method, use an on-chip memory with a dual port and connect each port to a tight coupled memory port on each of the CPUs.
If you need more memory than what you have available in the FPGA, use external memory. If the external memory is an SSRAM, you can use uncached pointers or uncached macros. If the external memory is as SDRAM you will have a huge speed loss on consecutive accesses without a cache, so I would recommend to use the data cache and the flush functions. But in that case you must be sure that your memory blocks are aligned on cache lines, because as dsl says, nasty things happen when different blocks share lines and that you do flushes.
Altera_Forum
Honored Contributor
15 years ago
Thanks for your comments.

Forum Discussion

I need some help of creating shared ddr sdram memory

23 Replies

Recent Discussions

USING SIGNAL TAP TO MONOTOR AVALON_BUS WITH NIOS DESIGN

DK-DEV-AGI027-RA: JTAG chain broken after Nios V Hello, FPGA recovery fails

NIOS does not start after SW download (timing issue?)

Nios V license

reCAPTCHA Verification failed