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

Floating point data path for single data type #128

Open
ppisa opened this issue Apr 27, 2024 · 2 comments
Open

Floating point data path for single data type #128

ppisa opened this issue Apr 27, 2024 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@ppisa
Copy link
Member

ppisa commented Apr 27, 2024

For some reference, look at the proposal by @Jingqing3948 which implements instructions decoding (See pull request
#109). But some solution for parallel data path visualization should be considered before consideration for mainline. It is necessary to decide how it would map to pipeline version and there has to be option to switch off at least the visualization, because it would make core view hard to read for novices.

@ppisa ppisa added enhancement New feature or request help wanted Extra attention is needed labels Apr 27, 2024
@Jingqing3948
Copy link

Jingqing3948 commented Apr 27, 2024

Thank you! I closed the pr because I decided to resubmit a version that already support some F inst execution (or we work together, sorry I'm a RISC-V freshman for now).
For now I have achieved the following F inst correct execution result locally(by modifying backend module: 'machine'):

  • flw
  • fsw
  • fadd.s
  • fsub.s
  • fld
  • fsd

But that is just a correct execution result in single pipeline, without proper hardware behavior. You can see it in this figure, the fp register representation and memory access is correct but execute fp inst in one instruction cycle in this hardware visualization isn't correct.

image

Is there anything I can do to help?

@ppisa
Copy link
Member Author

ppisa commented Apr 27, 2024

OK, if you want to update pull request, you do not need to close it. You can force push new state of the branch to the original pushed branch and it updates in the pull request. So I suggest to reopen pull request and update it. As for the registers, there should be a complete another register block for floating point in visualization and separate data path going through stages. The integer data path should be inactive in the stages corresponding to the passed floating point instruction. Integer datapath should be active only for these from the instructions you are adding, which transfer data from/to GPR register to/from floating point register.

I think that clean implementation is not so big problem and if the whole computation is done in single cycle in exec phase then it is really straightforward. Problem is to fit all required additional wires and blocks into core view. And as I have written, it has to be possible to disable that part of diagram, because we lose novice students if all is shown at start.

If you come with clean core implementation but visualization is missing, I have no problem to pull it, make F extension optional in config and allow its use even that it will not be visualized at all. Visualization can be another step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants