MLBEDSW-3938: Describe internal-default CLI value2.1.0.rc2

 - Updated system config and memory mode CLI options
 - Fixed some formatting problems in other markdown files

Signed-off-by: Tim Hall <tim.hall@arm.com>
Change-Id: If0fc2989538f372bfb6d6370565e940d132ca546

3 files changed, 52 insertions, 38 deletions

diff --git a/DEBUG_DB.md b/DEBUG_DB.md
index 2b530c5..7522ad4 100644
--- a/DEBUG_DB.md
+++ b/DEBUG_DB.md
@@ -1,36 +1,36 @@
-# Debug database
+# Vela Debug Database
 
 The purpose of the debug database is to track operator transformations during
-the optimisation process of Vela. This is later correlated with the trace
+the optimisation process of Vela.  This is later correlated with the trace
 output of the model, externally, to determine the runtime of the original layer
-operators. Standalone, the debug database can be used in order to give a brief
+operators.  Standalone, the debug database can be used in order to give a brief
 overview of how the operators in the network change throughout the optimisation
-process. This document gives an overview of the structure of the database and
+process.  This document gives an overview of the structure of the database and
 its outputs, to help parsing of the generated data in a debug procedure.
 
-# Contents
+## Contents
 
 While processing, Vela maintains information about operator substitutions and
-command generation in its internal Debug Database. The database tracks the data
+command generation in its internal Debug Database.  The database tracks the data
 transformations through the following states:
 
 - Creation of Source operators - these operators are created from the source
-representation,  in this case the original TFLite file.
+  representation, in this case the original TFLite file
 - Creation of Optimised operators - these are the operators that result from
- optimising the source operators. They may be the source operators repeated,
-or substitute operators inserted by the optimiser.
+  optimising the source operators.  They may be the source operators repeated,
+  or substitute operators inserted by the optimiser
 - Creation of Queue commands - these are the register command sequences
-generated by the code generator from the optimised operators.
+  generated by the code generator from the optimised operators
 
 Vela's processing steps add data to internal debug tables; one table for each
-of the above states. When vela has completed processing, it can write out the
-internal debug tables through the command line option "++enable-debug-db".
+of the above states.  When vela has completed processing it can write out the
+internal debug tables through the command line option `--enable-debug-db`.
 
-# File Format
+## File Format
 
 The internal debug tables are formatted as columnar CSV. Each row represents an
 operator or stream command; keyed on a numeric value that uniquely identifies
-that operator or command. These tables are further packaged into an XML
+that operator or command.  These tables are further packaged into an XML
 container file, along with metadata, for easier transport and handling.
 
 **Debug node**
@@ -38,7 +38,9 @@ container file, along with metadata, for easier transport and handling.
 The top-level debug node wraps the entire file and contains information about
 the source and optimised file paths.
 
+```xml
 <debug optimised="output_from_vela.tflite" source="input.tflite">
+```
 
 **Table nodes**
 
@@ -46,27 +48,28 @@ The top-level debug node contains one or more table nodes. Each table node is
 named, and the table data is represented as CSV formatted text stored in a
 CDATA payload tag. The first row of the table contains column headers.
 
-<table name="source"><![CDATA[ "column0", "column1", "column2", ...
+```xml
+<table name="source"><![CDATA[ "column0", "column1", "column2", ... ]]></table>
+```
 
 There currently are 4 named tables.
 
-- "source" - Table of TFLite operators from the source file.
-- "optimised" - Table of optimised operators generated by vela
-- "queue" - Table of command queue offsets
-- "cmdstream" - Table describing properties of one or more command streams
-
-
-The tables reference each other through the following connections: the Queue
-table is linked to the Optimised table through the *optimised_id* and the
-command stream table through the *cmdstream_id*. The Optimised table is in turn
-linked to the Source table through the *source_id*.
-
-# Ordering
-
-Note that the source, cmdstream and optimised tables are not ordered in a
-meaningful way. The insertion order of entries in the source and optimised
-tables is arbitrarty - a side effect of traversal and optimisation. No attempt
-should be made to interpret the entries as a graph. The only ordered table is
-the queue table; which is ordered by its queue offset. This table describes the
-execution order of the hardware commands, and they can be mapped back to the
-optimised and source operators in order to determine their execution order.
\ No newline at end of file
+- `source` - Table of TFLite operators from the source file.
+- `optimised` - Table of optimised operators generated by vela
+- `queue` - Table of command queue offsets
+- `cmdstream` - Table describing properties of one or more command streams
+
+The tables reference each other through the following connections: the `queue`
+table is linked to the `optimised` table through the *optimised_id* and the
+command stream table through the *cmdstream_id*.  The `optimised` table is in
+turn linked to the `source` table through the *source_id*.
+
+## Ordering
+
+Note that the `source`, `cmdstream` and `optimised` tables are not ordered in
+any particular way.  The insertion order of entries in the `source` and
+`optimised` tables is due to Vela's internal operation and does not represent a
+graph structure.  The only ordered table is the `queue`; which is ordered by its
+queue offset.  This table describes the execution order of the hardware
+commands, and they can be mapped back to the optimised and source operators in
+order to determine their execution order.
diff --git a/OPTIONS.md b/OPTIONS.md
index dbd1869..86b05f6 100644
--- a/OPTIONS.md
+++ b/OPTIONS.md
@@ -161,7 +161,12 @@ vela network.tflite --accelerator-config ethos-u55-64
 Selects the system configuration to use as specified in the Vela configuration
 file (see section below).  
 **Type: String**  
-**Default: Use internal default config**  
+**Default: Use `internal-default` config.  This maps to the following configs from the example `vela.ini` file**  
+
+- **Ethos-U65** - System configuration Ethos-U65 Client-Server: SRAM (16 GB/s)
+  and DRAM (12 GB/s)  
+- **Ethos-U55** - System configuration Ethos-U55 High-End Embedded: SRAM
+  (4 GB/s) and Flash (0.5 GB/s)  
 
 ```bash
 vela network.tflite --config my_vela_cfg.ini --system-config My_Sys_Cfg
@@ -172,7 +177,13 @@ vela network.tflite --config my_vela_cfg.ini --system-config My_Sys_Cfg
 Selects the memory mode to use as specified in the Vela configuration file (see
 section below).  
 **Type: String**  
-**Default: Use internal default config**  
+**Default: Use `internal-default` config.  This maps to the following configs from the example `vela.ini` file**  
+
+- **Ethos-U65** - Memory mode Dedicated SRAM: the SRAM is only for use by the
+  Ethos-U.  The non-SRAM memory is assumed to be read-writeable  
+- **Ethos-U55** - Memory mode Shared SRAM: the SRAM is shared between the
+  Ethos-U and the Cortex-M software.  The non-SRAM memory is assumed to be
+  read-only  
 
 ```bash
 vela network.tflite --config my_vela_cfg.ini --memory-mode My_Mem_Mode
diff --git a/SECURITY.md b/SECURITY.md
index c795d52..690a04b 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -82,4 +82,4 @@ yYCr2gCFPymkkRYhPr2w5EgbWyzLaBIwqjyIbXaveuB3DYi2Lhbf64I=
 ~~~
 
 For more information visit
-<https://developer.arm.com/support/arm-security-updates/report-security-vulnerabilities>
\ No newline at end of file
+<https://developer.arm.com/support/arm-security-updates/report-security-vulnerabilities>