aboutsummaryrefslogtreecommitdiff
path: root/chapters
diff options
context:
space:
mode:
Diffstat (limited to 'chapters')
-rw-r--r--chapters/custom.adoc6
-rw-r--r--chapters/introduction.adoc8
-rw-r--r--chapters/operators.adoc21
3 files changed, 22 insertions, 13 deletions
diff --git a/chapters/custom.adoc b/chapters/custom.adoc
index 4804e25..e748f38 100644
--- a/chapters/custom.adoc
+++ b/chapters/custom.adoc
@@ -12,9 +12,9 @@
Hardware implementing TOSA may choose to add additional custom operators that are not expressed in the existing TOSA operations. These operators are not expected to be portable across TOSA implementations. The input and output signatures must be expressed in the corresponding TOSA node.
==== CUSTOM
-Input Operands:
+Input arguments:
-* Num input operands – Scalar number of input operands
-* Num output operands – Scalar number of output operands
+* Num input arguments – Scalar number of input arguments
+* Num output arguments – Scalar number of output arguments
* Operator code – untyped data consisting of the operator data
* Affine transform description for each tensor
diff --git a/chapters/introduction.adoc b/chapters/introduction.adoc
index 9cfccb7..b369070 100644
--- a/chapters/introduction.adoc
+++ b/chapters/introduction.adoc
@@ -79,7 +79,7 @@ The following principles govern the selection of operators within TOSA.
|Consistent sub-operation definition reduces the operator implementation cost.
|P4
-|The valid input and output ranges for all operands shall be specified.
+|The valid input and output ranges for all arguments shall be specified.
|Ranges are required to make consistent (numerically agreeing) implementations possible.
|P5
@@ -108,11 +108,11 @@ The following table summarizes the three profiles:
=== Levels
-A TOSA level defines operator parameter ranges that an implementation shall support.
+A TOSA level defines operator argument ranges that an implementation shall support.
This is distinct from a profile that defines the operations and data-types supported.
This version of the specification defines two TOSA levels:
-* No level : allows the full range of parameters specified by the operations according to the operation data types.
+* No level : allows the full range of arguments specified by the operations according to the operation data types.
* Level 8K : ranges are expected to be sufficient for applications with frame sizes up to 8K.
Later versions of the specification may define additional levels.
@@ -522,7 +522,7 @@ To convert a network containing quantized tensors to TOSA, generate explicit RES
This reduces quantized operations to purely integer operations.
As an example, an ADD between two quantized tensors requires the integer values represent the same range.
-The scale parameters for RESCALE can be calculated to ensure that the resulting tensors represent the same range.
+The scale arguments for RESCALE can be calculated to ensure that the resulting tensors represent the same range.
Then the ADD is performed, and a RESCALE can be used to ensure that the result is scaled properly.
RESCALE provides support for per-tensor and per-channel scaling values to ensure compatibility with a range of possible quantization implementations.
diff --git a/chapters/operators.adoc b/chapters/operators.adoc
index 897ff17..3a4c831 100644
--- a/chapters/operators.adoc
+++ b/chapters/operators.adoc
@@ -9,14 +9,23 @@
== Operators
-=== Operator Parameters
+=== Operator Arguments
-An operator processes input operands to produce output operands. An operator can have three types of parameters:
+Operators process input arguments to produce output arguments.
+Their behavior can be configured using attribute arguments.
+Arguments may have one of the following types:
-* An input operand. This must be a tensor or a list of tensors and data is read by the operation.
-* An output operand. This must be a tensor or a list of tensors and data is written by the operation.
-* An attribute. This is a parameter that is constant for a particular instance of the operator. It may have any data type supported by TOSA. It is expected to be set at compile time.
+* `tensor_t<element_type>`, abbreviated `T<element_type>`, represents a tensor whose elements are of type `element_type` where `element_type` can be any of the data types supported in TOSA.
+* `tensor_list_t` represents a list of tensors. When lists are homogeneous, i.e. contain tensors of the same type, their type is further qualified as follows: `tensor_list_t<T<element_type>>`.
+* `tosa_graph_t` represents a TOSA graph (see <<operator-graphs>>).
+Arguments belong to one of three categories: Input, Output, or Attribute. The category to which an argument belongs further constrains its type:
+
+* An Input argument must be a tensor or a list of tensors used to provide the data read by the operation.
+* An Output argument must be a tensor or a list of tensors into which the data produced by the operation is written.
+* An Attribute argument is constant, i.e. its value is known at compilation time. It may have any data type supported by TOSA.
+
+[[operator-graphs]]
=== Operator Graphs
A TOSA graph is a collection of TOSA operators where:
@@ -27,7 +36,7 @@ A TOSA graph is a collection of TOSA operators where:
* The attributes must be in the valid range permitted for the operator
* The tensor dimensions must be in the valid range permitted for the operator
-Some operators, such as control flow operators, take a graph of other operators as an attribute. The type tosa_graph_t will denote a graph of operators and the following functions define the tensor shape list for the graph input and outputs:
+Some operators, such as control flow operators, take a graph of other operators as an attribute. The type `tosa_graph_t` will denote a graph of operators and the following functions define the tensor shape list for the graph input and outputs:
[source,c++]
----