Add Smcsrind and Sscsrind CSR YAML Files

[syedowaisalishah]

This PR adds:

• Extension YAML files for Smcsrind and Sscsrind

• CSR YAMLs for:

  • MISELECT, MIREG to MIREG6
  • SISELECT, SIREG to SIREG6
  • VSISELECT, VSIREG to VSIREG6

  Closes Add Smcsrind/Sscsrind YAML #557

[dhower-qc]

Take a look at #594

With that patch, you should be able to write the sw_read/sw_write functions for the indirect CSRs

[syedowaisalishah]

Thanks for the clarification, @dhower-qc. I've updated all relevant CSR fields to use:
reset_value: UNDEFINED_LEGAL.
I've reviewed the proposed schema changes in PR #594. Once it's merged, I plan to implement the sw_read() and sw_write() functions for the indirect CSRs as a follow-up.
I'll push the fixes shortly and re-request review once done.

[ThinkOpenly]

I left a lot of single comments instead of a review, so adding my review now. (Leaving a review needs a comment, so viola.)

[AFOliveira]

@syedowaisalishah There are several comments on this PR that likely have already been solved by recent changes, can you either answer them or resolve them so reviewers can know exactly what to look like when taking a second look at this PR? Also, Github will request that all of them are resolved when we want to merge.

[syedowaisalishah]

@AFOliveira Thanks for the reminder! I'll go through all the comments, respond where needed, and resolve the ones that have been addressed by the recent changes. I'll make sure everything is clear for the reviewers before we proceed with the next review.

[dhower-qc]

The comments generally apply to all the files.

[ThinkOpenly]

@dhower-qc, is there a way to incorporate this:

The behavior upon accessing sireg* from M-mode or S-mode, while siselect holds a value that is not implemented at supervisor level, is UNSPECIFIED.

It is recommended that implementations raise an illegal instruction exception for such accesses, to facilitate possible emulation (by M-mode) of these accesses.

Given the "recommended" term, do we need an extension parameter?

[dhower-qc]

@dhower-qc, is there a way to incorporate this:

The behavior upon accessing sireg* from M-mode or S-mode, while siselect holds a value that is not implemented at supervisor level, is UNSPECIFIED.
It is recommended that implementations raise an illegal instruction exception for such accesses, to facilitate possible emulation (by M-mode) of these accesses.

Given the "recommended" term, do we need an extension parameter?

This is already handled as long as we call unimplemented_csr in IDL, since it's the same situation with direct CSR accesses. There is a TRAP_ON_UNIMPLEMENTED_CSR parameter, that does the following:

function unimplemented_csr {
  arguments Bits<INSTR_ENC_SIZE> encoding
  description {
    Either raises an IllegalInstruction exception or enters unpredictable state,
    depending on the setting of the TRAP_ON_UNIMPLEMENTED_CSR parameter.
  }
  body {
    if (TRAP_ON_UNIMPLEMENTED_CSR) {
      raise(ExceptionCode::IllegalInstruction, mode(), encoding);
    } else {
      unpredictable("Accessing an unimplmented CSR");
    }
  }
}

[syedowaisalishah]

@dhower-qc I’ve applied all the requested updates across mireg[1–6].yaml, sireg[1–6].yaml, and vsireg[1–6].yaml:

• Converted description fields to the structured format.

• Added long_name to the VALUE field.

• Implemented sw_read() and sw_write() methods, using the appropriate index in indirect_csr_lookup() for each file.

• Corrected the description format for {m,v,s}select as well.

[dhower-qc]

Other than the small indentation request, looking good!!

[dhower-qc]

Looks good, assuming the regressions pass after pulling main.

Thanks for all the work!