Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
977 Views

problem with LCD Refreshing rate

Hello, 

I recently designed a model in Quartus which connects to a color LCD device and shows what ever is on the SRAM. 

 

I am using the NIOS processor to fill the RAM with the relevent Data (PICS,ANIMATIONS and so). 

 

One problem is that the reading cycle time of a byte is 55nsec. 

the LCD can work up to 33MHZ(840X480) so I'm not able to fully use the LCD's Resolution(I'm using 8 MHZ which is 480X272 Res). 

 

another Problem is the Data size (24 bits - 8 red + 8 green + 8 blue). 

I cant write 2 cycles on the sram for every Pixel because it doesent match the 8 MHZ timing. 

 

so what i did is to normalize the data bits to 15 bits per each pixel (5r+5g+5b) and decrase the lcd's speed to 8 mhz 

 

for every screen I want to load I need to fill up the ram with 480*272 Addreses(130.5Kbytes). 

 

The problem is that the NIOS clk seem to be 50MHZ but the actual one is much slower,so it takes me about 2 secs to fill up the sram

 

that gives me a slow refresh rate on the LCD. 

 

are there any sugesstions to make the NIOS RUN faster? 

Is my techniqe OK?  

 

are there any other good methods to work with LCD so I would able to exploit the SPEED and pixel bits? 

 

thanks for all the helpers, 

Asaf
0 Kudos
24 Replies
Altera_Forum
Honored Contributor I
95 Views

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.
Altera_Forum
Honored Contributor I
95 Views

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).
Altera_Forum
Honored Contributor I
95 Views

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);
Altera_Forum
Honored Contributor I
95 Views

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.
Altera_Forum
Honored Contributor I
95 Views

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.
Altera_Forum
Honored Contributor I
95 Views

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).
Altera_Forum
Honored Contributor I
95 Views

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?
Altera_Forum
Honored Contributor I
95 Views

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.
Altera_Forum
Honored Contributor I
95 Views

Thank you veryn much 

Ill contact you if I will have more questions
Altera_Forum
Honored Contributor I
95 Views

This forum is for C2H, not for general software/hardware questions...... moved

Altera_Forum
Honored Contributor I
95 Views

Hi 

i tried to use the cross bridge 

 

now the add and dat lines doesnt work well . 

It seems like the dat line became 8 bit instead of 16  

and also,timing still very slow comparing to the clock on the cpu 

any suggestions?
Altera_Forum
Honored Contributor I
95 Views

I remain on my original advice: use the standard sram interface module provided by sopc builder. Then you can easily tune all the parameters, access timing, waitstates, data and address width. 

For extra performance you can connect the sram to a Nios TC port, instead of the main data master. This will avoid stalls due to arbitration with other MM devices. 

Anyway, I don't see a reason to optimize further; I think you can attain a good refreshing rate without effort.
Altera_Forum
Honored Contributor I
95 Views

Ok then... 

I just need to know what is the way to read and write data from the nios to the sram 

thank u very much
Altera_Forum
Honored Contributor I
95 Views

I can't understand your concern with sram. You access sram like any other kind of memory. 

e.g. you can use sram base address with IOWR/IORD for direct access; 

alternatively you can map C variables/buffers (or even an entire memory section) to sram physical addresses. 

Example: 

int * lcd_buffer = (int*)LCD_SRAM_BASE;  

for (i=0; i<num_of_pixels; i++) { 

lcd_buffer[i] = <your graphic data>; 

}
Altera_Forum
Honored Contributor I
95 Views

As Cris72 said - you can also do that into your own Avalon slave. 

 

You do need to write one - it isn't hard, and the 'PIO' slave won't really give you the flexibility you need. 

 

You also need ensure your slave defines all 32 data bits - even if you ignore the high ones. 

 

If you set a C pointer to IO, remember to set bit31 so that the data cache (if used) is bypassed. 

 

One 'cheat' method I've sometimes used to determine which parts of a system are taking the time, is to do some parts twice. If it makes no difference it isn;t the problem!
Altera_Forum
Honored Contributor I
95 Views

thanks... 

I understand how to write data to the ram...the tricky part with your suggestion is to read the ram without using the nios. 

Thats what i have left to do...how can i write from the nios and read from the mode? 

I dont want to spend time on presenting the picure from the cpu..just want to set the data from the cpu and read it from out side the processor...any suggestions?
Altera_Forum
Honored Contributor I
95 Views

I can't get the point. Probably I still don't understand what you want to do.  

Please clarify. 

- where your picture data is stored? 

- how are you supposed to get this picture data? 

- do you want to use Nios for the transfer or not? 

- is LCD actually seen as a sram or a more complex interface is required? I mean, if you write a sram address, the related pixel changes on the display? Or maybe a special protocol is involved for transferring the display image?
Altera_Forum
Honored Contributor I
95 Views

 

--- Quote Start ---  

I can't get the point. Probably I still don't understand what you want to do.  

Please clarify. 

- where your picture data is stored? on the sram addresses 

 

- how are you supposed to get this picture data?from an external vhdl model which reads from the sram and sends the pic according to the svreen protocol 

 

- do you want to use Nios for the transfer or not?only for the writing 

 

- is LCD actually seen as a sram or a more complex interface is required? I mean, if you write a sram address, the related pixel changes on the display? Or maybe a special protocol is involved for transferring the display image?special serial protocol...you can look at terasic's touch screen 

--- Quote End ---  

 

 

http://www.terasic.com.tw/cgi-bin/page/archive.pl?language=english&no=213
Altera_Forum
Honored Contributor I
95 Views

Q: Is there display memory on the display module? or do you have to continuously clock the pixel data to it (from the dev board SRAM)?

Altera_Forum
Honored Contributor I
27 Views

No...i need to keep streaming the pic in order to keep the pic on

Reply