07-15-2014, 02:12 PM
(This post was last modified: 08-09-2016, 10:21 PM by LordDecapo.)
Recently (about a week and a half ago or so) Cutlass convinced me to give LogiSim a try again (long ago I tried and was overwhelmed).
Later that night DylanRusell got online and showed me the basics as well as a bunch of essential tips and tricks. Since then I have been working on a 16bit CPU with To test out the Out Of Order Execution algorithm I have developed in MC. So I may test it and make sure it works before preceding in MC.
I'm posting this for two reasons;
(1) I'm curious what others have made in LogiSim. If you have made something,,, please share! I'm curious, what is it? How does it work? Did you follow a tutorial, or is it your own creation. And maybe post a download here so everyone can check it out.
(2) I want to write up my algorithm and see if anyone sees any issues that may arise upon my execution of said algorithm.
The algorithm is as follows;
1. Ins gets pulled from cache/RAM and put into a queue.
2. As the Queue fills, it dispatches 1 ins per clock cycle to the O3 unit (the name of my put of order execution IC in LogiSim.
3. Once the ins is there it is assigned a name by the Ins_Name_Counter. The name is determined by the order in which it was dispatched from the Queue. So it is named in program order.
4. The ins then gets partially decoded and sent into the RRT (Register Rename Table) to determine if either or both needed variables are either in the ROB (ReOrder Buffer, where it waits after being executed to be commited to registers in proper programming order) or in the Reg. If it is in the reg then that variable in the ins is given a 1bit "Reg_accurate" flag: which tells the system to get that variable from Reg like a normal CPU.
5. Once ins goes through the RRT it is sent to the top of the 4deep RS-Queue (Reservation Station). There the names of the variables it needs are checked against all current ROB entries. If the data is in one of those entries then it is stored in the respective data location for that RS entry.
6.Instructions in the RS stay there until both variables have a "data_accurate" flag, signally that that ins is ready to be executed and it has all the data it needs .
7. Ins is executed.
8. Result is stored in the ROB and it's data is checked against all current RS entries. If the name of the result matches the name of a needed variable for any ROB entry, it is stored in that entries respective data location within the RS.
9. A counter in the ROB keeps track of the order that ins are committed and only let's the one next in order to commit. (Save to physical Reg)
10. Smile cause it just executed OOOEXE.
This system has flags for hazards and errors that prevent backups and over filling of RS and ROB. As well as a priority system for dispatching ins to be exe. So the oldest always has priority.
Thanks for reading if u actually did xD
Let me know what you think
PS. This adds 3 stages to the pipeline
Later that night DylanRusell got online and showed me the basics as well as a bunch of essential tips and tricks. Since then I have been working on a 16bit CPU with To test out the Out Of Order Execution algorithm I have developed in MC. So I may test it and make sure it works before preceding in MC.
I'm posting this for two reasons;
(1) I'm curious what others have made in LogiSim. If you have made something,,, please share! I'm curious, what is it? How does it work? Did you follow a tutorial, or is it your own creation. And maybe post a download here so everyone can check it out.
(2) I want to write up my algorithm and see if anyone sees any issues that may arise upon my execution of said algorithm.
The algorithm is as follows;
1. Ins gets pulled from cache/RAM and put into a queue.
2. As the Queue fills, it dispatches 1 ins per clock cycle to the O3 unit (the name of my put of order execution IC in LogiSim.
3. Once the ins is there it is assigned a name by the Ins_Name_Counter. The name is determined by the order in which it was dispatched from the Queue. So it is named in program order.
4. The ins then gets partially decoded and sent into the RRT (Register Rename Table) to determine if either or both needed variables are either in the ROB (ReOrder Buffer, where it waits after being executed to be commited to registers in proper programming order) or in the Reg. If it is in the reg then that variable in the ins is given a 1bit "Reg_accurate" flag: which tells the system to get that variable from Reg like a normal CPU.
5. Once ins goes through the RRT it is sent to the top of the 4deep RS-Queue (Reservation Station). There the names of the variables it needs are checked against all current ROB entries. If the data is in one of those entries then it is stored in the respective data location for that RS entry.
6.Instructions in the RS stay there until both variables have a "data_accurate" flag, signally that that ins is ready to be executed and it has all the data it needs .
7. Ins is executed.
8. Result is stored in the ROB and it's data is checked against all current RS entries. If the name of the result matches the name of a needed variable for any ROB entry, it is stored in that entries respective data location within the RS.
9. A counter in the ROB keeps track of the order that ins are committed and only let's the one next in order to commit. (Save to physical Reg)
10. Smile cause it just executed OOOEXE.
This system has flags for hazards and errors that prevent backups and over filling of RS and ROB. As well as a priority system for dispatching ins to be exe. So the oldest always has priority.
Thanks for reading if u actually did xD
Let me know what you think
PS. This adds 3 stages to the pipeline