Re: [Gems-users] stalling simics

[Dan Gibson <degibson@xxxxxxxx>]

Both the error message and the assertion are dynamic checks that the Ruby/Simics interface is operating as Ruby thinks it is. Ruby expects Simics to remain stalled if Ruby has stalled Simics to service a memory request -- if you call explicitly unstall Simics elsewhere, then simics will re-issue the memory request (recall Simics (re-)issues all requests until a stall time of zero is returned by Ruby). However, SimicsProcessor manages the actual stalling state of Simics, and becomes confused when Simics unstalls unexpectedly.

Basically, you need to be careful about when you stall and unstall Simics. You should NOT stall Simics if Ruby has _already_ stalled a given processor, nor should you unstall a processor that Ruby has stalled on a memory request.

Regards,
Dan

Dave Z. wrote:

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.