Electronic – SDRAM: Why CAS latency is configurable

The main advantage of synchronous design is that it's behavior is easy to predict, model, and validate because everything happens on a predefined schedule. However, waiting for a specified time to perform an action makes synchronous design slower than a comparable asynchronous design. And even when the circuit is not responding to its logic inputs, it is still drawing power since it is responding to the clock signal.

An asynchronous circuit can be much faster because it responds to its inputs as they change. No waiting around for a clock signal before processing can take place. They also can take less power since they don't have anything to do when the inputs are inactive and have better EMI performance since there isn't a constant digital signal floating around. But the design of such systems is much more difficult because all combinations of inputs over time need to be taken into consideration to ensure proper operation of the circuit. When two inputs change at almost the same time, this is called a race condition and the circuit can have undefined behavior if the designer didn't plan for every combination of inputs at every combination of time.

Comparing and contrasting synchronous to asynchronous design, you're probably thinking that big companies like Samsung can spend billions on the research and design to fully model a DRAM circuit so that its operation is really stable and then we would have really fast, really low power memory. So why is SDRAM so much more popular?

While asynchronous design is faster than synchronous in sequential operations, it is much much easier to design a circuit to perform parallel or simulations operations if the operations are synchronous. And when many operations can be performed at the same time, the speed advantage of asynchronous design disappears.

So three main things to consider when designing a RAM circuit are speed, power, and ease of design. SDRAM wins over plain DRAM on two out of three of those and by a very large margin.

Wikipedia quotes:

Dynamic random-access memory -

The most significant change, and the primary reason that SDRAM has supplanted asynchronous RAM, is the support for multiple internal banks inside the DRAM chip. Using a few bits of "bank address" which accompany each command, a second bank can be activated and begin reading data while a read from the first bank is in progress. By alternating banks, an SDRAM device can keep the data bus continuously busy, in a way that asynchronous DRAM cannot.

Synchronous dynamic random-access memory -

Classic DRAM has an asynchronous interface, which means that it responds as quickly as possible to changes in control inputs. SDRAM has a synchronous interface, meaning that it waits for a clock signal before responding to control inputs and is therefore synchronized with the computer's system bus. The clock is used to drive an internal finite state machine that pipelines incoming commands. The data storage area is divided into several banks, allowing the chip to work on several memory access commands at a time, interleaved among the separate banks. This allows higher data access rates than an asynchronous DRAM.

Pipelining means that the chip can accept a new command before it has finished processing the previous one. In a pipelined write, the write command can be immediately followed by another command, without waiting for the data to be written to the memory array. In a pipelined read, the requested data appears after a fixed number of clock cycles after the read command (latency), clock cycles during which additional commands can be sent.

You can do a little better than this; because burst transfers only use the data paths while in progress, you can overlap bursts with address signal transfers.

So you can get ready to transfer the next burst while the current burst is in progress; likewise you can open the next bank and set RAS for it before the current bank's transfer is done. Start the next actual transfer, then come back to precharge this bank.

It's more complex, and you'd have to read the Spartan-6 MCB docs in case they don't allow this stuff; I was rolling my own controller when I did this.

In any case it sounds like you won't need it, but its nice to know it's there.

A bigger problem is that it will want to stop every 8 us and spend a chunk of time generating a refresh pulse (and precharges around it). I could tell it not to in my own core, (until a convenient break, but no longer than 70 us) and later added a similar hack to the Virtex-5 MIG core for this purpose but I don't think you can control refreshes on Spartan-6. So, if this is a problem, you'll need an elastic buffer somewhere to take up the slack.