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

(1) Refactoring FPU internals before (2) and (3). (2) Implementation … #20

Merged
merged 2 commits into from Nov 23, 2021

Conversation

bandvig
Copy link

@bandvig bandvig commented Jul 25, 2020

…tininess detection BEFORE ROUNDING. (3) Correction underflow flag generation. Result is underflow flag behavior has become equal to Berkeley's soft float library.

…tininess detection BEFORE ROUNDING. (3) Correction underflow flag generation. Result is all underflow flag behavior has become equal to Berkley's soft float library.
@bandvig
Copy link
Author

bandvig commented Jul 25, 2020

@stffrdhrn @skristiansson @wallento @juliusbaxter @bluecmd @olofk
Hello all.
I made some corrections in MAROCCHINO FPU to fix tininess detection and therefore correct underflow flag raising. I implemented tininess detection BEFORE ROUNDING because it looks simpler for implementation. I checked lints by Verilator and verified the mods by Berkeley's soft float library.
I see that Travis CI failed, but following log the fails don't look related to Verilog sources.
Could somebody check what the issue could be?

Stafford, you can now try FPU related tests in glibc, but #define _FP_TININESS_AFTER_ROUNDING 0 in
glibc:
https://github.com/openrisc/or1k-glibc/blob/e237000aec139d21b3ed467e314442f28a993814/sysdeps/or1k/sfp-machine.h#L102
and
gcc:
https://github.com/stffrdhrn/gcc/blob/8e99e252edc130162b6d2d7bdef2180305389053/libgcc/config/or1k/sfp-machine.h#L88

BTW, Stafford. I'm interested to build glibc-based tool-chain to be able to build and run FPU-related tests by myself on my Atlys board. Could I use upstream glibc and gcc sources (i.e. was you able to push your mods to glibc and gcc upstream) for that? Or should I use your forks?

…dd "or1k_defines.v" include into or1k_marocchino_monitor.v (2) Move qm_r declaration before 1st usage in pfpu_marocchino_div.v. Both the issues cause error in Modelsim.
@bandvig bandvig merged commit 0c0eedc into master Nov 23, 2021
@stffrdhrn
Copy link
Member

@bandvig I have just finished pushing the glibc port upstream. Currently the implementation is soft-float only so it will not support the FPU instructions. I have patches for hard float and I will setup a new branch for that. But more work is needed to support hard-float running with glibc (which means linux too). This is described here: https://openrisc.io/proposals/p17-user-mode-fpcsr

My test platform is an arty running a mor1k Litex SoC https://github.com/litex-hub/litex-boards. I would like to get this working with marocchino and it would also be good to support the atlys board so you can also test (maybe using fusesoc).

@bandvig
Copy link
Author

bandvig commented Jan 7, 2022

@stffrdhrn It is really great advance, Stafford!
I'm not very familiar neither with fisesoc nor with litex. But I use marocchino-based SoC for Atlys which was converted from mor1kx-based SoC manually by replacing mor1kx with marocchino. So I have test platform already. And I've started to build glibc-based toolchain to try tests and linux.
Of course in some time (as the glibc-based toolchain will be completed) I think I will ask you to guide me how these tests could be run.
By the way. Are your planning just to add marocchino for arty SoC or also to add atlys SoC to litex project?

@stffrdhrn
Copy link
Member

@bandvig I created #22 to continue the discussion about marocchino FPU testing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants