[Open-graphics] Notes on the memory controller and interface

[ndownes at tampabay.rr.com]

This does not seem to be a terribly efficient method for memory control, unless I'm missing something.  Is there a blitter for handling the memory needs?  Is it FIFO, SIMD or Vector based?

---- Timothy Normand Miller <theosib at gmail.com> wrote: 
> 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
> Open-graphics at duskglow.com
> http://lists.duskglow.com/mailman/listinfo/open-graphics
> List service provided by Duskglow Consulting, LLC (www.duskglow.com)