minor clarifications

src/cap-description.adoc

@@ -349,6 +349,12 @@ Decoding the bounds:
 top:    t = { a[XLENMAX - 1:E + MW] + ct, T[MW - 1:0]    , {E{1'b0}} }
 base:   b = { a[XLENMAX - 1:E + MW] + cb, B[MW - 1:0]    , {E{1'b0}} }
 ```
+NOTE: The representable range
+ is defined by the space beneath the bottom address bit (`a[E + MW]`)
+ in the expression above. If the capability address changes causing that address bit
+ to change, then the representable range is violated and so the tag will be cleared
+ by an instruction such as <<CINCOFFSET>>. This is represented by a range
+ of `s=2^E+MW^` in xref:cap_bounds_map[xrefstyle=short].
 
 The corrections c~t~ and c~b~ are calculated as as shown below using the
 definitions in xref:cap_encoding_ct[xrefstyle=short] and

src/riscv-integration.adoc

@@ -1013,6 +1013,8 @@ Unlike machine and supervisor level CSRs, {cheri_base_ext_name} does not require
 The <<pcc>> is made visible in a CSR. This provides access to an
 <<infinite-cap>> capability while in debug mode without executing <<AUIPCC>>.
 
+<<pcc>> resets to the <<infinite-cap>> with the address field set to the core boot address.
+
 NOTE: It is common for implementations to not allow executing *pc* relative
 instructions, such as <<AUIPC>> or <<JAL>>, in debug mode.
 

src/tables.adoc

@@ -99,6 +99,8 @@ include::generated/csr_alias_action_table_body.adoc[]
  in within bounds of the capability written to `Xtvecc`. The check on writing
  must include the lowest (0 offset) and highest possible offset (e.g. 64 * XLENMAX bits where HICAUSE=16).
 
+NOTE: _XLEN writing_ is only available if {cheri_mode_ext_name} is implemented.
+
 NOTE: Implementations which allow misa.C to be writable need to legalise *Xepcc*
  on _reading_ if the misa.C value has changed since the value was written as this
  can cause the read value of bit [1] to change state.