Is Ripes configurable for simulating Tomasulo?

[jontrossbach]

I read in the documentation that even if you simulate a 5-stage pipeline with Ripes, it currently runs a single-cycle simulation in the background to get the outputs. What does this mean for trying to built a Tomasulo configuration for Ripes? If you have any insights into this I would like to know: is Ripes well suited for a Tomasulo or will the out of order processing likely conflict with the current set up?

Thanks,
Jon

[mortbopet]

I read in the documentation that even if you simulate a 5-stage pipeline with Ripes, it currently runs a single-cycle simulation in the background to get the outputs.

This is not true - could you point me to the place in the documentation which led you to this conclusion? (the wording might need to be revised).

is Ripes well suited for a Tomasulo or will the out of order processing likely conflict with the current set up?

First of all, I'd like to say that adding one (or multiple) out-of-order processor implementations to Ripes would in my view be a significant step towards to allowing Ripes to aid in teaching some non-introductory computer architecture topics - and something I've been wondering about how we best go about, for a while.

The processor models in Ripes are all described using VSRTL. VSRTL, theoretically speaking is able to simulate any circuit, which uses a single clock, in a cycle-accurate manner. And as such, it is definitely possible to simulate a Tomasulu implementation. While it is an out-of-order processor algorithm, it is nevertheless still described using digital circuit components that can operate on a single clock. My only initial worry would be how to describe the common data bus of the Tomasulu algorithm in VSRTL, since I've yet to need such functionality.

Now, a note on VSRTL:
When describing a circuit in VSRTL, the designer may describe circuit operations at whatever level of abstraction that they desire. This also means that we may describe "black box" circuits. Here, we describe the I/O of the component and the operations that are performed when signals are propagated through the black box component after a rising edge of the clock - without going into details about how that logic is actually synthesized.
An example could be the instruction decode unit of the processors in Ripes: . In the constructor, the opcode << [=] { ... function defines a lambda that, when the circuit is propagated, computes the output value of the opcode port.

So, using black-boxes we are be able to describe some of the more complex components of an out-of-order processor purely in software.

The next question is probably how to properly visualize the implementation. Most Tomasulu algorithm simulators present a set of tables, showing instruction queues, buffers, reservation stations etc.. And for good reason - i suspect that a representation of the actual datapath of such an implementation could be quite cluttered.
To address this, an idea would be that black-box components may also describe an accompanying graphics object which is able to reflect the state of the black-box. As such, we should be able to embed a QTableView inside the VSRTL graphical component. I don't suspect this to be that difficult.

To conclude; no, there should not be anything that makes it impossible to describe a Tomasulu algorithm in VSRTL (and thus, use this model in Ripes). There needs to be some modifications to VSRTL to support "high-level" visualization of black-box components, but this should not be too difficult. I anticipate that the most challenging part is to actually write a functioning Tomasulu implementation using VSRTL, which might require some modifications/additions to the simulation primitives of VSRTL.

[schoeberl]

On 3 Jan, 2021, at 10:42, Morten Borup Petersen ***@***.***> wrote: The processor models in Ripes are all described using VSRTL <https://github.com/mortbopet/VSRTL>. VSRTL, theoretically speaking is able to simulate any circuit, which uses a single clock, in a cycle-accurate manner. And as such, it is definitely possible to simulate a Tomasulu implementation. While it is an out-of-order processor algorithm, it is nevertheless still described using digital circuit components that can operate on a single clock. My only initial worry would be how to describe the common data bus of the Tomasulu algorithm in VSRTL, since I've yet to need such functionality.

A common data bus is still something made out of “normal” circuits, e.g., multiplexers and some circuit for the arbitration.

To conclude; no, there should not be anything that makes it impossible to describe a Tomasulu algorithm in VSRTL (and thus, use this model in Ripes). There needs to be some modifications to VSRTL to support "high-level" visualization of black-box components, but this should not be too difficult. I anticipate that the most challenging part is to actually write a functioning Tomasulu implementation using VSRTL, which might require some modifications/additions to the simulation primitives of VSRTL.

A Tomasulo simulation would for sure be a cool addition. But you will only see interesting effects when there are variable length executions of instructions. E.g., adding/inventing a FPU with different latencies for different operations. Cheers, Martin

[mortbopet]

A common data bus is still something made out of “normal” circuits, e.g., multiplexers and some circuit for the arbitration.

Correct; I think my concern was also somewhat based on the actual visualization of the CDB. And how such visualization might get quite cluttered, quite fast, if the underlying muxes/arbitration units are exposed. One of the (current) key points of the visualization in Ripes is that not the entire RTL circuit is shown, but rather we visualize at a high(er) level of abstraction, ie. whatever level facilitates understanding of the "general idea" of the processor, and not the minutiae of the actual circuit.

A Tomasulo simulation would for sure be a cool addition. But you will only see interesting effects when there are variable length executions of instructions. E.g., adding/inventing a FPU with different latencies for different operations.

This is definitely something that is possible in VSRTL. Circuits can be run-time defined, so it's just a matter of having configuration parameters for the model that one wants to describe (whether those be # of functional units, latencies etc.). Parameters which ofcourse can be exposed through the UI.