IVGCVSW-3507 Revise and update readmes for 19.08

Signed-off-by: Aron Virginas-Tar <Aron.Virginas-Tar@arm.com>
Change-Id: I3da43122240fda7864e0932d47b3efeea8bbed40

7 files changed, 67 insertions, 62 deletions

diff --git a/README.md b/README.md
index a23d1e96a2..6f68261957 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
 # Arm NN

 

-Arm NN is a key component of the [machine learning platform](https://mlplatform.org/) which is part of the [Linaro Machine Intelligence Initiative](https://www.linaro.org/news/linaro-announces-launch-of-machine-intelligence-initiative/). For more information on the machine learning platform and Arm NN, see: <https://mlplatform.org/>, also there is further Arm NN information available from <https://developer.arm.com/products/processors/machine-learning/arm-nn>

+Arm NN is a key component of the [machine learning platform](https://mlplatform.org/), which is part of the [Linaro Machine Intelligence Initiative](https://www.linaro.org/news/linaro-announces-launch-of-machine-intelligence-initiative/). For more information on the machine learning platform and Arm NN, see: <https://mlplatform.org/>, also there is further Arm NN information available from <https://developer.arm.com/products/processors/machine-learning/arm-nn>

 

 There is a getting started guide here using TensorFlow: <https://developer.arm.com/technologies/machine-learning-on-arm/developer-material/how-to-guides/configuring-the-arm-nn-sdk-build-environment-for-tensorflow>

 

@@ -18,22 +18,22 @@ Arm tests the build system of Arm NN with the following build environments:
 

 * Android NDK: [How to use Android NDK to build Arm NN](BuildGuideAndroidNDK.md)

 * Cross compilation from x86_64 Ubuntu to arm64 Linux: [Arm NN Cross Compilation](BuildGuideCrossCompilation.md)

-* Native compilation under arm64 Debian 9

+* Native compilation under aarch64 Debian 9

 

-Arm NN is written using portable C++14 and the build system uses [CMake](https://cmake.org/) so it is possible to build for a wide variety of target platforms, from a wide variety of host environments.

+Arm NN is written using portable C++14 and the build system uses [CMake](https://cmake.org/), therefore it is possible to build for a wide variety of target platforms, from a wide variety of host environments.

 

 The armnn/tests directory contains tests used during Arm NN development. Many of them depend on third-party IP, model protobufs and image files not distributed with Arm NN. The dependencies of some of the tests are available freely on the Internet, for those who wish to experiment.

 

-The 'armnn/samples' directory contains SimpleSample.cpp. A very basic example of the ArmNN SDK API in use.

+The 'armnn/samples' directory contains SimpleSample.cpp, a very basic example of the ArmNN SDK API in use.

 

-The 'ExecuteNetwork' program, in armnn/tests/ExecuteNetwork, has no additional dependencies beyond those required by Arm NN and the model parsers. It takes any model and any input tensor, and simply prints out the output tensor. Run with no arguments to see command-line help.

+The 'ExecuteNetwork' program, in armnn/tests/ExecuteNetwork, has no additional dependencies beyond those required by Arm NN and the model parsers. It takes any model and any input tensor, and simply prints out the output tensor. Run it with no arguments to see command-line help.

 

-The 'ArmnnConverter' program, in armnn/src/armnnConverter, has no additional dependencies beyond those required by Arm NN and the model parsers. It takes a model in TensorFlow format and produces a serialized model in Arm NN format. Run with no arguments to see command-line help. Note that this program can only convert models for which all operations are supported by the serialization tool (src/armnnSerializer).

+The 'ArmnnConverter' program, in armnn/src/armnnConverter, has no additional dependencies beyond those required by Arm NN and the model parsers. It takes a model in TensorFlow format and produces a serialized model in Arm NN format. Run it with no arguments to see command-line help. Note that this program can only convert models for which all operations are supported by the serialization tool [src/armnnSerializer](src/armnnSerializer/README.md).

 

 The 'ArmnnQuantizer' program, in armnn/src/armnnQuantizer, has no additional dependencies beyond those required by Arm NN and the model parsers. It takes a 32-bit float network and converts it into a quantized asymmetric 8-bit or quantized symmetric 16-bit network.

-Static quantization is supported by default but dynamic quantization can be enabled if CSV file of raw input tensors is specified. Run with no arguments to see command-line help.

+Static quantization is supported by default but dynamic quantization can be enabled if CSV file of raw input tensors is specified. Run it with no arguments to see command-line help.

 

-Note that Arm NN needs to be built against a particular version of ARM's Compute Library. The get_compute_library.sh in the scripts subdirectory will clone the compute library from the review.mlplatform.org github repository into a directory alongside armnn named 'clframework' and checkouts the correct revision

+Note that Arm NN needs to be built against a particular version of [ARM's Compute Library](https://github.com/ARM-software/ComputeLibrary). The get_compute_library.sh in the scripts subdirectory will clone the compute library from the review.mlplatform.org github repository into a directory alongside armnn named 'clframework' and checks out the correct revision.

 

 ### License

 

diff --git a/src/armnnQuantizer/README.md b/src/armnnQuantizer/README.md
index cad382078c..73b65e74b4 100644
--- a/src/armnnQuantizer/README.md
+++ b/src/armnnQuantizer/README.md
@@ -1,6 +1,6 @@
 # The ArmnnQuantizer
 
-The `ArmnnQuantizer` is a program for loading a 32-bit float network into ArmNN and converting it into a quantized asymmetric 8-bit or quantized symmetric 16-bit network. 
+The `ArmnnQuantizer` is a program for loading a 32-bit float network into ArmNN and converting it into a quantized asymmetric 8-bit or quantized symmetric 16-bit network.
 It supports static quantization by default, dynamic quantization is enabled if CSV file of raw input tensors is provided. Run the program with no arguments to see command-line help.
 
 
@@ -15,4 +15,4 @@ It supports static quantization by default, dynamic quantization is enabled if C
 | -o | --outfile            | ArmNN output file name |
 
 Example usage: <br>
-<code>./ArmnnQuantizer -f /path/to/armnn/input/graph/ -s "QSymm16" -c /path/to/csv/file -p 1 -d /path/to/output -o outputFileName</code>
\ No newline at end of file
+<code>./ArmnnQuantizer -f /path/to/armnn/input/graph/ -s "QSymm16" -c /path/to/csv/file -p 1 -d /path/to/output -o outputFileName</code>
diff --git a/src/armnnSerializer/README.md b/src/armnnSerializer/README.md
index 61478b1470..0656c8bb79 100644
--- a/src/armnnSerializer/README.md
+++ b/src/armnnSerializer/README.md
@@ -3,4 +3,4 @@
 The `armnnSerializer` is a library for serializing an Arm NN network to a stream.
 
 For more information about the layers that are supported, and the networks that have been tested,
-see [SerializerSupport.md](./SerializerSupport.md)
+see [SerializerSupport.md](./SerializerSupport.md).
diff --git a/src/armnnTfLiteParser/README.md b/src/armnnTfLiteParser/README.md
index aeb79eee46..5e76a9cfe0 100644
--- a/src/armnnTfLiteParser/README.md
+++ b/src/armnnTfLiteParser/README.md
@@ -4,4 +4,4 @@
 into the Arm NN runtime.
 
 For more information about the TensorFlow Lite operators that are supported, and the networks that have been tested,
-see [TensorFlowLiteSupport.md](./TensorFlowLiteSupport.md)
\ No newline at end of file
+see [TensorFlowLiteSupport.md](./TensorFlowLiteSupport.md).
diff --git a/src/armnnTfParser/README.md b/src/armnnTfParser/README.md
index e4aed65b94..dc7def8d41 100644
--- a/src/armnnTfParser/README.md
+++ b/src/armnnTfParser/README.md
@@ -2,4 +2,4 @@
 
 `armnnTfParser` is a library for loading neural networks defined by TensorFlow protobuf files into the Arm NN runtime.
 
-For more information about the TensorFlow operators that are supported, and the networks that have been tested, see [TensorFlowSupport.md](./TensorFlowSupport.md)
\ No newline at end of file
+For more information about the TensorFlow operators that are supported, and the networks that have been tested, see [TensorFlowSupport.md](./TensorFlowSupport.md).
diff --git a/src/armnnTfParser/TensorFlowSupport.md b/src/armnnTfParser/TensorFlowSupport.md
index 2e09768e42..67c69ea887 100644
--- a/src/armnnTfParser/TensorFlowSupport.md
+++ b/src/armnnTfParser/TensorFlowSupport.md
@@ -167,7 +167,7 @@ The parser does not support all forms of broadcasting [broadcast composition](ht
 
 Arm tests these operators with the following TensorFlow fp32 neural networks:
 
-* Cifar10.
+* Cifar10
 
 * Lenet
 
@@ -177,4 +177,10 @@ Arm tests these operators with the following TensorFlow fp32 neural networks:
 
 * inception_v3. The Arm NN SDK only supports the official inception_v3 transformed model. See the TensorFlow documentation on [preparing models for mobile deployment](https://www.tensorflow.org/mobile/prepare_models) for more information on how to transform the inception_v3 network.
 
+* FCRN
+
+* FSRCNN
+
+* DeepSpeaker
+
 More machine learning operators will be supported in future releases.
diff --git a/src/backends/README.md b/src/backends/README.md
index 829b8eddba..96ffd77603 100644
--- a/src/backends/README.md
+++ b/src/backends/README.md
@@ -1,23 +1,22 @@
 # Backend developer guide
 
-ArmNN allows adding new backends through the 'Pluggable Backend' mechanism.
+Arm NN allows adding new backends through the 'Pluggable Backend' mechanism.
 
 ## How to add a new backend
 
-Backends reside under [src/backends](./), in separate subfolders. For Linux builds they must have a ```backend.cmake``` file
+Backends reside under [src/backends](./), in separate subfolders. For Linux builds they must have a ```backend.cmake``` file,
 which is read automatically by [src/backends/backends.cmake](backends.cmake). The ```backend.cmake``` file
 under the backend-specific folder is then included by the main CMakeLists.txt file at the root of the
-ArmNN source tree.
+Arm NN source tree.
 
 ### The backend.cmake file
 
 The ```backend.cmake``` has three main purposes:
 
-1. It makes sure the artifact (a cmake OBJECT library) is linked into the ArmNN shared library by appending the name of the library to the ```armnnLibraries``` list.
+1. It makes sure the artifact (a cmake OBJECT library) is linked into the Arm NN shared library by appending the name of the library to the ```armnnLibraries``` list.
 2. It makes sure that the subdirectory where backend sources reside gets included into the build.
 3. To include backend-specific unit tests, the object library for the unit tests needs to be added to the ```armnnUnitTestLibraries``` list.
 
-
 Example ```backend.cmake``` file taken from [reference/backend.cmake](reference/backend.cmake):
 
 ```cmake
@@ -30,7 +29,7 @@ add_subdirectory(${PROJECT_SOURCE_DIR}/src/backends/reference)
 
 #
 # Add the cmake OBJECT libraries built by the reference backend to the
-# list of libraries linked against the ArmNN shared library.
+# list of libraries linked against the Arm NN shared library.
 #
 list(APPEND armnnLibraries armnnRefBackend armnnRefBackendWorkloads)
 
@@ -47,16 +46,16 @@ list(APPEND armnnUnitTestLibraries armnnRefBackendUnitTests)
 
 As described in the previous section, adding a new backend will require creating a ```CMakeLists.txt``` in
 the backend folder. This follows the standard cmake conventions, and is required to build a static cmake OBJECT library
-to be linked into the ArmNN shared library. As with any cmake build, the code can be structured into
+to be linked into the Arm NN shared library. As with any cmake build, the code can be structured into
 subfolders and modules as the developer sees fit.
 
 Example can be found under [reference/CMakeLists.txt](reference/CMakeLists.txt).
 
 ### The backend.mk file
 
-ArmNN on Android uses the native Android build system. New backends are integrated by creating a
-```backend.mk``` file which has a single variable called ```BACKEND_SOURCES``` listing all cpp
-files to be built by the Android build system for the ArmNN shared library.
+Arm NN on Android uses the native Android build system. New backends are integrated by creating a
+```backend.mk``` file, which has a single variable called ```BACKEND_SOURCES``` listing all cpp
+files to be built by the Android build system for the Arm NN shared library.
 
 Optionally, backend-specific unit tests can be added similarly, by
 appending the list of cpp files to the ```BACKEND_TEST_SOURCES``` variable.
@@ -102,7 +101,7 @@ common code is built first, so the backend code can depend on them.
 
 Backends are identified by a string that must be unique across backends. This string is
 wrapped in the [BackendId](../../include/armnn/BackendId.hpp) object for backward compatibility
-with previous ArmNN versions.
+with previous Arm NN versions.
 
 ## The IBackendInternal interface
 
@@ -125,7 +124,7 @@ have been deprecated.
 The method ```OptimizationViews OptimizeSubgraph(const SubgraphView& subgraph)``` should be used instead to
 apply specific optimizations to a given sub-graph.
 
-The ArmNN framework then creates instances of the IBackendInternal interface with the help of the
+The Arm NN framework then creates instances of the IBackendInternal interface with the help of the
 [BackendRegistry](backendsCommon/BackendRegistry.hpp) singleton.
 
 **Important:** the ```IBackendInternal``` object is not guaranteed to have a longer lifetime than
@@ -135,13 +134,13 @@ its lifetime and the lifetime of the objects it creates.
 
 For each backend one needs to register a factory function that can
 be retrieved using a [BackendId](../../include/armnn/BackendId.hpp).
-The ArmNN framework creates the backend interfaces dynamically when
+The Arm NN framework creates the backend interfaces dynamically when
 it sees fit and it keeps these objects for a short period of time. Examples:
 
-* During optimization ArmNN needs to decide which layers are supported by the backend.
+* During optimization Arm NN needs to decide which layers are supported by the backend.
   To do this, it creates a backends and calls the ```GetLayerSupport()``` function and creates
   an ```ILayerSupport``` object to help deciding this.
-* During optimization ArmNN can run backend-specific optimizations. After splitting the graph into
+* During optimization Arm NN can run backend-specific optimizations. After splitting the graph into
   sub-graphs based on backends, it calls the ```OptimizeSubgraphView()``` function on each of them and, if possible,
   substitutes the corresponding sub-graph in the original graph with its optimized version.
 * When the Runtime is initialized it creates an optional ```IBackendContext``` object and keeps this context alive
@@ -151,7 +150,7 @@ it sees fit and it keeps these objects for a short period of time. Examples:
 
 ## The BackendRegistry
 
-As mentioned above, all backends need to be registered through the BackendRegistry so ArmNN knows
+As mentioned above, all backends need to be registered through the BackendRegistry so Arm NN knows
 about them. Registration requires a unique backend ID string and a lambda function that
 returns a unique pointer to the [IBackendInternal interface](backendsCommon/IBackendInternal.hpp).
 
@@ -165,7 +164,7 @@ Dynamic backends are registered during the runtime creation.
 
 ## The ILayerSupport interface
 
-ArmNN uses the [ILayerSupport](../../include/armnn/ILayerSupport.hpp) interface to decide if a layer
+Arm NN uses the [ILayerSupport](../../include/armnn/ILayerSupport.hpp) interface to decide if a layer
 with a set of parameters (i.e. input and output tensors, descriptor, weights, filter, kernel if any) are
 supported on a given backend. The backends need a way to communicate this information by implementing
 the ```GetLayerSupport()``` function on the ```IBackendInternal``` interface.
@@ -184,10 +183,10 @@ the input and output tensor information and a workload specific queue descriptor
 
 ## The IMemoryManager interface
 
-Backends may choose to implement custom memory management. ArmNN supports this concept through the following
+Backends may choose to implement custom memory management. Arm NN supports this concept through the following
 mechanism:
 
-* the ```IBackendInternal``` interface has a ```CreateMemoryManager()``` function which is called before
+* the ```IBackendInternal``` interface has a ```CreateMemoryManager()``` function, which is called before
   creating the workload factory
 * the memory manager is passed to the ```CreateWorkloadFactory(...)``` function so the workload factory can
   use it for creating the backend-specific workloads
@@ -201,11 +200,12 @@ This is supported through the method ```OptimizationViews OptimizeSubgraph(const
 the backend interface that allows the backends to apply their specific optimizations to a given sub-graph.
 
 The ```OptimizeSubgraph(...)``` method returns an OptimizationViews object containing three lists:
+
 * A list of the sub-graph substitutions: a "substitution" is a pair of sub-graphs, the first is the "substitutable" sub-graph,
   representing the part of the original graph that has been optimized by the backend, while the second is the "replacement" sub-graph,
   containing the actual optimized layers that will be replaced in the original graph correspondingly to the "substitutable" sub-graph
 * A list of the failed sub-graphs: these are the parts of the original sub-graph that are not supported by the backend,
-  thus have been rejected. ArmNN will try to re-allocate these parts on other backends if available.
+  thus have been rejected. Arm NN will try to re-allocate these parts on other backends if available.
 * A list of the untouched sub-graphs: these are the parts of the original sub-graph that have not been optimized,
   but that can run (unoptimized) on the backend.
 
@@ -226,13 +226,13 @@ runtime will hold this for its entire lifetime. It then calls the following inte
 
 ## Dynamic backends
 
-Backends can also be loaded by ArmNN dynamically at runtime.
+Backends can also be loaded by Arm NN dynamically at runtime.
 To be properly loaded and used, the backend instances must comply to the standard interface for dynamic backends and to the versioning
 rules that enforce ABI compatibility.
 
 ## Dynamic backends base interface
 
-The dynamic backend shared object must expose the following interface for ArmNN to handle it correctly:
+The dynamic backend shared object must expose the following interface for Arm NN to handle it correctly:
 
 ```c++
 extern "C"
@@ -245,16 +245,16 @@ void* BackendFactory();
 
 Interface details:
 
-* ```extern "C"``` is needed to use avoid C++ name mangling, necessary to allow ArmNN to dynamically load the symbols.
+* ```extern "C"``` is needed to use avoid C++ name mangling, necessary to allow Arm NN to dynamically load the symbols.
 * ```GetBackendId()```: must return the unique id of the dynamic backends.
-  If at the time of the loading the id already exists in the internal ArmNN's backend registry, the backend will be skipped and
-  not loaded in ArmNN
+  If at the time of the loading the id already exists in the internal Arm NN's backend registry, the backend will be skipped and
+  not loaded in Arm NN
 * ```GetVersion()```: must return the version of the dynamic backend.
   The version must indicate the version of the Backend API the dynamic backend has been built with.
   The current Backend API version can be found by inspecting the IBackendInternal interface.
-  At the time of loading, the version of the backend will be checked against the version of the Backend API ArmNN is built with.
+  At the time of loading, the version of the backend will be checked against the version of the Backend API Arm NN is built with.
   If the backend version is not compatible with the current Backend API, the backend will not be loaded as it will be assumed that
-  it is not ABI compatible with the current ArmNN build.
+  it is not ABI compatible with the current Arm NN build.
 * ```BackendFactory()```: must return a valid instance of the backend.
   The backend instance is an object that must inherit from the version of the IBackendInternal interface declared by GetVersion().
   It is the backend developer's responsibility to ensure that the backend implementation correctly reflects the version declared by
@@ -265,29 +265,29 @@ Interface details:
 
 Dynamic backend versioning policy:
 
-Updates to ArmNN's Backend API follow these rules: changes to the Backend API (the IBackendInternal interface) that break
+Updates to Arm NN's Backend API follow these rules: changes to the Backend API (the IBackendInternal interface) that break
 ABI compatibility with the previous API version will be indicated by a change of the API's major version, while changes
 that guarantee ABI compatibility with the previous API version will be indicated by a change in API's the minor version.
 
 For example:
 
-* Dynamic backend version 2.4 (i.e. built with Backend APi version 2.4) is compatible with ArmNN's Backend API version 2.4
+* Dynamic backend version 2.4 (i.e. built with Backend API version 2.4) is compatible with Arm NN's Backend API version 2.4
   (same version, backend built against the same Backend API)
-* Dynamic backend version 2.1 (i.e. built with Backend APi version 2.1) is compatible with ArmNN's Backend API version 2.4
+* Dynamic backend version 2.1 (i.e. built with Backend API version 2.1) is compatible with Arm NN's Backend API version 2.4
   (same major version, backend built against earlier compatible API)
-* Dynamic backend version 2.5 (i.e. built with Backend APi version 2.5) is not compatible with ArmNN's Backend API version 2.4
+* Dynamic backend version 2.5 (i.e. built with Backend API version 2.5) is not compatible with Arm NN's Backend API version 2.4
   (same major version, backend built against later incompatible API, backend might require update to the latest compatible backend API)
-* Dynamic backend version 2.0 (i.e. built with Backend APi version 2.0) is not compatible with ArmNN's Backend API version 1.0
+* Dynamic backend version 2.0 (i.e. built with Backend API version 2.0) is not compatible with Arm NN's Backend API version 1.0
   (backend requires a completely new API version)
-* Dynamic backend version 2.0 (i.e. built with Backend APi version 2.0) is not compatible with ArmNN's Backend API version 3.0
+* Dynamic backend version 2.0 (i.e. built with Backend API version 2.0) is not compatible with Arm NN's Backend API version 3.0
   (backward compatibility in the Backend API is broken)
 
 ## Dynamic backend loading paths
 
-During the creation of the Runtime, ArmNN will scan a given set of paths searching for suitable dynamic backend objects to load.
+During the creation of the Runtime, Arm NN will scan a given set of paths searching for suitable dynamic backend objects to load.
 A list of (absolute) paths can be specified at compile-time by setting a define named ```DYNAMIC_BACKEND_PATHS``` in the form of a colon-separated list of strings.
 
-```
+```shell
 -DDYNAMIC_BACKEND_PATHS="PATH_1:PATH_2...:PATH_N"
 ```
 
@@ -295,22 +295,22 @@ The paths will be processed in the same order as they are indicated in the macro
 
 It is also possible to override those paths at runtime when creating the Runtime object by setting the value of the ```m_DynamicBackendsPath``` member in the CreationOptions class.
 Only one path is allowed for the override via the CreationOptions class.
-By setting the value of the ```m_DynamicBackendsPath``` to a path in the filesystem, ArmNN will entirely ignore the list of paths passed via the
+By setting the value of the ```m_DynamicBackendsPath``` to a path in the filesystem, Arm NN will entirely ignore the list of paths passed via the
 ```DYNAMIC_BACKEND_PATHS``` compiler directive.
 
 All the specified paths are validate before processing (they must exist, must be directories, and must be absolute paths),
-in case of error a warning message will be added to the log, but ArmNN's execution will not be stopped.
-If all path are not valid, then no dynamic backends will be loaded in the ArmNN's runtime.
+in case of error a warning message will be added to the log, but Arm NN's execution will not be stopped.
+If all path are not valid, then no dynamic backends will be loaded in the Arm NN's runtime.
 
 Passing an empty list of paths at compile-time and providing no path override at runtime will effectively disable the
-dynamic backend loading feature, and no dynamic backends will be loaded into ArmNN's runtime.
+dynamic backend loading feature, and no dynamic backends will be loaded into Arm NN's runtime.
 
 ## Dynamic backend file naming convention
 
-During the creation of a Runtime object, ArmNN will scan the paths specified for dynamic backend loading searching for suitable backend objects.
-ArmNN will try to load only the files that match the following accepted naming scheme:
+During the creation of a Runtime object, Arm NN will scan the paths specified for dynamic backend loading searching for suitable backend objects.
+Arm NN will try to load only the files that match the following accepted naming scheme:
 
-```
+```shell
 <vendor>_<name>_backend.so[<version>] (e.g. "Arm_GpuAcc_backend.so" or "Arm_GpuAcc_backend.so.1.2.3")
 ```
 
@@ -320,7 +320,7 @@ Only dots and numbers are allow for the optional `<version>` field.
 
 Symlinks to other files are allowed to support the standard linux shared object versioning:
 
-```
+```shell
 Arm_GpuAcc_backend.so -> Arm_GpuAcc_backend.so.1.2.3
 Arm_GpuAcc_backend.so.1 -> Arm_GpuAcc_backend.so.1.2.3
 Arm_GpuAcc_backend.so.1.2 -> Arm_GpuAcc_backend.so.1.2.3
@@ -362,7 +362,7 @@ Examples:
 | pathA/Arm_GpuAcc_backend.so                              | valid: basic backend name                         |
 | pathB/Arm_GpuAcc_backend.so                              | valid: but duplicated from pathA/                 |
 
-ArmNN will try to load the dynamic backends in the same order as they are parsed from the filesystem.
+Arm NN will try to load the dynamic backends in the same order as they are parsed from the filesystem.
 
 ## Dynamic backend examples
 
@@ -373,7 +373,7 @@ The source code includes an example that is used to generate some mock dynamic b
 
 This example is useful for going through all the use cases that constitute an invalid dynamic backend object, such as
 an invalid/malformed implementation of the shared object interface, or an invalid value returned by any of the interface methods
-that would prevent ArmNN from making use of the dynamic backend.
+that would prevent Arm NN from making use of the dynamic backend.
 
 A dynamic implementation of the reference backend is also provided. The source files are:
 
@@ -384,7 +384,7 @@ The implementation itself is quite simple and straightforward. Since an implemen
 the dynamic version is just a wrapper around the original code that simply returns the backend id, version and an instance of the
 backend itself via the factory function.
 For the sake of the example, the source code of the reference backend is used to build the dynamic version (as you would for any new
-dynamic backend), while all the other symbols needed are provided by linking the dynamic backend against ArmNN.
+dynamic backend), while all the other symbols needed are provided by linking the dynamic backend against Arm NN.
 
 The makefile used for building the reference dynamic backend is also provided: [CMakeLists.txt](dynamic/reference/CMakeLists.txt)
 
@@ -395,10 +395,9 @@ where only the reference dynamic backend is.
 In this example the file is named ```Arm_CpuRef_backend.so```, which is compliant with the expected naming scheme for dynamic backends.
 A ```DynamicBackend``` is created in the runtime to represent the newly loaded backend, then the backend is registered in the Backend
 Registry with the id "CpuRef" (returned by ```GetBackendId()```).
-The unit test makes sure that the backend is actually registered in ArmNN, before trying to create an instance of the backend by
+The unit test makes sure that the backend is actually registered in Arm NN, before trying to create an instance of the backend by
 calling the factory function provided through the shared object interface (```BackendFactory()```).
 The backend instance is used to verify that everything is in order, testing basic 2D convolution support by making use of the
 Layer Support API and the Workload Factory.
 At the end of test, the runtime object goes out of scope and the dynamic backend instance is automatically destroyed, and the handle to
 the shared object is closed.
-