The case for SRAM


burann

Recommended Posts

I'm looking for a FPGA platform that have around 2 MB of fast SRAM, vga/hdmi or DVI out, audio and clocked around 100 Mhz.  So far I've found allot of projects with SDRAM and like, but no SRAM.  which is a bit surprising, sure its more expensive, but almost all these boards are targeted at hobbyist and writing a SDRAM controller thats more advanced than just reading/writing a byte is allot of work that is probably beyond a large part of the potential customers.

 

My ideal card would be:

 

- Spartan 6 LX9+ 

- 2 MB SRAM (<10 ns)

- Flash 

- SD Card

- USB x 2

- DVI/HDMI

- 2 channel audio

- Some GPIO

 

The glove is right there on the ground, hope someone picks it up :)

 

 

Link to comment
Share on other sites

>> and writing a SDRAM controller thats more advanced than just reading/writing a byte is allot of work that is probably beyond a large part of the potential customers.

 

Hi,

 

have a look at the one on the Xess site: http://www.xess.com/appnotes/ top of page. It dates back to 2005, license is AFAIK Creative Commons.

There is also an article on the same site that mentions a non-encrypted SDRAM model to be used in simulations.

I haven't tried it myself, will probably one day try to make it work on the Papilio Pro.

 

Dual-USB, one or two of those https://www.sparkfun.com/products/9873 and a hot-glue gun.

 

Audio, I know of two codec boards:

https://mbed.org/cookbook/RS-Audio-Codec

http://www.xess.com/shop/product/stickit-audioio/

 

If this is your first board, pick a cheap one (Papilio is a good choice from both Windoze and Linux), consider it disposable and don't worry about abusing or breaking it.

If not, you already know what you're up against :)

 

There are some ugly dead-beetle-stacking hacks that could extend an existing SRAM board with a smaller capacity. 10 ns, don't know about that.

Link to comment
Share on other sites

I have a non-encripted SDRAM model, but I am not sure about its license, so I cannot redistribute it.

 

The SDRAM controller on ZPUino is based on Hamster previous work, and offers a random access with pipelining. See my other post regarding the SDRAM interface for details.

 

Although we can squeeze most of the SDRAM, the latency is still high. But, again, if you're doing FPGA, you can tune your system to take that into account. Might not be simple, tough.

 

http://forum.gadgetfactory.net/index.php?/topic/1894-overview-of-an-sdram-transfer/?hl=sdram

Link to comment
Share on other sites

Hi Alvie,

 

I'm in now way saying its not possible and the SDRAM controller work mentioned is great, but for many hobbyists like me, its a steep learning curve to work with the dynamic nature of SDRAM et al, even if the controller is simple to use, the rest of the design need to accommodate for the memory characteristics.

 

For what I'm doing 2 MB of 10 ns SRAM would be perfect, it would provide some 50:ISH MB/sec transfer rate (?) and thats more than enough to do basic VGA and have half bus time over (?)

Link to comment
Share on other sites

So you already have to deal with "contention" on your system, because you have two masters accessing the memory, is this correct ?

 

are you using any standard IO bus to connect the components ?

 

 

the rest of the design need to accommodate for the memory characteristics.

 

No. It needs to accomodate the controller being busy, and to accomodate that read acknowledges (valid signal) can only come after a few cycles.

 

Even with SRAM you would have that issue due to the multimaster architecture.

 

Alvie

Link to comment
Share on other sites

>So you already have to deal with "contention" on your system, because you have two masters accessing the memory, is this correct ?

 

I plan to split time between CPU, graphics, sound into time slots based around scanline time

 

>are you using any standard IO bus to connect the components ?

 

Not standard in sense of Wishbone, just top module interconnecting the various parts, memory access signaling 

 

>No. It needs to accomodate the controller being busy, and to accomodate that read acknowledges (valid signal) can only come after a few cycles.

 

Yes, but in the SRAM case, I dont have to deal with refresh timing that happens under the hood in the controller.

 

>Even with SRAM you would have that issue due to the multimaster architecture.

 

Sure, but the design would be pretty static in usage time since I would base everything around a scanline timing. 

 

I'm finding my way around and are no expert on this, but I think the right way to go is SRAM, it would make the whole thing a bit more expensive, but easier to wrap my head around, less VHDL.

Link to comment
Share on other sites

>> Sure, but the design would be pretty static in usage time since I would base everything around a scanline timing.

 

this actually sounds like a good architecture to me, have some global coordinator to multiplex resources usage at ultrasonic frequency. If not scanline, then audio sample rate would be another obvious candidate. Doesn't mean that everything needs to be co-periodic.

 

BTW if it's of any use, I can provide a monochrome RGB text interface in 640x480x60, 40x30 char that uses only one of the built-in 18kBit FPGA RAMS and needs less than 3% of LX9 FPGA resources. Ugly but perfectly readable, let me know if interested.

Link to comment
Share on other sites

Here you go...

1 RAMB16, 30 slices out of 1430 used.

 

Characters > 128 are shown in reverse.

The character memory can be overwritten like the video mem, and the first 10 characters are left blank. Use for embedded graphics (i.e. 3x3 or 5x2), bar graph display or the like.

Video mem access has its own clock so it is easily driven from an existing design.

 

For true terminal addicts there's also an ad-hoc compilation script included (Linux) for command line use. This will need some editing, though.

 

top.v: example instantiation

ucf file for Xess RGB adapter and Papilio Pro

sk61_lib.v: modules, some unused (the UART at the top isn't mine)

 

post-36723-0-20062800-1396040513_thumb.j

RGB.zip

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.