Adding options for branch strategies and branch delay

[silvigon]

Hi, I'm part of a project at UCLM with the goal of adding some new features to Ripes, so that it can eventually replace some older simulator software that's still in use in a few courses. Part of this involves adding support for other static branch prediction strategies (flushing the datapath and delayed branch), as well as supporting branch address calculation at the ID and MEM stages.

As far as I've understood from looking at the code, this would imply modifying the simulated datapath accordingly, at least in the latter case. Is there any way to do this that avoids having to add a new processor model for each combination of options? The interface for branch predictors proposed in #289 would probably come in handy here, but other ideas are welcome in the meantime.

[mortbopet]

Hi @silvigon - great to hear about that, and I'm keen on seeing what your project comes up with.

Regarding branch prediction; the comments and discussion in #289 is of course highly relevant here, and i'd encourage you to either revive that PR or take from it what you need to build an improved version.

Your concern about multiple processor models is indeed valid. I'd say that, based on the current design of Ripes and VSRTL, new processor models typically employed if the "physical" datapath changes. That is, if you're adding new VSRTL components and/or wiring things differently between processors model This restriction mainly comes from the need to have a layout file specific to the components that are present in a given processor model.

If instead your changes can be described as a software-only change (e.g. enabling/disabling ISA extensions) then the path is obviously much simpler.

Now, you don't actually have to add a new processor model to make physical changes to a datapath - processor model wiring is done at runtime and it's also perfectly valid to instantiate processor model components at runtime (a macro is usually used for convenience, but you can just as well "manually" construct subcomponents based on how you configure a processor at runtime- i.e. calling SimComponent::create_component before wiring up the processor.

If you do the above, you'll still have the issue in having to manually define compatible processor layouts for the different combinations of datapath options.

... if only we had a way to automatically, heuristically, create a nice looking circuit layout so that we could ditch these pre-defined processor layouts 🤔... Started work on this maany years ago over in VSRTL, but never got around to finishing it; it'll probably have to be someone else than me who does that (see https://github.com/mortbopet/VSRTL/projects/3#card-18251185).