MLBEDSW-3938: Describe internal-default CLI value
- 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
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 @@
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 @@
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
+- `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*.
-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
-# 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
+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 @@
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 @@
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 @@
~~~
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>