The memory controller is broken up into multiple stages, with the last
being a state machine that controls the memories themselves. Here's
how it breaks down:
(1) memctl_buf - This is like a HEADER stage described in the pipeline
discussion
(2) memctl_rh - Computes row hit/miss
(3) memctl_fsm - The controller logic
Here's the interface
// Configuration register access
input reg_clock;
input [15:0] reg_data;
input [3:0] reg_addr;
input reg_write;
Memory timing parameters
0: r2w_wait <= reg_data;
1: w2r_wait <= reg_data;
2: act2rw_wait <= reg_data;
3: r2pre_wait <= reg_data;
4: w2pre_wait <= reg_data;
5: pre2act_wait <= reg_data;
6: act2pre_wait <= reg_data;
7: refresh2act_wait <= reg_data;
8: cas_latency <= reg_data;
The encoding of the registers is not straightforward, but this is a
"software issue" that we'll address later. I've also posted the
details on the list before.
// Command interface
input [2:0] cmd_in;
These are the commands:
parameter cmd_read = 1;
parameter cmd_write = 2;
parameter cmd_precharge = 3;
parameter cmd_refresh = 4;
parameter cmd_lmr = 5;
Read and write are obvious. For normal accesses, the fsm does all the
right things to close/open the right rows, so most use is through just
those two.
The lmr command is used to write to config registers in the DRAM
chips. A precharge command must be sent before an lmr. Also,
software is responsible for inserting the required delays between
precharge and lmr commands.
The refresh command is also obvious. However, I don't recall if a
precharge command must be sent first or if the FSM takes care of that
automatically. I'll have to fill in that detail later.
// Parts of the address
input [1:0] bank_in;
input [12:0] row_in, col_in;
// Write data
input [63:0] wdata_in;
input [7:0] wbytes_in;
// If doing a read, this is a tag that identifies who requested the
data. This comes out the other end with the data.
input [2:0] rtag_in;
// This is equivalent to the "full" signal from a fifo. The "enq"
signal is inferred from a nonzero cmd_in.
output busy_out;
// This is the external interface to the DRAM chips
output [2:0] bus_cmd;
output [12:0] addr_out;
output [1:0] bank_out;
inout [31:0] dq;
output [3:0] dm_out, dqs_out;
output [1:0] ram_clk_p, ram_clk_n;
// Read return path
output [63:0] rdata_out; // data word
output rdata_valid_out; // rdata_out must be accepted
output [2:0] rtag_out; // who requested this read
Note that the read return path is not a fifo interface. The
rdata_valid_out is not a request. If other logic is not able to
accept the data, the data will be lost. Thus, it is important to
ensure that no more requests are made than words that can be accepted
into the return fifo(s).
--
Timothy Normand Miller
http://www.cse.ohio-state.edu/~millerti
Open Graphics Project
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
