Is there a way to have a parameterized replacement policy/branch predictor/prefetcher in ChampSim such that the parameter is passed via the config file?

[Setu-Gupta]

I want to implement a replacement policy which has a tuning knob. I want to pass this constant to my policy as a parameter via the CACHE::initialize_replacement() call. Is it possible to convert this signature to something like CACHE::initialize_replacement(uint32_t param) so that I can pass a parameter to my policy when it is created? Moreover, if it is indeed possible to do so, how can I specify the value of this parameter in my config file?

I know that I can hardcode this value in my policy bu I don't want to do that. I want to be able to change this value via the config.

[ngober]

I've theorized about this before, and I would love it if it's eventually possible. The mechanisms are probably in place on the develop branch, it would probably just take someone willing to work on it.

I think something that you could do is to use the development branch, where modules can be specified as classes, and to make the module class a template class, like template <uint32_t param> class MyReplacement : public champsim::modules::replacement {};. Then, in the configuration, you could specify

{ "LLC": { "replacement": {
    "class": "MyReplacement<2>",
    "path": ...
} } }

[maccoymerrell]

Seems like this would still be tedious with Champsim's current need to recompile after altering the config file. I saw that simulators like Ramulator2 built their entire system based on the config file passed at runtime rather than hardcoding and selective compiling. The con of course is that you need to compile in all prefetching schemes, replacement policies, etc....

I have thought about something like this a lot when having to make 6 or 7 directories with different configurations of champsim. It feels wrong to just have a directory full of nothing but different champsim binaries with different configurations.

[ngober]

I really do agree with you. We eventually ought to go with runtime configuration. But, you've identified the difficulty. We would need to compile in all possible modules and make them runtime selectable. Not impossible, it would just take a bit of work. ChampSim already has a dependency on a reputable JSON parser, so we're a good step of the way there already. I would want to guarantee that the current specification flexibility is maintained. That would mean porting all of the Python configuration parsing to C++. I have other thoughts about this, but yes, we should eventually do that. I'll be waiting in my office for any volunteers.