Is it possible to use SDRAM like SRAM?


RorschachUK

Recommended Posts

Hi, I'm still very much a newbie with this stuff, but am slowly reaching a point where I can figure out just enough to be able to adapt VHDL intended for one board and change pin constraints and get a 50Mhz clock from the 32Mhz oscillator and so on with some limited successes.  But I'm coming across various things I want to get working which rely on external SRAM (or more internal block ram than I've got available).  For example, Mike Field's Hamsterworks wiki has several projects aimed at the Papilio Plus and other FPGAs with external SRAM, and I'd really like to see that Mandelbrot browser running on the Pro.  Or, recreations of old computer hardware that require external RAM.  But SDRAM seems to be far from trivial to use in place of SRAM and I've seen surprisingly few examples of source code making use of it.

 

Is there any kind of VHDL wrapper / adapter layer that might talk to your external SDRAM and present an instantiation component interface to use that looks like SRAM so that designs targeting SRAM can be easily adapted?  Would such a thing be possible, hiding away details about refreshing or bursts or whatever?  If a 'generic' one-wrapper-fits-all solution isn't feasible, how do I take source code intended for external SRAM and adapt it to use the external SDRAM instead?

Link to comment
Share on other sites

Short answer - no. It takes about 11 cycles to read or write a byte from SDRAM, and maybe another 8 if a refresh cycle is needed. So if you are using 100MHz SDRAM you could only make it look like SDRAM if you ran your project at under 5MHz.

 

To make good use of SDRAM your design must decouple most of your access to memory - either by caching, busting data into FIFOs, careful scheduling or some other magic...

Link to comment
Share on other sites

I must say I loved that the Papilio Plus had a fast SRAM on board as I found it to be an invaluable resource. The only way it could have been better is if it had a IS61WV102416 (2MB RAM) or even two :). I still use my Papilio Plus regularly for projects that need a lot of memory with fast and predictable random access.

 

The Papilio Pro also has plenty of memory capacity in the form of a SDRAM but because it uses a LX9 FPGA, it doesn't have a built in MCB (Memory Controller Block), so accessing the SDRAM is further complicated by having to build your own controller like hamster did.

 

The Pipistrello is a great FPGA board if you want to boot up Linux on it and because it is based on a LX45 FPGA it has a built in MCB that abstracts the SDRAM by treating it a a number of FIFOs but you still run into the issues that hamster described.

 

While a SDRAM has great throughput on paper when you just stream data into or out of it, if you want truly random access (ie constant non consecutive address access) your throughput to the SDRAM plummets dramatically. The only way to recover from that is to add more complexity by adding some form of cache, then you have to deal with cache misses, flushing caches out and cache refreshes... Even with caches, if you can't roughly predict what memory location your design is about to access in order to pre-fill the cache, you will have to stall the hardware while the data is fetched from SDRAM. If your design needs to run at a constant speed, you're out of luck, the most you can hope for is that your design will run at the desired average speed, ie run faster than you need, then when you stall for memory access you loose some of the time you gained, so on average you kind of run at the speed you want but in the short term you're running in a very stop-go manner.

 

You really can't beat a fast SRAM.

Link to comment
Share on other sites

Thanks guys - no wonder there are so few examples of projects using the SDRAM.  Since the implementations of 48k ZX Spectrum and Oric Atmos (nice work Alex!) are exactly the sort of thing I'd like to get running, sounds like Pipistrello might be the most straightforward way to go - and they're down to their last four units from this batch!  Even on that though, projects look more likely to use onboard block ram on the larger LX45 than touch the external 64Mb DRAM.  I assume that it would be easier to take one of the Papilio Plus projects - Mike's DSPFract Mandelbrot one for instance - and adapt that for Pipistrello using internal block ram generated in ISE than it would to adapt for Papilio Pro?

Link to comment
Share on other sites

