It certainly can be put in all of them. The need is that with the support for ARMv8 we will be adding a set of options about what features you want with the current running simulator (e.g. do you want to start in 64bit or 32bit mode or do you want support for the security extensions?). This doesn't make much sense to have an option on the ISA objects, because it's not configurable per CPU, it's really a system thing and having CPUs with different ideas about the feature set would be hugely problematic. So, we've added a parameter to the ISA objects so from the ISA you can get to the system and inquire if a certain feature is enabled. For this to work every ISA needs to have a system object, although none of them use it for anything other than ARM at the moment.

Make sense?

Thanks for the explanation.  Practically it makes sense, though philosophically it seems a bit weird... I still think of the ISA as really just a glorified namespace, or a policy template parameter (which is actually how it's used in some cases, I think).  I don't even remember when we made it a SimObject, but presumably that was only so it could be manipulated in Python.  So giving it state, even if it's just a pointer, seems strange to me... though I see that MIPS has already crossed that bridge.  Cores have state, decoders have state, but an ISA is just a set of definitions.

So to me a model where the enabled ISA feature set is a property of the core (or a subcomponent of the core), and all the cores inherit their settings from the System object, and somehow the ISA interfaces with the core to learn about the current settings, would be a better match to reality.  However, I can believe that that's more awkward, and I can't say that I see a practical benefit, beyond the general principle that making things match reality to the extent possible is usually a good policy.  So I'll register my unease, but I won't object ;).