Illegal instruction exceptions in floating-point code

[tymcauley]

Impact: software

What is the current behavior?
When running floating-point code on the basic Rocket config, simulations will occasionally give an illegal-instruction-exception at floating-point instructions that involve rounding, such as fcvt.s.w.

What is the expected behavior?
These instructions are valid, so they should execute without issue.

Please tell us about your environment:
- version: 24fada1d9ca4dc8cad7900676ab7b6ebf5c138b8 (current dev branch)
- os: Linux my-hostname 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Other information
I've found the root cause for the issue: The current C runtime in libgloss-htif doesn't initialize the FPU, which means the floating-point rounding mode control register is randomly initialized. If it gets initialized to 5, 6, or 7 (see section 11.2 of the RISC-V user spec), then floating-point instructions that involve rounding will generate an illegal-instruction exception, due to the illegal_rm signal going high in Rocket's FPU. The solution is initializing the FPU's control register to 0, as is done here: ucb-bar/libgloss-htif@dcbb7f1#diff-1eb65a00dfc5fc10e70a5baff32d50c6R59 (although the old fssr instruction maybe should be replaced with the newer fscsr instruction).

Looks like there are a number of improvements being added to libgloss-htif, so I'm not sure when a PR should be added to update it. I can confirm that updating my version to ucb-bar/libgloss-htif@dcbb7f1 did fix this problem, and floating-point code now works without issue.

[a0u]

Fixed in ucb-bar/libgloss-htif@a122c82.