Merge branch 'add-ssqosid-csr-yaml' of https://github.com/syedowaisalishah/riscv-unified-db into add-ssqosid-csr-yaml

Author: syedowaisalishah

.devcontainer/devcontainer.json

@@ -25,14 +25,13 @@
         "asciidoc.antora.showEnableAntoraPrompt": true
       },
       "extensions": [
-        "castwide.solargraph",
-        "redhat.vscode-yaml",
         "asciidoctor.asciidoctor-vscode",
-        "zhwu95.riscv",
-        "mathematic.vscode-pdf",
+        "castwide.solargraph",
         "CraigMaslowski.erb",
         "HowerLimited.udb-extension-pack-vscode",
-        "sorbet.sorbet-vscode-extension"
+        "mathematic.vscode-pdf",
+        "redhat.vscode-yaml",
+        "zhwu95.riscv"
       ]
     }
   },

.github/workflows/regress.yml

@@ -134,7 +134,6 @@ jobs:
           rm -rf ext/llvm-project
           git submodule sync --recursive
           git submodule update --init --recursive --depth=1 ext/llvm-project
-
       - name: Check for required directories and files
         if: ${{ steps.cache-riscv.outputs.cache-hit != 'true' }}
         run: |
@@ -158,6 +157,11 @@ jobs:
             -o ext/llvm-project/riscv.json
       - name: Show riscv.json output
         run: ls -l ext/llvm-project/riscv.json
+      - name: Upload RISC-V JSON as Artifact
+        uses: actions/upload-artifact@v4
+        with:
+          name: riscv-json
+          path: ext/llvm-project/riscv.json
   regress-gen-go:
     runs-on: ubuntu-latest
     env:
@@ -169,6 +173,17 @@ jobs:
         uses: ./.github/actions/singularity-setup
       - name: Generate Go code
         run: ./do gen:go
+  regress-gen-c-header:
+    runs-on: ubuntu-latest
+    env:
+      SINGULARITY: 1
+    steps:
+      - name: Clone Github Repo Action
+        uses: actions/checkout@v4
+      - name: singularity setup
+        uses: ./.github/actions/singularity-setup
+      - name: Generate c_header code
+        run: ./do gen:c_header
   regress-cpp-unit:
     runs-on: ubuntu-latest
     env:

.gitignore

@@ -9,6 +9,7 @@
 .asciidoctor
 .vscode/*
 !.vscode/launch.json
+!.vscode/extensions.json
 .container-type
 diag-ditaa-*
 arch/manual/isa/**/riscv-isa-manual

.vscode/extensions.json

@@ -0,0 +1,11 @@
+{
+  "recommendations": [
+    "asciidoctor.asciidoctor-vscode",
+    "castwide.solargraph",
+    "CraigMaslowski.erb",
+    "HowerLimited.udb-extension-pack-vscode",
+    "mathematic.vscode-pdf",
+    "redhat.vscode-yaml",
+    "zhwu95.riscv"
+  ]
+}

arch/inst/Zawrs/wrs.nto.yaml

@@ -3,11 +3,44 @@
 $schema: "inst_schema.json#"
 kind: instruction
 name: wrs.nto
-long_name: No synopsis available
+long_name: Wait-on-Reservation-Set-with-No-Timeout
 description: |
