Re: [Gems-users] Sequencer::isReady - one request type per address?

[Philip Garcia <pcgarcia@xxxxxxxx>]

Do you know what the crash is?  I recently experienced some issues with the isReady code when using an SMT setup where I could end up in a case were one of the SMT threads starves the other, and a lack of forward progress is made.  However, this was for GEMS with ruby/opal loaded.  If you could give details of the system you were simulating, and what the error was I might be able to offer some advice on it.

I'm not 100% sure about the invariant thrown in there either, I didn't end up changing that at all.

Phil

On Mar 31, 2011, at 3:14 PM, Binh Q. Pham wrote:

Hi everyone,
I am using GEMS for x86, and my simulation crashed in Sequencer::isReady:
// LUKE - disallow more than one request type per address
    //     INVARIANT: at most one request type per address, per processor
    int smt_threads = RubyConfig::numberofSMTThreads();
    for(int p=0; p < smt_threads; ++p){
        if( m_writeRequestTable_ptr[p]->exist(line_address(request.getAddress())) ||
                m_readRequestTable_ptr[p]->exist(line_address(request.getAddress())) ){
            cout << "OUTSTANDING REQUEST EXISTS " << p << " VER " << m_version << endl;  //binh: bug is here
            //printProgress(cout);
            return false;
        }
    }

Is there any reason why we have to keep the invariant: one request type per address above? To me, it is possible to have multiple requests per address in the cache...

Thank you in advance for your time and help,
Binh

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