Re: [Gems-users] Help with Opal Tester

[lyen@xxxxxxxxxxx]

Ankit,

   The Opal tester was designed to test the important components of Opal,
such as instruction decoding (when you use the command "make usd") and
basic pipeline functionality (when you use "make tester").  When
executing in stand-alone mode Opal simulates its own TLB, which gets
its translations from the TLB trace file, and uses its own internal
memory hierarchy (not Ruby).  Simics API calls are ignored (see
simdis12.h in system/).  This  memory hierarchy does not have any
built-in cache coherence, so I would not use it for MP traces.

  Regards,
   Luke

> Hi,
>
> Regarding the first option : I think there is a problem. The trace may
> not match the opal simulation
> because of the OS activity going on (hadling interrupts) as the sequence
> of instructions being fetched is different. Do you think
> this problem can be avoided?
> What is was thinking was that if "tester" runs the trace exactly as the
> opal simulations except ofcourse it is reading from the trace then that
> should effectively be a perfect branch predictor. But I am not sure if
> tester was written for this purpose. Can you please let me know what the
> tester was designed for?
>
> Thanks,
> Ankit
>
> Luke Yen wrote:
>
>>Ankit,
>>
>>  I have looked into this problem before (trying to do the same thing),
>>and I think there are a couple options.
>>
>>1) As I have mentioned before there is no perfect BP flag in Opal, and I
>>recommended using the Opal trace utility to generate branch traces and
>>then feeding it back into Opal.  I am not sure if that is currently
>>an option for Opal, or if it just works for the tester.  I can imagine
>>someone modifying Opal to read from the branch trace in real time, while
>>simulating a workload.
>>
>>2) Carl Mauer (author of Opal) was experimenting with some runahead type
>>ideas, because Opal has some initial code to construct a control flow
>>graph.  You can find this code in pseq.C.  Search for flow_inst_t, which
>>are instructions that are linked together to form a CFG.  However one of
>>the problems I saw is that in order to construct the CFG one must
>> actually
>>step Simics, which will conflict with simulating the OoO timing of the
>>processor.  I haven't figured out a solution to this problem, and maybe
>>you can figure out how to get this working and post a solution.
>>
>>3) I am not sure if MAI has some perfect branch prediction options but
>>maybe one can write a simple MAI module that can hook up to Opal whenever
>>it sees a branch instruction, and then choose the correct path.
>>
>>  Regards,
>>   Luke
>>
>>On Fri, 8 Jul 2005, Ankit Jalote wrote:
>>
>>
>>
>>>Hi,
>>>Thanks for the reply. I will look at the code to figure this out.
>>>I have one additional question though. I am trying to simulate perfect
>>>branch prediction in gems. Can you please give me some pointers to do
>>> this?
>>>One way I can think of is by creating the trace and then running the
>>>created trace through tester. But is there a better way to implement
>>>perfect prediction?
>>>Thanks a lot,
>>>Ankit
>>>
>>>
>>>
>>_______________________________________________
>>Gems-users mailing list
>>Gems-users@xxxxxxxxxxx
>>https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>>
>>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>