-  No description available.
+  -id: inst-wrs.nto-behaviour
+  -normative: false
+  -text: |
+    To mitigate the wasteful looping in such usages, a `wrs.nto` (WRS-with-no-timeout) instruction is provided.
+    Instead of polling for a store to a specific memory location, software registers a reservation set that
+    includes all the bytes of the memory location using the LR instruction. Then a subsequent `wrs.nto`
+    instruction would cause the hart to temporarily stall execution in a low-power state until a store
+    occurs to the reservation set or an interrupt is observed.
+
+    This instruction is not supported in a constrained LR/SC loop.
+    While stalled, an implementation is permitted to occasionally terminate the stall and complete
+    execution for any reason.
+
+    `wrs.nto` follows the rules of the WFI instruction for resuming execution
+    on a pending interrupt.
+
+    When the TW (Timeout Wait) bit in `mstatus` is set and `wrs.nto` is executed
+    in any privilege mode otherthan M mode, and it does not complete within an implementation-specific
+    bounded time limit, the `wrs.nto` instruction will cause an illegal instruction exception.
+
+    When executing in VS or VU mode, if the VTW bit is set in `hstatus`, the TW bit in `mstatus` is clear,
+    and the `wrs.nto` does not complete within an implementation-specific bounded time limit,
+    the `wrs.nto` instruction will cause a virtual instruction exception.
+
+    [Note]
+    Since `wrs.nto` can complete execution for reasons other than stores to the reservation set,
+    software will likely need a means of looping until the required stores have occurred.
+
+    [Note]
+    `wrs.nto`, unlike WFI, is not specified to cause an illegal instruction exception if executed in U-mode
+    when the governing TW bit is 0. WFI is typically not expected to be used in U-mode and on many systems
+    may promptly cause an illegal instruction exception if used at U-mode.
+    Unlike WFI, `wrs.nto` is expected to be used by software in U-mode when waiting on memory but without
+    a deadline for that wait.
 definedBy: Zawrs
-assembly: wrs_nto
+assembly: ""
 encoding:
   match: "00000000110100000000000001110011"
   variables: []

arch/inst/Zawrs/wrs.sto.yaml

@@ -3,11 +3,40 @@
 $schema: "inst_schema.json#"
 kind: instruction
 name: wrs.sto
-long_name: No synopsis available
+long_name: Wait-on-Reservation-Set-with-Short-Timeout
 description: |
-  No description available.
+  -id: inst-wrs.sto-behaviour
+  -normative: false
+  -text: |
+    Instead of polling for a store to a specific memory location, software registers a
+    reservation set that includes all the bytes of the memory location using the LR instruction.
+    A subsequent `wrs.sto` instruction would cause the hart to temporarily stall execution in a
+    low-power state until a store occurs to the reservation set or an interrupt is observed.
+    Sometimes the program waiting on a memory update may also need to carry out a task at a future time
+    or otherwise place an upper bound on the wait. To support such use cases, `wrs.sto` bounds the
+    stall duration to an implementation-define short timeout such that the stall is terminated on the
+    timeout if no other conditions have occurred to terminate the stall. The program using this instruction
+    may then determine if its deadline has been reached.
+    `wrs.sto` causes the hart to temporarily stall execution in a low-power state as long as the reservation
+    set is valid and no pending interrupts, even if disabled, are observed. For `wrs.sto` the stall duration
+    is bounded by an implementation defined short timeout. These instructions are not supported in a
+    constrained LR/SC loop.
+    Hart execution may be stalled while the following conditions are all satisfied:
+    a. The reservation set is valid
+    b. If `wrs.sto`, a "short" duration since start of stall has not elapsed
+    c. No pending interrupt is observed (see the rules below)
+
+    While stalled, an implementation is permitted to occasionally terminate the stall and complete
+    execution for any reason. `wrs.sto` follows the rules of the WFI instruction for resuming execution
+    on a pending interrupt. Since `wrs.sto` can complete execution for reasons other than stores to
+    the reservation set, software will likely need a means of looping until the required stores have occurred.
+
+    [Note]
+    The duration of a `wrs.sto` instruction's timeout may vary significantly within and among implementations.
+    In typical implementations this duration should be roughly in the range of 10 to 100 times an on-chip
+    cache miss latency or a cacheless access to main memory.
 definedBy: Zawrs
-assembly: wrs_sto
+assembly: ""
 encoding:
   match: "00000001110100000000000001110011"
   variables: []

arch/inst/Zicsr/csrrc.yaml

@@ -3,11 +3,25 @@
 $schema: inst_schema.json#
 kind: instruction
 name: csrrc
-long_name: No synopsis available
+long_name: Atomic Read and Clear Bits in CSR
 description: |
