FPGA SDRAM

To save data from the inputs an SDRAM is used that is connected to the FPGA. Because we may want to store a lot of data it makes sense to us an SDRAM instead of an SRAM as they provide more storage per unit of cost. The negative thing about SDRAM is they need a more complicated controller.

A quick google search gave me these sites:

An alternative to SDRAM could be FLASH as was used in the first version. With FLASH we could get an enormous amount of storage for a reasonable price but the biggest problem with it is the limited lifetime. Most FLASH chips specify a program/erase cycle of around 100 000 which would limit how many times data could be stored. Data in the serial monitor is stored momentarily so that the user can see what is captured but it should also be possible to quickly erase the latest capture and start a new one. This is where FLASH will be limiting as it both takes time to do an erase but also it's limited number of cycles. Therefore a RAM makes more sense.

SDRAM Controller

After trying to get some controllers I found to work I decided to write my own. Even though it's as unoptimized as it can be it is functional and when I have some time left over later I can make it more efficient.

The controller is basically a state machine with the following main states:

Init
Idle
Open
Read
Write
Close

In the datasheet for the SDRAM there's a lot of information on how to interface with it. For the HexMon I'm using IS42S16400J (PDF). On page 9 there is information on how to set some of the pins to activate different modes for the SDRAM. There are some extra commands in that list that is not used in my controller as it's a very basic one.

After power has been applied to the SDRAM and everything has stabilized the first thing the controller does is wait for a specified time (100us for IS42S16400J). This is part of the initialization where the next step is to load the Mode Register with the settings that you want to use. After this the controller is basically idle.

Because of how the SDRAM is constructed the data has to be refreshed every now and then. More information about this can be found here. In the controller this is done using a counter which at given intervals (4096 times every 64ms) indicates that a refresh should be done. When the state machine is in the idle state and sees that the counter has expired it will issue a refresh before doing anything else.

Writing and reading data are both using similar steps. The first thing to do is to open the row where the data is located. After this the column in the row is selected and the read or write command is done. At this point the current controller is kind of "stupid". When a row is opened in the SDRAM it is possible to read/write to many of the columns in that row before closing it, but this controller closes the row after one piece of data has been processed. If you are accessing many positions after each other in the memory you could save some time here but as said before, this optimization can be done later when time is available. After the row is closed the controller goes back to idle again and that's basically it.