- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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, AsafLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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);- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you veryn much
Ill contact you if I will have more questions- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This forum is for C2H, not for general software/hardware questions...... moved
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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>; }- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No...i need to keep streaming the pic in order to keep the pic on

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page