-  No description available.
+  -id: inst-csrrc-behavior
+  -normative: false
+  -text: |
+    The CSRRC (Atomic Read and Clear Bits in CSR) instruction reads the value of the CSR, zero-extends
+    the value to XLEN bits, and writes it to integer register `rd`. The initial value in integer register `rs1` is
+    treated as a bit mask that specifies bit positions to be cleared in the CSR. Any bit that is high in `rs1` will
+    cause the corresponding bit to be cleared in the CSR, if that CSR bit is writable.
+
+    For CSRRC, if `rs1=x0`, then the instruction will not write to the CSR at all, and so shall
+    not cause any of the side effects that might otherwise occur on a CSR write, nor raise illegal-
+    instruction exceptions on accesses to read-only CSRs. CSRRC always reads the addressed CSR and
+    cause any read side effects regardless of `rs1` and `rd` fields.
+    Note that if `rs1` specifies a register other than `x0`, and that register holds a zero value,
+    the instruction will not action any attendant per-field side effects, but will action any
+    side effects caused by writing to the entire CSR.
 definedBy: Zicsr
-assembly: xd, imm, xs1
+assembly: xd, csr, xs1
 encoding:
   match: -----------------011-----1110011
   variables:

arch/inst/Zicsr/csrrci.yaml

@@ -3,9 +3,17 @@
 $schema: inst_schema.json#
 kind: instruction
 name: csrrci
-long_name: No synopsis available
+long_name: Atomic Read and Clear Bits in CSR with Immediate
 description: |
-  No description available.
+  -id: inst-csrrci-behavior
+  -normative: false
+  -text: |
+    The CSRRCI variant is similar to CSRRC, except this updates the CSR using an XLEN-bit value obtained
+    by zero-extending a 5-bit unsigned immediate (uimm[4:0]) field encoded in the `rs1` field instead of a
+    value from an integer register. For CSRRCI, if the `uimm[4:0]` field is zero, then this instruction
+    will not write to the CSR, and shall not cause any of the side effects that might otherwise occur on
+    a CSR write, nor raise illegal-instruction exceptions on accesses to read-only CSRs. The CSRRCI will
+    always read the CSR and cause any read side effects regardless of `rd` and `rs1` fields.
 definedBy: Zicsr
 assembly: xd, csr, uimm
 encoding:

arch/inst/Zicsr/csrrsi.yaml

@@ -3,9 +3,17 @@
 $schema: inst_schema.json#
 kind: instruction
 name: csrrsi
-long_name: No synopsis available
+long_name: Atomic Read and Set Bits in CSR with Immediate
 description: |
-  No description available.
+  -id: inst-csrrsi-behavior
+  -normative: false
+  -text: |
+    The CSRRSI variant is similar to CSRRS, except this updates the CSR using an XLEN-bit value obtained
+    by zero-extending a 5-bit unsigned immediate (uimm[4:0]) field encoded in the `rs1` field instead of a
+    value from an integer register. For CSRRSI, if the `uimm[4:0]` field is zero, then this instruction
+    will not write to the CSR, and shall not cause any of the side effects that might otherwise occur on
+    a CSR write, nor raise illegal-instruction exceptions on accesses to read-only CSRs. The CSRRSI will
+    always read the CSR and cause any read side effects regardless of `rd` and `rs1` fields.
 definedBy: Zicsr
 assembly: xd, csr, uimm
 encoding:

arch/inst/Zkn/aes64ks1i.yaml

@@ -3,9 +3,15 @@
 $schema: "inst_schema.json#"
 kind: instruction
 name: aes64ks1i
-long_name: No synopsis available
+long_name: AES Key Schedule Instruction 1
 description: |
-  No description available.
+  -id: inst-aes64ks1i-behavior
+  -normative: true
+  -text: |
+    This instruction implements the rotation, SubBytes and Round Constant addition steps of the AES
+    block cipher Key Schedule. This instruction must _always_ be implemented such that its execution
+    latency does not depend on the data being operated on. Note that `rnum` must be in the range
+    `0x0..0xA`. The values `0xB..0xF` are reserved.
 definedBy:
   anyOf: [Zknd, Zkne]
 base: 64