Re: [Gems-users] how to generate ruby tester clock

[mehmetderin.harmanci@xxxxxxx]

Hello,

 I'm only a GEMS user but I guess you can check the

   TraceRecord::issueRequest()

 function (in the recorder/TraceRecord.C file). Here for each request the
 g_eventQueue is rescheduled (that is, it is triggered in X cycles later to
 trigger all the events between the current_cycle and current_cycle+X. If
 I'm not mistaken there is a fixed X value set in the GEMS code, but you can
 change it for your needs (for myself I had modified the code such that each
 trace record also had its arrival time in the trace file and I was each time
 recheduling the event queue to this arrival times, all the events in between
 were triggered (I guess it is like a chain reaction, the first event which
 is  scheduled, when triggered generates another event which is again
 scheduled indirectly by enqueueing messages into some message queues (the
 links betweem caches and memories). Since a new event is scheduled and the
 EventQueue tries to trigger all the events up to a given time, the newly
 scheduled event is also directly triggered by the EventQueue object. So
 rescheduling the EventQueue to a later time automaticly provides all the
 events to be processed up to the new scheduling time provided thatthe time at
 which you rescheduled the EventQueue is long enough for the request to be
 processed (i.e. if the latency of the worst memory request penalty is smaller
 than X cycles) then everything would work properly. In my case, I did not
 care about the final execution time of the requests I always  had the
 interval between two consecutive access (two consecutive trace record)
 larger than that of the worst possible a memory request penalty (I was more
 focused on how the system responded to each request rather than the timing).

 Another solution that comes to my mind now is that leaving everthing in
 TraceRecord as is and just find the two lines in Tracer::playbackTrace
 function (recorder/Tracer.C file)


  // Flush the prefetches through the system
  g_eventQueue_ptr->triggerEvents(g_eventQueue_ptr->getTime() + 1000);  // FIXME
- should be smarter

  EventQueue is rescheduled for the last time for 1000 cycles later than
  current time. I guess this line is here to ensure that if the current
  simulation time was not enough to run all the necessary events, then by
  rescheduling the EventQueue once more all those remaining events will also
  be triggered. So if you figure out that you simulation stops earlier than
  it should you can just adjust the 1000 cycles to anything so that you are
  sure to run the simulation till the end (e.g. if you think the simulation
  should run until 5000 cycles and it runs until 2000 cycles (including the
  line execution of the line above) change 1000 to 4000 (or more)
  in the above line so that you are sure the simulation runs until the point
  you like.

   Maybe I'm still missing a point. GEMS developers would tell better.

    Hope this helps,

      Derin.





Selon wshaogang <wshaogang@xxxxxxxxxxx>:

> Dear all:
>
>          I know that if ruby runs as a Simics module, then by using
> SIM_time_post_cycle function, ruby repeatedly triggers events in global
> event queue every ruby clock. This is the main mechanism that event
> scheduled to run in future will be eventually triggered.
>
>          But I am not very clear that if the ruby runs under the tester
> which is relatively independent of SIMICS, how to generate the ruby's
> driving clock? I have studied the tester code, but I can not found such
> code.  So can anybody explain by what means that events in global queue be
> triggered?
>
>          Thanks very much.
>
>
>
>
>
> Best regards
>
>