typos and minor fixes (#409)

I'll leave this one open for a while as we are bound to spot more
problems

src/attributes.adoc

@@ -79,7 +79,10 @@ endif::[]
 :cap_rv32_mw_width:    10
 :cap_rv64_mw_width:    14
 :cap_rv32_perms_width:  5
+//including Zcherilevels, 6 without
 :cap_rv64_perms_width:  6
+//CL is not a permission, so 8 not 9
+:cap_rv64_perms_levels_width:  8
 :cap_rv32_addr_width:  32
 :cap_rv64_addr_width:  64
 :cap_rv32_exp_width:    5

src/cap-description.adoc

@@ -169,6 +169,8 @@ Therefore, it is only possible to encode a subset of all combinations.
 ^| 64    | {cap_rv64_perms_width} | Separate bits for each architectural permission.
 |==============================================================================
 
+NOTE: if {cheri_levels_ext_name} is supported then there are {cap_rv64_perms_levels_width} architectural permission bits.
+
 For MXLEN=32, the permissions encoding is split into four quadrants.
 The quadrant is taken from bits [4:3] of the permissions encoding.
 The meaning for bits [2:0] are shown in <<cap_perms_encoding32>> for each quadrant.
@@ -225,8 +227,8 @@ reserved values as if it were 0b00000 (no permissions). Future extensions may as
 meanings to the reserved bit patterns, in which case <<GCPERM>> is allowed to report a
 non-zero value.
 
-A {cap_rv64_perms_width}-bit vector encodes the permissions when MXLEN=64. In
-this case, there is a bit per permission as shown in
+A {cap_rv64_perms_width}-bit vector encodes the permissions when MXLEN=64 ({cap_rv64_perms_levels_width}-bit if {cheri_levels_ext_name} is supported).
+In this case, there is a bit per permission as shown in
 xref:cap_perms_encoding64[xrefstyle=short]. A permission is granted if its
 corresponding bit is set, otherwise the capability does not grant that
 permission.

src/img/acperm_bit_field.edn

@@ -25,7 +25,7 @@
 (draw-box "1"         {:span 1 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})
-(draw-box "8"         {:span 6 :borders {}})
+(draw-box "10-SDPLEN" {:span 6 :borders {}})
 (draw-box "SDPLEN"    {:span 4 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})
 (draw-box "1"         {:span 1 :borders {}})

src/insns/acperm_32bit.adoc

@@ -70,6 +70,8 @@ include::../img/acperm_bit_field.edn[]
 
 NOTE: The <<el_perm,EL>>, <<sl_perm,SL>> and <<section_cap_level,CL>> fields are only defined if the implementation supports <<section_ext_cheri_levels,{cheri_levels_ext_name}>>.
 
+NOTE: Even though being included here <<section_cap_level,CL>> is not considered an architectural permission.
+
 Exceptions::
 include::require_cre.adoc[]
 

src/insns/hypv-virt-loadx.adoc

@@ -5,21 +5,19 @@
 
 See <<HLVX_WU>>.
 
-<<<
-
 [#HLVX_WU,reftext="HLVX.WU"]
 ==== HLVX.WU
 
 Synopsis::
 Hypervisor virtual machine load from executable memory
 
 {cheri_cap_mode_name} Mnemonics::
-`hlv.hu rd, cs1` +
-`hlv.wu rd, cs1`
+`hlvx.hu rd, cs1` +
+`hlvx.wu rd, cs1`
 
 {cheri_int_mode_name} Mnemonics::
-`hlv.hu rd, rs1` +
-`hlv.wu rd, rs1`
+`hlvx.hu rd, rs1` +
+`hlvx.wu rd, rs1`
 
 Encoding::
 include::wavedrom/hypv-virt-loadx.adoc[]

src/insns/modesw_32bit.adoc

@@ -24,7 +24,7 @@ Set the hart's current CHERI execution mode in <<pcc>>.
 * MODESW.INT: If the current mode in <<pcc>> is {cheri_cap_mode_name} ({CAP_MODE_VALUE}), then the <<m_bit>> in <<pcc>> is set to {cheri_int_mode_name} ({INT_MODE_VALUE}). Otherwise no effect.
 
 NOTE: Implementations may optionally support executing <<MODESW_CAP>> and <<MODESW_INT>> from the
-program buffer while in debug mode. If supported them the <<m_bit>> in
+program buffer while in debug mode. If supported then the <<m_bit>> in
 <<dinfc>> is set accordingly and used to control which mode to enter next time debug
 mode is entered. The CHERI execution mode is only controlled by the <<m_bit>>
 of <<dinfc>> in debug mode.

src/level-ext.adoc

@@ -100,7 +100,7 @@ endif::[]
 
 [#section_cap_level_change]
 === Changing capability levels and permissions
-While capability levels are conceptually a label on the capability rather than a permission granted by the capability, they are adjusted using the <<ACPERM>> instruction.
+While capability levels (<<section_cap_level,CL>>) are conceptually a label on the capability rather than a permission granted by the capability, they are adjusted using the <<ACPERM>> instruction.
 This avoids the need for a dedicated instruction and allows reducing the level and removing <<el_perm>> in a single instruction.
 
 <<<

src/system.adoc

@@ -5,12 +5,12 @@ CHERI processors need memory systems which support the capability validity tags
 
 There are, or will soon be, a wide range of CHERI systems in existence from tiny IoT devices up to server chips.
 
-There are two types of bus connections used in chips which contain CHERI CPUs:
+There are two types of bus connections used in SoCs which contain CHERI CPUs:
 
-. Tag-aware busses, where the bus protocol is extended to carry the tag along with the data.  This is typically done using a user defined bit in the protocol.
+. Tag-aware busses, where the bus protocol is extended to carry the tag along with the data.  This is typically done using user defined bits in the protocol.
 .. These busses will read tags from memory (if tags are present in the target memory) and return them to the requestor.
 .. These busses will write the tag to memory as an extension of the data write.
-. Non-tag aware busses, i.e. normal non-CHERI aware busses.
+. Non-tag aware busses, i.e. current non-CHERI aware busses.
 .. Reads of tagged memory will not read the tag.
 .. Writes to tagged memory will clear the tag of any CLEN-aligned CLEN-wide memory location where any byte matches the memory write.
 

src/tid-ext.adoc

@@ -7,7 +7,7 @@ software compartmentalization of CHERI programs.
 
 === Control and Status Registers (CSRs)
 
-{tid_ext_name} adds two new CSRs to implement a trusted thread
+{tid_ext_name} adds new CSRs to implement a trusted thread
 identifier (TID) used in compartmentalization. These CSRs are listed in
 xref:tid-mcsrnames-added[xrefstyle=short],
 xref:tid-scsrnames-added[xrefstyle=short],