From b0b56d3ad218fbc78629c22096e12be4775f30ed Mon Sep 17 00:00:00 2001 From: Tim Hall Date: Thu, 18 Feb 2021 23:02:50 +0000 Subject: 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 Change-Id: If0fc2989538f372bfb6d6370565e940d132ca546 --- DEBUG_DB.md | 73 ++++++++++++++++++++++++++++++++----------------------------- OPTIONS.md | 15 +++++++++++-- SECURITY.md | 2 +- 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 +``` **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. -
+``` 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 - \ No newline at end of file + -- cgit v1.2.1