mem-ruby, configs: Add a generic CHI controller as a stepping stone for ruby+classic topology

[giactra]

This PR is mainly adding a CHIGenericController class to model a coherence controller entirely
in C++ to work with ruby. This is a stepping stone towards supporting a hybrid setup with
classic caches + ruby.

[powerjg]

Would you be willing to talk about this in the next gem5-dev meeting?

This is super cool!

[giactra]

Would you be willing to talk about this in the next gem5-dev meeting?

Will it be on the 9th of May? If that's the case I won't be able to attend it, though @tiagormk (who's the author of these changes/feature) might be

[ivanaamit]

Yes, it will be on May 9th at 4pm UTC.

@tiagormk, would you be available to attend and discuss this improvement?

[tiagormk]

Yes, it will be on May 9th at 4pm UTC.

@tiagormk, would you be available to attend and discuss this improvement?

Unfortunately I have a conflict that time. But I could join the June meeting probably.

[shinezyy]

Cool!
We are doing something similar: see gem5 issue #1164.

I notice that you have many empty implementations like

Sequencer*
CHIGenericController::getCPUSequencer() const
{
    // CHIGenericController doesn't have a CPUSequencer
    return nullptr;
}

We are facing similar things.
The root cause is that AbstractController is the interface for a Ruby cache but not the interface for an upstream of Ruby cache. So we define a more basic class HasDownStream (has ruby cache downstream) here. This is only a draft.

I think there should be something defining a cleaner interface of an upstream of Ruby cache. I'd like to participate.

[giactra]

Cool! We are doing something similar: see gem5 issue #1164.

Yes I saw the issue few days ago and I also noticed the similarity

I notice that you have many empty implementations like

Sequencer*
CHIGenericController::getCPUSequencer() const
{
    // CHIGenericController doesn't have a CPUSequencer
    return nullptr;
}

Yes, that is mainly because this controller constitutes a pure virtual interface. We have a subclass we will upstream which overrides most of these methods to be able to transform a gem5 classic packet into a ruby packet. The reason why we don't commit to a sequencer in the CHIGenericController is because we want to be able to support the case of a sequencer-less configuration.

If I understood correctly this might be a useful scenario for you as well.

We are facing similar things. The root cause is that AbstractController is the interface for a Ruby cache but not the interface for an upstream of Ruby cache. So we define a more basic class HasDownStream (has ruby cache downstream) here. This is only a draft.

I think there should be something defining a cleaner interface of an upstream of Ruby cache. I'd like to participate.

Thanks I will look at your draft if I find some time. I will also keep you in the loop if there is an update. Most likely we will discuss this feature at the next gem5 developer meeting.

[ivanaamit]

@giactra, @tiagormk: Are you available to present this at next week's developer meeting on Thursday, June 13th, at 4 PM UTC?

[tiagormk]

@giactra, @tiagormk: Are you available to present this at next week's developer meeting on Thursday, June 13th, at 4 PM UTC?

Yes, I can present this.