DRAM Controller Design Tutorial
Build Your Own IP
If you want to design a moderately complex piece of IP, there are not too many good sources for hardware design methodology, so for my next design I have decided to document the process.
List of tasks:
I have decided to design an SDRAM controller. This seems to be a very popular design. There are a lot of engineers who have designed their own SDRAM controller to cater for their own peculiar needs, but at the same time there are not too many options on the Opencores web site. So let's see if we can create a flexible design capable of satisfying multiple requirements.
First off let's aim for a design that will operate at a high clock speed. Let's aim for 167MHz in an Altera Cyclone II. Possible? Maybe, maybe not, but we'll make that the target in order to emphasize high speed design concepts. Similarly the controller should have the capability to run at close to 100% of theoretical bandwidth, when data accesses are sequential.
List of requirements:
First off we need to be familiar with the application. We need to know how SDRAM works and the operation of the Wishbone interface. Once we fully understand the interfaces of the IP core, then we can start thinking about how we can best service these interfaces whilst fulfilling our list of requirements. The best places to start are the Wishbone specification, and the Micron SDRAM datasheet. Also see the Wikipedia SDRAM introduction.
Initially we will concentrate on the fifo interface, and the interface to the DRAM, and making the logic within the DRAM clock domain as simple as possible. Once we have the fifo interface designed the Wishbone interface should be somewhat similar. At this stage I have to admit that the DRAM controller part of the design is much more specialized than I originally thought would be the case. And this is probably why so many people design their own DRAM controllers to suit their own specialized application. For example, if you need a DRAM controller that is capable of close to 100% of theoretical maximum throughput for a streaming video application, then a generic DRAM controller probably won't meet your requirements.
The page burst mode seems like a good candidate for high speed streaming access. It should be possible to construct the control/data sequence in fifo/memory and then stream directly from fifo/memory to/from the DRAM. For a write sequence, load the data into a fifo, and load the control sequence into dual port memory, then stream everything out to the DRAM. For a read sequence only the control sequence needs to be loaded and then streamed to the DRAM, the read data can be read back to a fifo. The aim is to reduce the amount of logic in the DRAM clock domain portion of the controller, thus increasing the maximum clock speed. Fig (1) shows a block diagram of the DRAM controller.
We have two fifos for data, plus one dual port memory buffer for address/control. The address buffers are mostly full of NOPs which are written once at start up, so only a limited number of write operations are required prior to a read/write burst sequence:
The control section is split into two portions. The more complex within the input clock domain, and the simpler portion within the DRAM clock domain.
Fig (2) shows the DRAM arbiter. This handles access requests from multiple DRAM controllers.
The description and block diagrams shown above are a good high level view, and sufficient to determine the high level modules within the design, but we need more details on the interface signals between the blocks. I don't want to spend the time producing detailed block diagrams using Open Office Draw, and so will complete this stage of the design on paper.
Send mail to
questions or comments about this web site.