Re: [Gems-users] Philip Garcia

[Philip Garcia <pcgarcia@xxxxxxxx>]

no real clue what that assertion does exactly... it sounds like pseq has a problem because the local cycles is less than what it should be.  I'd recommend looking at what getLocalCycle() does, and what exactly is stored in m_fetch_ready_cycle[proc].  

phil

On Feb 13, 2010, at 3:46 AM, Muhammad abid Mughal wrote:

hi Philip Garcia :

 

thanks for your quick response.

 

             One more question please:

 

              I am using opal+ruby. when i use WriteBuffer, the following assertion get failed:

void pseq_t::fetchInstrSimple():Assertion '( m_fetch_ready_cycle[proc] >= getLocalCycle()  )'

 

 

Could you please give me some clues?

 

Thank you very much

 

Regards,

Muhammad abid

---

From: Philip Garcia <pcgarcia@xxxxxxxx>
To: Gems Users <gems-users@xxxxxxxxxxx>
Sent: Saturday, February 13, 2010 14:51:16
Subject: Re: [Gems-users] Philip Garcia

changing the tick stuff doesn't effect simulation speed...  The only thing is changes is how often the OS executes.  In my experience, on a 2.4GHz core-2 machine, it takes just less than 1 day to simulate 2 billion cycles of a single core system.  The time scales linearly with the number of cores.

Phil

On Feb 13, 2010, at 1:39 AM, Muhammad abid Mughal wrote:

Hi Philip Garcia:-

                         Hope you are doing good.  Could you please spare some time out for my questions?

      Did you use %stick and %stick_cmpr  registers with 75mhz-based cpu machine to improve simulation speed?

      In your case , how much time it took to simulate 1 billion instructions when you used the above hack?

   Thanks

Muhammad abid

---

From: Philip Garcia <pcgarcia@xxxxxxxx>
To: Gems Users <gems-users@xxxxxxxxxxx>
Sent: Tuesday, February 9, 2010 7:44:43
Subject: Re: [Gems-users] Change in cpu frequency - question

if you want, I could get together sometime, with you, or someone else working on Opal to see if we can get these changes working on one of your branches of opal running solaris.  I don't have any of that locally, and my opal files have been modified enough from the vanilla install.  However, it would likely be useful for gems to have code to support this, as well as fixed code that does context tracking.

Phil

On Feb 8, 2010, at 5:41 PM, Dan Gibson wrote:

Neat. I'd be interested in learning whether this hoses Solaris or not.

On Mon, Feb 8, 2010 at 4:42 PM, Philip Garcia <pcgarcia@xxxxxxxx> wrote:

for the first part of our work, we modified pseq.C.  We have a variable called m_time_per_1_ms, which is just the number of cycles in 1ms of simulated cycle time.  We use this, because linux typically expects a timer interrupt every mS.  We added this variable to the rubyconfig class.  Also note that our current implementation is not SMT aware, but should be simple to modify for that.  This modification just checks if we should have another timer interrupt, and if so tells simics to post the event in 2 cycles.


At the end of AdvanceCycle We have the following code:
tick_t curr_time = system_t::inst->getGlobalCycle();
   //If it has been almost 1mS since the last interrupt, we want to set the tick cmpr register
   //if(curr_time %100000 == 0){
   //  DEBUG_OUT("advanceCycle:: curr_time = %llu, last_intr_time = %llu, m_time_per_1ms = %llu\n",curr_time,m_last_interrupt4e_time, m_time_per_1ms);
   //}

   //Phil:  SMT has to be disabled.  This is really ugly!!!  Someone needs to fix this...
   if((curr_time - m_last_interrupt4e_time > (m_time_per_1ms - 3)) && !m_tick_interrupt_pending ){
     tick_t curr_tick = SIM_read_register(M_PSTATE->getSimicsProcessor(0), 39);//get tick register
     //print info
     DEBUG_OUT("T=%10llu :: pseq_t[%d]:advanceCycle last interrupt = %llu, curr_tick = %llu, set tick_cmpr\n",curr_time,m_id,m_last_interrupt4e_time, curr_tick);
     //Write curr_tick + 2 so that the interrupt will happen in two SIMICS ticks
     SIM_write_register(M_PSTATE->getSimicsProcessor(0), 41, curr_tick+2);
     //set tick_interrupt_pending so that we don't update the tick_cmpr register again
     //before the interrupt happens
     m_tick_interrupt_pending = true;
   }
 }

