Skip to content

Commit c08ea36

Browse files
dhower-qcdhower-qc
authored
Many updates: (#8)
* Many updates: * Highlighted IDL compilation errors * Exact lines numbers from IDL, even when source comes from YAML * Fixed bug generating decode variable indicies * Few updates to make older versions of singularity acceptable * Complete virtual address translation for all translation sizes (Sv*) * Implement Zalrsc * Parse sw_write(csr_value) for CSRs * Add Svade/Svadu * break globals.isa into builtins/include files * enable passing Strings as function arguments in IDL * compiler performance improvements
1 parent 25a202b commit c08ea36

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

41 files changed

+2866
-999
lines changed

‎.github/workflows/regress.yml

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -12,12 +12,14 @@ jobs:
1212
uses: actions/checkout@v4
1313
- name: Setup apptainer
1414
uses: eWaterCycle/setup-apptainer@v2.0.0
15+
- name: Read container tag
16+
run: echo "CONTAINER_TAG=$(cat bin/.container-tag)" >> $GITHUB_ENV
1517
- name: Get container from cache
1618
id: cache-sif
1719
uses: actions/cache@v3
1820
with:
19-
path: .singularity/image.sif
20-
key: ${{ hashFiles('container.def') }}
21+
path: .singularity/image${{ env.CONTAINER_TAG }}.sif
22+
key: ${{ hashFiles('container.def', 'bin/.container-tag') }}
2123
- name: Get gems and node files from cache
2224
id: cache-bundle-npm
2325
uses: actions/cache@v3

‎README.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@ This repository contains:
3838

3939
== Prerequisites
4040

41-
The only requirement is the `Singularity CE` or `Apptainer` container system. Either one will work (they are forks).
41+
The only requirement is the `Singularity CE` (>= 3.3) or `Apptainer` (>= 1.0) container system. Either one will work (they are forks).
4242

4343
If it is not installed, either as your IT admin or:
4444

‎arch/csr/menvcfg.yaml

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -158,6 +158,30 @@ menvcfg:
158158
definedBy: Svpbmt
159159
type: RW
160160
reset_value: UNDEFINED_LEGAL
161+
ADUE:
162+
location: 61
163+
description: |
164+
If the Svadu extension is implemented, the ADUE bit controls whether hardware updating of
165+
PTE A/D bits is enabled for S-mode and G-stage address translations. When ADUE=1, hardware
166+
updating of PTE A/D bits is enabled during S-mode address translation, and the
167+
implementation behaves as though the Svade extension were not implemented for S-mode address
168+
translation.
169+
170+
When the hypervisor extension is implemented, if ADUE=1, hardware updating of PTE A/D bits
171+
is enabled during G-stage address translation, and the implementation behaves as though the
172+
Svade extension were not implemented for G-stage address translation. When ADUE=0, the
173+
implementation behaves as though Svade were implemented for S-mode and
174+
G-stage address translation.
175+
176+
If Svadu is not implemented, ADUE is read-only zero.
177+
178+
Furthermore, for implementations with the hypervisor extension, henvcfg.ADUE is read-only
179+
zero if menvcfg.ADUE is zero.
180+
definedBy: Svadu
181+
type(): |
182+
return (implemented?(ExtensionName::Svadu)) ? CsrFieldType::RO : CsrFieldType::RW;
183+
reset_value(): |
184+
return (implemented?(ExtensionName::Svadu)) ? UNDEFINED_LEGAL : 0;
161185
CBZE:
162186
location: 7
163187
description: |

‎arch/csr/menvcfgh.yaml

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -28,3 +28,13 @@ menvcfgh:
2828
definedBy: Svpbmt
2929
type: RW
3030
reset_value: UNDEFINED_LEGAL
31+
ADUE:
32+
location: 29
33+
alias: menvcfg.ADUE
34+
description: |
35+
Alias of `menvcfg.ADUE`
36+
definedBy: Svadu
37+
type(): |
38+
return (implemented?(ExtensionName::Svadu)) ? CsrFieldType::RO : CsrFieldType::RW;
39+
reset_value(): |
40+
return (implemented?(ExtensionName::Svadu)) ? UNDEFINED_LEGAL : 0;

‎arch/csr/mepc.yaml

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ mepc:
3737
reset_value: 0
3838
sw_read(): |
3939
if (implemented?(ExtensionName::C) && CSR[misa].C == 1'b1) {
40-
return CSR[mepc] & ~64'b1;
40+
return CSR[mepc].PC & ~64'b1;
4141
} else {
42-
return CSR[mepc];
42+
return CSR[mepc].PC;
4343
}

‎arch/ext/A.yaml

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3,13 +3,26 @@
33
A:
44
type: unprivileged
55
long_name: Atomic instructions
6+
company:
7+
name: RISC-V International
8+
url: https://riscv.org
69
versions:
710
- version: 2.1
811
state: ratified
912
ratification_date: 2019-12
13+
contributors:
14+
- name: Unknown
15+
email: unknown@void.segfault
16+
company: Unknown
1017
implies:
1118
- [Zaamo, 1.0]
1219
- [Zalrsc, 1.0]
20+
required_parameters:
21+
- MUTABLE_MISA_A
22+
- LRSC_RESERVATION_STRATEGY
23+
- LRSC_FAIL_ON_VA_SYNONYM
24+
- LRSC_FAIL_ON_NON_EXACT_LRSC
25+
- LRSC_MISALIGNED_BEHAVIOR
1326
description: |
1427
1528
The atomic-instruction extension, named `A`, contains

‎arch/ext/Svade.yaml

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
# yaml-language-server: $schema=../../schemas/ext_schema.json
2+
3+
Svade:
4+
long_name: Exception on PTE A/D Bits
5+
type: unprivileged
6+
description: |
7+
The Svade extension indicates that hardware does *not* update the A/D bits of a page table
8+
during a page walk. Rather, encountering a PTE with the A bit clear or the D bit clear when
9+
an operation is a write will cause a Page Fault.
10+
versions:
11+
- version: 1.0
12+
state: ratified
13+
ratification_date: 2023-11
14+
url: https://github.com/riscvarchive/riscv-svadu/releases/download/v1.0/riscv-svadu.pdf
15+
repositories:
16+
- url: https://github.com/riscvarchive/riscv-svadu
17+
branch: main
18+
contributors:
19+
- name: Aaron Durbin
20+
company: Rivos, Inc.
21+
- name: Andrew Waterman
22+
company: SiFive
23+
- name: Earl Killian
24+
company: Aril
25+
- name: Greg Favor
26+
company: Ventana
27+
- name: John Ingalls
28+
company: SiFive
29+
- name: Ken Dockser
30+
company: Tenstorrent
31+
- name: Krste Asanovic
32+
company: SiFive
33+
- name: Paul Donahue
34+
- name: Ved Shanbhogue
35+
company: Rivos, Inc.
36+
conflicts: Svadu
37+
doc_license:
38+
name: Creative Commons Attribution 4.0 International License (CC-BY 4.0)
39+
url: https://creativecommons.org/licenses/by/4.0/
40+

‎arch/ext/Svadu.yaml

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
# yaml-language-server: $schema=../../schemas/ext_schema.json
2+
3+
Svadu:
4+
long_name: Hardware Updating of PTE A/D Bits
5+
type: unprivileged
6+
description: |
7+
The Svadu extension adds support and CSR controls for hardware updating of PTE
8+
A/D bits. The A and D bits are managed by these extensions as follows:
9+
10+
* When a virtual page is accessed and the A bit is clear, the PTE is updated to
11+
set the A bit. When the virtual page is written and the D bit is clear, the
12+
PTE is updated to set the D bit. When G-stage address translation is in use
13+
and is not Bare, the G-stage virtual pages may be accessed or written by
14+
implicit accesses to VS-level memory management data structures, such as page
15+
tables.
16+
17+
* When two-stage address translation is in use, an explicit access may cause
18+
both VS-stage and G-stage PTEs to be updated. The following rules apply to all
19+
PTE updates caused by an explicit or an implicit memory accesses. +
20+
+
21+
The PTE update must be atomic with respect to other accesses to the PTE, and
22+
must atomically perform all tablewalk checks for that leaf PTE as part of, and
23+
before, conditionally updating the PTE value. Updates of the A bit may be
24+
performed as a result of speculation, even if the associated memory access
25+
ultimately is not performed architecturally. However, updates to the D bit,
26+
resulting from an explicit store, must be exact (i.e., non-speculative), and
27+
observed in program order by the local hart. When two-stage address
28+
translation is active, updates of the D bit in G-stage PTEs may be performed
29+
as a result of speculative updates of the A bit in VS-stage PTEs. +
30+
+
31+
The PTE update must appear in the global memory order before the memory access
32+
that caused the PTE update and before any subsequent explicit memory access to
33+
that virtual page by the local hart. The ordering on loads and stores provided
34+
by FENCE instructions and the acquire/release bits on atomic instructions also
35+
orders the PTE updates associated with those loads and stores as observed by
36+
remote harts. +
37+
+
38+
The PTE update is not required to be atomic with respect to the memory access
39+
that caused the update and a trap may occur between the PTE update and the
40+
memory access that caused the PTE update. If a trap occurs then the A and/or D
41+
bit may be updated but the memory access that caused the PTE update might not
42+
occur. The hart must not perform the memory access that caused the PTE update
43+
before the PTE update is globally visible.
44+
45+
[NOTE]
46+
====
47+
The PTE updates due to memory accesses ordered-after a FENCE are not themselves
48+
ordered by the FENCE.
49+
50+
Simpler implementations that cannot precisely order the PTE update before
51+
subsequent explicit memory accesses to the associated virtual page by the local
52+
hart may simply order the PTE update before all subsequent explicit memory
53+
accesses to any virtual page by the local hart.
54+
====
55+
56+
Svadu extension requires the page tables to be located in memory with hardware
57+
page-table write access and _RsrvEventual_ PMA.
58+
59+
<<<
60+
61+
The translation of virtual addresses (or guest physical addresses) to physical
62+
(or guest physical) addresses is accomplished with the same algorithm as
63+
specified in the Supervisor-Level ISA extension (section "Virtual Address
64+
Translation Process") and as modified by the hypervisor extension (section
65+
"Two-stage Address Translation"), except that step 7 of the translation process,
66+
instead of causing a page-fault exception due to A and/or D bits being 0 when
67+
required to be 1, continues as follows:
68+
69+
[start=7]
70+
. If `pte.a = 0`, or if the original memory access is a store and `pte.d = 0`:
71+
.. If a store to `pte` would violate a PMA or PMP check, raise an access-fault
72+
exception corresponding to the original access type.
73+
.. Perform the following steps atomically:
74+
... Compare `pte` to the value of the PTE at address `a + va.vpn[i] * PTESIZE`.
75+
... If the values match, set `pte.a` to 1 and, if the original memory access is
76+
a store, also set `pte.d` to 1.
77+
... If the comparison fails, return to step 2
78+
79+
The Svadu extension adds the `ADUE` bit (bit 61) to `menvcfg`. When
80+
`menvcfg.ADUE` is 1, hardware updating of PTE A/D bits is enabled during
81+
single-stage address translation. When the hypervisor extension is implemented,
82+
if `menvcfg.ADUE` is 1, hardware updating of PTE A/D bits is enabled during
83+
G-stage address translation. When `menvcfg.ADUE` is zero, the implementation
84+
behaves as though Svadu were not implemented. If Svadu is not implemented,
85+
`menvcfg.ADUE` is read-only zero. Furthermore, for implementations with the
86+
hypervisor extension, `henvcfg.ADUE` is read-only zero if `menvcfg.ADUE` is zero.
87+
88+
When the hypervisor extension is implemented, the Svadu extension adds the
89+
`ADUE` bit (bit 61) to `henvcfg`. When `henvcfg.ADUE` is 1, hardware updating of
90+
PTE A/D bits is enabled during VS-stage address translation. When `henvcfg.ADUE`
91+
is zero, the implementation behaves as though Svadu were not implemented for
92+
VS-stage address translation.
93+
versions:
94+
- version: 1.0
95+
state: ratified
96+
ratification_date: 2023-11
97+
url: https://github.com/riscvarchive/riscv-svadu/releases/download/v1.0/riscv-svadu.pdf
98+
repositories:
99+
- url: https://github.com/riscvarchive/riscv-svadu
100+
branch: main
101+
contributors:
102+
- name: Aaron Durbin
103+
company: Rivos, Inc.
104+
- name: Andrew Waterman
105+
company: SiFive
106+
- name: Earl Killian
107+
company: Aril
108+
- name: Greg Favor
109+
company: Ventana
110+
- name: John Ingalls
111+
company: SiFive
112+
- name: Ken Dockser
113+
company: Tenstorrent
114+
- name: Krste Asanovic
115+
company: SiFive
116+
- name: Paul Donahue
117+
- name: Ved Shanbhogue
118+
company: Rivos, Inc.
119+
conflicts: Svade
120+
doc_license:
121+
name: Creative Commons Attribution 4.0 International License (CC-BY 4.0)
122+
url: https://creativecommons.org/licenses/by/4.0/
123+

‎arch/inst/A/lr.d.yaml

Lines changed: 87 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,87 @@
1+
# yaml-language-server: $schema=../../../schemas/inst_schema.json
2+
3+
lr.d:
4+
long_name: Load reserved doubleword
5+
description: |
6+
Loads a word from the address in rs1, places the value in rd,
7+
and registers a _reservation set_ -- a set of bytes that subsumes the bytes in the
8+
addressed word.
9+
10+
The address in rs1 must be 8-byte aligned.
11+
12+
If the address is not naturally aligned, a `LoadAddressMisaligned` exception or an
13+
`LoadAccessFault` exception will be generated. The access-fault exception can be generated
14+
for a memory access that would otherwise be able to complete except for the misalignment,
15+
if the misaligned access should not be emulated.
16+
17+
An implementation can register an arbitrarily large reservation set on each LR, provided the
18+
reservation set includes all bytes of the addressed data word or doubleword.
19+
An SC can only pair with the most recent LR in program order.
20+
An SC may succeed only if no store from another hart to the reservation set can be
21+
observed to have occurred between the LR and the SC, and if there is no other SC between the
22+
LR and itself in program order.
23+
An SC may succeed only if no write from a device other than a hart to the bytes accessed by
24+
the LR instruction can be observed to have occurred between the LR and SC. Note this LR
25+
might have had a different effective address and data size, but reserved the SC's
26+
address as part of the reservation set.
27+
28+
[NOTE]
29+
----
30+
Following this model, in systems with memory translation, an SC is allowed to succeed if the
31+
earlier LR reserved the same location using an alias with a different virtual address, but is
32+
also allowed to fail if the virtual address is different.
33+
34+
To accommodate legacy devices and buses, writes from devices other than RISC-V harts are only
35+
required to invalidate reservations when they overlap the bytes accessed by the LR.
36+
These writes are not required to invalidate the reservation when they access other bytes in
37+
the reservation set.
38+
----
39+
40+
Software should not set the _rl_ bit on an LR instruction unless the _aq_ bit is also set.
41+
LR.rl and SC.aq instructions are not guaranteed to provide any stronger ordering than those
42+
with both bits clear, but may result in lower performance.
43+
definedBy: [A, Zalrsc]
44+
base: 64
45+
assembly: xd, xs1
46+
encoding:
47+
match: 00010--00000-----011-----0101111
48+
variables:
49+
- name: aq
50+
location: 26
51+
- name: rl
52+
location: 27
53+
- name: rs1
54+
location: 19-15
55+
- name: rd
56+
location: 11-7
57+
access:
58+
s: always
59+
u: always
60+
vs: always
61+
vu: always
62+
operation(): |
63+
if (implemented?(ExtensionName::A) && (CSR[misa].A == 1'b0)) {
64+
raise (ExceptionCode::IllegalInstruction, $encoding);
65+
}
66+
67+
XReg virtual_address = X[rs1];
68+
69+
if (!is_naturally_aligned<XLEN, 64>(virtual_address)) {
70+
# can raise either LoadAddressMisaligned *or* LoadAccessFault
71+
#
72+
# from the spec:
73+
# If the address is not naturally aligned, an address-misaligned exception or
74+
# an access-fault exception will be generated. The access-fault exception can
75+
# be generated for a memory access that would otherwise be able to complete except
76+
# for the misalignment, if the misaligned access should not be emulated.
77+
78+
if (LRSC_MISALIGNED_BEHAVIOR == "always raise misaligned exception") {
79+
raise(ExceptionCode::LoadAddressMisaligned, virtual_address);
80+
} else if (LRSC_MISALIGNED_BEHAVIOR == "always raise access fault") {
81+
raise(ExceptionCode::LoadAccessFault, virtual_address);
82+
} else {
83+
unpredictable("Implementations may raise either a LoadAddressMisaligned or a LoadAccessFault when an LR/SC address is misaligned");
84+
}
85+
}
86+
87+
X[rd] = load_reserved<32>(virtual_address, aq, rl);

‎arch/inst/A/lr.w.yaml

Lines changed: 24 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -70,5 +70,27 @@ lr.w:
7070
7171
XReg virtual_address = X[rs1];
7272
73-
#X[rd] = load_reserved<32>(virtual_address);
74-
X[rd] = read_memory<32>(virtual_address);
73+
if (!is_naturally_aligned<XLEN, 32>(virtual_address)) {
74+
# can raise either LoadAddressMisaligned *or* LoadAccessFault
75+
#
76+
# from the spec:
77+
# If the address is not naturally aligned, an address-misaligned exception or
78+
# an access-fault exception will be generated. The access-fault exception can
79+
# be generated for a memory access that would otherwise be able to complete except
80+
# for the misalignment, if the misaligned access should not be emulated.
81+
82+
if (LRSC_MISALIGNED_BEHAVIOR == "always raise misaligned exception") {
83+
raise(ExceptionCode::LoadAddressMisaligned, virtual_address);
84+
} else if (LRSC_MISALIGNED_BEHAVIOR == "always raise access fault") {
85+
raise(ExceptionCode::LoadAccessFault, virtual_address);
86+
} else {
87+
unpredictable("Implementations may raise either a LoadAddressMisaligned or a LoadAccessFault when an LR/SC address is misaligned");
88+
}
89+
}
90+
91+
XReg load_value = load_reserved<32>(virtual_address, aq, rl);
92+
if (xlen() == 64) {
93+
X[rd] = load_value;
94+
} else {
95+
X[rd] = sext(load_value[31:0], 32);
96+
}

0 commit comments

Comments
 (0)