Changes to support integrating MAP simulations as components in some larger simulation

[VictorYing]

Hi, Sparta/MAP developers, we have an existing perf model code base that uses Sparta/MAP, and we've been exploring how we can integrate one or more instances of that into larger system simulation together with other components modeled using another framework such as SST.

Would you be open to accepting patches to make it easier for perf modelers to instantiate multiple concurrent Simulations and Schedulers, possibly in multiple threads? We have some initial working experiments that demonstrate it is possible to bypass (or, inherit from and override parts of) sparta::app::CommandLineSimulator as a means to construct and control multiple co-existing sparta::Scheduler instances. Along the way we found some changes we want to make within the Sparta/MAP framework that we believe should not impose noticeable overhead or complexity, such as:

• sparta::app::Simulation could have an option to not register any signal handler in the constructor, in order to integrate with a larger framework that may prefer to register its own handlers
• TriggerManager needn't be a global singleton, for example each Scheduler instance can own a TriggerManager instance, or perhaps we could have a single TriggerManager instance per thread.

We're open to suggestions for how we can best contribute our changes back upstream to this repository.

[klingaard]

Hi Victor! Thanks for the questions.

First, that's exciting to see a potential integration with frameworks (other than SystemC) like SST. I know the MEEP project did something like this with SST, but not sure where it ended up.

Yes! We are always open to accepting patches that improve the framework. We have some simple rules that we require folks follow; Rule #1 being the most critical. 😁 Bring them on over!

Regarding the other enhancements:

• Telling the Simulation class to NOT register signal handling is a good enhancement. In fact, I've had some folks at Synopsys ask the same thing. We should enable that support natively
• I really don't like singletons, so having the TriggerManager be owned by a specific class like the Scheduler (i.e. your suggestion) seems prudent to me

Please prepare a PR for each of those enhancements.

BTW, I opened a discussion for map_v3 if you're interested in adding your complain... er... suggestions. #509