From 67a6ae966c986869b4ba164c6341c0a0e7cb311f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Sintzoff?= <61976467+ASintzoff@users.noreply.github.com> Date: Tue, 22 Oct 2024 14:44:02 +0200 Subject: [PATCH] update riscv-isa-manual to riscv-isa-release-2c07aa2-2024-10-18 (#2560) Since last riscv-isa-manual update (CVA6 commit 3059b1cb2): - Privileged Architecture 1.13 ratified - minor documentation changes - wavedrom file renamed to .edn --- docs/04_cv32a65x/config/config.adoc | 1 + docs/04_cv32a65x/riscv/priv-isa-cv32a65x.html | 87 +-- .../riscv/unpriv-isa-cv32a65x.html | 591 +++++++++--------- docs/06_cv64a6_mmu/config/config.adoc | 1 + docs/riscv-isa/riscv-isa-manual | 2 +- docs/riscv-isa/src/colophon.adoc | 2 +- docs/riscv-isa/src/counters.adoc | 2 +- docs/riscv-isa/src/machine.adoc | 109 ++-- docs/riscv-isa/src/priv-preface.adoc | 34 +- docs/riscv-isa/src/riscv-privileged.adoc | 11 +- docs/riscv-isa/src/riscv-unprivileged.adoc | 4 +- docs/riscv-isa/src/rv64.adoc | 12 +- docs/riscv-isa/src/supervisor.adoc | 23 +- docs/riscv-isa/src/zpm.adoc | 6 + 14 files changed, 465 insertions(+), 420 deletions(-) create mode 100644 docs/riscv-isa/src/zpm.adoc diff --git a/docs/04_cv32a65x/config/config.adoc b/docs/04_cv32a65x/config/config.adoc index 1983cd1300..4f2401a639 100644 --- a/docs/04_cv32a65x/config/config.adoc +++ b/docs/04_cv32a65x/config/config.adoc @@ -28,6 +28,7 @@ :RVZihpm: false :RVZimop: false :RVZk: false +:RVZpm: false :RVZsmcdeleg: false :RVZsmcntrpmf: false :RVZsmcsrind-RVZsscsrind: false diff --git a/docs/04_cv32a65x/riscv/priv-isa-cv32a65x.html b/docs/04_cv32a65x/riscv/priv-isa-cv32a65x.html index d686c75b12..d4657b1a6a 100644 --- a/docs/04_cv32a65x/riscv/priv-isa-cv32a65x.html +++ b/docs/04_cv32a65x/riscv/priv-isa-cv32a65x.html @@ -440,7 +440,8 @@
-
Stack pointer adjustment handling
+
29.13.2.1. Stack pointer adjustment handling

The instructions all automatically adjust the stack pointer by enough to cover the memory required for the registers being saved or restored. Additionally the spimm field in the encoding allows the stack pointer to be adjusted in additional increments of 16-bytes. There is only a small restricted @@ -11568,7 +11569,7 @@

Stack pointer adjustment handling
-
Register list handling
+
29.13.2.2. Register list handling

There is no support for the {ra, s0-s10} register list without also adding s11. Therefore the {ra, s0-s11} register list must be used in this case.

@@ -11600,7 +11601,7 @@

29.13.3. PUSH/POP Fault handling

29.13.4. Software view of execution

-
Software view of the PUSH sequence
+
29.13.4.1. Software view of the PUSH sequence

From a software perspective the PUSH sequence appears as:

@@ -11682,7 +11683,7 @@
Software view of the PUSH sequence<
-
Software view of the POP/POPRET sequence
+
29.13.4.2. Software view of the POP/POPRET sequence

From a software perspective the POP/POPRET sequence appears as:

@@ -11780,7 +11781,7 @@

29.13.6. Example RV32I PUSH/POP sequen Examples of cm.popret and cm.popretz are not included, as the difference in the expanded sequence from cm.pop is trivial in all cases.

-
cm.push {ra, s0-s2}, -64
+
29.13.6.1. cm.push {ra, s0-s2}, -64

Encoding: rlist=7, spimm=3

@@ -11798,7 +11799,7 @@
cm.push {ra, s0-s2}, -64
-
cm.push {ra, s0-s11}, -112
+
29.13.6.2. cm.push {ra, s0-s11}, -112

Encoding: rlist=15, spimm=3

@@ -11826,7 +11827,7 @@
cm.push {ra, s0-s11}, -112
-
cm.pop {ra}, 16
+
29.13.6.3. cm.pop {ra}, 16

Encoding: rlist=4, spimm=0

@@ -11841,7 +11842,7 @@
cm.pop {ra}, 16
-
cm.pop {ra, s0-s3}, 48
+
29.13.6.4. cm.pop {ra, s0-s3}, 48

Encoding: rlist=8, spimm=1

@@ -11860,7 +11861,7 @@
cm.pop {ra, s0-s3}, 48
-
cm.pop {ra, s0-s4}, 64
+
29.13.6.5. cm.pop {ra, s0-s4}, 64

Encoding: rlist=9, spimm=2

@@ -13611,7 +13612,7 @@

30.4. Extensions

✓

✓

-

orc.b rd, rs1, rs2

+

orc.b rd, rs

Bitwise OR-Combine, byte granule

✓

@@ -13902,7 +13903,7 @@

30.4.1. Zba: Address generation

While the shift and add instructions are limited to a maximum left shift of 3, the slli instruction (from the base ISA) can be used to perform similar shifts for indexing into arrays of wider elements. The slli.uw — added in this extension — can be used when the index is to be interpreted as an unsigned word.

-

The following instructions (and pseudoinstructions) comprise the Zba extension:

+

The following instructions comprise the Zba extension:

@@ -13968,19 +13969,13 @@

30.4.1. Zba: Address generation

- - - - - -

slli.uw rd, rs1, imm

Shift-left unsigned word (Immediate)

✓

zext.w rd, rs

Add unsigned word

30.4.2. Zbb: Basic bit-manipulation

-
Logical with negate
+
30.4.2.1. Logical with negate
@@ -14035,7 +14030,7 @@
Logical with negate
-
Count leading/trailing zero bits
+
30.4.2.2. Count leading/trailing zero bits
@@ -14080,7 +14075,7 @@
Count leading/trailing zero bits
-
Count population
+
30.4.2.3. Count population

These instructions count the number of set bits (1-bits). This is also commonly referred to as population count.

@@ -14117,7 +14112,7 @@
Count population
-
Integer minimum/maximum
+
30.4.2.4. Integer minimum/maximum

The integer minimum/maximum instructions are arithmetic R-type instructions that return the smaller/larger of two operands.

@@ -14166,7 +14161,7 @@
Integer minimum/maximum
-
Sign extension and zero extension
+
30.4.2.5. Sign extension and zero extension

These instructions perform the sign extension or zero extension of the least significant 8 bits or 16 bits of the source register.

@@ -14211,7 +14206,7 @@
Sign extension and zero extension
-
Bitwise rotation
+
30.4.2.6. Bitwise rotation

Bitwise rotation instructions are similar to the shift-logical operations from the base spec. However, where the shift-logical instructions shift in zeros, the rotate instructions shift in the bits that were shifted out of the other side of the value. @@ -14289,7 +14284,7 @@

Bitwise rotation
-
OR Combine
+
30.4.2.7. OR Combine

orc.b sets the bits of each byte in the result rd to all zeros if no bit within the respective byte of rs is set, or to all ones if any bit within the respective byte of rs is set.

@@ -14322,7 +14317,7 @@
OR Combine
-
Byte-reverse
+
30.4.2.8. Byte-reverse

rev8 reverses the byte-ordering of rs.

@@ -16560,6 +16555,23 @@

30.5.26. pack

+
+ + + + + +
+ + +For RV32, the pack instruction with rs2=x0 is the zext.h +instruction. +Hence, for RV32, any extension that contains the pack instruction also +contains the zext.h instruction (but not necessarily the c.zext.h +instruction, which is only guaranteed to exist if both the Zcb and Zbb +extensions are implemented). +
+
@@ -16693,6 +16705,23 @@

30.5.28. packw

+
+ + + + + +
+ + +For RV64, the packw instruction with rs2=x0 is the zext.h +instruction. +Hence, for RV64, any extension that contains the packw instruction also +contains the zext.h instruction (but not necessarily the c.zext.h +instruction, which is only guaranteed to exist if both the Zcb and Zbb +extensions are implemented). +
+
@@ -17913,7 +17942,8 @@

30.5.46. unzip

Synopsis
-

Implements the inverse of the zip instruction.

+

Place odd and even bits of the source register into upper and lower halves of +the destination register, respectively.

Mnemonic
@@ -17924,16 +17954,16 @@

30.5.46. unzip

-Diagram +Diagram
Description
-

This instruction gathers bits from the high and low halves of the source -word into odd/even bit positions in the destination word. -It is the inverse of the zip instruction. +

This instruction scatters all of the odd and even bits of a source word into +the high and low halves of a destination word. +It is the inverse of the zip instruction. This instruction is available only on RV32.

Operation
@@ -18309,8 +18339,8 @@

30.5.51. zip

Synopsis
-

Gather odd and even bits of the source word into upper/lower halves of the -destination.

+

Interleave upper and lower halves of the source register into odd and even +bits of the destination register, respectivley.

Mnemonic
@@ -18321,16 +18351,16 @@

30.5.51. zip

-Diagram +Diagram
Description
-

This instruction scatters all of the odd and even bits of a source word into -the high and low halves of a destination word. -It is the inverse of the unzip instruction. +

This instruction gathers bits from the high and low halves of the source +word into odd/even bit positions in the destination word. +It is the inverse of the unzip instruction. This instruction is available only on RV32.

Operation
@@ -18548,32 +18578,7 @@

30.6.2. strcmp

-

31. "J" Extension for Dynamically Translated Languages, Version 0.0

-
-
-

This chapter is a placeholder for a future standard extension to support -dynamically translated languages.

-
-
- - - - - -
- - -
-

Many popular languages are usually implemented via dynamic translation, -including Java and Javascript. These languages can benefit from -additional ISA support for dynamic checks and garbage collection.

-
-
-
-
-
-
-

32. "P" Extension for Packed-SIMD Instructions, Version 0.2

+

31. "P" Extension for Packed-SIMD Instructions, Version 0.2

@@ -18597,7 +18602,7 @@

32. "P" Extension for Packed-SIMD Instructions, Version 0.2<
-

33. "V" Standard Extension for Vector Operations, Version 1.0

+

32. "V" Standard Extension for Vector Operations, Version 1.0

CV32A65X: This extension is not supported.

@@ -18605,7 +18610,7 @@

33. "V" Standard Extension for Vector Operations, Version 1.0

-

34. Cryptography Extensions: Scalar & Entropy Source Instructions, Version 1.0.1

+

33. Cryptography Extensions: Scalar & Entropy Source Instructions, Version 1.0.1

CV32A65X: These extensions are not supported.

@@ -18613,7 +18618,7 @@

34. Cryptography Extensions: Scalar & Entropy Source

-

35. Cryptography Extensions: Vector Instructions, Version 1.0

+

34. Cryptography Extensions: Vector Instructions, Version 1.0

CV32A65X: These extensions are not supported.

@@ -18621,7 +18626,7 @@

35. Cryptography Extensions: Vector Instructions, Version

-

36. Control-flow Integrity (CFI)

+

35. Control-flow Integrity (CFI)

CV32A65X: The Zicfiss extension is not supported.

@@ -18632,7 +18637,7 @@

36. Control-flow Integrity (CFI)

-

37. RV32/64G Instruction Set Listings

+

36. RV32/64G Instruction Set Listings

One goal of the RISC-V project is that it be used as a stable software @@ -18745,7 +18750,7 @@

37. RV32/64G Instruction Set Listings

benefits to a restricted class of applications, e.g., for multimedia or security. Unlike most commercial ISAs, the RISC-V ISA design clearly separates the base ISA and broadly applicable standard extensions from -these more specialized additions. Chapter 38 +these more specialized additions. Chapter 37 has a more extensive discussion of ways to add extensions to the RISC-V ISA.

@@ -19541,7 +19546,7 @@

37. RV32/64G Instruction Set Listings

-

38. Extending RISC-V

+

37. Extending RISC-V

In addition to supporting standard general-purpose software development, @@ -19562,13 +19567,13 @@

38. Extending RISC-V

for supervisor-level extensions described in the second volume.

-

38.1. Extension Terminology

+

37.1. Extension Terminology

This section defines some standard terminology for describing RISC-V extensions.

-

38.1.1. Standard versus Non-Standard Extension

+

37.1.1. Standard versus Non-Standard Extension

Any RISC-V processor implementation must support a base integer ISA (RV32I, RV32E, RV64I, RV64E, or RV128I). In addition, an implementation may @@ -19593,7 +19598,7 @@

38.1.1. Standard versus Non-Sta

-

38.1.2. Instruction Encoding Spaces and Prefixes

+

37.1.2. Instruction Encoding Spaces and Prefixes

An instruction encoding space is some number of instruction bits within which a base ISA or ISA extension is encoded. RISC-V supports varying @@ -19745,7 +19750,7 @@

38.1.2. Instruction Encoding

-

38.1.3. Greenfield versus Brownfield Extensions

+

37.1.3. Greenfield versus Brownfield Extensions

We use the term greenfield extension to describe an extension that begins populating a new instruction encoding space, and hence can only @@ -19813,7 +19818,7 @@

38.1.3. Greenfield versus Brow

-

38.1.4. Standard-Compatible Global Encodings

+

37.1.4. Standard-Compatible Global Encodings

A complete or global encoding of an ISA for an actual RISC-V implementation must allocate a unique non-conflicting prefix for every @@ -19836,7 +19841,7 @@

38.1.4. Standard-Compatible Globa

-

38.1.5. Guaranteed Non-Standard Encoding Space

+

37.1.5. Guaranteed Non-Standard Encoding Space

To support development of proprietary custom extensions, portions of the encoding space are guaranteed to never be used by standard extensions.

@@ -19844,7 +19849,7 @@

38.1.5. Guaranteed Non-Standard

-

38.2. RISC-V Extension Design Philosophy

+

37.2. RISC-V Extension Design Philosophy

We intend to support a large number of independently developed extensions by encouraging extension developers to operate within @@ -19895,7 +19900,7 @@

38.2. RISC-V Extension Design Philo

-

38.3. Extensions within fixed-width 32-bit instruction format

+

37.3. Extensions within fixed-width 32-bit instruction format

In this section, we discuss adding extensions to implementations that only support the base fixed-width 32-bit instruction format.

@@ -19916,7 +19921,7 @@

38.3. Extensions within fixed-width 32-bit instruction format

-

38.3.1. Available 30-bit instruction encoding spaces

+

37.3.1. Available 30-bit instruction encoding spaces

In the standard encoding, three of the available 30-bit instruction encoding spaces (those with 2-bit prefixes 00, 01, and 10) are used to @@ -19927,7 +19932,7 @@

38.3.1. Available 30-bit

-

38.3.2. Available 25-bit instruction encoding spaces

+

37.3.2. Available 25-bit instruction encoding spaces

A 25-bit instruction encoding space corresponds to a major opcode in the base and standard extension encodings.

@@ -19963,7 +19968,7 @@

38.3.2. Available 25-bit

-

38.3.3. Available 22-bit instruction encoding spaces

+

37.3.3. Available 22-bit instruction encoding spaces

A 22-bit encoding space corresponds to a funct3 minor opcode space in the base and standard extension encodings. Several major opcodes have a @@ -19978,7 +19983,7 @@

38.3.3. Available 22-bit

-

38.3.4. Other spaces

+

37.3.4. Other spaces

Smaller spaces are available under certain major opcodes, and not all minor opcodes are entirely filled.

@@ -19986,7 +19991,7 @@

38.3.4. Other spaces

-

38.4. Adding aligned 64-bit instruction extensions

+

37.4. Adding aligned 64-bit instruction extensions

The simplest approach to provide space for extensions that are too large for the base 32-bit fixed-width instruction format is to add naturally @@ -20023,7 +20028,7 @@

38.4. Adding aligned 64-b

-

38.5. Supporting VLIW encodings

+

37.5. Supporting VLIW encodings

Although RISC-V was not designed as a base for a pure VLIW machine, VLIW encodings can be added as extensions using several alternative @@ -20031,7 +20036,7 @@

38.5. Supporting VLIW encodings

to allow use of any standard software tools.

-

38.5.1. Fixed-size instruction group

+

37.5.1. Fixed-size instruction group

The simplest approach is to define a single large naturally aligned instruction format (e.g., 128 bits) within which VLIW operations are @@ -20042,7 +20047,7 @@

38.5.1. Fixed-size instruction group

-

38.5.2. Encoded-Length Groups

+

37.5.2. Encoded-Length Groups

Another approach is to use the standard length encoding from Table 1 to encode parallel @@ -20064,7 +20069,7 @@

38.5.2. Encoded-Length Groups

-

38.5.3. Fixed-Size Instruction Bundles

+

37.5.3. Fixed-Size Instruction Bundles

Another approach, similar to Itanium, is to use a larger naturally aligned fixed instruction bundle size (e.g., 128 bits) across which @@ -20075,7 +20080,7 @@

38.5.3. Fixed-Size Instruction Bundles<

-

38.5.4. End-of-Group bits in Prefix

+

37.5.4. End-of-Group bits in Prefix

None of the above approaches retains the RISC-V encoding for the individual operations within a VLIW instruction. Yet another approach is @@ -20098,7 +20103,7 @@

38.5.4. End-of-Group bits in Prefix

-

39. ISA Extension Naming Conventions

+

38. ISA Extension Naming Conventions

This chapter describes the RISC-V ISA extension naming scheme that is @@ -20123,13 +20128,13 @@

39. ISA Extension Naming Conventions

-

39.1. Case Sensitivity

+

38.1. Case Sensitivity

The ISA naming strings are case insensitive.

-

39.2. Base Integer ISA

+

38.2. Base Integer ISA

RISC-V ISA strings begin with either RV32I, RV32E, RV64I, RV64E, or RV128I indicating the supported address space size in bits for the base integer @@ -20137,7 +20142,7 @@

39.2. Base Integer ISA

-

39.3. Instruction-Set Extension Names

+

38.3. Instruction-Set Extension Names

Standard ISA extensions are given a name consisting of a single letter. For example, the first four standard extensions to the integer bases @@ -20166,48 +20171,20 @@

39.3. Instruction-Set Extension Names<

-

39.4. Version Numbers

-
-

Recognizing that instruction sets may expand or alter over time, we -encode extension version numbers following the extension name. Version -numbers are divided into major and minor version numbers, separated by a -"p". If the minor version is "0", then "p0" can be omitted from -the version string. Changes in major version numbers imply a loss of -backwards compatibility, whereas changes in only the minor version -number must be backwards-compatible. For example, the original 64-bit -standard ISA defined in release 1.0 of this manual can be written in -full as "RV64I1p0M1p0A1p0F1p0D1p0", more concisely as -"RV64I1M1A1F1D1".

-
-
-

We introduced the version numbering scheme with the second release. -Hence, we define the default version of a standard extension to be the -version present at that time, e.g., "RV32I" is equivalent to -"RV32I2".

-
-
-
-

39.5. Underscores

+

38.4. Underscores

Underscores "_" may be used to separate ISA extensions to improve readability and to provide disambiguation, e.g., "RV32I2_M2_A2".

-
-

Because the "P" extension for Packed SIMD can be confused for the -decimal point in a version number, it must be preceded by an underscore -if it follows a number. For example, "rv32i2p2" means version 2.2 of -RV32I, whereas "rv32i2_p2" means version 2.0 of RV32I with version 2.0 -of the P extension.

-
-

39.6. Additional Standard Unprivileged Extension Names

+

38.5. Additional Standard Unprivileged Extension Names

-

Standard unprivileged extensions can also be named using a single "Z" followed by -an alphabetical name and an optional version number. For example, -"Zifencei" names the instruction-fetch fence extension described in -Chapter 6; "Zifencei2" and -"Zifencei2p0" name version 2.0 of same.

+

Standard unprivileged extensions can also be named by using a single "Z" followed by an +alphanumeric name. The name must end with an alphabetical character. +The second letter from the end cannot be numeric if the +last letter is "p". For example, "Zifencei" names the instruction-fetch fence extension +described in Chapter 6.

The first letter following the "Z" conventionally indicates the most @@ -20225,24 +20202,29 @@

39.6. Additional Stan

-

39.7. Supervisor-level Instruction-Set Extensions

+

38.6. Supervisor-level Instruction-Set Extension Names

Standard extensions that extend the supervisor-level virtual-memory -architecture are prefixed with the letters "Sv", followed by an alphabetical -name and an optional version number, or by a numeric name with no version number. -Other standard extensions that extend -the supervisor-level architecture are prefixed with the letters "Ss", -followed by an alphabetical name and an optional version number. Such -extensions are defined in Volume II.

+architecture are prefixed with the letters "Sv", followed by an alphanumeric +name. Other standard extensions that extend the supervisor-level architecture are +prefixed with thel letters "Ss", followed by an alphanumeric name. The name +must end with an alphabetical character. The second letter from the end cannot +be numeric if the last letter is "p". These extensions are further defined in +Volume II.

+
+
+

The extensions "sv32", "sv39", "sv48", and "sv59" were defined before the rule +against extension names ending in numbers was established.

Standard supervisor-level extensions should be listed after standard -unprivileged extensions. If multiple supervisor-level extensions are -listed, they should be ordered alphabetically.

+unprivileged extensions, and like other multi-letter extensions, must be +separated from other multi-letter extensions by an underscore. If multiple +supervisor-level extensions are listed, they should be ordered alphabetically.

-

39.8. Hypervisor-level Instruction-Set Extensions

+

38.7. Hypervisor-level Instruction-Set Extension Names

Standard extensions that extend the hypervisor-level architecture are prefixed with the letters "Sh". @@ -20267,24 +20249,26 @@

39.8. Hypervisor-level Ins

-

39.9. Machine-level Instruction-Set Extensions

+

38.8. Machine-level Instruction-Set Extension Names

Standard machine-level instruction-set extensions are prefixed with the letters "Sm".

Standard machine-level extensions should be listed after standard -lesser-privileged extensions. If multiple machine-level extensions are -listed, they should be ordered alphabetically.

+lesser-privileged extensions, and like other multi-letter extensions, must be +separated from other multi-letter extensions by an underscore. If multiple +machine-level extensions are listed, they should be ordered alphabetically.

-

39.10. Non-Standard Extension Names

+

38.9. Non-Standard Extension Names

-

Non-standard extensions are named using a single "X" followed by an -alphabetical name and an optional version number. For example, -"Xhwacha" names the Hwacha vector-fetch ISA extension; "Xhwacha2" -and "Xhwacha2p0" name version 2.0 of same.

+

Non-standard extensions are named by using a single "X" followed by the alphanumeric +name. The name must end with an alphabetic character. The +second letter from the end cannot be numeric if the last letter is +"p". For example, "Xhwacha" names the Hwacha vector-fetch ISA +extension.

Non-standard extensions must be listed after all standard extensions, and, @@ -20295,11 +20279,44 @@

39.10. Non-Standard Extension Names

If multiple non-standard extensions are listed, they should be ordered -alphabetically.

+alphabetically. Like other multi-letter extensions, they should be +separated from other multi-leter extensions by an underscore.

+
+
+
+

38.10. Version Numbers

+
+

Recognizing that instruction sets may expand or alter over time, we +encode extension version numbers following the extension name. Version +numbers are divided into major and minor version numbers, separated by a +"p". If the minor version is "0", then "p0" can be omitted from +the version string. To avoid ambiguity, no extension name may end with a number +or a "p" preceded by a number.

+
+
+

Because the "P" extension for Packed SIMD can be confused for the +decimal point in a version number, it must be preceded by an underscore +if it follows another extension with a version number. For example, "rv32i2p2" +means version 2.2 of RV32I, whereas "rv32i2_p2" means version 2.0 of RV32I with +version 2.0 of the P extension.

+
+
+

Changes in major version numbers imply a loss of +backwards compatibility, whereas changes in only the minor version +number must be backwards-compatible. For example, the original 64-bit +standard ISA defined in release 1.0 of this manual can be written in +full as "RV64I1p0M1p0A1p0F1p0D1p0", more concisely as +"RV64I1M1A1F1D1".

+
+
+

We introduced the version numbering scheme with the second release. +Hence, we define the default version of a standard extension to be the +version present at that time, e.g., "RV32I" is equivalent to +"RV32I2".

-

39.11. Subset Naming Convention

+

38.11. Subset Naming Convention

Table 30 summarizes the standardized extension names. The table also defines the canonical @@ -20412,6 +20429,14 @@

39.11. Subset Naming Convention

+

Standard Hypervisor-Level Extensions

+ + +

Hypervisor-level extension "ghi"

+

Shghi

+ + +

Standard Machine-Level Extensions

@@ -20433,10 +20458,10 @@

39.11. Subset Naming Convention

-

40. History and Acknowledgments

+

39. History and Acknowledgments

-

40.1. "Why Develop a new ISA?" Rationale from Berkeley Group

+

39.1. "Why Develop a new ISA?" Rationale from Berkeley Group

We developed RISC-V to support our own needs in research and education, where our group is particularly interested in actual hardware @@ -20590,7 +20615,7 @@

40.1. "Why Develop

-

40.2. History from Revision 1.0 of ISA manual

+

39.2. History from Revision 1.0 of ISA manual

The RISC-V ISA and instruction-set manual builds upon several earlier projects. Several aspects of the supervisor-level machine and the @@ -20658,7 +20683,7 @@

40.2. History from Revision 1.

-

40.3. History from Revision 2.0 of ISA manual

+

39.3. History from Revision 2.0 of ISA manual

Multiple implementations of RISC-V processors have been completed, including several silicon fabrications, as shown in @@ -20840,7 +20865,7 @@

40.3. History from Revision 2.

-

40.4. Acknowledgments

+

39.4. Acknowledgments

Thanks to Christopher F. Batten, Preston Briggs, Christopher Celio, David Chisnall, Stefan Freudenberger, John Hauser, Ben Keller, Rishiyur @@ -20849,7 +20874,7 @@

40.4. Acknowledgments

-

40.5. History from Revision 2.1

+

39.5. History from Revision 2.1

Uptake of the RISC-V ISA has been very rapid since the introduction of the frozen version 2.0 in May 2014, with too much activity to record in @@ -20861,7 +20886,7 @@

40.5. History from Revision 2.1

-

40.6. Acknowledgments

+

39.6. Acknowledgments

Thanks to Scott Beamer, Allen J. Baum, Christopher Celio, David Chisnall, Paul Clayton, Palmer Dabbelt, Jan Gray, Michael Hamburg, and @@ -20869,18 +20894,18 @@

40.6. Acknowledgments

-

40.7. History from Revision 2.2

+

39.7. History from Revision 2.2

-

40.8. Acknowledgments

+

39.8. Acknowledgments

Thanks to Jacob Bachmeyer, Alex Bradbury, David Horner, Stefan O’Rear, and Joseph Myers for comments on the version 2.1 specification.

-

40.9. History for Revision 2.3

+

39.9. History for Revision 2.3

Uptake of RISC-V continues at a breakneck pace.

@@ -20898,7 +20923,7 @@

40.9. History for Revision 2.3

-

40.10. Funding

+

39.10. Funding

Development of the RISC-V architecture and implementations has been partially funded by the following sponsors.

@@ -21333,7 +21358,7 @@

A.3.2. Load value axiom

Consider the Table 33. When running this program on an implementation with -store buffers, it is possible to arrive at the final outcome a0=1, a1=0, a2=1, a3=0 as follows:

+store buffers, it is possible to arrive at the final outcome a0=1, a1=0, a2=1, a3=0 as follows:

@@ -21467,7 +21492,7 @@

A.3.2. Load value axiom

(e) precedes (f): by rule X

  • -

    (f) precedes (h): by rule 4]

    +

    (f) precedes (h): by rule 4

  • (h) precedes (a): by the load value axiom, as above.

    @@ -25339,7 +25364,7 @@

    B.3.5. Transitions

    generate the new system state.

    -
    Fetch instruction
    +
    B.3.5.1. Fetch instruction

    A possible program-order-successor of instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d can be fetched from address loc if:

    @@ -25406,7 +25431,7 @@
    Fetch instruction
    -
    Initiate memory load operations
    +
    B.3.5.2. Initiate memory load operations

    An instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Load_mem(kind, address, size, load_continuation)) can always initiate the @@ -25451,7 +25476,7 @@

    Initiate memory load operations
    -
    Satisfy memory load operation by forwarding from unpropagated stores
    +
    B.3.5.3. Satisfy memory load operation by forwarding from unpropagated stores

    For a non-AMO load instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Pending_mem_loads(load_continuation), and a memory load operation @@ -25605,7 +25630,7 @@

    Satisfy memory load operation by forwarding from unpr
    -
    Satisfy memory load operation from memory
    +
    B.3.5.4. Satisfy memory load operation from memory

    For an instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d of a non-AMO load instruction or an AMO instruction in the context of the Satisfy, commit and propagate operations of an AMO transition, @@ -25635,7 +25660,7 @@

    Satisfy memory load operation from memory
    -
    Complete load operations
    +
    B.3.5.5. Complete load operations

    A load instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Pending_mem_loads(load_continuation) can be completed (not to be @@ -25648,7 +25673,7 @@

    Complete load operations
    -
    Early sc fail
    +
    B.3.5.6. Early sc fail

    An sc instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Early_sc_fail(res_continuation)) can always be made to fail. @@ -25657,7 +25682,7 @@

    Early sc fail
    -
    Paired sc
    +
    B.3.5.7. Paired sc

    An sc instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Early_sc_fail(res_continuation)) can continue its (potentially @@ -25666,7 +25691,7 @@

    Paired sc
    -
    Initiate memory store operation footprints
    +
    B.3.5.8. Initiate memory store operation footprints

    An instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Store_ea(kind, address, size, next_state)) can always announce its pending memory @@ -25714,7 +25739,7 @@

    Initiate memory store operation footprints
    -
    Instantiate memory store operation values
    +
    B.3.5.9. Instantiate memory store operation values

    An instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Store_memv(mem_value, store_continuation)) can always @@ -25735,7 +25760,7 @@

    Instantiate memory store operation values
    -
    Commit store instruction
    +
    B.3.5.10. Commit store instruction

    An uncommitted instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d of a non-sc store instruction or an sc instruction in the context of the Commit and propagate store operation of an sc @@ -25812,7 +25837,7 @@

    Commit store instruction
    -
    Propagate store operation
    +
    B.3.5.11. Propagate store operation

    For a committed instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Pending_mem_stores(store_continuation), and an unpropagated memory @@ -25888,7 +25913,7 @@

    Propagate store operation
    -
    Commit and propagate store operation of an sc
    +
    B.3.5.12. Commit and propagate store operation of an sc

    An uncommitted sc instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d, from hart stem af98b3d273f2fa50eec5140dd48d1eae, in state Pending_mem_stores(store_continuation), with @@ -25935,7 +25960,7 @@

    Commit and propagate store operation of an sc
    -
    Late sc fail
    +
    B.3.5.13. Late sc fail

    An sc instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Pending_mem_stores(store_continuation), that has not propagated its @@ -25964,7 +25989,7 @@

    Late sc fail
    -
    Complete store operations
    +
    B.3.5.14. Complete store operations

    A store instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Pending_mem_stores(store_continuation), for which all the memory store @@ -25975,7 +26000,7 @@

    Complete store operations
    -
    Satisfy, commit and propagate operations of an AMO
    +
    B.3.5.15. Satisfy, commit and propagate operations of an AMO

    An AMO instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Pending_mem_loads(load_continuation) can perform its memory access if @@ -26043,7 +26068,7 @@

    Satisfy, commit and propagate operations of an AMO
    -
    Commit fence
    +
    B.3.5.16. Commit fence

    A fence instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Fence(kind, next_state)) can be committed if:

    @@ -26079,7 +26104,7 @@
    Commit fence
    -
    Register read
    +
    B.3.5.17. Register read

    An instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Read_reg(reg_name, read_cont)) can do a register read of @@ -26106,7 +26131,7 @@

    Register read
    -
    Register write
    +
    B.3.5.18. Register write

    An instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Write_reg(reg_name, reg_value, next_state)) can always do a @@ -26131,7 +26156,7 @@

    Register write
    -
    Pseudocode internal step
    +
    B.3.5.19. Pseudocode internal step

    An instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Internal(next_state)) can always do that pseudocode-internal @@ -26140,7 +26165,7 @@

    Pseudocode internal step
    -
    Finish instruction
    +
    B.3.5.20. Finish instruction

    A non-finished instruction instance stem 6ac91b4e7dd35551c6ea477deba5f82d in state Plain(Done) can be finished if:

    @@ -26365,7 +26390,7 @@

    Bibliography

    diff --git a/docs/06_cv64a6_mmu/config/config.adoc b/docs/06_cv64a6_mmu/config/config.adoc index b9040b7532..c75aab3266 100644 --- a/docs/06_cv64a6_mmu/config/config.adoc +++ b/docs/06_cv64a6_mmu/config/config.adoc @@ -8,6 +8,7 @@ :SV: SV0 :RVZicfilp: false :RVZicfiss: false +:RVZpm: false :RVZsmstateen: false :RVZsmcsrind-RVZsscsrind: false :RVZsmepmp: false diff --git a/docs/riscv-isa/riscv-isa-manual b/docs/riscv-isa/riscv-isa-manual index 5ddbdd678a..2c07aa2bcc 160000 --- a/docs/riscv-isa/riscv-isa-manual +++ b/docs/riscv-isa/riscv-isa-manual @@ -1 +1 @@ -Subproject commit 5ddbdd678a03dc1d7801d4ef5bb143375cae5a43 +Subproject commit 2c07aa2bcc02fd5fb2e53e42a32dc62a3eb0aa62 diff --git a/docs/riscv-isa/src/colophon.adoc b/docs/riscv-isa/src/colophon.adoc index c34a2c2dc1..d05ee78be3 100644 --- a/docs/riscv-isa/src/colophon.adoc +++ b/docs/riscv-isa/src/colophon.adoc @@ -7,7 +7,7 @@ This document describes the RISC-V unprivileged architecture tailored for OpenHW Group {ohg-config}. -[.big]*_Preface to Document Version 20240801_* +[.big]*_Preface to Document Version 20241017_* This document describes the RISC-V unprivileged architecture. diff --git a/docs/riscv-isa/src/counters.adoc b/docs/riscv-isa/src/counters.adoc index b9fb8a3cc9..ec0676006e 100644 --- a/docs/riscv-isa/src/counters.adoc +++ b/docs/riscv-isa/src/counters.adoc @@ -27,7 +27,7 @@ Some execution environments might prohibit access to counters, for example, to impede timing side-channel attacks. ==== -include::images/wavedrom/counters-diag.adoc[] +include::images/wavedrom/counters-diag.edn[] For base ISAs with XLEN≥64, CSR instructions can access diff --git a/docs/riscv-isa/src/machine.adoc b/docs/riscv-isa/src/machine.adoc index 6bb419d60f..f99c225a40 100644 --- a/docs/riscv-isa/src/machine.adoc +++ b/docs/riscv-isa/src/machine.adoc @@ -300,7 +300,7 @@ endif::[] //image::png/mvendorid.png[align="center"] .Vendor ID register (`mvendorid`) -include::images/bytefield/mvendorid.adoc[] +include::images/bytefield/mvendorid.edn[] ifdef::archi-default[] JEDEC manufacturer IDs are ordinarily encoded as a sequence of one-byte @@ -348,7 +348,7 @@ of the hart supplied to CVA6, 0x3. endif::[] .Machine Architecture ID (`marchid`) register -include::images/bytefield/marchid.adoc[] +include::images/bytefield/marchid.edn[] ifdef::archi-default[] Open-source project architecture IDs are allocated globally by RISC-V @@ -410,7 +410,7 @@ processor itself and not any surrounding system. endif::[] .Machine Implementation ID (`mimpid`) register -include::images/bytefield/mimpid.adoc[] +include::images/bytefield/mimpid.edn[] ifeval::[{note} == true] [NOTE] @@ -443,7 +443,7 @@ Hart ID is zero. endif::[] .Hart ID (`mhartid`) register -include::images/bytefield/mhartid.adoc[] +include::images/bytefield/mhartid.edn[] ifeval::[{note} == true] [NOTE] @@ -487,13 +487,13 @@ endif::[] ifdef::archi-default,XLEN-32[] [[mstatusreg-rv32]] .Machine-mode status (`mstatus`) register for RV32 -include::images/wavedrom/mstatusreg-rv321.adoc[] +include::images/wavedrom/mstatusreg-rv321.edn[] endif::[] ifdef::archi-default,XLEN-64[] [[mstatusreg]] .Machine-mode status (`mstatus`) register for RV64 -include::images/wavedrom/mstatusreg.adoc[] +include::images/wavedrom/mstatusreg.edn[] endif::[] ifdef::archi-default[] @@ -509,7 +509,7 @@ endif::[] ifdef::archi-default,XLEN-32[] [[mstatushreg]] .Additional machine-mode status (`mstatush`) register for RV32. -include::images/wavedrom/mstatushreg.adoc[] +include::images/wavedrom/mstatushreg.edn[] endif::[] [[privstack]] @@ -1606,7 +1606,7 @@ and a vector mode (MODE). .Encoding of mtvec MODE field. -include::images/bytefield/mtvec.adoc[] +include::images/bytefield/mtvec.edn[] ifdef::archi-default[] The `mtvec` register must always be implemented, but can contain a @@ -1774,7 +1774,7 @@ endif::[] ifdef::archi-default,RVS-true[] .Machine Exception Delegation (`medeleg`) register. -include::images/bytefield/medeleg.adoc[] +include::images/bytefield/medeleg.edn[] `medeleg` has a bit position allocated for every synchronous exception shown in <>, with the index of the @@ -1794,7 +1794,7 @@ endif::[] ifdef::archi-default,RVS-true[] .Machine Interrupt Delegation (`mideleg`) Register. -include::images/bytefield/mideleg.adoc[] +include::images/bytefield/mideleg.edn[] `mideleg` holds trap delegation bits for individual interrupts, with the layout of bits matching those in the `mip` register (i.e., STIP @@ -1833,10 +1833,10 @@ at the platform's discretion. endif::[] .Machine Interrupt-Pending (`mip`) register. -include::images/bytefield/mideleg.adoc[] +include::images/bytefield/mideleg.edn[] .Machine Interrupt-Enable (`mie`) register -include::images/bytefield/mideleg.adoc[] +include::images/bytefield/mideleg.edn[] ifdef::archi-default[] An interrupt _i_ will trap to M-mode (causing the privilege mode to @@ -1883,11 +1883,11 @@ formatted as shown in <> and <> respectively. [[mipreg-standard]] .Standard portion (bits 15:0) of `mip`. -include::images/bytefield/mipreg-standard.adoc[] +include::images/bytefield/mipreg-standard.edn[] [[miereg-standard]] .Standard portion (bits 15:0) of `mie`. -include::images/bytefield/miereg-standard.adoc[] +include::images/bytefield/miereg-standard.edn[] endif::[] ifeval::[{note} == true] @@ -2055,11 +2055,12 @@ formatted as shown in <> and <> respectively. [[mipreg-standard]] .Standard portion (bits 15:0) of `mip`. -include::images/bytefield/mipreg-standard.adoc[] +include::images/bytefield/mipreg-standard.edn[] [[miereg-standard]] .Standard portion (bits 15:0) of `mie`. -include::images/bytefield/miereg-standard.adoc[] +include::images/bytefield/miereg-standard.edn[] +endif::[] [{ohg-config}] Bits `mip`.MEIP and `mie`.MEIE are the interrupt-pending and @@ -2156,7 +2157,7 @@ endif::[] ifdef::archi-default,RVZsmcntrpmf-true[] .Hardware performance monitor counters. -include::images/bytefield/hpmevents.adoc[] +include::images/bytefield/hpmevents.edn[] The `mhpmcounters` are *WARL* registers that support up to 64 bits of precision on RV32 and RV64. @@ -2190,7 +2191,7 @@ these events is defined by the platform, but event 0 is defined to mean selector are read-only 0. .Hardware performance monitor counters. -include::images/bytefield/hpmevents.adoc[] +include::images/bytefield/hpmevents.edn[] endif::[] The `mhpmcounters` are *WARL* registers that support up to 64 bits of @@ -2224,7 +2225,7 @@ counters to the next-lower privileged mode. ifdef::archi-default,RVU-true[] .Counter-enable (`mcounteren`) register. -include::images/bytefield/counteren.adoc[] +include::images/bytefield/counteren.edn[] The settings in this register only control accessibility. The act of reading or writing this register does not affect the underlying @@ -2285,7 +2286,7 @@ endif::[] ==== Machine Counter-Inhibit (`mcountinhibit`) Register .Counter-inhibit `mcountinhibit` register -include::images/bytefield/counterinh.adoc[] +include::images/bytefield/counterinh.edn[] ifdef::archi-default,RVZsmcntrpmf-true[] The counter-inhibit register `mcountinhibit` is a 32-bit *WARL* register that @@ -2333,7 +2334,7 @@ machine-mode hart-local context space and swapped with a user register upon entry to an M-mode trap handler. .Machine-mode scratch register. -include::images/bytefield/mscratch.adoc[] +include::images/bytefield/mscratch.edn[] ifeval::[{note} == true] [NOTE] @@ -2394,7 +2395,7 @@ though it may be explicitly written by software. [[mepcreg]] .Machine exception program counter register. -include::images/bytefield/mepcreg.adoc[] +include::images/bytefield/mepcreg.edn[] [[mcause]] ==== Machine Cause (`mcause`) Register @@ -2413,7 +2414,7 @@ the possible machine-level exception codes. The Exception Code is a [[mcausereg]] .Machine Cause (`mcause`) register. -include::images/bytefield/mcausereg.adoc[] +include::images/bytefield/mcausereg.edn[] ifdef::archi-default,RVU-true[] Note that load and load-reserved instructions generate load exceptions, @@ -2539,6 +2540,9 @@ _Designated for platform use_ 0 + 0 + 0 + +0 + +0 + +0 + 0 |0 + 1 + @@ -2722,7 +2726,7 @@ particularly those with hardware page-table walkers. [[mtvalreg]] .Machine Trap Value (`mtval`) register. -include::images/bytefield/mtvalreg.adoc[] +include::images/bytefield/mtvalreg.edn[] If `mtval` is written with a nonzero value when a misaligned load or @@ -2815,7 +2819,7 @@ and their configuration. [[mconfigptrreg]] .Machine Configuration Pointer (`mconfigptr`) register. -include::images/bytefield/mconfigptrreg.adoc[] +include::images/bytefield/mconfigptrreg.edn[] The pointer alignment in bits must be no smaller than MXLEN: @@ -2863,7 +2867,7 @@ privileged than M. [[menvcfgreg]] .Machine environment configuration (`menvcfg`) register. -include::images/wavedrom/menvcfgreg.adoc[] +include::images/wavedrom/menvcfgreg.edn[] If bit FIOM (Fence of I/O implies Memory) is set to one in `menvcfg`, @@ -3001,9 +3005,7 @@ ifdef::archi-CVA6+RVU-true[] endif::[] ifdef::archi-default,RVU-true[] -The definition of the PMM field will be furnished by the forthcoming -Smnpm extension. Its allocation within `menvcfg` may change prior to the -ratification of that extension. +The definition of the PMM field is furnished by the Smnpm extension. endif::[] ifdef::archi-CVA6+RVU-true[] @@ -3076,19 +3078,15 @@ shown in <>, that controls security features. [[mseccfg]] .Machine security configuration (`mseccfg`) register. -include::images/wavedrom/mseccfg.adoc[] +include::images/wavedrom/mseccfg.edn[] -The definitions of the SSEED and USEED fields will be furnished by the -forthcoming entropy-source extension, Zkr. Their allocations within -`mseccfg` may change prior to the ratification of that extension. +The definitions of the SSEED and USEED fields are furnished by the +entropy-source extension, Zkr. -The definitions of the RLB, MMWP, and MML fields will be furnished by -the forthcoming PMP-enhancement extension, Smepmp. Their allocations -within `mseccfg` may change prior to the ratification of that extension. +The definitions of the RLB, MMWP, and MML fields are furnished by the +PMP-enhancement extension, Smepmp. -The definition of the PMM field will be furnished by the forthcoming -Smmpm extension. Its allocation within `mseccfg` may change prior to the -ratification of that extension. +The definition of the PMM field is furnished by the Smmpm extension. The Zicfilp extension adds the `MLPE` field in `mseccfg`. When `MLPE` field is 1, Zicfilp extension is enabled in M-mode. When the `MLPE` field is 0, the @@ -3141,10 +3139,10 @@ writing `mtimecmp`). The interrupt will only be taken if interrupts are enabled and the MTIE bit is set in the `mie` register. .Machine time register (memory-mapped control register). -include::images/bytefield/mtime.adoc[] +include::images/bytefield/mtime.edn[] .Machine time compare register (memory-mapped control register). -include::images/bytefield/mtimecmp.adoc[] +include::images/bytefield/mtimecmp.edn[] ifeval::[{note} == true] [NOTE] @@ -3228,7 +3226,7 @@ endif::[] ==== Environment Call and Breakpoint -include::images/wavedrom/mm-env-call.adoc[] +include::images/wavedrom/mm-env-call.edn[] ifdef::archi-default,RVU-true[] The ECALL instruction is used to make a request to the supporting @@ -3281,7 +3279,7 @@ not increment the `minstret` CSR. Instructions to return from trap are encoded under the PRIV minor opcode. -include::images/wavedrom/trap-return.adoc[] +include::images/wavedrom/trap-return.edn[] ifdef::archi-default,RVU-true[] To return after handling a trap, there are separate trap return @@ -3349,7 +3347,7 @@ cannot raise an illegal-instruction exception because TW=0 in `mstatus`, as described in <>. endif::[] -include::images/wavedrom/wfi.adoc[] +include::images/wavedrom/wfi.edn[] If an enabled interrupt is present or later becomes present while the hart is stalled, the interrupt trap will be taken on the following @@ -3444,7 +3442,7 @@ minimum required privilege mode, as do other SYSTEM instructions. [[customsys]] .SYSTEM instruction encodings designated for custom use. -include::images/bytefield/cust-sys-instr.adoc[] +include::images/bytefield/cust-sys-instr.edn[] [[reset]] === Reset @@ -3463,7 +3461,9 @@ the platform mandates a different reset value for some PMP registers’ A and L fields. If the hypervisor extension is implemented, the `hgatp`.MODE and `vsatp`.MODE fields are reset to 0. If the Smrnmi extension is implemented, the `mnstatus`.NMIE field is reset to 0. No - *WARL* field contains an illegal value. All other hart state is UNSPECIFIED. + *WARL* field contains an illegal value. If the Zicfilp extension is +implemented, the `mseccfg`.MLPE field is reset to 0. All other hart +state is UNSPECIFIED. The `mcause` values after reset have implementation-specific interpretation, but the value 0 should be returned on implementations @@ -3817,7 +3817,7 @@ Specific supported values for this PMA are represented by MAG__NN__, e.g., MAG16 indicates the misaligned atomicity granule is at least 16 bytes. The misaligned atomicity granule PMA applies only to AMOs, loads and stores -defined in the base ISAs, and loads and stores of no more than MXLEN bits +defined in the base ISAs, and loads and stores of no more than XLEN bits defined in the F, D, and Q extensions. For an instruction in that set, if all accessed bytes lie within the same misaligned atomicity granule, the instruction will not raise an exception for @@ -4145,11 +4145,11 @@ endif::[] ifdef::archi-default[] [[pmpcfg-rv32]] .RV32 PMP configuration CSR layout. -include::images/bytefield/pmp-rv32.adoc[] +include::images/bytefield/pmp-rv32.edn[] [[pmpcfg-rv64]] .RV64 PMP configuration CSR layout. -include::images/bytefield/pmp-rv64.adoc[] +include::images/bytefield/pmp-rv64.edn[] The PMP address registers are CSRs named `pmpaddr0`-`pmpaddr63`. Each @@ -4177,11 +4177,11 @@ endif::[] ifdef::archi-default[] [[pmpaddr-rv32]] .PMP address register format, RV32. -include::images/bytefield/pmpaddr-rv32.adoc[] +include::images/bytefield/pmpaddr-rv32.edn[] [[pmpaddr-rv64]] .PMP address register format, RV64. -include::images/bytefield/pmpaddr-rv64.adoc[] +include::images/bytefield/pmpaddr-rv64.edn[] endif::[] ifdef::archi-CVA6[] @@ -4201,7 +4201,7 @@ The 14 upper PMP configuration CSRs, `pmpcfg2`-`pmpcfg15`, are read-only zero. [[pmpcfg-rv32]] .RV32 PMP configuration CSR layout. -include::images/bytefield/pmp-rv32.adoc[] +include::images/bytefield/pmp-rv32.edn[] [{ohg-config}] The PMP address registers are CSRs named `pmpaddr0`-`pmpaddr63`. Each PMP address register encodes bits 33-2 of a 34-bit physical address for @@ -4212,7 +4212,7 @@ The 56 upper PMP address CSRs, `pmpaddr8`-`pmpaddr63`, are read-only zero. [[pmpaddr-rv32]] .PMP address register format, RV32. -include::images/bytefield/pmpaddr-rv32.adoc[] +include::images/bytefield/pmpaddr-rv32.edn[] endif::[] <> shows the layout of a PMP configuration @@ -4223,7 +4223,7 @@ W, and X fields form a collective *WARL* field for which the combinations with R [[pmpcfg]] .PMP configuration register format. -include::images/bytefield/pmpcfg.adoc[] +include::images/bytefield/pmpcfg.edn[] Attempting to fetch an instruction from a PMP region that does not have @@ -4240,7 +4240,6 @@ access-fault exception. The A field in a PMP entry's configuration register encodes the address-matching mode of the associated PMP address register. The encoding of this field is shown in <>. - When A=0, this PMP entry is disabled and matches no addresses. Two other address-matching modes are supported: naturally aligned power-of-2 regions (NAPOT), including the special case of naturally aligned diff --git a/docs/riscv-isa/src/priv-preface.adoc b/docs/riscv-isa/src/priv-preface.adoc index a687107be8..c971911fb3 100644 --- a/docs/riscv-isa/src/priv-preface.adoc +++ b/docs/riscv-isa/src/priv-preface.adoc @@ -6,24 +6,24 @@ This document describes the RISC-V privileged architecture tailored for OpenHW Group {ohg-config}. -[.big]*_Preface to Version 20240801_* +[.big]*_Preface to Version 20241017_* This document describes the RISC-V privileged architecture. This -release, version 20240801, contains the following versions of the RISC-V ISA +release, version 20241017, contains the following versions of the RISC-V ISA modules: [%autowidth,float="center",align="center",cols="^,<,^",options="header",] |=== |Module |Version |Status -|_Machine ISA_ + +|*Machine ISA* + *Smstateen Extension* + *Smcsrind/Sscsrind Extension* + *Smepmp* + *Smcntrpmf* + *Smrnmi Extension* + *Smcdeleg* + -_Smdbltrp_ + -_Supervisor ISA_ + +*Smdbltrp* + +*Supervisor ISA* + *Svade Extension* + *Svnapot Extension* + *Svpbmt Extension* + @@ -31,20 +31,22 @@ _Supervisor ISA_ + *Svadu Extension* + *Sstc* + *Sscofpmf* + -_Ssdbltrp_ + +*Ssdbltrp* + *Hypervisor ISA* + -_Shlcofideleg_ + +*Shlcofideleg* + *Svvptc* -|_1.13_ + +|*1.13* + +*1.0* + +*1.0* + +*1.0* + *1.0* + *1.0* + *1.0* + *1.0* + +*1.13* + *1.0* + *1.0* + -_1.0_ + -_1.13_ + *1.0* + *1.0* + *1.0* + @@ -52,20 +54,20 @@ _1.13_ + *1.0* + *1.0* + *1.0* + -_1.0_ + *1.0* + -_0.1_ + *1.0* -|_Draft_ + +|*Ratified* + +*Ratified* + +*Ratified* + +*Ratified* + +*Ratified* + *Ratified* + *Ratified* + *Ratified* + *Ratified* + *Ratified* + *Ratified* + -_Draft_ + -_Draft_ + *Ratified* + *Ratified* + *Ratified* + @@ -73,9 +75,7 @@ _Draft_ + *Ratified* + *Ratified* + *Ratified* + -_Draft_ + *Ratified* + -_Draft_ + *Ratified* |=== diff --git a/docs/riscv-isa/src/riscv-privileged.adoc b/docs/riscv-isa/src/riscv-privileged.adoc index 473a73dcf5..bc8d53217e 100644 --- a/docs/riscv-isa/src/riscv-privileged.adoc +++ b/docs/riscv-isa/src/riscv-privileged.adoc @@ -4,8 +4,8 @@ include::config.adoc[] = The RISC-V Instruction Set Manual for {ohg-config}: Volume II: Privileged Architecture include::../docs-resources/global-config.adoc[] :description: Volume II - Privileged Architecture -:revnumber: 20240801 -//:revremark: Pre-release version +:revnumber: 20241017 +:revremark: This document is in Ratified state. //development: assume everything can change //stable: assume everything could change //frozen: of you implement this version you assume the risk that something might change because of the public review cycle but we expect little to no change. @@ -15,7 +15,7 @@ include::../docs-resources/global-config.adoc[] :appendix-caption: Appendix :imagesdir: ../docs-resources/images :title-logo-image: image:risc-v_logo.png["RISC-V International Logo",pdfwidth=3.25in,align=center] -:page-background-image: image:draft.png[opacity=20%] +//:page-background-image: image:draft.png[opacity=20%] :title-page-background-image: image:ohg_logo.png[fit=none,pdfwidth=3.25in,position=top] //:title-page-background-image: none //:back-cover-image: image:backpage.png[opacity=25%] @@ -70,11 +70,11 @@ Avižienis, Jacob Bachmeyer, Allen J. Baum, Jonathan Behrens, Paolo Bonzini, Rus Christopher Celio, Chuanhua Chang, David Chisnall, Anthony Coulter, Palmer Dabbelt, Monte Dalrymple, Paul Donahue, Greg Favor, Dennis Ferguson, Marc Gauthier, Andy Glew, Gary Guo, Mike Frysinger, John Hauser, David Horner, Olof -Johansson, David Kruckemyer, Yunsup Lee, Daniel Lustig, Andrew Lutomirski, Prashanth Mundkur, +Johansson, David Kruckemyer, Yunsup Lee, Daniel Lustig, Andrew Lutomirski, Martin Maas, Prashanth Mundkur, Jonathan Neuschäfer, Rishiyur Nikhil, Stefan O'Rear, Albert Ou, John Ousterhout, David Patterson, Dmitri Pavlov, Kade Phillips, Josh Scheid, Colin Schmidt, Michael Taylor, Wesley Terpstra, Matt Thomas, Tommy Thorn, Ray -VanDeWalker, Megan Wachs, Steve Wallach, Andrew Waterman, Claire Wolf, +VanDeWalker, Megan Wachs, Steve Wallach, Andrew Waterman, Claire Wolf, Adam Zabrocki, and Reinoud Zandijk.._ _This document is released under a Creative Commons Attribution 4.0 International License._ @@ -106,6 +106,7 @@ include::sscofpmf.adoc[] include::hypervisor.adoc[] include::priv-cfi.adoc[] include::ssdbltrp.adoc[] +include::zpm.adoc[] include::priv-insns.adoc[] include::priv-history.adoc[] include::bibliography.adoc[] diff --git a/docs/riscv-isa/src/riscv-unprivileged.adoc b/docs/riscv-isa/src/riscv-unprivileged.adoc index c80307ef32..c9c5bb8861 100644 --- a/docs/riscv-isa/src/riscv-unprivileged.adoc +++ b/docs/riscv-isa/src/riscv-unprivileged.adoc @@ -4,7 +4,7 @@ include::config.adoc[] = The RISC-V Instruction Set Manual for {ohg-config}: Volume I - Unprivileged Architecture include::../docs-resources/global-config.adoc[] :description: Unprivileged Architecture -:revnumber: 20240801 +:revnumber: 20241017 //:revremark: Pre-release version :colophon: :preface-title: Preamble @@ -30,6 +30,7 @@ include::../docs-resources/global-config.adoc[] :example-caption: Example :listing-caption: Listing :sectnums: +:sectnumlevels: 5 :toc: left :toclevels: 5 :source-highlighter: pygments @@ -197,7 +198,6 @@ include::zfinx.adoc[] include::c-st-ext.adoc[] include::zc.adoc[] include::b-st-ext.adoc[] -include::j-st-ext.adoc[] include::p-st-ext.adoc[] include::v-st-ext.adoc[] include::scalar-crypto.adoc[] diff --git a/docs/riscv-isa/src/rv64.adoc b/docs/riscv-isa/src/rv64.adoc index 05a4e3bf90..38c52e66c7 100644 --- a/docs/riscv-isa/src/rv64.adoc +++ b/docs/riscv-isa/src/rv64.adoc @@ -46,7 +46,7 @@ endif::[] ==== Integer Register-Immediate Instructions -include::images/wavedrom/rv64i-base-int.adoc[] +include::images/wavedrom/rv64i-base-int.edn[] [[rv64i-base-int]] //.RV64I register-immediate instructions @@ -57,7 +57,7 @@ immediate to register _rs1_ and produces the proper sign extension of a writes the sign extension of the lower 32 bits of register _rs1_ into register _rd_ (assembler pseudoinstruction SEXT.W). -include::images/wavedrom/rv64i-slli.adoc[] +include::images/wavedrom/rv64i-slli.edn[] [[rv64i-slli]] //.RV64I register-immediate (descr ADDIW) instructions @@ -74,7 +74,7 @@ copied into the vacated upper bits). (((RV64I, SRLIW))) (((RV64I, RV64I-only))) -include::images/wavedrom/rv64i-slliw.adoc[] +include::images/wavedrom/rv64i-slliw.edn[] [[rv64i-slliw]] SLLIW, SRLIW, and SRAIW are RV64I-only instructions that are analogously @@ -91,7 +91,7 @@ are marked as reserved. This is a backwards-compatible change. ==== endif::[] -include::images/wavedrom/rv64_lui-auipc.adoc[] +include::images/wavedrom/rv64-lui-auipc.edn[] [[rv64_lui-auipc]] //.RV64I register-immediate (descr) instructions @@ -119,7 +119,7 @@ endif::[] ==== Integer Register-Register Operations //this diagramdoesn't match the tex specification -include::images/wavedrom/rv64i_int-reg-reg.adoc[] +include::images/wavedrom/rv64i-int-reg-reg.edn[] [[int_reg-reg]] //.RV64I integer register-register instructions @@ -147,7 +147,7 @@ results to 64 bits. The shift amount is given by _rs2[4:0]_. RV64I extends the address space to 64 bits. The execution environment will define what portions of the address space are legal to access. -include::images/wavedrom/load_store.adoc[] +include::images/wavedrom/load-store.edn[] [[load_store]] //.Load and store instructions diff --git a/docs/riscv-isa/src/supervisor.adoc b/docs/riscv-isa/src/supervisor.adoc index f1e16d5d51..697cbf541f 100644 --- a/docs/riscv-isa/src/supervisor.adoc +++ b/docs/riscv-isa/src/supervisor.adoc @@ -908,17 +908,12 @@ enabled. endif::[] ifdef::archi-default[] -The definition of the CBZE field will be furnished by the forthcoming -Zicboz extension. Its allocation within `senvcfg` may change prior to -the ratification of that extension. +The definition of the CBZE field is furnished by the Zicboz extension. -The definitions of the CBCFE and CBIE fields will be furnished by the -forthcoming Zicbom extension. Their allocations within `senvcfg` may -change prior to the ratification of that extension. +The definitions of the CBCFE and CBIE fields are furnished by the Zicbom +extension. -The definition of the PMM field will be furnished by the forthcoming -Ssnpm extension. Its allocation within `senvcfg` may change prior to the -ratification of that extension. +The definition of the PMM field is furnished by the Ssnpm extension. The Zicfilp extension adds the `LPE` field in `senvcfg`. When the `LPE` field is set to 1, the Zicfilp extension is enabled in VU/U-mode. When the `LPE` field is @@ -1646,8 +1641,9 @@ Two schemes to manage the A and D bits are defined: architecturally. However, updates to the D bit, resulting from an explicit store, must be exact (i.e., non-speculative), and observed in program order by the local hart. When two-stage address translation is - active, updates of the D bit in G-stage PTEs may be performed as a - result of speculative updates of the A bit in VS-stage PTEs. + + active, updates to the D bit in G-stage PTEs may be performed by an + implicit access to a VS-stage PTE, if the G-stage PTE provides write + permission, before any speculative access to the VS-stage PTE. + + The PTE update must appear in the global memory order before the memory access that caused the PTE update and before any subsequent @@ -2478,6 +2474,11 @@ Second, if `vsatp`.MODE is not equal to zero, non-zero VS-stage PTE PBMT bits override the intermediate attributes to produce the final set of attributes used by accesses to the page in question. Otherwise, the intermediate attributes are used as the final set of attributes. + +NOTE: These final attributes apply to implicit and explicit accesses that +are subject to both stages of address translation. +For accesses that are not subject to the first stage of address translation, +e.g. VS-stage page-table accesses, the intermediate attributes apply instead. endif::[] ifdef::archi-default[] diff --git a/docs/riscv-isa/src/zpm.adoc b/docs/riscv-isa/src/zpm.adoc new file mode 100644 index 0000000000..9102f56c31 --- /dev/null +++ b/docs/riscv-isa/src/zpm.adoc @@ -0,0 +1,6 @@ +[[Zpm]] +== Pointer Masking Extensions, Version 1.0.0 + +ifeval::[{RVZpm} == false] +{ohg-config}: These extensions are not supported. +endif::[]
    • Table 33. A store buffer forwarding litmus test (outcome permitted)