Basically, one way or another you've made SimicsProcessor think there is another
request coming from Simics -- thats why lingering request isn't set. Either
detect when you're issuing cache-clearing accesses (and DON'T set
m_lingering_request in those cases) or detect when m_lingering_request is set
out-of-range and fix it.
Mladen Nikitovic wrote:
> by "passing through to the Sequencer", do you mean an early return in
> the hitCallback function?
>
> This is a suggestion for the first few lines in hitCallback function.
>
> void SimicsProcessor::hitCallback(SubBlock& data) {
> DEBUG_MSG(SEQUENCER_COMP, MedPrio, "hitCallback");
> DEBUG_EXPR(SEQUENCER_COMP, MedPrio, m_proc);
> DEBUG_EXPR(SEQUENCER_COMP, MedPrio, data.getAddress());
> DEBUG_EXPR(SEQUENCER_COMP, MedPrio, data.getSize());
>
> * if(data.getAddress().getAddress() < 0x100000000ll &&
> data.getAddress().getAddress() >= RubyConfig::memorySizeBytes()/2)
> return;
> *....
>
> Basically, I'm checking if the address is within the address space where
> I issue my "flushing" requests. I noticed that requests above
> 0x100000000ll belong to the transaction log, so I had to add that condition.
>
> Is this what you had in mind?
>
> /M
>
> Dan Gibson wrote:
>
>> The 'lingering' request is SimicsProcessor's way if hiding a particular
>> peculiarity of the Simics interface:
>> When Simics sends a request to Ruby for timing information, it expects a
>> stall time in return. Ruby provides this -- 2 billion cycles in most
>> cases. Thats OK, since Ruby is going to eventually explicilty unstall
>> simics with a call to SIMICS_stall_cycle(). However, when Simics is
>> explicitly unstalled, it re-issues the memory request to Ruby. (In
>> effect, it asks it's cache model AGAIN if the block is there or not).
>> This second request is intercepted at SimicsProcessor, identified as the
>> lingering request, and the rest of Ruby never sees it.
>>
>> You should modify SimicsProcessor to allow your writeback callbacks to
>> pass through to the sequencer. Either add a flag (last_flushing_addr ?)
>> or maybe just check if the address is sufficiently large...
>>
>> Regards,
>> Dan
>>
>> Mladen Nikitovic wrote:
>>
>>
>>> Hi,
>>>
>>> I'm encountering some problems when flushing the L1 data cache of a
>>> processor. I have already notified the target operating system that the
>>> processor is offline, so there is no problems regarding that. The
>>> processor does not execute any real instructions after that.
>>>
>>> The approach is to simply walk the cache, detect the entries that are
>>> dirty and by issuing a write operation to that same entry (but with an
>>> address that would not conflict any other requests, using addresses
>>> beyond the physical memory size, yes I do lie to ruby about the size :)
>>> one would to force the entry out to the L2.
>>>
>>> I did the following in Sequencer.C (where the flush is implemented).
>>>
>>> First I addressed the mandatory queue explicitly of that processor that
>>> is being shut down. I enqueued requests of type CacheRequestType_ST with
>>> addresses that would force the cache to push out the dirty entries (the
>>> physical memory size is 256MB but I use address space 256 - 512 MB to
>>> request data addresses that will not be used in reality, they are only
>>> used for flushing).
>>>
>>> However, using this approach i got the following assertion:
>>>
>>> Sequencer: flushIL1caches: Dcache flush done
>>> failed assertion 'm_writeRequestTable_ptr->exist(line_address(address))'
>>> at fn void Sequencer::writeCallback(const Address&, DataBlock&, Gener
>>> icMachineType, PrefetchBit) in system/Sequencer.C:403
>>> failed assertion 'm_writeRequestTable_ptr->exist(line_address(address))'
>>> at fn void Sequencer::writeCallback(const Address&, DataBlock&, Gener
>>> icMachineType, PrefetchBit) in system/Sequencer.C:403
>>> At this point you might want to attach a debug to the running and get to the
>>> crash site; otherwise press enter to continue
>>>
>>> This assertion led me to the conclusion that I probably need to make a
>>> call to makeRequest in order to force the request to exist in the
>>> writeRequestTable.
>>>
>>> So, the "flush" is now done the follwing way:
>>>
>>> for(i=0; i<Dsets; i++) {
>>> for(j=0; j<Dassoc; j++) {
>>> if(m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[cpu]->getDirty(i,j)) {
>>>
>>> m_chip_ptr->getSequencer(cpu)->makeRequest(CacheMsg(Address(m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[cpu]->getAddress(i,j)
>>> +
>>> (RubyConfig::memorySizeBytes()/2)),
>>> CacheRequestType_ST,
>>> Address(0),
>>> AccessModeType_SupervisorMode,
>>> 4,
>>> PrefetchBit_No,
>>> 0,
>>> false));
>>> }
>>> }
>>> }
>>>
>>> Using this approach I get the following assertion instead:
>>>
>>> Sequencer: flushIL1caches: Dcache flush done
>>> failed assertion 'm_lingering_request_address != Address(0-1)' at fn
>>> void SimicsProcessor::hitCallback(SubBlock&) in simics/SimicsProcessor.C:202
>>> failed assertion 'm_lingering_request_address != Address(0-1)' at fn
>>> void SimicsProcessor::hitCallback(SubBlock&) in simics/SimicsProcessor.C:202
>>> At this point you might want to attach a debug to the running and get to the
>>> crash site; otherwise press enter to continue
>>> PID: 19536
>>>
>>> There is something about a "lingering_request" that is supposed to be
>>> equal to Address(0-1), but I don't understand what might be wrong with
>>> my request. Am I missing something regarding the parameters to my call
>>> to MakeRequest?
>>>
>>> Hope you can help me.
>>>
>>> /Mladen
>>>
>>>
>>> _______________________________________________
>>> 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.
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}