Skip to content

Commit

Permalink
Fix reversed T and B fields in the capability encoding diagram. (#38)
Browse files Browse the repository at this point in the history
There was an inconsistency between the Sail implementation and this
document about the locations of the T and B fields in the capability
encoding.  The document had the T and B fields swapped compared to the
Sail (which matches the Ibex implementation) so we treat the Sail as
canonical and update the document to match i.e. B is in bits 0 to 8 of
the metadata word and T is in 9 to 17.

Also fix a minor typo in description of R bit.

Co-authored-by: Robert Norton <[email protected]>
  • Loading branch information
rmn30 and ronorton authored Feb 23, 2024
1 parent 0185917 commit 7490c42
Show file tree
Hide file tree
Showing 2 changed files with 8 additions and 4 deletions.
3 changes: 3 additions & 0 deletions archdoc/chap-changes.tex
Original file line number Diff line number Diff line change
Expand Up @@ -22,5 +22,8 @@ \chapter{Version history}
If either of the two least significant bits of \MTCC{}.\caddress{} is set on write then they are cleared and the tag is cleared.
This simplifies both ISA and hardware and avoids potential violations of capability monotonicity due to \asm{mtvec} and \asm{mepc} legalization.
vectored interrupt mode is explicitly unsupported.
\item[\ghpr{38}] Fix reversed T and B fields in the capability encoding diagram (\cref{fig:capformat}).
There was an inconsistency between the Sail implementation and this document about the locations of the T and B fields in the capability encoding.
The document had the T and B fields swapped compared to the Sail (which matches the Ibex implementation) so we treat the Sail as canonical and update the document to match i.e. B is in bits 0 to 8 of the metadata word and T is in 9 to 17.
\end{description}
\end{description}
9 changes: 5 additions & 4 deletions archdoc/chap-cheri-riscv.tex
Original file line number Diff line number Diff line change
Expand Up @@ -276,17 +276,18 @@ \section{Capability encoding}
\begin{figure}
\begin{bytefield}[bitwidth=\linewidth/32]{32}
\bitheader[endianness=big]{0,8,9,17,18,21,22,24,25,31} \\
\bitbox{1}{R} & \bitbox{6}{$p$'6} & \bitbox{3}{otype'3} & \bitbox{4}{E'4} & \bitbox{9}{B'9} & \bitbox{9}{T'9} \\
\bitbox{1}{R} & \bitbox{6}{$p$'6} & \bitbox{3}{otype'3} & \bitbox{4}{E'4} & \bitbox{9}{T'9} & \bitbox{9}{B'9} \\
\bitbox[lrb]{32}{$a$'32}
\end{bytefield}
\begin{description}
\item[R] a reserved bit, which is zero in the root capabilities (and hence all tagged capabilities), but may be set if untagged data is loaded into a register.
In this case its value must be preserved. This is very important because memory copies are performed with capability load a store instructions in order to preserve the tag on any capabilities present, meaning these instructions must also faithfully copy arbitrary untagged data.
\item[R] a reserved bit. This is zero in the root capabilities (and hence all tagged capabilities), but may be set if untagged data is loaded into a register.
In this case its value must be preserved.
This is important because memory copies are performed with capability load and store instructions in order to preserve the tag on any capabilities present, meaning these instructions must also faithfully copy arbitrary untagged data.
\item[p] a 6-bit compressed permissions field (see \cref{sec:perms})
\item[otype] a 3-bit `object type' used for sealing capabilities (see \cref{sec:sealing})
\item[E] a 4-bit exponent used for the bounds encoding (see \cref{sec:bounds})
\item[B] a 9-bit base used for the bounds encoding (see \cref{sec:bounds})
\item[T] a 9-bit top used in the bounds encoding (see \cref{sec:bounds})
\item[B] a 9-bit base used for the bounds encoding (see \cref{sec:bounds})
\item[a] the 32-bit address of the capability
\end{description}
\caption{\label{fig:capformat}Capability format}
Expand Down

0 comments on commit 7490c42

Please sign in to comment.