How to configure the RISC-V ISA parameters in stdlib?

[rogerchang23424]

In the comment. We should have efficient approach to configure the parameter riscv_type, vlen, elen and so on in stdlib.

[BobbyRBruce]

Sorry for the delayed response here, I think this discussion is worth having. I think Jason's comment was more to do with exposing more and more parameters in these scripts is basically reaching a point where gem5 users expect to configure a system entirely through a script's arguments which doesn't scale. One big thing I want to focus in on here is when you expose something as a command line parameter users will assume any parameter value (or combination of values) is valid and supported which isn't really the case.

For example, you might have an argument for "memory access model" allowing a user to specify whether Timing or Atomic access is used, and have another, --use-kvm, for using KVM cores or now. As user I'd see the option --use-kvm as an something I can mix into any simulation I want. However even with just these two arguments there's a cross-product of 4 different configurations and half of them are invalid (you can't use timing with KVM). So this necessities adding some kind of warning code or procedure. Now envision the cross product you must consider if you start to add a parameter allowing the user to chose a cache hierarchy setup (can't use with ATOMIC), different CPU modes (KVM necessities host ISA is the same as the CPU isa), etc. etc. Even if the arguments supported values are discrete and limited, these arguments are non-linear; they interact and it becomes a nightmare try to keep the scripts sound. The cross-product is too large to test or engineer effectively. Not to mention how crazy it becomes to pass dozens of arguments via the CLI to run a simulation.

These scripts really need to be scaled back and, in many cases, simply removed. We can't support scripts that try to do everything. A script should have a specific purpose which proves, demonstrates, or tests a specific thing. While any user can open the script and modify any parameters they wish, by this point it is their responsibility to educate themselves on how to do this safely and I think this is generally understood.

What I want is to get to a situation where the scripts we provide do what they do well. Well tested and constrained to their stated purpose. If someone wants to simulate something which hasn't been provided then they'll need to sit down and define it in a configuration file. The true is we, as gem5 engineers, can't do that work for everyone. We're a project that provides a tool to create simulations but we can't be a project that provides every simulation that tool can produce.

To be constructive, if someone wants to use a RISCV CPU with different values for, say, vlen then I'd advise them to write their own configuration with something like this:

class BigVLenCore(RiscvCore):
    def __init__()
        super().__init__(vlen=64)

class SmallVLenCore(RiscvCore):
    def __init__()
        super().__init__(vlen=32)

# Elsewhere in the code

argparse.add_parameter("core",
    store_value=True,
    choices=["BigVLenCore", "SmallVLenCore"],
    help="..",

(I didn't bother to look up the core here so treat this as pseudocode, also this hypothetical investigation I go with is totally fabricated and probably makes no sense. Just focus on the engineering).

This is nicer because it's constraining the space of configurations your simulation setup exposes to a sensible subset suitable for its purpose (whatever that may be --- let's just say comparing 32 and 64 length vectors). You can test these finite set of models created and distribute them with certain guarantees.

You can also build on top of this more easily. Let's say that you've created a new mmu which works differently for cases where vlen=64, you'd only need to add:

from m5.objects import NewMMU

class NewMMURiscvCore(BigVLenCore):
    def __init__()
        super().__init__()
        super().mmu = NewMMU

# The `NewMMURiscvCore` would then be added to the argparse.

This is nice because it conforms to the Open-Closed. To add a new model here we are not modifying any model already present, you just add a new model. In addition, you're not enabling a configuration which is invalid. There's no option to use vlen=32 with the NewMMU. You've blocked that off.

I realize there are experiments in which it's sensible to expose something lie vlen to as an argument, but such experiments should have purposes which can be summerized in questions like "How how does varying the vector length impact multi-core CPU performance in RISC-V systems?".

[grigohas]

Hello, can i change the elen to more than 64 bit ? I amanged to change the isa but i dont know if gem5 supports 128bit arithemtics