You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, the existing implementation is functionally correct and operates as follows: All SYS instructions bypass the execution step and proceed directly to the ROB. When the instruction is retired, the ROB will flush. If there is a destination register, the ROB will remove it from the scoreboard.
Knute provided a more elegant solution, as follows: Every SYS instruction will go through an execution pipe, most likely the ALU pipe. This execution pipe will remove the destination register from the scoreboard after the instruction is executed. The execution unit will also determine whether retiring the instruction by the ROB will result in a flush. To facilitate this, we need to add a new flag to the INST structure.
I believe that the execution pipe, rather than the ROB, is the appropriate place to decide whether to flush because the decision is not straightforward. There are three native CSR instruction types, all of which are really atomic read-modify-write operations. However, two of the three categories are read-and-set and read-and-clear. When the set or clear bit register is x0, these two instructions become read-only. The modeling code to accomplish this will need to open up some data structures, which I believe are best suited for the execution pipe.
Please give me your thoughts or comments.
The text was updated successfully, but these errors were encountered:
This PR is a followup to
#162.
It is also discussed in:
#164
This PR changes the way SYS instructions are executed. Previously, SYS
instructions did not go through an execution pipe but instead were
dispatched to the ROB without delay, and the ROB handled the scoreboard
with respect to the destination register. This PR requires the SYS
instructions to pass through an execution pipe, thereby obviating any
special scoreboard code in the ROB. With the exception of CSR read
instructions, the ROB will flush all SYS instructions.
This feature can be tested by running example_json.json workload, which
is part of the make regress suite. Also, the sys execute pipe was added
to 3 config files big_core, medium_core and small_core.
How was this tested:
make regress passes 83/83.
---------
Co-authored-by: Anthony Hung <[email protected]>
So, the existing implementation is functionally correct and operates as follows: All SYS instructions bypass the execution step and proceed directly to the ROB. When the instruction is retired, the ROB will flush. If there is a destination register, the ROB will remove it from the scoreboard.
Knute provided a more elegant solution, as follows: Every SYS instruction will go through an execution pipe, most likely the ALU pipe. This execution pipe will remove the destination register from the scoreboard after the instruction is executed. The execution unit will also determine whether retiring the instruction by the ROB will result in a flush. To facilitate this, we need to add a new flag to the INST structure.
I believe that the execution pipe, rather than the ROB, is the appropriate place to decide whether to flush because the decision is not straightforward. There are three native CSR instruction types, all of which are really atomic read-modify-write operations. However, two of the three categories are read-and-set and read-and-clear. When the set or clear bit register is x0, these two instructions become read-only. The modeling code to accomplish this will need to open up some data structures, which I believe are best suited for the execution pipe.
Please give me your thoughts or comments.
The text was updated successfully, but these errors were encountered: