Is it possible to use SDRAM like SRAM?


RorschachUK

Recommended Posts

You don't want to use SRAM - it's expensive and capacity is very low.

I think one day we'll move to LPDDR3 or similar, but that would require BGA ability which currently we don't have.

 

It's expensive for a mass production design, but for something like the Papilio the relatively high cost and low capacity is not really a big deal. Adding 512k of SRAM opens a lot of doors compared to living within the much smaller amount of BRAM in the FPGA and it's far easier to work with than SDRAM. Using the SDRAM is quite a daunting task for the beginner compared to SRAM which is a piece of cake. By the time most people get to the point of wanding to use SDRAM, they would likely be ready for a bigger FPGA anyway and IIRC the larger Spartan6 chips have onboard DRAM controllers.

Link to comment
Share on other sites

Maybe have locations for both SRAM and DRAM? With some clever routing they could overlap

 

I am currently have a  board that does exactly that - the footprint and power pins are the same for SDRAM or SRAM, just have to install different parts on the PCB.

 

It does however mean that you end up with some wasted I/O pins in some configrations.

Link to comment
Share on other sites

I am currently have a  board that does exactly that - the footprint and power pins are the same for SDRAM or SRAM, just have to install different parts on the PCB.

 

It does however mean that you end up with some wasted I/O pins in some configrations.

 

 

The pins don't have to be wasted, they can be strapped to additional headers or other pads so they can be utilized for other purposes if not required by the installed RAM.

Link to comment
Share on other sites

The pins don't have to be wasted, they can be strapped to additional headers or other pads so they can be utilized for other purposes if not required by the installed RAM.

 

The problem as I see it is that these pins run at very high speeds. If you have multiple footprints or even worse, run some pins to other headers then these unterminated transmission lines will cause signal bounce and introduce noise causing signal corruption. Your suggestions would have worked fine in the 80's when the logic run at 1 to 4 MHz, but now we're running them at x100 the speed and everything changes :)

 

Oh and also while it's easy to say strap this pin to this, that and the other, when you factor in the 2 layer board constraints then it's not always so easy to route everything around the board. Maybe if we had 4 or 16 layers, sure, but then the cost and complexity goes way up.

Link to comment
Share on other sites

The problem as I see it is that these pins run at very high speeds. If you have multiple footprints or even worse, run some pins to other headers then these unterminated transmission lines will cause signal bounce and introduce noise causing signal corruption. Your suggestions would have worked fine in the 80's when the logic run at 1 to 4 MHz, but now we're running them at x100 the speed and everything changes :)

 

Oh and also while it's easy to say strap this pin to this, that and the other, when you factor in the 2 layer board constraints then it's not always so easy to route everything around the board. Maybe if we had 4 or 16 layers, sure, but then the cost and complexity goes way up.

 

 

Well naturally it depends on the layout and it isn't always possible, it's just an idea that I've used with success in the past and figured it was worth throwing out there. What I've done is to use 0603 or 0402 resistor pads as jumpers. If the layout permits, they can be placed very close to the trace and add only a small pad which is then jumpered to a trace going somewhere else if desired by installing a 0 Ohm resistor. Even if it's only practical to do this with a few pins, that's still a few pins that would otherwise be wasted. I haven't looked at the SRAM vs DRAM pinouts so I can't say how practical this is for that application, but the highly configurable IO nature of the FPGA does make this more feasible in concept.

 

Whatever the case, it would definitely be cool to see a Papilio with SRAM at some point. An additional 512KB would be ample for the needs of a large number of classic arcade games for example. The Williams games are notable as needing a lot of RAM for the era as they have a framebuffer. Quite a few classic computer systems had much less than that too.

Link to comment
Share on other sites

There was a Papilio with SRAM at one point, the Papilio Plus, but it only made it to prototype stage then axed in favor of the Pro. IMHO the Plus was almost darn near perfect. The only bug with it was that the external SRAM that had a x16 bit wide data bus could only be accessed in 16 bit mode because the pins that selected which half of the data bus you wanted to write to were tied together. Despite this, my Plus is still getting a lot of use but unfortunately projects using the Plus' SRAM can't easily be ported to the Pro's DRAM.

Link to comment
Share on other sites

I use my Pro a fair amount, but I haven't used the SDRAM with any of my own projects, it just makes my head spin looking at how complicated it is to make it do anything.

 

I've wondered for some time though why there aren't more FPGAs with larger amounts of BRAM. I guess most applications just use external memory but it would be cool to have something with the logic features of the Spartan3-500k or Spartan6 lx9 but perhaps 4x-5x the amount of BRAM. I suppose an external parallel ROM would also work to free up scarce BRAM from being used as ROM.

Link to comment
Share on other sites

I'm just putting the finishing touches / testing on a SDRAM controller for Spartan 6 boards:

 

http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller

 

I'm working on it for the Logi-Pi, but Jim Battle has a varient working on his Papilio Pro (I didn't have a Pro when I started the project...)

 

It is very simple at the moment - each transaction takes about 170ns, so it is only getting 25MB/s or so, but once I have a working validation set-up it should get improved into the 100MB/s range for most workloads.

Link to comment
Share on other sites

Archived

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