COMPMID-1170 Updated Doxygen

- Removed references to old validation test suite
- Updated folders hierarchy
- Fixed NDK commands formatting
- Updated changelog for 18.05

Change-Id: I8e82c11298b5d837efd5056ac7c37668556c8e2c
Reviewed-on: https://eu-gerrit-1.euhpc.arm.com/132047
Reviewed-by: Pablo Tello <pablo.tello@arm.com>
Tested-by: Jenkins <bsgcomp@arm.com>

2 files changed, 52 insertions, 86 deletions

diff --git a/docs/00_introduction.dox b/docs/00_introduction.dox
index c5ec3c9946..c6c0ab2ac5 100644
--- a/docs/00_introduction.dox
+++ b/docs/00_introduction.dox
@@ -71,20 +71,34 @@ You should have the following file organisation:
 	│   │   │   └── OpenGLES.h --> Wrapper to configure the Khronos EGL and OpenGL ES C header
 	│   │   ├── NEON
 	│   │   │   ├── kernels --> Folder containing all the NEON kernels
-	│   │   │   │   ├── arm64 --> Folder containing the interfaces for the assembly arm64 NEON kernels
-	│   │   │   │   ├── arm32 --> Folder containing the interfaces for the assembly arm32 NEON kernels
-	│   │   │   │   ├── assembly --> Folder containing the NEON assembly routines.
+	│   │   │   │   ├── assembly --> headers for assembly optimised NEON kernels.
+	│   │   │   │   ├── convolution --> headers for convolution assembly optimised NEON kernels.
+	│   │   │   │   │   ├── common --> headers for code which is common to several convolution implementations.
+	│   │   │   │   │   ├── depthwise --> headers for Depthwise convolultion assembly implementation
+	│   │   │   │   │   └── winograd --> headers for Winograd convolution assembly implementation
+	│   │   │   │   ├── detail --> Common code for several intrinsics implementations.
 	│   │   │   │   └── NE*Kernel.h
 	│   │   │   └── NEKernels.h --> Includes all the NEON kernels at once
 	│   │   ├── All common basic types (Types.h, Window, Coordinates, Iterator, etc.)
 	│   │   ├── All generic objects interfaces (ITensor, IImage, etc.)
 	│   │   └── Objects metadata classes (ImageInfo, TensorInfo, MultiImageInfo)
 	│   ├── graph
-	│   │   ├── CL --> OpenCL specific operations
-	│   │   │   └── CLMap.h / CLUnmap.h
+	│   │   ├── algorithms
+	│   │   │   └── Generic algorithms used by the graph backend (e.g Order of traversal)
+	│   │   ├── backends --> The backend specific code
+	│   │   │   ├── CL --> OpenCL specific operations
+	│   │   │   ├── GLES  --> OpenGLES Compute Shaders specific operations
+	│   │   │   └── NEON --> NEON specific operations
+	│   │   ├── detail
+	│   │   │   └── Collection of internal utilities.
+	│   │   ├── frontend
+	│   │   │   └── Code related to the stream frontend interface.
+	│   │   ├── mutators
+	│   │   │   └── Used to modify / optimise the Graph intermediate representation(Operator fusion, in place operations, etc.)
 	│   │   ├── nodes
 	│   │   │   └── The various nodes supported by the graph API
-	│   │   ├── Nodes.h --> Includes all the Graph nodes at once.
+	│   │   ├── printers
+	│   │   │   └── Debug printers
 	│   │   └── Graph objects ( INode, ITensorAccessor, Graph, etc.)
 	│   └── runtime
 	│       ├── CL
@@ -92,10 +106,14 @@ You should have the following file organisation:
 	│       │   ├── functions --> Folder containing all the OpenCL functions
 	│       │   │   └── CL*.h
 	│       │   ├── CLScheduler.h --> Interface to enqueue OpenCL kernels and get/set the OpenCL CommandQueue and ICLTuner.
-	│       │   └── CLFunctions.h --> Includes all the OpenCL functions at once
+	│       │   ├── CLFunctions.h --> Includes all the OpenCL functions at once
+	│       │   └── tuners
+	│       │       └── Local workgroup size tuners for specific architectures / GPUs
 	│       ├── CPP
 	│       │   ├── CPPKernels.h --> Includes all the CPP functions at once.
-	│       │   └── CPPScheduler.h --> Basic pool of threads to execute CPP/NEON code on several cores in parallel
+	│       │   ├── CPPScheduler.h --> Basic pool of threads to execute CPP/NEON code on several cores in parallel
+	│       │   └── functions --> Folder containing all the CPP functions
+	│       │       └── CPP*.h
 	│       ├── GLES_COMPUTE
 	│       │   ├── GLES objects & allocators (GCArray, GCImage, GCTensor, etc.)
 	│       │   ├── functions --> Folder containing all the GLES functions
@@ -122,6 +140,7 @@ You should have the following file organisation:
 	│   ├── graph_*.cpp --> Graph examples
 	│   ├── neoncl_*.cpp --> NEON / OpenCL interoperability examples
 	│   └── neon_*.cpp --> NEON examples
+	├── graph.h --> Includes all the Graph headers at once.
 	├── include
 	│   ├── CL
 	│   │   └── Khronos OpenCL C headers and C++ wrapper
@@ -152,31 +171,32 @@ You should have the following file organisation:
 	│   └── Various headers to work around toolchains / platform issues.
 	├── tests
 	│   ├── All test related files shared between validation and benchmark
-	│   ├── CL --> OpenCL accessors
-	│   ├── GLES_COMPUTE --> GLES accessors
-	│   ├── NEON --> NEON accessors
 	│   ├── benchmark --> Sources for benchmarking
 	│   │   ├── Benchmark specific files
+	│   │   ├── fixtures
+	│   │   │   └── Backend agnostic fixtures to initialise and run the functions to test.
 	│   │   ├── CL --> OpenCL benchmarking tests
 	│   │   ├── GLES_COMPUTE --> GLES benchmarking tests
-	│   │   ├── fixtures
-	│   │   │   └── Fixtures to initialise and run the runtime Functions.
 	│   │   └── NEON --> NEON benchmarking tests
+	│   ├── CL --> OpenCL accessors
+	│   ├── GLES_COMPUTE --> GLES accessors
+	│   ├── NEON --> NEON accessors
 	│   ├── datasets
 	│   │   └── Datasets for all the validation / benchmark tests, layer configurations for various networks, etc.
 	│   ├── framework
 	│   │   └── Boiler plate code for both validation and benchmark test suites (Command line parsers, instruments, output loggers, etc.)
 	│   ├── networks
 	│   │   └── Examples of how to instantiate networks.
-	│   ├── validation --> Sources for validation
-	│   │   ├── Validation specific files
-	│   │   ├── CL --> OpenCL validation tests
-	│   │   ├── GLES_COMPUTE --> GLES validation tests
-	│   │   ├── CPP --> C++ reference implementations
-	│   │   ├── fixtures
-	│   │   │   └── Fixtures to initialise and run the runtime Functions.
-	│   │   └── NEON --> NEON validation tests
-	│   └── dataset --> Datasets defining common sets of input parameters
+	│   └── validation --> Sources for validation
+	│       ├── Validation specific files
+	│       ├── fixtures
+	│       │   └── Backend agnostic fixtures to initialise and run the functions to test.
+	│       ├── reference
+	│       │   └── Reference implementation used to validate the results of the various backends.
+	│       ├── CL --> OpenCL validation tests
+	│       ├── GLES_COMPUTE --> GLES validation tests
+	│       ├── CPP --> C++ reference implementations
+	│       └── NEON --> NEON validation tests
 	└── utils --> Boiler plate code used by examples
 	    └── Various utilities to print types, load / store assets, etc.
 
@@ -219,6 +239,7 @@ v18.05 Public maintenance release
     - @ref CLChannelShuffleLayer / @ref CLChannelShuffleLayerKernel
     - @ref CLConvertFullyConnectedWeightsKernel / @ref CLConvertFullyConnectedWeights
     - @ref CLCopy / @ref CLCopyKernel
+    - @ref CLLSTMLayer
     - @ref CLRNNLayer
     - @ref CLWidthConcatenateLayer / @ref CLWidthConcatenateLayerKernel
     - @ref CLWinogradFilterTransformKernel / @ref CLWinogradInputTransformKernel / @ref CLWinogradConvolutionLayer
@@ -249,6 +270,7 @@ v18.05 Public maintenance release
  - Added the prepare() method to perform any one off pre-processing before running the function.
  - Added new examples:
     - graph_inception_v4.cpp
+    - graph_resnext50.cpp
  - Added memory measurement instrument for CL.
 
 v18.03 Public maintenance release
@@ -812,6 +834,7 @@ or
 @note Examples accept different types of arguments, to find out what they are run the example without any argument and the help will be displayed at the beginning of the run.
 
 For example:
+
 	LD_LIBRARY_PATH=. ./graph_lenet
 
 	./graph_lenet
@@ -835,13 +858,18 @@ Here is a guide to <a href="https://developer.android.com/ndk/guides/standalone_
 - Download the NDK r16b from here: https://developer.android.com/ndk/downloads/index.html
 - Make sure you have Python 2 installed on your machine.
 - Generate the 32 and/or 64 toolchains by running the following commands:
+<!-- Leave 2 blank lines here or the formatting of the commands below gets messed up --!>
+
 
