[Deprecated] RISC-V IEEE 754 Floating point Support

[NLS-04]

Add comprehensive floating-point extension support to RISC-V processor models

Summary

This PR adds floating-point support to Ripes, enabling simulation of the RISC-V F single-precision floating-point (and Zicsr constrol and status register) extensions. The implementation is modular in design so that future works can build upon this PR.

What is Added

• New RISC-V processors with floating-point support
• Core floating-point integration into ripes (register file, instructions, extensions, isa, assembler etc.)
• New extension handling and managing system for more complex extensions and overall clarity
• New processor registration implementation with a new processor selection GUI, declutering the existing processor selction GUI, grouping processor by a common family or idea (like 5-stage)

---

The whole PR is composed of 3 sub-PRs:

1. PR [Deprecated] RISC-V IEEE 754 Floating point Support #448 (This one): builds the base of the two remaining PRs and integrates the core floating-point implementation
2. PR [Deprecated] RISC-V IEEE 754 Floating point Support #449 : overhauls and extends the system for managing ISA extensions, replacing the simple string literal based implementation with an extendable abstraction interface
3. PR RISC-V IEEE 754 Floating point Support #450 : introduces a new way of registering, managing, and selecting processors

---

In this Pull-Request

Impact

• Enables simulation of floating-point workloads on RISC-V processors
• Provides accurate RISC-V and IEEE 754-compliant floating-point behavior
• Improves register file design for extensibility
• Adds foundation for future floating-point integrations, like the D, Q, Zfh extensions etc.

What Changed

Core Components:

• Floating-Point Unit (FPU): Added FPU with support for all standard operations, rounding modes, and exception flags, and fcsr interactions. Added two variants of the FPU:
  • the core FPU, which handles all floating-point operations, delegating them to the softfloat library, managing and synchronizing the internal state of the rounding mode and flags between the softlfoat library and the Simulation;
  • and a wrapper around the core that exposes the internal state via pins to the widget so that the state can be visualized in the processor diagram, as seen in the pictures
• fcsr: floating-point csr as VSRTL Register component inside the FPU for direct access
• Berkeley SoftFloat Integration: Integrated Berkeley SoftFloat library for (RISC-V) IEEE 754-compliant floating-point arithmetic
• Floating-Point & CSR Register Files: Added floating-point and csr register file to ISA
• Sim Components: added updated and extended Decoder, controller and register file components to work with the additions of the F extensions

ISA Extensions:

• F Extension: Added all the Single-precision floating-point instructions and pseudo instructions (FADD.S, FSUB.S, FMUL.S, FDIV.S, etc.)
• Zicsr Extension: Added all Control and Status Register insructions and pseudo instructions

Note:

For simplicity the current intergations of the floating-point unit and fcsr avaoid the integration of a dedicated CSR register file and controller by making the fcsr part of the FPU. Therefore, the FPU also manages the state of the fcsr and the acces via the Zicsr instructions.

Processor Models:

• rvss_float: Single-cycle floating-point processor
  
• rv5s_float_no_fw_hz: Five-stage pipeline floating-point processor (no forwarding, no hazard detection)
  

Assembler & Frontend:

• Added floating-point immediate parsing in expression evaluator
• Added .float GNU directive support
• Enhanced syntax highlighting for FP immediates, rounding mode constants, and Zicsr registers
• Improved expression parser for easier extension of epxressions (deviating from a union/variant design to a polymorphism design, as this simplifies the expression parsing definition)
• Correctly added the floating-point register file to the existing register file viewer in the GUI
  

Testing & Quality: (also regard PR: #450)

• Integrated the comprehensive floating-point instruction assembly tests of the existing testing files for the F extension
• Test reorganization: separated F and D extension tests into dedicated directories
• Added cosimulation support for floating-point operations (cosimulation can now handle multiple register files)

[mortbopet]

@NLS-04 Awesome! This is a massive change, so it's taking me some time to review. Are you on top of the CI errors?

[NLS-04]

@mortbopet

Are you on top of the CI errors?

Yes — the CI failures in #448 are expected, since that PR partially depends on #449.

More broadly, these PRs are structured as a dependency chain:

• [Deprecated] RISC-V IEEE 754 Floating point Support #448 is the base for [Deprecated] RISC-V IEEE 754 Floating point Support #449
• [Deprecated] RISC-V IEEE 754 Floating point Support #449 is the base for RISC-V IEEE 754 Floating point Support #450
• RISC-V IEEE 754 Floating point Support #450 is the effective “head” PR containing the complete working state

Because of this, #448 and #449 are not intended to be standalone, conflict-free merge-ready additions to Ripes. They primarily exist to split the work into smaller, more manageable review chunks.

As a result, the CI issues in #448 and #449 can be ignored, since the related problems are resolved in #450.

Hope that clarifies things.

[NLS-04]

After taking another look, I realized something went wrong during the PR setup, and the current structure is unfortunately not what I originally intended 🫤

Contrary to the plan, PR #450 already contains the changes from #448 and #449. That effectively makes #448 and #449 obsolete, and they should therefore not be merged into Ripes separately.

Only PR #450, which includes the complete implementation, should be considered for merging.

Sorry for the confusion on my end 🫤

@mortbopet, how would you prefer to proceed from here?

Would you rather review the full implementation as it currently exists in PR #450, or should I properly split it again into smaller follow-up PRs?

In any case, I would suggest closing PR #448 and PR #449, since their contents are already covered by PR #450, and moving any relevant descriptions/information from those PRs into #450 instead.