Accessing on chip memory

Altera_Forum · ‎04-25-2005

I recently added 1KB of on chip memory and am trying to write to this location without success. There is still external SRAM in our design; however, I'd like to utilize the on chip memory to minimize trips out on the bus. I know it's easy to turn on cache, but I'd still like to figure this out.

Essentially I'm trying to someting like the following:

char *on_chip_memory = ((char *)ONCHIP_MEMORY_0_BASE);

*on_chip_memory = 0;

.. do something else with application

// now set on_chip_memory value

*on_chip_memory = 1;

It appears that no matter what value I try to set in the on chip memory space, it always has the contents of the original .hex file. I have chosen RAM (read/write) option from SOPC Builder, but still nothing.

I can see there's an option in the system library properties that allow me to change .rodata and .rwdata (currently set to external sram); however I don't want to alter my current system. What I'm looking/hoping to do is add this 1KB of on chip memory with read and write abilities in addition to the external sram.

I'm somewhat confused since I've been able to do this in the past with Nios I designs. Am I missing something or doing something wrong?

Thanks,

-Mark

Altera_Forum · ‎04-25-2005

My best bet is that

A) you have forgotten to connect the data-bus to the processor. You do that in sopc builder.

Second posibilty is the cache..

B) Change your pointer to..

char *on_chip_memory = ((char *)(0x80000000 | ONCHIP_MEMORY_0_BASE) );

Setting MSB of the address bypasses the cache.

C) Optimizer is too 'clever' in this case. Depending on your code and optimization level, you may get this kind of seemingly 'strange' results because the optimizer has seen that you effectively are not doing anything with the data. It simply removes the code. Set optimization to off in nios IDE. You can also counteract optimization by using volatile intermediate variables.

volatile char vChar;
vChar = on_chip_memory;
on_chip_memory = vChar;

But I recall to have read somewhere that

volatile char *on_chip_memory = ((char *)ONCHIP_MEMORY_0_BASE);

does NOT help with this kind of cache problems. In this case its the pointer which is volatile, not the data. Maybe someone else could comment on this?

D) You are right not to change the .rodata and .rwdata. This wont help for what you are doing.

Altera_Forum · ‎04-25-2005

Thanks for the [wonderful] tips.

I backed off a little on the compiler's optimizations and added a few additional 'volatile' declarations and everything appears to be working now.

Thanks,

-Mark

Altera_Forum · ‎04-25-2005

You should be able to use compiler optimizations as long as the volatile declation is in place.

However, you should note that for the Nios II compiler, "volatile" means "do not optimize" (which is the traditional meaning of volatile), it does NOT prevent the processor from caching it. Depending on your application this may or may not be an issue.. if you have some other master (CPU, DMA, other peripheral) which needs to read or write the data of that on-chip memory, you should probably bypass the cache.

To bypass data cache (if present), there are a few ways:

- The other person's reccomendation to set bit-31 is possible. All accesses to the pointer will bypass the cache

- Use the IORD and IOWR macros as they call special instructions that are guaranteed to bypass the data cache

- Access the pointer normally and when you are done writing your buffer and wish to update the external memory, flush the data cache.

IORD, IOWR, and the cache flushing should be discussed in the processor reference handbook.

Altera_Forum · ‎04-26-2005

Note that if you use bit-31 then you need to mark your data volatile as otherwise the compiler will optimise it out.

It knows that IORD/IOWR are special so will not optimise these out, even when they appear to do something.