Add execution driven support

[arupc-vmicro]

Olympia a trace-driven model; the input to the simulator is a trace generated in STF standard.. The trace (.zstf or .stf file extension) is a stream of instructions that a program took to execute itself on the core. The instruction stream consists of only those instructions that actually retired.

Because the trace only contains instructions that are on the correct path, performance deviations results from behaviors like branch mispredictions, speculative load/store/instruction cache effects, etc are not taken into consideration when analyzing core performance.

In execution-driven mode (EDM), instead of using an instruction stream from an STF trace, the Olympia simulator would instead execute a workload directly including speculative behaviors.

To facilitate execution-driven mode in Olympia, Olympia would need a "dynamic trace" from a functional model that is actively executing the workload. But the functional model cannot just execute the instruction stream as the program dictates. Instead, the functional must be directed by the performance model on which instructions to execute which includes speculative paths. Do so, however, will corrupt the program execution. The functional model must be able to recover from a flush and handle redirects just like real hardware.

This issue will define those requirements on the functional model to support OoO execution as well as speculative paths. From these requirements, a functional modeling API must be built and a backend chosen (like Spike or SAIL or ...?) to perform the execution.

[VictorYing]

Hello, I'm looking to build an execution-driven RISC-V core performance model, to enable studies of multicore systems running interacting software threads, or studies evaluating effects of speculative execution on, for example, cache state. It looks like you've considered going execution-driven as a potential feature for Olympia. Is this still something on your roadmap? If so, what sort of goals you would be interested in working towards, and would be interested in accepting or collaborating on support for execution-driven simulation?

[ghost]

Hi Victor, there is a discussion about this here: https://github.com/riscv-software-src/riscv-perf-model/discussions/68

Olympia is only about a year old and the basics of the pipeline design is still being fleshed out. Adding a functional back-end to the model is basically a wish list item until resources (volunteers) can be allocated to work on it. You want to volunteer? 😄

The effort will consist of the following plans:

1. Define/determine which functional back-end tool to use (Spike, Dramajo, something new?)
2. Determine the requirements to support EDM: speculative path support? functional speculation execution/rewind support? etc
3. Design an API to basically generate traces on-the-fly and feed into Olympia OR
4. Design an API to actually execute instructions at the correct moment in Olympia (drop trace)
5. etc, etc

So many issues/design points to consider, esp if we want Olympia to support multicore (think cohesive behaviors). But that's a different set of requirements.

[VictorYing]

Thanks for the pointer to the discussion and the mention of Dramajo which I haven't looked into yet. I'm exploring options right now and might be able to allocate time to work on something down the line.

[arupc]

@klingaard Can you please complete the description of the issue, per discussion in the weekly sync? cc: @knute-mips

Please feel free to unassign yourself after completing the description