Re: [Gems-users] Variable Latency DRAM memory system

[Mike Marty <mikem@xxxxxxxxxxx>]

At the Ruby/Simics interface (or Ruby/Opal/Simics), we do exactly this.
We call back into Simics (or Opal) only when the request completes.  We
obviously can't know a priori how future requests will affect the current
request.

But what you want is further in the system.

The short answer is Yes, I believe that GEMS can be easily extended to do
what you want to do.

As I tried to explain in a previous message, latency is accumulated in
Ruby through the interconnection network.  Messages are consumed and
generated at various endpoints.  A SLICC controller controls how this
happens.  If a message is available, a controller acts on the message by
triggering the Event/Transition.  This happens at the "in_ports" of SLICC
controllers.  Actions associated with the Event/Transition will carry out
various things and will eventually either callback to Simics/Opal if at
the L1 controller, or will inject additional messages into the network
with a _predetermined_ delay (like you said, calling a function to findout
what the latency is).  This is obviously _not_ what you want because your
delay isn't predetermined.

To model the behavior the way you want, the DRAM module should actually
generate a message into some consumer of messages.  For example, the SLICC
memory controller can issue a request to your DRAM subsystem by calling a
function.  At some point later, your DRAM subsystem will generate a
message that will "wakeup" the memory controller to complete the request
(which may require additional messages sent down to the L1 controller).

An example of something similar is how the TimerTable module is
implemented in ruby/system/TimerTable.C.  This is a simple module where a
SLICC controller will call a function to be woken up at some point in the
future.  The function merely schedules an event in the global event_queue.
It passed the consumer of the event which will receive the wakeup.
TimerTable is used in MOESI_CMP_token-L1cache.sm.  Each one has an
"in_port" associated with it which means it is the consumer.  Internally,
when the current cycle reaches the time of the event, the consumer's
wakeup() method is called.  From SLICC's point-of-view, a message appears
on the in_port associated with the TimerTable and the appropriate
Event/Transition is triggered.

I envision your module being somewhat similar.  It is connected to an
in_port of some SLICC controller and will generate a message at the
appropriate time.  Your module will be somewhat different because it
doesn't know exactly when to wakeup the consumer.  However when it does
know, it can simply schedule an event to wake up at the very next cycle on
the global event queue causing a message to appear on the in_port.
Depending on how your DRAM module works, it may need a "heartbeat"
function called every cycle so that it has the opportunity to schedule
these wakeups.

Am I making any sense?

--Mike


>
>      	I just subscribed to the user list, but I am trying to follow up on
> Nazanin's post.
>
>  	Basically, what Nazanin is asking for is if GEMS has the facility
> to support a callback function to allow the memory system to return a
> latency value at a later time, after the memory system simulation code
> has had time to wait around a bit, not at request time. We don't want to
> "call a function to find out what the latency is". To do that implies
> that the function has to return right away with the latency of the
> access. What we really want is the ability to issue a memory request into
> a buffer/queue, and then simulate the request through the memory
> subsystem hierarchy. If that request hits a bank conflict, a later
> request may be able to complete earlier, and re-ordering can occur in the
> memory system, but that re-ordering may have effects on the
> deferred/re-ordered request that occured semantically at an earlier time.
> We'd like to be able to simulate all those interactions, re-ordering
> policies and mechanisms.
>
>  	What we need is to support a mechanism where a callback function
> can be used to tell the processor(s) that a memory reference has
> completed, not just an external function call to return latency value.
>
>  	We're still stumbling around the GEMS code, looking at the slicc,
> but can't quite make heads or tails of it right now. Your help is
> appreciated.  Thank you.
>
>  							David
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>