Yes within limits. The LX9 has 32 RAMBs for a max RAM of 64KB whereas the LX45 has 116 RAMBs for a total max RAM of 232KB so it's easier to develop on the Pipistrello

Perhaps Jack still has some Papilio Plus boards for sale? I can't remember what size RAM it came with. I think it was 256K. I upgraded mine to the largest RAM that fit in that footprint (512K x16 = 1MB) and posted about it here somewhere.
The main drawback of the Plus was that the UB and LB pins of the RAM were tied together so you have to access it in 16bit mode.

Link to comment
Share on other sites

The Plus still had 48 pins for wings after connecting the RAM. I don't know if this makes sense commercially but perhaps discontinue the One and replace it with a LX9 based Pro with the RAM chip not populated for a low cost board then offer another option where the RAM chip is soldered as well for a bit more cost.

Link to comment
Share on other sites

Is there any way to have Spartan-6 plus enough SRAM for reasonable resolution/bit depth video frame buffer plus onboard VGA connector plus wing headers or Arduino headers?  Almost all the projects I'm most interested in running are asking for SRAM as either a framebuffer for VGA, or for RAM for a retro microcomputer that would also want VGA, or to give ZPUino a better video output.  This would also leave enough free I/O for Arduino-esque hardware to talk to ZPUino, or PS/2 keyboards for retro computers, or joysticks and buttons for arcade games.  Currently ZPUino's video bitfiles rely on either LogicStart or Arcade Megawing, both of which use up every port and make it tricky to talk to any other hardware - maybe have to resort to poking wires into unused joystick ports and the like.  Would be nice to use external SRAM to back a better resolution and leave I/O free and easy to access.  Would this require the BGA package though?

Link to comment
Share on other sites

Is there any way to have Spartan-6 plus enough SRAM for reasonable resolution/bit depth video frame buffer plus onboard VGA connector plus wing headers or Arduino headers?  Almost all the projects I'm most interested in running are asking for SRAM as either a framebuffer for VGA, or for RAM for a retro microcomputer that would also want VGA, or to give ZPUino a better video output.  This would also leave enough free I/O for Arduino-esque hardware to talk to ZPUino, or PS/2 keyboards for retro computers, or joysticks and buttons for arcade games.  Currently ZPUino's video bitfiles rely on either LogicStart or Arcade Megawing, both of which use up every port and make it tricky to talk to any other hardware - maybe have to resort to poking wires into unused joystick ports and the like.  Would be nice to use external SRAM to back a better resolution and leave I/O free and easy to access.  Would this require the BGA package though?

 

One of the main drivers for going with SDRAM over SRAM with the Papilio Pro was to be able to achieve higher resolution/bit depth video frame buffers. SRAM gets extremely expensive to add 8Mbyte of space, $30 or something crazy like that. It's only a couple dollars for SDRAM...

 

Let's talk about the ZPUino bitfiles, like you say we need to be able to make a ZPUino project that is not locked to the Arcade MegaWing or the LogicStart MegaWing. If you look at the board types in the ZAP IDE I did make a Pin Select version of the Hyperion variant, for the Papilio One 500K, that allows you to move the VGA pins on the fly, but I didn't do the same for the Papilio Pro... I will put that as a task on my task list, make a pin select version for the Papilio Pro.

 

I'm also finishing up the Papilio SOC system, which is a schematic based SOC builder that will let you build Hyperion based systems and easily connect the VGA pins anywhere you want.

 

Alvie is working on HDMI support as well, not sure when we will see that available but we do have a Wing that is being tested right now.

 

Alvie also has a better VGA controller that uses more memory on the Papilio Pro that we will hopefully get released soon.

 

Jack.

Link to comment
Share on other sites

OK, but that brings us back to my original post, doesn't it?  I mentioned one specific 'for instance' example there of a Papilio Plus SRAM-using project I'd like to see working with Papilio Pro and SDRAM: Hamster's DSPFract Mandelbrot browser - and Mike was the first person to answer, with what sounded to my newbie ears to be "It's hard", although that was probably in answer to my suggestion of a wrapper.

 

