Re: [Gems-users] stalling simics

[Brianna Sue Bethel <Brianna.Bethel@xxxxxxxxxxxx>]

Hello,

I have a related question to your answer below.  You state below that "The model is that Ruby will stall a Simics processor indefinitely until a request finishes. "  Does this mean that on a 2 processor system for example Ruby will stall both Simics processors or just the one that its working on?  

Thank you,

Liz 

---- Original message ----
>Date: Wed, 2 May 2007 16:00:16 -0700 (PDT)
>From: "Dave Z." <zhu_dave@xxxxxxxxx>  
>Subject: Re: [Gems-users] stalling simics  
>To: Gems Users <gems-users@xxxxxxxxxxx>
>
>Thanks for your quick reply, Dan! Now, I got the
>stalling and unstalling working. But this raised some
>other issues in SimicsProcessor. When the request is
>"serving", there is an error message for unstalling
>Simics without Ruby asking. Why is this considered an
>error? 
>
>Also, there is an assertion
>(m_active_requests[idx].status == Queued), why is this
>necessary? Is it okay to remove this assertion without
>breaking anything else?
>
>Thanks,
>
>Dave
>
>
>--- Dan Gibson <degibson@xxxxxxxx> wrote:
>
>> Ruby stalls Simics initially by returning a huge
>> number of stall cycles 
>> (2 billion if I remember correctly) from the initial
>> request.
>> 
>> The unstall events occur as part of a hitCallback,
>> via the SIMICS_* 
>> interface. Grep in interface.C for "stall" and you
>> should find lots of 
>> API for stalling and unstalling Simics.
>> 
>> Regards,
>> Dan
>> 
>> Dave Z. wrote:
>> > --- Mike Marty <mikem@xxxxxxxxxxx> wrote:
>> >
>> >   
>> >>> If I understand correctly, when Simics
>> encounters
>> >>>       
>> >> a
>> >>     
>> >>> data or instruction access, it stalls and passes
>> >>>       
>> >> the
>> >>     
>> >>> request to Ruby. Then, Ruby handles the request
>> >>> (SimicsDriver, SimicsProcessor, Sequencer,
>> >>>       
>> >> Coherence
>> >>     
>> >>> Protocol) and returns some number of cycles.
>> When
>> >>> Simics receives the number of cycles, it waits
>> >>>       
>> >> until
>> >>     
>> >>> that many cycles pass and continues simulation.
>> >>>       
>> >> Please
>> >>     
>> >>> correct me if I'm wrong.
>> >>>
>> >>>       
>> >> The model is that Ruby will stall a Simics
>> processor
>> >> indefinitely until a
>> >> request finishes.  Then it unstalls Simics and
>> >> Simics will "replay" the
>> >> stalled instruction.  It doesn't actually return
>> the
>> >> # of cycles stalled
>> >> to Simics.
>> >>     
>> >
>> >
>> > Thanks for your prompt reply, Mike. Could you
>> please
>> > tell me where Ruby stalls and unstalls Simics? Is
>> it
>> > possible to stall Simics indefinitely and unstall
>> it
>> > in a magic callback, for example?
>> >
>> > Thanks,
>> >
>> > Dave 
>> >
>> > __________________________________________________
>> > Do You Yahoo!?
>> > Tired of spam?  Yahoo! Mail has the best spam
>> protection around 
>> > http://mail.yahoo.com 
>> > _______________________________________________
>> > Gems-users mailing list
>> > Gems-users@xxxxxxxxxxx
>> >
>>
>https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>> > Use Google to search the GEMS Users mailing list
>> by adding
>> "site:https://lists.cs.wisc.edu/archive/gems-users/";
>> to your search.
>> >
>> >   
>> 
>> -- 
>> http://www.cs.wisc.edu/~gibson [esc]:wq!
>> 
>> _______________________________________________
>> Gems-users mailing list
>> Gems-users@xxxxxxxxxxx
>>
>https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>> Use Google to search the GEMS Users mailing list by
>> adding
>> "site:https://lists.cs.wisc.edu/archive/gems-users/";
>> to your search.
>> 
>> 
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam?  Yahoo! Mail has the best spam protection around 
>http://mail.yahoo.com 
>_______________________________________________
>Gems-users mailing list
>Gems-users@xxxxxxxxxxx
>https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>