SDRAM Controller
The Controller is the connecting link between the SDRAM and The User (Host) requesting to read/write from the SDRAM. Usually it is implemented in code as a state machine. The controller must keep track of The SDRAM in order to handle The Host's requests, this includes:
A) Current active row and bank in the SDRAM.
B) Any Unfinished operations in the SDRAM and the cycles remaining before they are completed
C) The current state of the SDRAM (initializing, waiting for initial mode setup command from the controller, refreshing, etc.)
Every request by the host is received by the controller. The controller determines whether the SDRAM can currently handle the request and acts accordingly. The controller translates each request into the commands needed for the SDRAM to handle the request and sends the appropriate control signals, waiting between each command for the appropriate amount of cycles if necessary.
The controller is connected to the Host and the SDRAM with the following signals:
Non-pipelined write operation
An example of write request in which the requested bank and row are already activated in the SDRAM and The SDRAM is not handling a previous command:
Cycle 1: The host sends the controller a WR signal since this is a write operation, the address to write the data in the haddr bus and the data to be written in the hdin bus .
Cycle 2: The controller sends The SDRAM The address to write into in the Saddr bus, The data to write in the Sdata bus and the appropriate values in the control signals to start a write operation(CS='0' RAS='1' CAS='0',WE='0' 10th address bit can be '0' or '1' depending on the controller's programming, determining whether The sdram precharges after the write operation, for a full explanation see The technical Data pages and the command table)
Since the controller's part in the write operation is complete it sends a done signal to the host that the write request was sent successfully.
Cycles 3-5: The SDRAM receives the write command and writes the data.
Had the Controller's data shown that the current active row and bank are different then the one's the host requested The controller would have sent a precharge request(see technical data for the control signals) waited the required amount of cycles for the precharge to complete, sent an activate command, waited again and then started The process from cycle 1.
If the SDRAM was already in the middle of a command (refreshing, a read request) the Controller would have waited the necessary amount of cycles for the operation to complete before sending the write request.
Non-pipelined read operation
an example read request in which the requested bank and row are already activated in the SDRAM and The SDRAM is not handling a previous command:
Cycle 1: The host sends the controller a RD signal since this is a read operation and the address to read from in the Haddr bus, the host is informed that the read request was sent using the earlyopbegun signal.
Cycle 2: The controller sends The sdram the address in the Saddr and the control signals to start a Read operation(see the Technical data page for details)
Cycle 3: SDRAM begins the read process.
Cycle 4: SDRAM waits for read result.
Cycle 5: The data from The SDRAM arrives to the controller in the sdata bus.
Cycle 6: The controller sends the data to the host in the hdout bus and a signal notifying the host that the read was complete and the data is ready(done), if The host does not change its RD signal to '0' another read operation would begin in the next cycle.
If the Controller's data showed that the current active row and bank are different then the one's the host requested The controller would have sent a precharge request [see technical data for the control signals] waited the required amount of cycles for the precharge to complete, sent an activate command, waited again and then started The process from cycle 1.
If the SDRAM was already in the middle of a command (for example refreashing) the Controller would have waited the necessary amount of cycles for the operation to complete before sending the read request.
The Host should not remove it's read request at that time as it does not recieve a done signal.
Pipelined read and write operations
As mentioned before the SDRAM can support pipelining, and so if the controller is programmed to enable pipelining the host can sent multiple read or write requests at a row like this :
The cycle graphs are taken from the Xess application note for the Xsa sdram.
In addition to translating the Host's requests the controller also handles auto-refreshing of the SDRAM by sending refresh commands at preset intervals And initializing the SDRAM when powered on by precharging it and setting the SDRAM'S mode of operation (see technical data for the possible modes).
After Reading what The SDRAM and the Controller are and how thay work, you can see how it all comes together in the interactive simulation, The simulation is based on the Controller code for XSA SDRAM Boards (The type used in the University's labs)as supplies in The Producer's(Xess corp) website.
