Mike,
I didn't find MEMORY_READ_LATENCY or MEMORY_WRITE_LATENCY being
used. There is only one macro MEMORY_LATENCY. And write is assumed to
happen in background without latency.
On Tue, 08 Feb 2005 10:23:11 -0600, Mike Marty <mikem@xxxxxxxxxxx> wrote:
> Weihang,
>
> You may want to simply do this in ruby/config/RubyConfig.h:
>
> #define MEMORY_READ_LATENCY ram_read()
> #define MEMORY_WRITE_LATENCY ram_write()
>
> In general, you do not want to modify the Slicc-generated files.
>
> One thing to note: in the released version of Ruby, the controllers are
> not blocked and are essentially infinitely pipelined. That is, if the
> memory/directory controller gets a read for block A and delays for 80
> cycles, it can immediately service other requests in the same cycle as
> well as the next cycle.
>
> --Mike
>
>
> On Mon, 2005-02-07 at 11:06, Weihang Jiang wrote:
> > Mike,
> > Yes, I am making prgress. Currently, my plan is to integrate
> > rambus memory module into ruby, since different eneregy management
> > algorithm may affect the MEMORY LATENCY.
> > During last weekend, I read the source code and try to figure out
> > where to integrate. To my understanding right now, the interface
> > between ruby and rambus module is simple, only 2 functions ram_read()
> > and ram_write() are needed. ram_read() tells rambus module what to
> > read at what time, and return the memory latency. ram_write() is
> > simpler, only telling module what to write at what time without
> > returning.
> > I plan to place ram_write in
> > Directory_Controller::r_writeDataFromRequest(), and to place ram_read
> > in Directory_Controller::d_sendDataMsg(). Also the MEMORY_LATENCY in
> > d_sendDataMsg() will be replaced with the latency caculated by rambus
> > module.
> > Inside ram_read() and ram_write() I can easily collect memory access trace.
> >
> > Does it sound correct? Please correct me if I am wrong.
> >
> > Thanks
> >
>
>
--
Weihang Jiang
|