MiA: Additional Pre-Reservation-Station Instruction Routing/Filtering

[AlexanderRipar]

In the following, "Routing" is used to refer to decisions where an instruction can proceed from one source to more than one destination. I am not sure whether this is the right term. Alternatives I have seen are "scheduling", "dispatch", as well as "fiter" in the MiA.

See Discussion #1046 "MiA: Superscalar and Out-of-Order Logic Elements [Copied from gitea]" for a more in-depth overview of the current state of the MiA in this regard, as well as some alternative ideas for where and how it needs improvement.

Motivation

I want to work on Instruction Scheduling in the LCB. To do this in an interesting way, I need information on the resources in the processor that the scheduler gets to work with. This requires specifying these resources, which should happen in the MiA.

The main elements that are relevant for modelling instruction scheduling are:

• Reservation Station
• Execution Units

Currently, there is already a logic element [reservation station], as well as stage definitions that can somewhat serve as execution units.
However, there is no good way to connect reservation stations to execution units. This requires a lot of flexibility, as reservation stations can be unified (centralised) or decoupled (distributed, decentralized).
In the first case, there is a single reservation station, which feeds into multiple execution units. In the second case, there are multiple reservation stations, which each feed a single execution unit.

Depending on which model is used, instruction routing needs to occur either between the unified reservation station and the execution units, or between instruction issue and the decoupled reservation stations. Additionally, the case where one decoupled reservation station is responsible for more than one execution unit is also reasonable, in which case routing is necessary in both places (See e.g. Zen3 and 4, as covered by Chips and Cheese).
The current operation and filter primitives can only model the first of these cases (unified reservation station -> execution units).

Proposed Solution

I propose to allow an additional annotation on [reservation station] logic to describe which instructions the reservation station can accept. Since this would effectively perform the same operation as the filter builtin, just at a different spot in the pipeline, I propose to also call it filter:

operation Alu1Ops = { Add, Sub, Mul, cvttsd2si }

[size : 16]
[filter : Alu1Ops] // New and shiny!
logic [reservation station] Alu1RS

This would only allow instructions contained in Alu1Ops into the annotated reservation station.

Open Problems

This does not address how instruction routing prioritizes between different possible destinations, which can get quite hairy in practice.
Imagine for example an architecture with decoupled reservation stations, where two reservation stations can accept an add operation. The decision which one of them receives a given add might be made dependent on the number of instructions currently active in each reservation station, the makeup of instructions waiting in a Non-Scheduling Queue ahead of the routing decision, or any of numerous other factors I don't know about.
It seems to me like getting something like this to work in a generalized manner would require a lot of effort, so maybe it isn't worth it to think about at this point.