Shop OBEX P1 Docs P2 Docs Learn Events
Can you drive a VGA display with an external SPI SRAM IC? — Parallax Forums

Can you drive a VGA display with an external SPI SRAM IC?

I have some shiny, new 128K SPI chips I want to play with.  They are rated at 20 MHz.  So I was wondering, could they be used to drive a VGA display?  According to http://www.tinyvga.com/vga-timing/640x480@60Hz, lo-res 640x480@60Hz has a pixel frequency of 25 MHz.
So unless I am reading this wrong, it would seem SPI is too slow.  But then I was thinking...maybe there are at least two other ways this could be done?
First, the SRAM can be driven in SDI mode.  I'm not really that familiar with SDI mode but I believe it doubles to 40 MHz but the SPI host is more complicated.
Second, I really don't care about 640x480 resolution.  So could it be done at half the resolution?  Perhaps 320x240 and 6 bit color?
Or, am I incorrect because the pixel frequency is the same (25 MHz) regardless of what the pixel density is?
Anyway, your thoughts are appreciated.
Thanks!

Comments

  • What's the part number of your RAM chips?

    -Phil
  • You can't do it with SPI RAM because the MHz rating is the clock rate of the SPI signal, which takes a fair amount of setup in addition to the data.  This has been done with SRAM but it takes a lot of I/O pins.
  • I was afraid of that.  I have some 55ns SRAM (512k).  I might try some experiments with that and see what I can do.

  • jmgjmg Posts: 15,173
    First, the SRAM can be driven in SDI mode.  I'm not really that familiar with SDI mode but I believe it doubles to 40 MHz but the SPI host is more complicated.

    SDI means Dual width, and SQI is Quad width.
    Those parts have no Double-edge options.

    I have some shiny, new 128K SPI chips I want to play with.  They are rated at 20 MHz.  So I was wondering, could they be used to drive a VGA display?  According to http://www.tinyvga.com/vga-timing/640x480@60Hz, lo-res 640x480@60Hz has a pixel frequency of 25 MHz.

    That 20MHz spec is with a 2.5V corner, so I would expect you can (over)clock at 25MHz at 3.3V+


    Second, I really don't care about 640x480 resolution.  So could it be done at half the resolution?  Perhaps 320x240 and 6 bit color?

    Sure. You would use the parts in SQI (4 bits wide) which gives a choice of 4/8/12b colour.
    You could test at 25MHz/2 and change to 25Mhz when you have that working.
    Handling the mix of Write and Read will be the challenge, as it takes many clocks to set Address.
    Simplest would be to write only in frame flyback, at least initially.
    During visible scan, you clock and pause (which is easy to do on a Prop)

    You could choose a clamped DAC, to allow you to go to background during a write burst, if flyback time write was too constraining..

  • kwinnkwinn Posts: 8,697

    I'm not absolutely sure but based on
    the following information from the data sheet it sounds like
    producing vga video at half the horizontal rate/resolution is
    possible, even full vga 640x480 if the memory can be clocked at
    25MHz.





    Sequential operation under mode
    description on page 5 and timing diagram on page 8.





    Dual serial mode description and timing
    diagram on page 13.





    Three chips (1 each for r, g, b) would
    be 524288 x 6bit pixels, which is more than what is needed for 640x480
    resolution.
    As jmg suggested, a similar chip with quad spi might be a better choice. A 1Mbit qspi chip would not be large enough for 640x480 (needs 307200 bytes) but it could definitely do 320x240 with memory left over.



  • kwinnkwinn Posts: 8,697
    Now something like this CY7C1049DV33-10ZSXI would do 640x480x8bit color, but would need a lot of pins or some additional hardware.
  • TubularTubular Posts: 4,702
    edited 2015-07-15 05:16
    You can't do it with SPI RAM because the MHz rating is the clock rate of the SPI signal, which takes a fair amount of setup in addition to the data.  This has been done with SRAM but it takes a lot of I/O pins.


    Yes you have to set up, but that can be done during blank intervals.  Then for every subsequent clock data appears on the bus during each clock cycle.   
    Don't get hung up on the 25MHz (unless driving dotclk driven lcds).  Note that the blanking cycles are nice and divisible, so you can easily aim for 0.75* those specs, which gives you 480 horizontal pixels, but a clock rate of 19 MHz which is within spec.
    You don't necessarily need a huge number of pins.  One other trick is to use QSPI to output multiple bits at once, but normal single DI pin to load the memory.   Can be useful for more color depth if required, and doesn't consume too many prop pins (see diagram in thread below)
    Some other info in this threadhttp://forums.parallax.com/discussion/113579/rgb-burger-generating-480-400-video-using-external-sram/p1



  • kwinnkwinn Posts: 8,697
    You can't do it with SPI RAM because the MHz rating is the clock rate of the SPI signal, which takes a fair amount of setup in addition to the data.  This has been done with SRAM but it takes a lot of I/O pins.


    Yes you have to set up, but that can be done during blank intervals.  Then for every subsequent clock data appears on the bus during each clock cycle.   
    Don't get hung up on the 25MHz (unless driving dotclk driven lcds).  Note that the blanking cycles are nice and divisible, so you can easily aim for 0.75* those specs, which gives you 480 horizontal pixels, but a clock rate of 19 MHz which is within spec.
    You don't necessarily need a huge number of pins.  One other trick is to use QSPI to output multiple bits at once, but normal single DI pin to load the memory.   Can be useful for more color depth if required, and doesn't consume too many prop pins (see diagram in thread below)
    Some other info in this threadhttp://forums.parallax.com/discussion/113579/rgb-burger-generating-480-400-video-using-external-sram/p1






    Good point, and a 1Mbit QSPI chip is
    131072 bytes/262144 nibbles which makes the maximum resolution
    dependent on max clock speed, not the available memory. Using two or
    three chips in parallel for 8/12 bit color also makes it possible to
    treat the individual chips as layers in the image, which is great for
    HMI displays. One chip can produce the background, and the other can be used to display status data, which dovetails nicely with your suggestion of updating them using one data pin.


  • Thanks for the suggestions guys but how would multiple chips work?  Would you use a cog to "mix" the signals for one output?
    This reminds me of the "planer" days of the Amiga where it used a planer display instead of a framebuffer.
    Neat stuff!
  • jmgjmg Posts: 15,173
    Thanks for the suggestions guys but how would multiple chips work?  Would you use a cog to "mix" the signals for one output?


    Fast streaming drives 'direct' from the SPI to VGA-DAC, so you run in Quad mode, and get 4 DAC drives per chip. 2 or 3 chips give 8 or 12 bits per pixel.In practice that 'direct' would be through a MUX or buffer, so you can decouple the SPI pins, for  write and not load the prop pins with R-DAC loads.If you had a high impedance DAC, with a blanking pin, that could do the same thing.
  • kwinnkwinn Posts: 8,697
    It's really too bad that barebones lcd's where you can drive the rgb lines directly are non-existant or very rare in the marketplace. They would be perfect for this. Just hook the data pins from the ram chips directly to the rgb lines on the panel along with the clock and synch.
  • @jmg
    Do you have any Quad SPI SRAM chips you know of?  I've searched (mostly Mouser) but cannot find them.
    The closest was the 23LCV1024-I/P I mentioned earlier (dual SDI).
    Thanks
  • yetiyeti Posts: 818
    edited 2015-07-17 17:34
    23LCV1024 without the V it is a SPI/SDI/SQI SRAM: 23LC1024
  • jmgjmg Posts: 15,173
    23LCV1024 without the V it is a SPI/SDI/SQI SRAM: 23LC1024

    Yup. I had just assumed all that family was SQI, but maybe a pin trade off is needed.
  • 23LCV1024 needs a pin for the battery which is missing for doing SQI.
  • I've driven SDRAM from the Prop - used WAITVID to drive the control signals to the SDRAM, other
    pins to the address and bank-address pins and route the SDRAM data to the VGA resistor network.
    A 74LVC16374 provides a latch for setting the data bus from the address bus for writing the SDRAM.
    The screen update involves a burst read for each scan line and refresh cycles during 'flyback' period.
    The frame blank interval is when writes are sequenced in from a queue generated by another cog.

    WAITVID allows running the SDRAM at 40MHz (and in theory 80MHz although not attempted this
    yet).  A lot of pins are needed, 16 for addres/data, bank of 8 for SDRAM control and latch control.
    A fun project although v. much on the back-burner ATM.  A cunning use for recycled PC133 SDRAMs
    I thought.  And there's enough memory for dozens of screenfuls.
Sign In or Register to comment.