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

Illegal Instruction Exception not Raised - Dynamic Rounding Mode #169

Closed
shetalani opened this issue Sep 27, 2019 · 2 comments
Closed

Illegal Instruction Exception not Raised - Dynamic Rounding Mode #169

shetalani opened this issue Sep 27, 2019 · 2 comments
Assignees
Labels
Component:RTL For issues in the RTL (e.g. for files in the rtl directory) PARAM:FPU Issue depends on the FPU parameter Status:Resolved Issue has been resolved, but closure is pending on git merge and/or issuer confirmation Type:Bug For bugs in the RTL, Documentation, Verification environment or Tool and Build system

Comments

@shetalani
Copy link

RISC-V Specification:

  • "Floating-point operations use either a static rounding mode encoded in the instruction, or a dynamic rounding mode held in frm."
  • "Rounding modes are encoded as shown in Table 11.1. A value of 111 in the instruction’s rm field selects the dynamic rounding mode held in frm."
  • "If frm is set to an invalid value (101–111), any subsequent attempt to execute a floating-point operation with a dynamic rounding mode will raise an illegal instruction exception."

Issue Description:

An illegal instruction exception is not raised for the case when a floating-point instruction uses a dynamic rounding mode while the frm is set to an invalid value.

Example:

As shown below, the instruction 32'hc011f1d3 (fcvt.wu.s x3, f3) is decoded at time point t##0 where rm field has the value 111, and frm has the value 101 (written by a previous instruction), with no illegal instruction being flagged, as illegal_insn_dec is de-asserted.

issue_8


Product: OneSpin 360 DV-Verify
App: RVV
Tool's version: 2019.2.2

@stmach
Copy link
Contributor

stmach commented Oct 8, 2019

The issue seems to be that the pipeline is not flushed upon CSR write to frm, i.e. the instruction decoded at t##0 does not see the updated CSR (and should actually stall until t##1).
We'll have a look.

@Silabs-ArjanB Silabs-ArjanB added Component:RTL For issues in the RTL (e.g. for files in the rtl directory) PARAM:FPU Issue depends on the FPU parameter Type:Bug For bugs in the RTL, Documentation, Verification environment or Tool and Build system labels Jul 13, 2020
pascalgouedo pushed a commit to pascalgouedo/cv32e40p that referenced this issue Apr 21, 2023
…ons following CSRW to FRM/FCSR.

Signed-off-by: Pascal Gouedo <[email protected]>
pascalgouedo pushed a commit to pascalgouedo/cv32e40p that referenced this issue Apr 28, 2023
…ons following CSRW to FRM/FCSR.

Signed-off-by: Pascal Gouedo <[email protected]>
@pascalgouedo
Copy link

Resolved with PR #801

@pascalgouedo pascalgouedo added the Status:Resolved Issue has been resolved, but closure is pending on git merge and/or issuer confirmation label Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Component:RTL For issues in the RTL (e.g. for files in the rtl directory) PARAM:FPU Issue depends on the FPU parameter Status:Resolved Issue has been resolved, but closure is pending on git merge and/or issuer confirmation Type:Bug For bugs in the RTL, Documentation, Verification environment or Tool and Build system
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants