From aaa31b306daac18036c97401300c07d68b35b311 Mon Sep 17 00:00:00 2001 From: Eric Kunze Date: Fri, 12 Apr 2024 15:25:24 -0700 Subject: Status update and text cleanup Update the status section of the specification as well as various textual simplifications/clarifications. Signed-off-by: Eric Kunze Change-Id: Ie77039e537bc66e6d05b14c7e0705b1c1cc4be58 --- chapters/appendix_a.adoc | 6 ++---- chapters/introduction.adoc | 29 +++++++++++++---------------- tosa.xml | 6 +++--- 3 files changed, 18 insertions(+), 23 deletions(-) diff --git a/chapters/appendix_a.adoc b/chapters/appendix_a.adoc index 6d85204..0f21b6b 100644 --- a/chapters/appendix_a.adoc +++ b/chapters/appendix_a.adoc @@ -9,8 +9,6 @@ == Appendix A -NOTE: This appendix is at an early stage of development at this point in time - === Random data generation The following function generates a pseudo-random floating-point value in the range -1.0 to +1.0 for use as test data. @@ -102,8 +100,8 @@ If the implementation changes the order of the sum, then the test data must also [cols="1,9"] |=== | p | tosa_mi_data(S, KS, p, k, i) = -| 0 | (k==0) ? 16.0 : exp(2*set_data(2*S+0, 2*i+0)) * set_data(2*S+0, 2*i+1) -| 1 | (k==0) ? 16.0 : exp(2*set_data(2*S+1, 2*i+0)) * set_data(2*S+1, 2*i+1) +| 0 | (k==0) ? ((set_data(2*S+0, 2*i+0) < 0) ? -16.0 : 16.0) : exp(2*set_data(2*S+0, 2*i+0)) * set_data(2*S+0, 2*i+1) +| 1 | (k==0) ? ((set_data(2*S+1, 2*i+0) < 0) ? -16.0 : 16.0) : exp(2*set_data(2*S+1, 2*i+0)) * set_data(2*S+1, 2*i+1) | 2 | 0.0 |=== diff --git a/chapters/introduction.adoc b/chapters/introduction.adoc index d931967..ef12dfd 100644 --- a/chapters/introduction.adoc +++ b/chapters/introduction.adoc @@ -35,7 +35,7 @@ framework operators can be reduced. the treatment of their numerical behavior in the case of precision, saturation, scaling, and range as required by quantized datatypes. -* Agnostic to any single high-level framework, compiler backend stack or +* Independent of any single high-level framework, compiler backend stack or particular target. * The detailed functional and numerical description enables precise code @@ -67,16 +67,16 @@ The following principles govern the selection of operators within TOSA. |If the operator can be broken down, then we should look at the component operators. |P1 -|An operator shall be a usable as a component out of which more complex operations can be constructed. +|An operator shall be usable as a component out of which more complex operations can be constructed. |Single use operators have a high architectural cost and a more reusable version should be considered instead. |P2 |Precision should be appropriate for the input and output data types. -|Precision higher than that needed to calculate the result leads to extra implementation cost. +|Precision higher than that needed to calculate the result leads to extra implementation complexity. |P3 |Numerical definition of common sub-operations should be consistent between operators (for example: value scaling). -|Consistent sub-operation definition reduces the operator implementation cost. +|Consistent sub-operation definition reduces the operator implementation complexity. |P4 |The valid input and output ranges for all arguments shall be specified. @@ -168,17 +168,19 @@ Later versions of the specification may define additional levels. The following table defines the value ranges for each level. These ranges are checked using the LEVEL_CHECK() function with the operator descriptions. -.Level maximums +.Level maxima include::{generated}/levels.adoc[] === Status -The TOSA specification is a work in progress. +This specification is the release candidate for TOSA 1.0. -* The Base Inference profile should be considered to be near release quality, with conformance tests available. -* The Main Inference profile has most of the expected operators in place, but is still subject to change. -* The reference model and conformance tests do not yet support all of the floating point types that have been defined. -* There is not currently a conformance test suite available for Main Inference. +The specific status of each profile and extension is contained in the tables in <>. +Possible values for status are: + +* Complete : All operators are specified, conformance tests are provided, no changes are expected. +* Unstable : Operators are specified, conformance tests provided, but less content has been tested. +* Incomplete : Operators or conformnace tests may be missing. Changes are likely in future versions of the specification. === Compliance @@ -233,15 +235,12 @@ bool tosa_test_compliance(tosa_graph_t graph, tensor_list_t input_list, tosa_lev A Main Inference compliant implementation must satisfy the following: -* The implementation must meet <> for all Base inference complaint graphs +* The implementation must meet <> for all Base inference compliant graphs * The implementation must support all Main Inference operations using the datatype fp32_t ** The operations must meet the precision requirements of <
> * The implementation must support all Main Inference operations using the datatype fp16_t ** The operations must meet the precision requirements of <
> ** Note: These requirements allow fp16_t operations to be implemented using the fp32_t datatype -* The implementation must support all Main Inference operations using the datatype bf16_t -** The operations must meet the precision requirements of <
> -** Note: These requirements allow bf16_t operations to be implemented using the fp32_t datatype As with <> the pseudo-code function tosa_execute_graph() can return one of three possible results. A compliant implementation must satisfy the following: @@ -256,8 +255,6 @@ In a compliant implementation, individual floating-point operations within the g In the table _ulp_ means unit of the last place. The function tosa_reference_check_fp() defines the error range permitted by a given number of units of last place in this specification. -NOTE: The error criteria in this section are at an early draft stage and are likely to change during conformance test development. - The following criteria apply to all operations: * If any input is a NaN and the result is floating-point then the result must be a NaN diff --git a/tosa.xml b/tosa.xml index 9a3b2c2..7ab182a 100644 --- a/tosa.xml +++ b/tosa.xml @@ -16,16 +16,16 @@ MI - + MI - + MI MI - + BI MI -- cgit v1.2.1