+<!-- End of the 2 blank lines --!>
 	$NDK/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir $MY_TOOLCHAINS/aarch64-linux-android-ndk-r16b --stl gnustl --api 21
 	$NDK/build/tools/make_standalone_toolchain.py --arch arm --install-dir $MY_TOOLCHAINS/arm-linux-android-ndk-r16b --stl gnustl --api 21
 
 @attention Due to some NDK issues make sure you use clang++ & gnustl
 
-@note Make sure to add the toolchains to your PATH: export PATH=$PATH:$MY_TOOLCHAINS/aarch64-linux-android-4.9/bin:$MY_TOOLCHAINS/arm-linux-androideabi-4.9/bin
+@note Make sure to add the toolchains to your PATH:
+
+	export PATH=$PATH:$MY_TOOLCHAINS/aarch64-linux-android-ndk-r16b/bin:$MY_TOOLCHAINS/arm-linux-android-ndk-r16b/bin
 
 @subsubsection S3_3_1_library How to build the library ?
 
diff --git a/docs/02_tests.dox b/docs/02_tests.dox
index 5fcb4ba1b7..0d5012a205 100644
--- a/docs/02_tests.dox
+++ b/docs/02_tests.dox
@@ -306,39 +306,8 @@ provide a good overview how test cases are structured.
   Typically the will be multiple tests for different data types and for
   different execution modes, e.g. precommit and nightly.
 
-<!-- FIXME: Remove before release -->
-@section building_test_dependencies Building dependencies
-
-@note Only required when tests from the old validation framework need to be run.
-
-The tests currently make use of Boost (Test and Program options) for
-validation. Below are instructions about how to build these 3rd party
-libraries.
-
-@note By default the build of the validation and benchmark tests is disabled, to enable it use `validation_tests=1` and `benchmark_tests=1`
-
-@subsection building_boost Building Boost
-
-First follow the instructions from the Boost library on how to setup the Boost
-build system
-(http://www.boost.org/doc/libs/1_64_0/more/getting_started/index.html).
-Afterwards the required libraries can be build with:
-
-    ./b2 --with-program_options --with-test link=static \
-    define=BOOST_TEST_ALTERNATIVE_INIT_API
-
-Additionally, depending on your environment, it might be necessary to specify
-the ```toolset=``` option to choose the right compiler. Moreover,
-```address-model=32``` can be used to force building for 32bit and
-```target-os=android``` must be specified to build for Android.
-
-After executing the build command the libraries
-```libboost_program_options.a``` and ```libboost_unit_test_framework.a``` can
-be found in ```./stage/lib```.
-<!-- FIXME: end remove -->
-
 @section tests_running_tests Running tests
-@subsection tests_running_tests_benchmarking Benchmarking
+@subsection tests_running_tests_benchmark_and_validation Benchmarking and validation suites
 @subsubsection tests_running_tests_benchmarking_filter Filter tests
 All tests can be run by invoking
 
@@ -412,37 +381,6 @@ To run the OpenCL precommit benchmark tests with OpenCL kernel timers in milisec
 
 	LD_LIBRARY_PATH=. ./arm_compute_benchmark --mode=precommit --filter="^CL.*" --instruments="opencl_timer_ms" --iterations=10
 
-<!-- FIXME: Remove before release and change above to benchmark and validation -->
-@subsection tests_running_tests_validation Validation
-
-@note The new validation tests have the same interface as the benchmarking tests.
-
-@subsubsection tests_running_tests_validation_filter Filter tests
-All tests can be run by invoking
-
-    ./arm_compute_validation -- ./data
-
-where `./data` contains the assets needed by the tests.
-
-As running all tests can take a lot of time the suite is split into "precommit" and "nightly" tests. The precommit tests will be fast to execute but still cover the most important features. In contrast the nightly tests offer more extensive coverage but take longer. The different subsets can be selected from the command line as follows:
-
-    ./arm_compute_validation -t @precommit -- ./data
-    ./arm_compute_validation -t @nightly -- ./data
-
-Additionally it is possible to select specific suites or tests:
-
-    ./arm_compute_validation -t CL -- ./data
-    ./arm_compute_validation -t NEON/BitwiseAnd/RunSmall/_0 -- ./data
-
-All available tests can be displayed with the `--list_content` switch.
-
-    ./arm_compute_validation --list_content -- ./data
-
-For a complete list of possible selectors please see: http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/runtime_config/test_unit_filtering.html
-
-@subsubsection tests_running_tests_validation_verbosity Verbosity
-There are two separate flags to control the verbosity of the test output. `--report_level` controls the verbosity of the summary produced after all tests have been executed. `--log_level` controls the verbosity of the information generated during the execution of tests. All available settings can be found in the Boost documentation for [--report_level](http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/report_level.html) and [--log_level](http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/log_level.html), respectively.
-<!-- FIXME: end remove -->
 */
 } // namespace test
 } // namespace arm_compute