Re: [Gems-users] Instruction Flow (contd...)

[Luke Yen <lyen@xxxxxxxxxxx>]

   I wanted to add to what has been said.  The stepping of Simics is even
more constrained than that described by Greg.  When Opal steps Simics,
Simics advances its own internal PC to execute the next instruction.  Opal
does not inform Simics as to which instruction should be executed, just
that Simics should execute another instruction.

  Thus Opal could go off and do something completely different from
Simics, but this would violate the in-order processor state as indicated
by Simics, and thus Opal during the retirement check would be restarted to
the correct PC indicated by Simics.

  So to summarize I see it as a circular relationship: Opal drives Simics
during the retirement check, and Simics drives Opal on any restarts due to
deviations between Simics and Opal processor state.

  Luke

On Thu, 8 Sep 2005, Greg Byrd wrote:

>
> In your terminology, Opal drives Simics -- at least that's my understanding.
>
> Opal fetches instructions directly from the memory object, not involving
> Simics.  When an instruction retires (in order), Opal tells Simics to
> execute that instruction.  Then the Simics processor state and the Opal
> state are compared to check for correctness.  If the Simics state
> doesn't agree with Opal, then Opal reinitializes with the Simics state
> and restarts the pipeline with the next instruction.
>
> Opal won't retire a memory instruction until it's complete.  So there's
> no possibility that Simics will execute an instruction before it's been
> executed in Opal.
>
> ...Greg Byrd, NC State
>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>