We then modified the pseq_t::postException method to check for the timer interrupt trap.  This way we can reset the tick compare register to a very large value so it only goes off when we specify (in advance cycle):
 //***************
 //tick hack
 if(exception == Trap_Interrupt_Level_14){ //the trap type for "4e"

   m_tick_interrupt_pending = false;

   tick_t curr_time = system_t::inst->getGlobalCycle();
   tick_t curr_tick = SIM_read_register(M_PSTATE->getSimicsProcessor(proc), 39);//get TICK register
   SIM_write_register(M_PSTATE->getSimicsProcessor(proc), 41, curr_tick+99000000);
   int delta_time = (curr_time - m_last_interrupt4e_time);
   int delta_tick = (curr_tick - m_last_interrupt4e_tick);

   m_last_interrupt4e_time = curr_time;
   m_last_interrupt4e_tick = curr_tick;

   m_last_interrupt4e_dtime = delta_time;//some calculation for delta time
   m_last_interrupt4e_dtick = delta_tick;//some calculation for delta tick
   DEBUG_OUT("T=%10llu ::pseq_t[%d] postException, save last_time = %llu, last_tick = %llu\n",curr_time,m_id, curr_time, curr_tick);
 }

Lastly, we reset the register when the OS is switched onto the CPU, and a tick interrupt was pending.  This is in the contextSwitch method.

if(new_context){
     //DEBUG_OUT("new_context = %x ",new_context);
     if(m_primary_ctx[proc] == 0 ){
       //DEBUG_OUT("m_primary_ctx is the OS ");
       if(!m_tick_interrupt_pending && thread_ctx){
         tick_t curr_tick = SIM_read_register(M_PSTATE->getSimicsProcessor(proc), 39); //get_tick_reg
         //write the tick_cmpr register as 99M more than the current value, but only if
         //we haven't just set it to something to cause an interrupt
         SIM_write_register(M_PSTATE->getSimicsProcessor(proc), 41, curr_tick + 99000000);
         if(thread_ctx){
           DEBUG_OUT("ContextSwitch::pseq_t[%d] set tick_cmpr to %llu\n",proc,curr_tick+99000000);
         }
       }
     }

These changes seem to be sufficient to make linux work properly, and it does allow timer interrupts to still go off.  One needs to be careful to not completely disable timer interrupts, or the OS can and likely will fail to function properly.

Phil

On Feb 8, 2010, at 4:09 PM, Pradeep Ramachandran wrote:

> I used the pointer given by Dan to reset the stick_cmpr registers from simics, and this masks out the Timer interrupt (thanks for the pointer Dan!). However, I just want to make doubly sure that there isn't something else that I should be doing that I'm not. If you can paste the snippet of code that you guys use, it would be very useful for me to cross-check.
>
> Thanks,
> Pradeep.
>
> On Feb 7, 2010, at 2:19 PM, Philip Garcia wrote:
>
>> I can look up the hack we use, however I can't really guarantee it will work for you.  I'm using GEMs on a bagle target machine which is based on an UltraSparc II processor, and not a III.  I'll try to post some code later tonight or tomorrow.
>>
>> Phil
>> On Feb 7, 2010, at 2:05 PM, Pradeep Ramachandran wrote:
>>
>>>
>>> On Feb 6, 2010, at 7:00 PM, Philip Garcia wrote:
>>>
>>>> You can get around the 75MHz clock issue by stalling the timer interrupts  until you want them.  This can be done by manipulating the tick and tick compare register so that it goes off at specified times.
>>>>
>>>
>>> I have been digging around to find information on the tick and tick compare registers (%stick and %stick_cmpr), but I have found hardly any info (even the SPARCV9 manual doesn't list them!). Do you have any pointers on how the registers are used? As I'd mentioned before, I would like to make the timer interrupts less frequent so that I simulate a 2GHz-like balanced machine with the 75MHz simics system, for which I need to make timer interrupts far less frequent.
>>>
>>> Thanks,
>>> Pradeep.
>>> _______________________________________________
>>> 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.
>>>
>>
>> _______________________________________________
>> 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.
>>
>
> _______________________________________________
> 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.
>

_______________________________________________
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.

---

New Email names for you! 
Get the Email name you've always wanted on the new @ymail and @rocketmail.
Hurry before someone else does! _______________________________________________
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.

---

Get your new Email address! 
Grab the Email name you've always wanted before someone else does! _______________________________________________
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.