So since this one specific example uses 512K of memory as a frame buffer, which is predictably accessing consecutive memory locations as you say, how would this be converted to Papilio Pro?

Link to comment
Share on other sites

The link I posted to Hamster's wiki takes you though to here were there is a SDRAM controller source. I haven't used it personally but it is supposed to be debugged and tested to be working. Your interface to this controller through an address, data in/out, a mask and three control pins. It should be fairly simple. This is about as simple as it's ever going to get.

Link to comment
Share on other sites

The Plus still had 48 pins for wings after connecting the RAM. I don't know if this makes sense commercially but perhaps discontinue the One and replace it with a LX9 based Pro with the RAM chip not populated for a low cost board then offer another option where the RAM chip is soldered as well for a bit more cost.

Couldn't find a "like" button so had to reply, a board with SRAM instead of DRAM might just make the difference between people with hair and fingernails and people with neither :)

-V

Link to comment
Share on other sites

The needs of my current project don't require much bandwidth ( < 1 MB/s) but does require more capacity than the internal FPGA RAM blocks allow, so I'm happy with a really dumb and simple hand-rolled SDRAM controller.  However, there is one thing I don't understand how to do -- I have two decades of verilog use, but this is my first time playing with FPGAs.

 

The SDRAM requires 1 ns hold time on its control inputs relative to the SDRAM CLK input.  What is the right way to do this?  Should I add IODELAY to all the outputs except for the one driving CLK?  Is the right way to use the PLL to generate two clocks, one 45 degrees delayed, with the earlier one driving CLK and the other driving the logic which feeds the control pins?

 

I looked at Hamster's design but it doesn't include a .ucf file which indicates the driving cell strength.  The module also accepts a clock input and a 3ns delayed clock input (from a PLL?  From IODELAY or something like that -- I can't tell).  He also uses a ODDR2 cell in a way that is somewhat voodoo to me.

 

Can anybody shed light on these issues?

 

Thanks

 

FYI: I'm using the Pro as a device to capture floppy disk data timing information for software-based decoding and archiving purposes.  I have both a catweasel card and a kryoflux card, but neither is suitable for this odd format.

Link to comment
Share on other sites

  • 2 weeks later...

I took up Hamster on his offer to use his latest (in progress) SDRAM controller.  Although my project uses verilog, it was no problem integrating his VHDL source.  After one round of improvements and fixes on his part, I now have a working SDRAM controller!  As I stated originally, I don't have high bandwidth requirements, so I'm not entirely taxing the design.

 

Mike's design is designed for 100 MHz operation, but it wasn't working reliably at that speed, nor at 80 MHz.  It works fine at 50 MHz and 66 MHz, but I didn't try any harder to find exactly where the breaking point is.  Without suitable test equipment, I can't get a good view of what is happening at the pins of the SDRAM to know the nature of the problem.  Perhaps it could be cured with some tuning of I/O pin drive strengths and slew rate control, perhaps some SDRAM clock phase tuning, but for the moment, this lets me get on with the rest of my project.

 

Hats off to the Hamster!

Link to comment
Share on other sites

The Plus still had 48 pins for wings after connecting the RAM. I don't know if this makes sense commercially but perhaps discontinue the One and replace it with a LX9 based Pro with the RAM chip not populated for a low cost board then offer another option where the RAM chip is soldered as well for a bit more cost.

 

That would be my vote, although already having a 500K and a Pro I'm not really in the market for another board at this time.

 

Maybe have locations for both SRAM and DRAM? With some clever routing they could overlap, requiring litlte more board space than just one set of pads and allowing either SRAM or DRAM to be fitted using the same PCB layout. As long as it doesn't increase the size of the board, adding part locations doesn't cost anything.

Link to comment
Share on other sites

Archived

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