ruby: consumer: avoid using receiver side clock

Information
Submitter:	Nilay Vaish
Repository:	gem5
Branch:	default
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

Description

Changeset 9590:db23351f5faa
---------------------------
ruby: consumer: avoid using receiver side clock
A set of patches was recently committed to allow multiple clock domains
in ruby. In those patches, I had inadvertently made an incorrect use of
the clocks. Suppose object A needs to schedule an event on object B. It
was possible that A accesses B's clock to schedule the event. This is not
possible in actual system. Hence, changes are being to the Consumer class
so as to avoid such happenings. Note that in a multi eventq simulation,
this can possibly lead to an incorrect simulation.

There are two functions in the Consumer class that are used for scheduling
events. The first function takes in the relative delay over the current time
as the argument and adds the current time to it for scheduling the event.
The second function takes in the absolute time (in ticks) for scheduling the
event. The first function is now being moved to protected section of the
class so that only objects of the derived classes can use it. All other
objects will have to specify absolute time while scheduling an event
for some consumer.

Testing Done

I'm a little bit confused with how things are scheduled here. The MessageBuffer is bi-synchronous and it makes sense that it has to deal with two clocks (or just absolute ticks). The other objects I am less convinced should ever have to worry. There is definitely some source of confusion here in that the output of object A currently might end up calling a function on object B at clk_a edge rather clk_b edge, but that's literally happening in 10's or even 100's of places in the codebase. If we "solve" it I'd rather go for something generic, otherwise we will have to resort to ticks everywhere which also is not feasible with the DVFS work requiring cycles.

Nilay Vaish March 12, 2013, 11:10 a.m. (March 12, 2013, 11:10 a.m.)

From a physical implementation, I think, A generally does not
know when B is going to act or should act. The only thing that A 
knows is that after X amount of time from now, B will have access 
to the output that A just generated. Hence, I am not in favor of 
accessing B's clock edge from A.

So for scheduling B, A specifies the delta time in Ticks. A wrapper 
function (scheduleEventAbsolute() in the current context) should 
actually schedule the event when the next edge for B is going to 
arrive after curTick() + delta time has passed. Note that this 
wrapper function should not at any time make access to B's clock
edge.

Andreas Hansson March 14, 2013, 12:10 a.m. (March 14, 2013, 12:10 a.m.)

I am not entirely convinced what the best way forward it, but it definitely extends beyond Ruby. I'm not sure the "absolute tick" is the solution. Ultimately we are trying to hide clock domain crossings in ports that are implemented as function calls. The sender should send in its clock. The receiver should ultimately not "see" this until all modules have had a chance to provide their input.

You have a pending review.

Review Board 2.0.15

This change has been marked as submitted.

Screenshots

Files

Status: Closed (submitted)