problem with LCD Refreshing rate

You are going wrong in something.

If your total data is 130.5kB, you'd need much less than 1sec even if you wrote a byte every 1us. So I don't understand what your 8MHz figure means.

Please specify how is the sram connected to the Nios and the exact access time.

How is the LCD accessing the frame buffer?

It might be that it is using all the SRAM banwidth - so the nios's accesses all get stalled.

If you are interfacing directly to an LCD panel you should be able to reduce the rate at which the pixel data is clocked into the panel (even mid-frame!). I've done that in the past to avoid LCD panel dma underruns when the cpu is doing slow cycles (ARM SoC part).

hi,

my NIOS is connected to the ram with IO Ports..

16 IOs for the DATA which I want to save.

18 IOs for the ADDRESS which I'm saving the data on.

and extra line to trig the saving.

those lines connected to a VHDL model which saves the data synchroniously on the ram

ALT_IOWR(ADDRESS,xxx);

ALT_IOWR(DATA,xxx);

ALT_IOWR(Save,1);

That's a very inefficient way to access the sram!

Why you didn't use the sram interface module provided with Qsys/SOPC?

You'd get at least a tenfold improvement in access time.

Even if you need to do it that way - in order to interleave with the LCD reads, you might add a 'DATA' port that triggers the write and increments the address - which will probably reduce the writes 3-fold.

You might still need to stall the next write if the logic is still busy.

Also, do make sure you code is all optimised.

Actually why not memory-map your display buffer through your own logic?

So, during the avalon slave cycle latch the data and low address bits?

You also want to drive the avalon slave from the nios clock, and do your own clock domain crossing - since you can then do it async to the avalon cycle. You might have a clock crossing bridge.

Make sure your slave is 32bits wide - just ignore the high bits (maybe convert 8-8-8 to 5-5-5 at that point??).

If the nios can then do writes too fast, you could add a small fifo (data+address).

Hi,

i didnt use the sram module because i only want to connect the sram to the lcd...i dont wqnt any delays from the nios.

So i used different mem on the nios....

Dsl,

i didnt understand your way...can you please give me more details about your method?

1) Instead of 3 writes, do one - using the data and address lines.

2) Put clock domain crossing logic between the Avalon slave and your SRAM+LCD logic (or run everything off exactly the same clock).

If the SOPC builder has added a clock crossing bridge it will significantly increase the cycle time and slow down your transfer rates.

Since the Avalon 'bus' is slave arbited, you could almost certainly have used the standard SRAM interface and given the LCD memory reads higher priority than the nios accesses. Then your LCD driver/dma would need to do Avalon master transfers to SRAM (would these need to be burst transfers??), maybe a standard DMA block could be used - dunno.

You might need to look at the generated code for your copy loop (etc), my suspicions are that the compiler will generate better code if your C has a pointer to the Avalon slave register area - rather than using the ALT_IOWR() (and similar) defines.

I arranged for the 'global pointer' to cover both internal (tightly coupled) memory and IO, and used the linker to assign the io addresses (to give the C variables fixed addresses). This gave single-cycle accesses to them.

This does require a compiler patch to allow global pointer accesses to structures (see wiki), and wont work if you are using the data cache.

Thank you veryn much

Ill contact you if I will have more questions