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 <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
