Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementation of the Control Unit #18

Closed
3 tasks done
thegabriele97 opened this issue Jun 6, 2021 · 7 comments · Fixed by #26 or #31
Closed
3 tasks done

Implementation of the Control Unit #18

thegabriele97 opened this issue Jun 6, 2021 · 7 comments · Fixed by #26 or #31
Assignees
Labels
PRO DLX New feature or request TO DO

Comments

@thegabriele97
Copy link
Owner

thegabriele97 commented Jun 6, 2021

  • Basic working implementation of it (with J and JAL and all basic OP required to be implemented in the base DLX)
  • The CALL/RET op should be executed only if there are no hazard (the hazard table is all at 0). If it's not, we should add some stall until the hazard table is all at 0. Maybe a signal is needed from the DECODE stage (and from the HazardTable unit) that tells us if there is at least a 1 in the table
  • When a JUMP/BRANCH occurs, a fetch cycle must be skipped (i.e. the IR enable should go off). I think it can be accomplished by setting the bit IF_EN (or the one that enables the IR) to 0 for each jump/branch instruction
  1. Acoomplished by setting a bit of the IR to 0, and when it's 0 IR <- NOP so a NOP is executed after a jump
@thegabriele97 thegabriele97 added documentation Improvements or additions to documentation PRO DLX New feature or request TO DO and removed documentation Improvements or additions to documentation PRO DLX New feature or request labels Jun 6, 2021
@thegabriele97 thegabriele97 linked a pull request Jun 8, 2021 that will close this issue
@giovannipollo
Copy link
Collaborator

giovannipollo commented Jun 8, 2021

The CALL/RET op should be executed only if there are no hazard (the hazard table is all at 0). If it's not, we should add some stall until the hazard table is all at 0. Maybe a signal is needed from the DECODE stage (and from the HazardTable unit) that tells us if there is at least a 1 in the table

The control if the Table is all 0 is ready to be tested. However I was not able to test it, because the waveform does not show up (did not understand why).

EDIT (by @thegabriele97 ): problem solved

@thegabriele97
Copy link
Owner Author

The CALL/RET op should be executed only if there are no hazard (the hazard table is all at 0). If it's not, we should add some stall until the hazard table is all at 0. Maybe a signal is needed from the DECODE stage (and from the HazardTable unit) that tells us if there is at least a 1 in the table

The control if the Table is all 0 is ready to be tested. However I was not able to test it, because the waveform does not show up (did not understand why).

EDIT (by @thegabriele97 ): problem solved

@giop98 is the signal you made (the Hazard table is all at 0) refereed to the second point of this issue?

@MatteoBattilana
Copy link
Collaborator

CALL and RET implementation is totally missing both from the VHD and compiler part.
I think that the CALL/RET signal must be put in an AND together the all zero signal. We have this signal both at DLX and Decode unit level, maybe we can propagate into the datapath to inhibit pipeline and put NOP.

@thegabriele97
Copy link
Owner Author

CALL and RET implementation is totally missing both from the VHD and compiler part.
I think that the CALL/RET signal must be put in an AND together the all zero signal. We have this signal both at DLX and Decode unit level, maybe we can propagate into the datapath to inhibit pipeline and put NOP.

Yes but I was thinking about looking only for R8..R31 about "busy registers" in order to insert the stall after a CALL/RET. This is because R0..R7 are in the GLOBALS so they are always the same and they are always available so there is no need to stall if they are the only busy registers

@thegabriele97
Copy link
Owner Author

thegabriele97 commented Jun 11, 2021

CALL and RET implementation is totally missing both from the VHD and compiler part.
I think that the CALL/RET signal must be put in an AND together the all zero signal. We have this signal both at DLX and Decode unit level, maybe we can propagate into the datapath to inhibit pipeline and put NOP.

Yes however about the other things, i think we should do something similar to the HAZARD_SIG, so stalling the pipeline when ALL_ZEROS & CALL/RET are both at 1

@giovannipollo
Copy link
Collaborator

@giop98 is the signal you made (the Hazard table is all at 0) refereed to the second point of this issue?

Yes, when I did the signal it was referring to the second point. But now, as both of you said, we may need to change something.

@giovannipollo
Copy link
Collaborator

Yes but I was thinking about looking only for R8..R31 about "busy registers" in order to insert the stall after a CALL/RET. This is because R0..R7 are in the GLOBALS so they are always the same and they are always available so there is no need to stall if they are the only busy registers

I think this is a nice idea.

Indeed, taking about PUSH/POP, I'm not sure if we have to do something (if I'm not wrong everything is already managed inside the windowed RF).
In case we should modify something, an idea, in order to check if we have free space, would be to check if, in the next window, we have no valid data (so value of the registers at 0).

@thegabriele97 thegabriele97 linked a pull request Jun 12, 2021 that will close this issue
@thegabriele97 thegabriele97 pinned this issue Jun 12, 2021
@thegabriele97 thegabriele97 added the PRO DLX New feature or request label Jun 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PRO DLX New feature or request TO DO
Projects
None yet
3 participants