Doc cleanups

doc/dev/ref-manual.md

@@ -91,14 +91,9 @@ Any memory that needs to be revocable must have one revocation tag per 32 bits.
 
 ### Capability tags
 
-All capability tags live in SRAM.
-All SRAM that is allocated for code and data will have corresponding capability tags.
-Any data stored to HyperRAM and flash are not expected to be tagged.
-Since capability tags are out of band information and do not need to be memory mapped, we can store these within the error correction bits that are available on the FPGA's memory.
-
+All of SRAM and 1 MiB of HyperRAM have corresponding capability tags.
+We envision code and read-only data to live in HyperRAM, while the stack and the heap live in SRAM.
 We envision that code can live in HyperRAM with an instruction cache for improved performance.
-However, this does require code to be able to live in untagged memory.
-This should be fine as CHERI capabilities are derived and manipulated at runtime, but does require toolchain changes to LLVM and the corresponding RTOS.
 
 ### Revocation tags
 
@@ -109,7 +104,7 @@ This is a temporary step as the revocation engine scans through memory to invali
 Once the complete memory is scanned, the revocation bit can be unset and the memory can be reused.
 
 In Sonata, the revocation tags only cover a subset of mapped memory.
-They should apply to memory regions that are most likely to be used as heap, it is likely this will cover all of internal SRAM and some of HyperRAM.
+They apply to memory regions that are most likely to be used as heap, it covers all of internal SRAM but no HyperRAM.
 Unlike capability tags, revocation tags need to be memory mapped so the memory allocator can manipulate them.
 
 In CHERIoT Ibex the size of memory allocated for this is defined by `TSMapSize` which indicates how many 32-bit words can be used for revocation bits.
@@ -119,16 +114,16 @@ In CHERIoT Safe the size of the revocation tag memory is 16 KiB.
 ### List of SRAM blocks
 
 Here's a list of blocks by size that we need to allocate in SRAM.
-The XC7A35T has 100 blocks of 18 kilobit block RAM, [see datasheet](https://docs.xilinx.com/v/u/en-US/ds180_7Series_Overview).
-In total that gives use 225 KiB of block RAM, but we may not efficiently map onto 18 kilobit blocks and thus lose some memory.
-The block RAM usage in the table below was calculated using Vivado 2023.2's block memory generator.
+The XC7A50T has 150 blocks of 18 kilobit block RAM, [see datasheet](https://docs.xilinx.com/v/u/en-US/ds180_7Series_Overview).
+In total that gives use 337 KiB of block RAM, but we may not efficiently map onto 18 kilobit blocks and thus lose some memory.
+The block RAM usage in the table below was calculated using Vivado 2024.1's block memory generator.:
 
 | Type                   | Size    | Width | Depth  | RAM Blocks |
 |------------------------|---------|-------|--------|------------|
 | Internal memory        | 128 KiB |    33 | 32,768 |         60 |
-| Revocation tags        |  16 KiB |    32 |  4,096 |          8 |
-| RAM capability tags    |  32 KiB |    32 |  8,192 |         15 |
+| Revocation tags        |   2 KiB |    32 |    512 |          1 |
+| RAM capability tags    |  36 KiB |    32 |  9,216 |         18 |
 | Instruction cache data |   4 KiB |    64 |    512 |          2 |
 | Instruction cache tags |   1 KiB |    22 |    512 |          1 |
-| Total                  | 181 KiB |       |        |         86 |
-| Available              | 225 KiB |       |        |        100 |
+| Total                  | 171 KiB |       |        |         82 |
+| Available              | 337 KiB |       |        |        150 |

util/templates/pinmux.md.tpl

@@ -8,7 +8,7 @@ All selectors are byte addressable, this means that you can write four selectors
 
 There are output pin selectors, which select which block output is connected to a particular FPGA pin.
 The selector is one-hot, so you need to write `8'b100` if you want to select input 3 for example.
-The default value for all of these selectors is `'b10`.
+The default value for all of these selectors is `'b10`. As a consequence, you will need to use the pinmux before attempting use the additional headers as GPIO (e.g. the Raspberry Pi header's GPIO).
 
 | Address | Pin output | Possible block outputs |
 |---------|------------|------------------------|

util/top_gen.py

@@ -1,4 +1,4 @@
-#!/usr/bin/env python3.10
+#!/usr/bin/env python3
 # Copyright lowRISC contributors
 # Licensed under the Apache License, Version 2.0, see LICENSE for details.
 # SPDX-License-Identifier: Apache-2.0