update OMZ submodule to fix bug (#17570)

* Normalize_L2 relax constant input restriction

* Fix warning treated as error during windows build

.ci/azure/linux.yml

@@ -32,13 +32,13 @@ resources:
     type: github
     endpoint: openvinotoolkit
     name: openvinotoolkit/openvino_contrib
-    ref: master
+    ref: releases/2023/0
 
   - repository: testdata
     type: github
     endpoint: openvinotoolkit
     name: openvinotoolkit/testdata
-    ref: master
+    ref: releases/2023/0
 
 variables:
   - group: github
@@ -105,7 +105,7 @@ jobs:
   steps:
   - task: UsePythonVersion@0
     inputs:
-      versionSpec: '$(OV_PYTHON_VERSION)' # Setting only major & minor version will download latest release from GH repo example 3.10 will be 3.10.10. 
+      versionSpec: '$(OV_PYTHON_VERSION)' # Setting only major & minor version will download latest release from GH repo example 3.10 will be 3.10.10.
       addToPath: true
       disableDownloadFromRegistry: false
       architecture: 'x64'
@@ -366,7 +366,7 @@ jobs:
     displayName: 'Build cpp samples - gcc'
 
   - script: $(SAMPLES_INSTALL_DIR)/cpp/build_samples.sh -b $(BUILD_DIR)/cpp_samples_clang
-    env: 
+    env:
       CC: clang
       CXX: clang++
     displayName: 'Build cpp samples - clang'

.ci/azure/linux_coverity.yml

@@ -4,7 +4,7 @@ resources:
     type: github
     endpoint: openvinotoolkit
     name: openvinotoolkit/openvino_contrib
-    ref: master
+    ref: releases/2023/0
 
 variables:
   - group: github

.ci/azure/linux_debian.yml

@@ -34,7 +34,7 @@ resources:
     type: github
     endpoint: openvinotoolkit
     name: openvinotoolkit/testdata
-    ref: master
+    ref: releases/2023/0
 
 jobs:
 - job: Lin_Debian

.ci/azure/linux_lohika.yml

@@ -4,7 +4,7 @@
 #    type: github
 #    endpoint: openvinotoolkit
 #    name: openvinotoolkit/testdata
-#    ref: master
+#    ref: releases/2023/0
 
 jobs:
 - job: Lin_lohika

.ci/azure/mac.yml

@@ -35,13 +35,13 @@ resources:
     type: github
     endpoint: openvinotoolkit
     name: openvinotoolkit/openvino_contrib
-    ref: master
+    ref: releases/2023/0
 
   - repository: testdata
     type: github
     endpoint: openvinotoolkit
     name: openvinotoolkit/testdata
-    ref: master
+    ref: releases/2023/0
 
 variables:
   - group: github

.ci/azure/windows.yml

@@ -32,13 +32,13 @@ resources:
     type: github
     endpoint: openvinotoolkit
     name: openvinotoolkit/openvino_contrib
-    ref: master
+    ref: releases/2023/0
 
   - repository: testdata
     type: github
     endpoint: openvinotoolkit
     name: openvinotoolkit/testdata
-    ref: master
+    ref: releases/2023/0
 
 jobs:
 - job: Win

.ci/openvino-onnx/Dockerfile

@@ -1,4 +1,4 @@
-FROM ubuntu:22.04
+FROM ubuntu:23.04
 
 LABEL version=2021.03.30.1
 
@@ -38,6 +38,7 @@ RUN apt-get update && apt-get -y --no-install-recommends install \
         python3 \
         python3-pip \
         python3-dev \
+        pybind11-dev \
         python3-virtualenv \
         cython3 \
         tox && \
@@ -71,5 +72,5 @@ RUN ninja install
 WORKDIR /openvino/src/bindings/python
 ENV OpenVINO_DIR=/openvino/dist/runtime/cmake
 ENV LD_LIBRARY_PATH=/openvino/dist/runtime/lib/intel64:/openvino/dist/runtime/3rdparty/tbb/lib
-ENV PYTHONPATH=/openvino/bin/intel64/${BUILD_TYPE}/python_api/python3.10:${PYTHONPATH}
+ENV PYTHONPATH=/openvino/bin/intel64/${BUILD_TYPE}/python_api/python3.11:${PYTHONPATH}
 CMD tox

cmake/dependencies.cmake

@@ -98,10 +98,10 @@ function(ov_download_tbb)
         # TODO: add target_path to be platform specific as well, to avoid following if
         # build oneTBB 2021.2.1 with Visual Studio 2019 (MSVC 14.21)
         RESOLVE_DEPENDENCY(TBB
-                ARCHIVE_WIN "oneapi-tbb-2021.2.1-win.zip"
+                ARCHIVE_WIN "oneapi-tbb-2021.2.2-win.zip"
                 TARGET_PATH "${TEMP}/tbb"
                 ENVIRONMENT "TBBROOT"
-                SHA256 "d81591673bd7d3d9454054642f8ef799e1fdddc7b4cee810a95e6130eb7323d4"
+                SHA256 "103b19a8af288c6a7d83ed3f0d2239c4afd0dd189fc12aad1d34b3c9e78df94b"
                 USE_NEW_LOCATION TRUE)
     elseif(ANDROID AND X86_64)
         RESOLVE_DEPENDENCY(TBB

cmake/developer_package/native_compile.cmake

@@ -99,6 +99,10 @@ function(ov_native_compile_external_project)
         list(APPEND ARG_CMAKE_ARGS "-DCMAKE_C_COMPILER_LAUNCHER=${CMAKE_C_COMPILER_LAUNCHER}")
     endif()
 
+    if(DEFINED CMAKE_MAKE_PROGRAM)
+        list(APPEND ARG_CMAKE_ARGS "-DCMAKE_MAKE_PROGRAM=${CMAKE_MAKE_PROGRAM}")
+    endif()
+
     ExternalProject_Add(${ARG_TARGET_NAME}
         # Directory Options
         SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}"

cmake/features.cmake

@@ -96,7 +96,7 @@ ie_option (ENABLE_HETERO "Enables Hetero Device Plugin" ON)
 
 ie_option (ENABLE_TEMPLATE "Enable template plugin" ON)
 
-ie_dependent_option (ENABLE_PLUGINS_XML "Generate plugins.xml configuration file or not" OFF "NOT BUILD_SHARED_LIBS" OFF)
+ie_dependent_option (ENABLE_PLUGINS_XML "Generate plugins.xml configuration file or not" OFF "BUILD_SHARED_LIBS" OFF)
 
 ie_dependent_option (GAPI_TEST_PERF "if GAPI unit tests should examine performance" OFF "ENABLE_TESTS;ENABLE_GAPI_PREPROCESSING" OFF)
 

docs/Documentation/openvino_ecosystem.md

@@ -100,7 +100,7 @@ A framework and CLI tool to build, transform, and analyze datasets.
 
 More resources:
 
-* `Documentation on GitHub <https://openvinotoolkit.github.io/datumaro/docs/>`__  
+* `Documentation on GitHub <https://openvinotoolkit.github.io/datumaro/stable/docs/get-started/introduction.html>`__  
 * `PyPI <https://pypi.org/project/datumaro/>`__  
 * `GitHub <https://github.com/openvinotoolkit/datumaro>`__  
 

docs/Documentation/openvino_training_extensions.md

@@ -26,14 +26,15 @@ If the results are unsatisfactory, add datasets and perform the same steps, star
 OpenVINO Training Extensions Components
 #######################################
 
-- `OpenVINO Training Extensions SDK <https://github.com/openvinotoolkit/training_extensions/tree/master/ote_sdk>`__
-- `OpenVINO Training Extensions CLI <https://github.com/openvinotoolkit/training_extensions/tree/master/ote_cli>`__
-- `OpenVINO Training Extensions Algorithms <https://github.com/openvinotoolkit/training_extensions/tree/master/external>`__
+* `OpenVINO Training Extensions API <https://github.com/openvinotoolkit/training_extensions/tree/develop/otx/api>`__
+* `OpenVINO Training Extensions CLI <https://github.com/openvinotoolkit/training_extensions/tree/develop/otx/cli>`__
+* `OpenVINO Training Extensions Algorithms <https://github.com/openvinotoolkit/training_extensions/tree/develop/otx/algorithms>`__
 
 Tutorials
 #########
 
-`Object Detection <https://github.com/openvinotoolkit/training_extensions/blob/master/ote_cli/notebooks/train.ipynb>`__
+* `Base tutorial <https://openvinotoolkit.github.io/training_extensions/stable/guide/tutorials/base/index.html>`__
+* `Advanced tutorial <https://openvinotoolkit.github.io/training_extensions/stable/guide/tutorials/advanced/index.html>`__
 
 @endsphinxdirective 
 

docs/Extensibility_UG/Intro.md

@@ -9,7 +9,6 @@
    openvino_docs_Extensibility_UG_add_openvino_ops
    openvino_docs_Extensibility_UG_Frontend_Extensions
    openvino_docs_Extensibility_UG_GPU
-   openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer
    
 .. toctree::
    :maxdepth: 1
@@ -18,6 +17,12 @@
    openvino_docs_transformations
    OpenVINO Plugin Developer Guide <openvino_docs_ie_plugin_dg_overview>
 
+.. toctree::
+   :maxdepth: 1
+   :hidden:
+   
+   openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer
+
 The Intel® Distribution of OpenVINO™ toolkit supports neural network models trained with various frameworks, including
 TensorFlow, PyTorch, ONNX, TensorFlow Lite, PaddlePaddle, Apache MXNet, Caffe, and Kaldi. The list of supported operations is different for
 each of the supported frameworks. To see the operations supported by your framework, refer to :doc:`Supported Framework Operations <openvino_docs_MO_DG_prepare_model_Supported_Frameworks_Layers>`.
@@ -54,7 +59,7 @@ Mapping of custom operation is implemented differently, depending on model forma
 
 1. If a model is represented in the ONNX (including models exported from Pytorch in ONNX), TensorFlow Lite, PaddlePaddle or TensorFlow formats, then one of the classes from :doc:`Frontend Extension API <openvino_docs_Extensibility_UG_Frontend_Extensions>` should be used. It consists of several classes available in C++ which can be used with the ``--extensions`` option in Model Optimizer or when a model is imported directly to OpenVINO runtime using the ``read_model`` method. Python API is also available for runtime model import.
 
-2. If a model is represented in the Caffe, Kaldi or MXNet formats, then :doc:`Model Optimizer Extensions <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` should be used. This approach is available for model conversion in Model Optimizer only.
+2. If a model is represented in the Caffe, Kaldi or MXNet formats, then :doc:`[Legacy] Model Optimizer Extensions <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` should be used. This approach is available for model conversion in Model Optimizer only.
 
 Existing of two approaches simultaneously is explained by two different types of frontends used for model conversion in OpenVINO: new frontends (ONNX, PaddlePaddle, TensorFlow Lite and TensorFlow) and legacy frontends (Caffe, Kaldi and Apache MXNet). Model Optimizer can use both front-ends in contrast to the direct import of model with ``read_model`` method which can use new frontends only. Follow one of the appropriate guides referenced above to implement mappings depending on framework frontend.
 
@@ -121,6 +126,8 @@ The ``Identity`` is a custom operation class defined in :doc:`Custom Operation G
 When Python API is used, there is no way to implement a custom OpenVINO operation. Even if custom OpenVINO operation is implemented in C++ and loaded into the runtime by a shared library, there is still no way to add a frontend mapping extension that refers to this custom operation. In this case, use C++ shared library approach to implement both operations semantics and framework mapping.
 
 Python can still be used to map and decompose operations when only operations from the standard OpenVINO operation set are used.
+
+.. _create_a_library_with_extensions:
  
 Create a Library with Extensions
 ++++++++++++++++++++++++++++++++
@@ -187,4 +194,4 @@ See Also
 * :doc:`Using OpenVINO Runtime Samples <openvino_docs_OV_UG_Samples_Overview>`
 * :doc:`Hello Shape Infer SSD sample <openvino_inference_engine_samples_hello_reshape_ssd_README>`
 
-@endsphinxdirective
+@endsphinxdirective

docs/Extensibility_UG/frontend_extensions.md

@@ -19,6 +19,11 @@ guide.
    operation that is a placeholder for your real custom operation. You can review the complete code, 
    which is fully compilable, to see how it works.
 
+
+.. note::
+   You can find more examples of extensions in `openvino_contrib repository <https://github.com/openvinotoolkit/openvino_contrib/tree/master/modules/custom_operations>`_.
+
+
 Single Operation Mapping with OpExtension
 #########################################
 
@@ -108,10 +113,18 @@ as it was demonstrated with ``TemplateExtension::Identity``.
 Attribute Mapping
 ++++++++++++++++++
 
-As described above, ``OpExtension`` is useful when attributes can be mapped one by one or initialized by a constant. 
+As described above, ``OpExtension`` is useful when attributes can be mapped one by one or initialized by a constant.
+Attributes in OpenVINO operators are identified by their names, so for frameworks that also have named attributes (like TensorFlow, PaddlePaddle, ONNX), 
+you can specify name to name mapping. For frameworks where OpenVINO operator's attributes can be mapped to one of the framework 
+operator inputs (like PyTorch), there's a name to input index mapping.
+
+
+Named attributes mapping
+^^^^^^^^^^^^^^^^^^^^^^^^
+
 If the set of attributes in framework representation and OpenVINO representation completely match by their names and types, 
-nothing should be specified in OpExtension constructor parameters. The attributes are discovered and mapped 
-automatically based on ``visit_attributes`` method that should be defined for any OpenVINO operation.
+no attribute mapping has to be specified in OpExtension constructor parameters. The attributes are discovered and mapped automatically 
+based on ``visit_attributes`` method that should be defined for any OpenVINO operation.
 
 Imagine you have CustomOperation class implementation that has two attributes with names: ``attr1`` and ``attr2``.
 
@@ -119,14 +132,15 @@ Imagine you have CustomOperation class implementation that has two attributes wi
    :language: cpp
    :fragment: [frontend_extension_CustomOperation]
 
-And the original model in the framework representation also has operation named “CustomOperation” with the same 
+And original model in framework representation also has operation with name ``CustomOperation`` with the same 
 ``attr1`` and ``attr2`` attributes. Then with the following code:
 
 .. doxygensnippet:: docs/snippets/ov_extensions.cpp
    :language: cpp
    :fragment: [frontend_extension_CustomOperation_as_is]
 
-Both ``attr1`` and ``attr2`` are copied from framework representation to OpenVINO representation automatically. 
+Both ``attr1`` and ``attr2`` are copied from framework representation to OpenVINO representation automatically.
+
 If for some reason names of attributes are different but values still can be copied “as-is” you can pass attribute 
 names mapping in ``OpExtension`` constructor:
 
@@ -144,48 +158,123 @@ to achieve that do the following:
    :language: cpp
    :fragment: [frontend_extension_CustomOperation_rename_set]
 
+
 So the conclusion is that each attribute of target OpenVINO operation should be initialized either by
 
 1. Setting automatically due to name matching
 2. Mapped by attribute name
 3. Set to a constant value
 
-This is achieved by specifying maps as arguments for `OpExtension` constructor.
+This is achieved by specifying maps as arguments for ``OpExtension`` constructor.
+
+
+Attribute mapping with named inputs and outputs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Mappings in previous examples assume that inputs and outputs of an operator in framework model representation come 
+with a particular order so you can directly map framework operation input ``0`` to OpenVINO operation input ``0`` and so on. 
+That's not always the case, for frameworks like PaddlePaddle, operation inputs and outputs are identified by their names 
+and may be defined in any order. So to map it to OpenVINO operation inputs and outputs, you have to specify that order yourself. 
+This can be done by creating two vector of strings, one for input and one for output, where framework operation 
+input name at position ``i`` maps to OpenVINO operation input at position ``i`` (and similarly for outputs).
+
+
+Let's see the following example. Like previously, we'd like to map ``CustomOperation`` in the original model, 
+to OpenVINO ``CustomOperation`` as is (so their name and attributes names match). This time, that framework operation 
+inputs and outputs are not stricly ordered and can be identified  by their names ``A``, ``B``, ``C`` for inputs 
+and ``X``, ``Y`` for outputs. Those inputs and outputs can be mapped to OpenVINO operation, such that inputs 
+``A``, ``B``, ``C`` map to OpenVINO ``CustomOperation`` first, second and third input and ``X`` and ``Y`` 
+outputs map to OpenVINO ``CustomOperation`` first and second output respectively. 
+
+Given that, such custom operation can be registered by the following:
+
+.. doxygensnippet:: docs/snippets/ov_extensions.cpp
+   :language: cpp
+   :fragment: [frontend_extension_CustomOperation_as_is_paddle]
+
+
+Second example shows how to map the operation with named inputs and outputs, but when names of attributes are different:
+
+.. doxygensnippet:: docs/snippets/ov_extensions.cpp
+   :language: cpp
+   :fragment: [frontend_extension_CustomOperation_rename_paddle]
+
+
+and the last one shows how to map the operation with named inputs and outputs, but when (in order to correctly map framework 
+operation to OpenVINO operation) one of the attributes has to be set to predefined value:
+
+.. doxygensnippet:: docs/snippets/ov_extensions.cpp
+   :language: cpp
+   :fragment: [frontend_extension_CustomOperation_rename_set_paddle]
+
+
+Mapping attributes from operation inputs
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For models (like PyTorch models), where operations have attributes on the input list, you can specify name to input index mapping.
+For example, imagine you have created a custom OpenVINO operation that implements a variant of ELU activation function 
+with two attributes ``alpha`` and ``beta``:
+
+.. math::
+
+    CustomElu=\left\lbrace
+    \begin{array}{ll}
+    beta * x & \textrm{if x > 0} \newline
+    alpha * (exp(x) - 1) & \textrm{otherwise}
+    \end{array}
+    \right.
+
+Below is a snippet of ``CustomElu`` class showing how to define its attributes: 
+
+.. doxygensnippet:: docs/snippets/ov_extensions.cpp
+   :language: cpp
+   :fragment: [frontend_extension_framework_map_CustomElu]
+
+Let's see an example of how you can map ``CustomElu`` to PyTorch `aten::elu <https://pytorch.org/docs/stable/generated/torch.nn.functional.elu.html>`_ 
+(note that if ``beta`` is equal to ``1``, ``CustomElu`` works the same as ``aten::elu``).
+``aten::elu`` has ``alpha`` attribute second on the input list, but it doesn't have ``beta``. 
+So in order to map it to ``CustomElu`` you can use the following:
+
+.. doxygensnippet:: docs/snippets/ov_extensions.cpp
+   :language: cpp
+   :fragment: [frontend_extension_framework_map_CustomElu_mapping]
+
+This will map ``alpha`` to the second input and map ``beta`` attribute to constant value ``1.0f``.
+
+Such created extension can be used, e.g. in dynamic library, please refer to :ref:`Create a library with extensions <create_a_library_with_extensions>`.
 
 Mapping custom operations to frontends with OPENVINO_FRAMEWORK_MAP macro
----------------------------------------------------------------------------
+########################################################################
 
-.. note:: 
-   
-   Below solution works only for ONNX and Tensorflow frontends.
+``OPENVINO_FRAMEWORK_MAP`` is a macro that should be used inside OpenVINO operation's class definition and that lets you specify 
+the mapping between this operation to a frontend operation.
 
-``OPENVINO_FRAMEWORK_MAP`` is a macro that should be used inside OpenVINO operation's class definition 
-and that lets you specify the mapping between this operation to a frontend operation.
+Let's consider the following example. Imagine you have an ONNX model with ``CustomOp`` operation (and this operation has ``mode`` attribute), 
+a TensorFlow model with ``CustomOpV3`` operation (this operation has ``axis`` attribute) and a PaddlePaddle model with ``CustomOp`` (with ``mode`` attribute) 
+that has input named "X" and output named "Out" and all of them can be implemented with a single OpenVINO operation ``CustomOp`` like follows:
 
-Let's consider the following example. Imagine you have an ONNX model with ``CustomOp`` operation 
-(and this operation has ``mode`` attribute) and a Tensorflow model with ``CustomOpV3`` operation 
-(this operation has ``axis`` attribute) and both of them can be implemented with a single OpenVINO 
-operation ``CustomOp`` like follows:
-
-.. doxygensnippet:: ov_extensions.cpp
+.. doxygensnippet:: docs/snippets/ov_extensions.cpp
    :language: cpp
    :fragment: [frontend_extension_framework_map_macro_headers]
 
-.. doxygensnippet:: ov_extensions.cpp
+.. doxygensnippet:: docs/snippets/ov_extensions.cpp
    :language: cpp
    :fragment: [frontend_extension_framework_map_macro_CustomOp]
 
+Let's take a closer look at the parameters this macro takes (note that there are two flavors - the second one is to map 
+for PaddlePaddle operations where input and output names have to be specified).
 
-Let's take a closer look at the parameters this macro takes:
-
-.. code-block::cpp
+.. code-block:: cpp
 
    OPENVINO_FRAMEWORK_MAP(framework, name, attributes_map, attributes_values)
+   OPENVINO_FRAMEWORK_MAP(framework, input_names, output_names, name, attributes_map, attributes_values)
 
 - ``framework`` - framework name.
 - ``name`` - the framework operation name. It's optional if the OpenVINO custom operation name 
-  (that is the name that is passed as the first parameter to `OPENVINO_OP` macro) is the 
-  same as the framework operation name and both ``attributes_map`` and ``attributes_values`` are not provided.
+  (that is the name that is passed as the first parameter to ``OPENVINO_OP`` macro) is the same 
+  as the framework operation name and both ``attributes_map`` and ``attributes_values`` are not provided.
+- ``input_names`` - vector of strings that specify the names of inputs (needed to map PaddlePaddle to OpenVINO operations),
+- ``output_names`` - vector of strings that specify the names of outputs (needed to map PaddlePaddle to OpenVINO operations),
 - ``attributes_map`` - used to provide a mapping between OpenVINO operation attribute and 
   framework operation attribute. Contains key-value pairs, where key is an OpenVINO operation 
   attribute name and value is its corresponding framework operation attribute name. 
@@ -196,14 +285,21 @@ Let's take a closer look at the parameters this macro takes:
   operation attribute name and the value is this attribute value. This parameter cannot be provided 
   if ``attributes_map`` contains all of OpenVINO operation attributes or if ``attributes_map`` is not provided.
 
-In the example above, ``OPENVINO_FRAMEWORK_MAP`` is used twice.
+In the example above, ``OPENVINO_FRAMEWORK_MAP`` is used three times.
 First, OpenVINO ``CustomOp`` is mapped to ONNX ``CustomOp`` operation, ``m_mode`` attribute is mapped to ``mode`` 
-attribute, while ``m_axis`` attribute gets the default value ``-1``. Secondly, OpenVINO `CustomOp` is mapped 
-to Tensorflow ``CustomOpV3`` operation, ``m_axis`` attribute is mapped to ``axis`` attribute, while ``m_mode`` 
-attribute gets the default value ``linear``.
+attribute, while ``m_axis`` attribute gets the default value ``-1``. Secondly, OpenVINO ``CustomOp`` is mapped 
+to TensorFlow ``CustomOpV3`` operation, ``m_axis`` attribute is mapped to ``axis`` attribute, while ``m_mode`` 
+attribute gets the default value ``"linear"``. Thirdly, OpenVINO ``CustomOp`` is mapped to PaddlePaddle ``CustomOp`` operation, 
+``m_mode`` attribute is mapped to ``mode`` attribute, while ``m_axis`` attribute gets the default value ``-1``. 
+This mapping also specifies the input name "X" and output name "Out".
 
 The last step is to register this custom operation by following:
-@snippet ov_extensions.cpp frontend_extension_framework_map_macro_add_extension
+
+
+.. doxygensnippet:: docs/snippets/ov_extensions.cpp
+   :language: cpp
+   :fragment: [frontend_extension_framework_map_macro_add_extension]
+
 
 Mapping to Multiple Operations with ConversionExtension
 #######################################################
@@ -222,7 +318,7 @@ operations constructing dependency graph of any complexity.
 operation classes. Follow chapter :ref:`Build a Model in OpenVINO Runtime <ov_ug_build_model>` to 
 learn how to use OpenVINO operation classes to build a fragment of model for replacement.
 
-The next example illustrates using ``ConversionExtension`` for conversion of “ThresholdedRelu” 
+Below example illustrates using ``ConversionExtension`` for conversion of “ThresholdedRelu” 
 from ONNX according to the formula: ``ThresholdedRelu(x, alpha) -> Multiply(x, Convert(Greater(x, alpha), type=float))``.
 
 .. note:: 
@@ -264,12 +360,23 @@ from ONNX according to the formula: ``ThresholdedRelu(x, alpha) -> Multiply(x, C
          :fragment: [py_frontend_extension_ThresholdedReLU]
 
 
-To access original framework operation attribute value and connect to inputs, 
-``node`` object of type ``NodeContext`` is used. It has two main methods:
+The next example shows how to use ``ConversionExtension`` to convert PyTorch 
+`aten::hardtanh <https://pytorch.org/docs/stable/generated/torch.nn.functional.hardtanh.html>`_ 
+to demonstrate how to use ``get_values_from_const_input`` function to fetch an attribute value from input:
+
+
+.. doxygensnippet:: docs/snippets/ov_extensions.py
+   :language: python
+   :fragment: [py_frontend_extension_aten_hardtanh]
+
+
+To access original framework operation attribute value and connect to inputs, ``node`` object of type ``NodeContext`` is used. It has three main methods:
 
 * ``NodeContext::get_input`` to get input with a given index,
 
-* ``NodeContext::get_attribute`` to get attribute value with a given name.
+* ``NodeContext::get_attribute`` to get attribute value with a given name,
+
+* ``NodeContext::get_values_from_const_input`` to get an attribute with a given input index.
 
 The conversion function should return a vector of node outputs that are mapped to 
 corresponding outputs of the original framework operation in the same order.

docs/MO_DG/Deep_Learning_Model_Optimizer_DevGuide.md

@@ -13,6 +13,7 @@
    openvino_docs_MO_DG_prepare_model_convert_model_Cutting_Model
    openvino_docs_MO_DG_Additional_Optimization_Use_Cases
    openvino_docs_MO_DG_FP16_Compression
+   openvino_docs_MO_DG_Python_API
    openvino_docs_MO_DG_prepare_model_Model_Optimizer_FAQ
 
 
@@ -138,5 +139,6 @@ Below is a list of separate examples for different frameworks and Model Optimize
 
 - To get conversion recipes for specific TensorFlow, ONNX, PyTorch, Apache MXNet, and Kaldi models, refer to the :doc:`Model Conversion Tutorials <openvino_docs_MO_DG_prepare_model_convert_model_tutorials>`.
 - For more information about IR, see :doc:`Deep Learning Network Intermediate Representation and Operation Sets in OpenVINO™ <openvino_docs_MO_DG_IR_and_opsets>`.
+- For more information about support of neural network models trained with various frameworks, see :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>`
 
-@endsphinxdirective
+@endsphinxdirective

docs/MO_DG/prepare_model/MO_Python_API.md

@@ -0,0 +1,110 @@
+# Model Optimizer Python API {#openvino_docs_MO_DG_Python_API}
+
+@sphinxdirective
+
+Model Optimizer (MO) has a Python API for model conversion, which is represented by the ``convert_model()`` method in the openvino.tools.mo namespace.
+
+``convert_model()`` has all the functionality available from the command-line tool, plus the ability to pass Python model objects, such as a Pytorch model or TensorFlow Keras model directly, without saving them into files and without leaving the training environment (Jupyter Notebook or training scripts). In addition to input models consumed directly from Python, ``convert_model`` can take OpenVINO extension objects constructed directly in Python for easier conversion of operations that are not supported in OpenVINO.
+ 
+``convert_model()`` returns an openvino.runtime.Model object which can be compiled and inferred or serialized to IR.
+
+Example of converting a PyTorch model directly from memory:
+
+.. code-block:: python
+
+   import torchvision
+   
+   model = torchvision.models.resnet50(pretrained=True)
+   ov_model = convert_model(model)
+
+The following types are supported as an input model for ``convert_model()``:
+
+* PyTorch - ``torch.nn.Module``, ``torch.jit.ScriptModule``, ``torch.jit.ScriptFunction``. Refer to the :doc:`Converting a PyTorch Model<openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_PyTorch>` article for more details.
+* TensorFlow / TensorFlow 2 / Keras - ``tf.keras.Model``, ``tf.keras.layers.Layer``, ``tf.compat.v1.Graph``, ``tf.compat.v1.GraphDef``, ``tf.Module``, ``tf.function``, ``tf.compat.v1.session``, ``tf.train.checkpoint``. Refer to the :doc:`Converting a TensorFlow Model<openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_TensorFlow>` article for more details.
+
+``convert_model()`` accepts all parameters available in the MO command-line tool. Parameters can be specified by Python classes or string analogs, similar to the command-line tool.
+
+Example of using native Python classes to set ``input_shape``, ``mean_values`` and ``layout``:
+
+.. code-block:: python
+
+   from openvino.runtime import PartialShape, Layout
+   
+   ov_model = convert_model(model, input_shape=PartialShape([1,3,100,100]), mean_values=[127, 127, 127], layout=Layout("NCHW"))
+
+Example of using strings for setting ``input_shape``, ``mean_values`` and ``layout``:
+
+.. code-block:: python
+
+   ov_model = convert_model(model, input_shape="[1,3,100,100]", mean_values="[127,127,127]", layout="NCHW")
+
+
+The ``input`` parameter can be set by a ``tuple`` with a name, shape, and type. The input name of the type string is required in the tuple. The shape and type are optional.
+The shape can be a ``list`` or ``tuple`` of dimensions (``int`` or ``openvino.runtime.Dimension``), or ``openvino.runtime.PartialShape``, or ``openvino.runtime.Shape``. The type can be of numpy type or ``openvino.runtime.Type``.
+
+Example of using a tuple in the ``input`` parameter to cut a model:
+
+.. code-block:: python
+
+   ov_model = convert_model(model, input=("input_name", [3], np.float32))
+
+For complex cases, when a value needs to be set in the ``input`` parameter, the ``InputCutInfo`` class can be used. ``InputCutInfo`` accepts four parameters: ``name``, ``shape``, ``type``, and ``value``. 
+
+``InputCutInfo("input_name", [3], np.float32, [0.5, 2.1, 3.4])`` is equivalent of ``InputCutInfo(name="input_name", shape=[3], type=np.float32, value=[0.5, 2.1, 3.4])``.
+
+Supported types for ``InputCutInfo``:
+
+* name: ``string``.
+* shape: ``list`` or ``tuple`` of dimensions (``int`` or ``openvino.runtime.Dimension``), ``openvino.runtime.PartialShape``, ``openvino.runtime.Shape``.
+* type: ``numpy type``, ``openvino.runtime.Type``.
+* value: ``numpy.ndarray``, ``list`` of numeric values, ``bool``.
+
+Example of using ``InputCutInfo`` to freeze an input with value:
+
+.. code-block:: python
+
+   from openvino.tools.mo import convert_model, InputCutInfo
+   
+   ov_model = convert_model(model, input=InputCutInfo("input_name", [3], np.float32, [0.5, 2.1, 3.4]))
+
+To set parameters for models with multiple inputs, use ``list`` of parameters.
+Parameters supporting ``list``: 
+
+* input
+* input_shape
+* layout 
+* source_layout
+* dest_layout
+* mean_values
+* scale_values
+
+Example of using lists to set shapes, types and layout for multiple inputs:
+
+.. code-block:: python
+
+   ov_model = convert_model(model, input=[("input1", [1,3,100,100], np.float32), ("input2", [1,3,100,100], np.float32)], layout=[Layout("NCHW"), LayoutMap("NCHW", "NHWC")])
+
+``layout``, ``source_layout`` and ``dest_layout`` accept an ``openvino.runtime.Layout`` object or ``string``.
+
+Example of using the ``Layout`` class to set the layout of a model input:
+
+.. code-block:: python
+
+   from openvino.runtime import Layout
+   from openvino.tools.mo import convert_model
+   
+   ov_model = convert_model(model, source_layout=Layout("NCHW"))
+
+To set both source and destination layouts in the ``layout`` parameter, use the ``LayoutMap`` class. ``LayoutMap`` accepts two parameters: ``source_layout`` and ``target_layout``.
+
+``LayoutMap("NCHW", "NHWC")`` is equivalent to ``LayoutMap(source_layout="NCHW", target_layout="NHWC")``.
+
+Example of using the ``LayoutMap`` class to change the layout of a model input:
+
+.. code-block:: python
+
+   from openvino.tools.mo import convert_model, LayoutMap
+   
+   ov_model = convert_model(model, layout=LayoutMap("NCHW", "NHWC"))
+
+@endsphinxdirective

docs/MO_DG/prepare_model/Model_Optimizer_FAQ.md

@@ -45,7 +45,7 @@ For example, to add the description of the ``CustomReshape`` layer, which is an
 
 3. Now, Model Optimizer is able to load the model into memory and start working with your extensions if there are any.
 
-   However, since your model has custom layers, you must register them as custom. To learn more about it, refer to :doc:`Custom Layers in Model Optimizer    <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`.
+   However, since your model has custom layers, you must register them as custom. To learn more about it, refer to the :doc:`[Legacy] Custom Layers in Model Optimizer <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`.
 
 .. _question-2:
 
@@ -69,28 +69,7 @@ Q3. What does the message "[ ERROR ]: Unable to create ports for node with id" m
 
 **A:** Most likely, Model Optimizer does not know how to infer output shapes of some layers in the given topology.
 To lessen the scope, compile the list of layers that are custom for Model Optimizer: present in the topology,
-absent in the :doc:`list of supported layers <openvino_docs_MO_DG_prepare_model_Supported_Frameworks_Layers>` for the target framework. Then, refer to available options in the corresponding section in the  :doc:`Custom Layers in Model Optimizer <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` page.
-
-.. _question-4:
-
-Q4. What does the message "Input image of shape is larger than mean image from file" mean?
-#####################################################################################################################################################
-
-**A:** Your model input shapes must be smaller than or equal to the shapes of the mean image file you provide. The idea behind the mean file is to subtract its values from the input image in an element-wise manner. When the mean file is smaller than the input image, there are not enough values to perform element-wise subtraction. Also, make sure you use the mean file that was used during the network training phase. Note that the mean file is dependent on dataset.
-
-.. _question-5:
-
-Q5. What does the message "Mean file is empty" mean?
-#####################################################################################################################################################
-
-**A:** Most likely, the mean file specified with the ``--mean_file`` flag is empty while Model Optimizer is launched. Make sure that this is exactly the required mean file and try to regenerate it from the given dataset if possible.
-
-.. _question-6:
-
-Q6. What does the message "Probably mean file has incorrect format" mean?
-#####################################################################################################################################################
-
-**A:** The mean file that you provide for Model Optimizer must be in the ``.binaryproto`` format. You can try to check the content, using recommendations from the BVLC Caffe (`#290 <https://github.com/BVLC/caffe/issues/290>`__).
+absent in the :doc:`list of supported layers <openvino_docs_MO_DG_prepare_model_Supported_Frameworks_Layers>` for the target framework. Then, refer to available options in the corresponding section in the :doc:`[Legacy] Custom Layers in Model Optimizer <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` page.
 
 .. _question-7:
 
@@ -211,14 +190,6 @@ Q9. What does the message "Mean file for topologies with multiple inputs is not
 
 **A:** Model Optimizer does not support mean file processing for topologies with more than one input. In this case, you need to perform preprocessing of the inputs for a generated Intermediate Representation in OpenVINO Runtime to perform subtraction for every input of your multi-input model. See the :doc:`Overview of Preprocessing <openvino_docs_OV_UG_Preprocessing_Overview>` for details.
 
-.. _question-10:
-
-Q10. What does the message "Cannot load or process mean file: value error" mean?
-#####################################################################################################################################################
-
-**A:** There are multiple reasons why Model Optimizer does not accept the mean file.
-See FAQs :ref:`#4 <question-4>`, :ref:`#5 <question-5>`, and :ref:`#6 <question-6>`.
-
 .. _question-11:
 
 Q11. What does the message "Invalid prototxt file: value error" mean?
@@ -238,7 +209,7 @@ Q12. What does the message "Error happened while constructing caffe.Net in the C
 Q13. What does the message "Cannot infer shapes due to exception in Caffe" mean?
 #####################################################################################################################################################
 
-**A:** Model Optimizer tried to infer a custom layer via the Caffe framework, but the model could not be inferred using Caffe. This might happen if you try to convert the model with some noise weights and biases, which conflict with layers that have dynamic shapes. You should write your own extension for every custom layer your topology might have. For more details, refer to the :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` page.
+**A:** Model Optimizer tried to infer a custom layer via the Caffe framework, but the model could not be inferred using Caffe. This might happen if you try to convert the model with some noise weights and biases, which conflict with layers that have dynamic shapes. You should write your own extension for every custom layer your topology might have. For more details, refer to the :doc:`[Legacy] Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` page.
 
 .. _question-14:
 
@@ -263,18 +234,8 @@ Q16. What does the message "Input shape is required to convert MXNet model. Plea
 
 .. _question-17:
 
-Q17. What does the message "Both --mean_file and mean_values are specified. Specify either mean file or mean values" mean?
-#####################################################################################################################################################
-
-**A:** The ``--mean_file`` and ``--mean_values`` options are two ways of specifying preprocessing for the input. However, they cannot be used together, as it would mean double subtraction and lead to ambiguity. Choose one of these options and pass it with the corresponding CLI option.
-
 .. _question-18:
 
-Q18. What does the message "Negative value specified for --mean_file_offsets option. Please specify positive integer values in format '(x,y)'" mean?
-#####################################################################################################################################################
-
-**A:** You might have specified negative values with ``--mean_file_offsets``. Only positive integer values in format '(x,y)' must be used.
-
 .. _question-19:
 
 Q19. What does the message "Both --scale and --scale_values are defined. Specify either scale factor or scale values per input channels" mean?
@@ -291,255 +252,257 @@ Q20. What does the message "Cannot find prototxt file: for Caffe please specify
 
 .. _question-21:
 
-Q21. What does the message "Failed to create directory .. . Permission denied!" mean?
+.. _question-22:
+
+Q22. What does the message "Failed to create directory .. . Permission denied!" mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer cannot create a directory specified via ``--output_dir``. Make sure that you have enough permissions to create the specified directory.
 
-.. _question-22:
+.. _question-23:
 
-Q22. What does the message "Discovered data node without inputs and value" mean?
+Q23. What does the message "Discovered data node without inputs and value" mean?
 #####################################################################################################################################################
 
 **A:** One of the layers in the specified topology might not have inputs or values. Make sure that the provided ``caffemodel`` and ``protobuf`` files are correct.
 
-.. _question-23:
+.. _question-24:
 
-Q23. What does the message "Part of the nodes was not translated to IE. Stopped" mean?
+Q24. What does the message "Part of the nodes was not translated to IE. Stopped" mean?
 #####################################################################################################################################################
 
 **A:** Some of the operations are not supported by OpenVINO Runtime and cannot be translated to OpenVINO Intermediate Representation. You can extend Model Optimizer by allowing generation of new types of operations and implement these operations in the dedicated OpenVINO plugins. For more information, refer to the :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>` guide.
 
-.. _question-24:
+.. _question-25:
 
-Q24. What does the message "While creating an edge from .. to .. : node name is undefined in the graph. Check correctness of the input model" mean?
+Q25. What does the message "While creating an edge from .. to .. : node name is undefined in the graph. Check correctness of the input model" mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer cannot build a graph based on a specified model. Most likely, it is incorrect.
 
-.. _question-25:
+.. _question-26:
 
-Q25. What does the message "Node does not exist in the graph" mean?
+Q26. What does the message "Node does not exist in the graph" mean?
 #####################################################################################################################################################
 
 **A:** You might have specified an output node via the ``--output`` flag that does not exist in a provided model. Make sure that the specified output is correct and this node exists in the current model.
 
-.. _question-26:
+.. _question-27:
 
-Q26. What does the message "--input parameter was provided. Other inputs are needed for output computation. Provide more inputs or choose another place to cut the net" mean?
+Q27. What does the message "--input parameter was provided. Other inputs are needed for output computation. Provide more inputs or choose another place to cut the net" mean?
 ##############################################################################################################################################################################
 
 **A:** Most likely, Model Optimizer tried to cut the model by a specified input. However, other inputs are needed.
 
-.. _question-27:
+.. _question-28:
 
-Q27. What does the message "Placeholder node does not have an input port, but input port was provided" mean?
+Q28. What does the message "Placeholder node does not have an input port, but input port was provided" mean?
 #####################################################################################################################################################
 
 **A:** You might have specified a placeholder node with an input node, while the placeholder node does not have it in the model.
 
-.. _question-28:
+.. _question-29:
 
-Q28. What does the message "Port index is out of number of available input ports for node" mean?
+Q29. What does the message "Port index is out of number of available input ports for node" mean?
 #####################################################################################################################################################
 
 **A:** This error occurs when an incorrect input port is specified with the ``--input`` command line argument. When using ``--input``, you may optionally specify an input port in the form: ``X:node_name``, where ``X`` is an integer index of the input port starting from 0 and ``node_name`` is the name of a node in the model. This error occurs when the specified input port ``X`` is not in the range 0..(n-1), where n is the number of input ports for the node. Specify a correct port index, or do not use it if it is not needed.
 
-.. _question-29:
+.. _question-30:
 
-Q29. What does the message "Node has more than 1 input and input shapes were provided. Try not to provide input shapes or specify input port with PORT:NODE notation, where PORT is an integer" mean?
+Q30. What does the message "Node has more than 1 input and input shapes were provided. Try not to provide input shapes or specify input port with PORT:NODE notation, where PORT is an integer" mean?
 ######################################################################################################################################################################################################
 
 **A:** This error occurs when an incorrect combination of the ``--input`` and ``--input_shape`` command line options is used. Using both ``--input`` and ``--input_shape`` is valid only if ``--input`` points to the ``Placeholder`` node, a node with one input port or ``--input`` has the form ``PORT:NODE``, where ``PORT`` is an integer port index of input for node ``NODE``. Otherwise, the combination of ``--input`` and ``--input_shape`` is incorrect.
 
 
-.. _question-30:
+.. _question-31:
 
-Q30. What does the message "Input port > 0 in --input is not supported if --input_shape is not provided. Node: NAME_OF_THE_NODE. Omit port index and all input ports will be replaced by placeholders. Or provide --input_shape" mean?
+Q31. What does the message "Input port > 0 in --input is not supported if --input_shape is not provided. Node: NAME_OF_THE_NODE. Omit port index and all input ports will be replaced by placeholders. Or provide --input_shape" mean?
 #######################################################################################################################################################################################################################################
 
 **A:** When using the ``PORT:NODE`` notation for the ``--input`` command line argument and ``PORT`` > 0, you should specify ``--input_shape`` for this input. This is a limitation of the current Model Optimizer implementation.
 
 > **NOTE**: It is no longer relevant message since the limitation on input port index for model truncation has been resolved.
 
-.. _question-31:
+.. _question-32:
 
-Q31. What does the message "No or multiple placeholders in the model, but only one shape is provided, cannot set it" mean?
+Q32. What does the message "No or multiple placeholders in the model, but only one shape is provided, cannot set it" mean?
 #####################################################################################################################################################
 
 **A:** You might have provided only one shape for the placeholder, while there are none or multiple inputs in the model. Make sure that you have provided the correct data for placeholder nodes.
 
-.. _question-32:
-
-Q32. What does the message "The amount of input nodes for port is not equal to 1" mean?
-#####################################################################################################################################################
-
-**A:** This error occurs when the ``SubgraphMatch.single_input_node`` function is used for an input port that supplies more than one node in a sub-graph. The ``single_input_node`` function can be used only for ports that has a single consumer inside the matching sub-graph. When multiple nodes are connected to the port, use the ``input_nodes`` function or ``node_by_pattern`` function instead of ``single_input_node``. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
-
 .. _question-33:
 
-Q33. What does the message "Output node for port has already been specified" mean?
+Q33. What does the message "The amount of input nodes for port is not equal to 1" mean?
+#####################################################################################################################################################
+
+**A:** This error occurs when the ``SubgraphMatch.single_input_node`` function is used for an input port that supplies more than one node in a sub-graph. The ``single_input_node`` function can be used only for ports that has a single consumer inside the matching sub-graph. When multiple nodes are connected to the port, use the ``input_nodes`` function or ``node_by_pattern`` function instead of ``single_input_node``. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`[Legacy] Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Transformation_Extensions>` guide.
+
+.. _question-34:
+
+Q34. What does the message "Output node for port has already been specified" mean?
 #####################################################################################################################################################
 
 **A:** This error occurs when the ``SubgraphMatch._add_output_node`` function is called manually from user's extension code. This is an internal function, and you should not call it directly.
 
-.. _question-34:
-
-Q34. What does the message "Unsupported match kind.... Match kinds "points" or "scope" are supported only" mean?
-#####################################################################################################################################################
-
-**A:** While using configuration file to implement a TensorFlow front replacement extension, an incorrect match kind was used. Only ``points`` or ``scope`` match kinds are supported.  For more details, refer to the :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
-
 .. _question-35:
 
-Q35. What does the message "Cannot write an event file for the TensorBoard to directory" mean?
+Q35. What does the message "Unsupported match kind.... Match kinds "points" or "scope" are supported only" mean?
+#####################################################################################################################################################
+
+**A:** While using configuration file to implement a TensorFlow front replacement extension, an incorrect match kind was used. Only ``points`` or ``scope`` match kinds are supported.  For more details, refer to the :doc:`[Legacy] Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
+
+.. _question-36:
+
+Q36. What does the message "Cannot write an event file for the TensorBoard to directory" mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer tried to write an event file in the specified directory but failed to do that. That could happen when the specified directory does not exist or you do not have permissions to write in it.
 
-.. _question-36:
+.. _question-37:
 
-Q36. What does the message "There is no registered 'infer' function for node  with op = .. . Please implement this function in the extensions" mean?
+Q37. What does the message "There is no registered 'infer' function for node  with op = .. . Please implement this function in the extensions" mean?
 #####################################################################################################################################################
 
 **A** Most likely, you tried to extend Model Optimizer with a new primitive, but you did not specify an infer function. For more information on extensions, see the :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>` guide.
 
-.. _question-37:
+.. _question-38:
 
-Q37. What does the message "Stopped shape/value propagation at node" mean?
+Q38. What does the message "Stopped shape/value propagation at node" mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer cannot infer shapes or values for the specified node. It can happen because of the following reasons: a bug exists in the custom shape infer function, the node inputs have incorrect values/shapes, or the input shapes are incorrect.
 
-.. _question-38:
+.. _question-39:
 
-Q38. What does the message "The input with shape .. does not have the batch dimension" mean?
+Q39. What does the message "The input with shape .. does not have the batch dimension" mean?
 #####################################################################################################################################################
 
 **A:** Batch dimension is the first dimension in the shape and it should be equal to 1 or undefined. In your case, it is not either equal to 1 or undefined, which is why the ``-b`` shortcut produces undefined and unspecified behavior. To resolve the issue, specify full shapes for each input with the ``--input_shape`` option. Run Model Optimizer with the ``--help`` option to learn more about the notation for input shapes.
 
-.. _question-39:
+.. _question-40:
 
-Q39. What does the message "Not all output shapes were inferred or fully defined for node" mean?
+Q40. What does the message "Not all output shapes were inferred or fully defined for node" mean?
 #####################################################################################################################################################
 
 **A:** Most likely, the shape is not defined (partially or fully) for the specified node. You can use ``--input_shape`` with positive integers to override model input shapes.
 
-.. _question-40:
+.. _question-41:
 
-Q40. What does the message "Shape for tensor is not defined. Can not proceed" mean?
+Q41. What does the message "Shape for tensor is not defined. Can not proceed" mean?
 #####################################################################################################################################################
 
 **A:** This error occurs when the ``--input`` command-line option is used to cut a model and ``--input_shape`` is not used to override shapes for a node, so a shape for the node cannot be inferred by Model Optimizer. You need to help Model Optimizer by specifying shapes with ``--input_shape`` for each node specified with the ``--input`` command-line option.
 
-.. _question-41:
+.. _question-42:
 
-Q41. What does the message "Module TensorFlow was not found. Please install TensorFlow 1.2 or higher" mean?
+Q42. What does the message "Module TensorFlow was not found. Please install TensorFlow 1.2 or higher" mean?
 #####################################################################################################################################################
 
 **A:** To convert TensorFlow models with Model Optimizer, TensorFlow 1.2 or newer must be installed. For more information on prerequisites, see the :doc:`Configuring Model Optimizer <openvino_docs_MO_DG_Deep_Learning_Model_Optimizer_DevGuide>` guide.
 
-.. _question-42:
+.. _question-43:
 
-Q42. What does the message "Cannot read the model file: it is incorrect TensorFlow model file or missing" mean?
+Q43. What does the message "Cannot read the model file: it is incorrect TensorFlow model file or missing" mean?
 #####################################################################################################################################################
 
 **A:** The model file should contain a frozen TensorFlow graph in the text or binary format. Make sure that ``--input_model_is_text`` is provided for a model in the text format. By default, a model is interpreted as binary file.
 
-.. _question-43:
+.. _question-44:
 
-Q43. What does the message "Cannot pre-process TensorFlow graph after reading from model file. File is corrupt or has unsupported format" mean?
+Q44. What does the message "Cannot pre-process TensorFlow graph after reading from model file. File is corrupt or has unsupported format" mean?
 #####################################################################################################################################################
 
 **A:** Most likely, there is a problem with the specified file for the model. The file exists, but it has an invalid format or is corrupted.
 
-.. _question-44:
+.. _question-45:
 
-Q44. What does the message "Found custom layer. Model Optimizer does not support this layer. Please, register it in CustomLayersMapping.xml or implement extension" mean?
+Q45. What does the message "Found custom layer. Model Optimizer does not support this layer. Please, register it in CustomLayersMapping.xml or implement extension" mean?
 ##########################################################################################################################################################################
 
 **A:** This means that the layer ``{layer_name}`` is not supported in Model Optimizer. You will find a list of all unsupported layers in the corresponding section. You should implement the extensions for this layer. See :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>` for more information.
 
-.. _question-45:
+.. _question-46:
 
-Q45. What does the message "Custom replacement configuration file does not exist" mean?
+Q46. What does the message "Custom replacement configuration file does not exist" mean?
 #####################################################################################################################################################
 
 **A:** A path to the custom replacement configuration file was provided with the ``--transformations_config`` flag, but the file could not be found. Make sure the specified path is correct and the file exists.
 
-.. _question-46:
+.. _question-47:
 
-Q46. What does the message "Extractors collection have case insensitive duplicates" mean?
+Q47. What does the message "Extractors collection have case insensitive duplicates" mean?
 #####################################################################################################################################################
 
 **A:** When extending Model Optimizer with new primitives, keep in mind that their names are case-insensitive. Most likely, another operation with the same name is already defined. For more information, see the :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>` guide.
 
-.. _question-47:
+.. _question-48:
 
-Q47. What does the message "Input model name is not in an expected format, cannot extract iteration number" mean?
+Q48. What does the message "Input model name is not in an expected format, cannot extract iteration number" mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer cannot load an MXNet model in the specified file format. Make sure you use the ``.json`` or ``.param`` format.
 
-.. _question-48:
+.. _question-49:
 
-Q48. What does the message "Cannot convert type of placeholder because not all of its outputs are 'Cast' to float operations" mean?
+Q49. What does the message "Cannot convert type of placeholder because not all of its outputs are 'Cast' to float operations" mean?
 #####################################################################################################################################################
 
 **A:** There are models where ``Placeholder`` has the UINT8 type and the first operation after it is 'Cast', which casts the input to FP32. Model Optimizer detected that the ``Placeholder`` has the UINT8 type, but the next operation is not 'Cast' to float. Model Optimizer does not support such a case. Make sure you change the model to have ``Placeholder`` for FP32.
 
-.. _question-49:
+.. _question-50:
 
-Q49. What does the message "Data type is unsupported" mean?
+Q50. What does the message "Data type is unsupported" mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer cannot read the value with the specified data type. Currently, the following types are supported: bool, float16, float32, double, int8, int16, int32, int64, uint8, uint16, uint32, uint64, str.
 
-.. _question-50:
+.. _question-51:
 
-Q50. What does the message "No node with name ..." mean?
+Q51. What does the message "No node with name ..." mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer tried to access a node that does not exist. This could happen if you have incorrectly specified placeholder, input or output node name.
 
-.. _question-51:
+.. _question-52:
 
-Q51. What does the message "Module MXNet was not found. Please install MXNet 1.0.0" mean?
+Q52. What does the message "Module MXNet was not found. Please install MXNet 1.0.0" mean?
 #####################################################################################################################################################
 
 **A:** To convert MXNet models with Model Optimizer, Apache MXNet 1.0.0 must be installed. For more information about prerequisites, see the :doc:`Configuring Model Optimizer <openvino_docs_MO_DG_Deep_Learning_Model_Optimizer_DevGuide>` guide.
 
-.. _question-52:
+.. _question-53:
 
-Q52. What does the message "The following error happened while loading MXNet model .." mean?
+Q53. What does the message "The following error happened while loading MXNet model .." mean?
 #####################################################################################################################################################
 
 **A:** Most likely, there is a problem with loading of the MXNet model. Make sure the specified path is correct, the model exists and is not corrupted, and you have sufficient permissions to work with it.
 
-.. _question-53:
+.. _question-54:
 
-Q53. What does the message "The following error happened while processing input shapes: .." mean?
+Q54. What does the message "The following error happened while processing input shapes: .." mean?
 #####################################################################################################################################################
 
 **A:** Make sure inputs are defined and have correct shapes. You can use ``--input_shape`` with positive integers to override model input shapes.
 
-.. _question-54:
+.. _question-55:
 
-Q54. What does the message "Attempt to register of custom name for the second time as class. Note that custom names are case-insensitive" mean?
+Q55. What does the message "Attempt to register of custom name for the second time as class. Note that custom names are case-insensitive" mean?
 #####################################################################################################################################################
 
 **A:** When extending Model Optimizer with new primitives, keep in mind that their names are case-insensitive. Most likely, another operation with the same name is already defined. For more information, see the :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>` guide.
 
-.. _question-55:
+.. _question-56:
 
-Q55. What does the message "Both --input_shape and --batch were provided. Please, provide only one of them" mean?
+Q56. What does the message "Both --input_shape and --batch were provided. Please, provide only one of them" mean?
 #####################################################################################################################################################
 
 **A:** Specifying the batch and the input shapes at the same time is not supported. You must specify a desired batch as the first value of the input shape.
 
-.. _question-56:
+.. _question-57:
 
-Q56. What does the message "Input shape .. cannot be parsed" mean?
+Q57. What does the message "Input shape .. cannot be parsed" mean?
 #####################################################################################################################################################
 
 **A:** The specified input shape cannot be parsed. Define it in one of the following ways:
@@ -565,170 +528,170 @@ Q56. What does the message "Input shape .. cannot be parsed" mean?
 
 Keep in mind that there is no space between and inside the brackets for input shapes.
 
-.. _question-57:
+.. _question-58:
 
-Q57. What does the message "Please provide input layer names for input layer shapes" mean?
+Q58. What does the message "Please provide input layer names for input layer shapes" mean?
 #####################################################################################################################################################
 
 **A:** When specifying input shapes for several layers, you must provide names for inputs, whose shapes will be overwritten. For usage examples, see the :doc:`Converting a Caffe Model <openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_Caffe>`. Additional information for ``--input_shape`` is in FAQ :ref:`#56 <question-56>`.
 
-.. _question-58:
+.. _question-59:
 
-Q58. What does the message "Values cannot be parsed" mean?
+Q59. What does the message "Values cannot be parsed" mean?
 #####################################################################################################################################################
 
 **A:** Mean values for the given parameter cannot be parsed. It should be a string with a list of mean values. For example, in '(1,2,3)', 1 stands for the RED channel, 2 for the GREEN channel, 3 for the BLUE channel.
 
-.. _question-59:
+.. _question-60:
 
-Q59. What does the message ".. channels are expected for given values" mean?
+Q60. What does the message ".. channels are expected for given values" mean?
 #####################################################################################################################################################
 
 **A:** The number of channels and the number of given values for mean values do not match. The shape should be defined as '(R,G,B)' or '[R,G,B]'. The shape should not contain undefined dimensions (? or -1). The order of values is as follows: (value for a RED channel, value for a GREEN channel, value for a BLUE channel).
 
-.. _question-60:
+.. _question-61:
 
-Q60. What does the message "You should specify input for each mean value" mean?
+Q61. What does the message "You should specify input for each mean value" mean?
 #####################################################################################################################################################
 
 **A:** Most likely, you didn't specify inputs using ``--mean_values``. Specify inputs with the ``--input`` flag. For usage examples, refer to the FAQ :ref:`#62 <question-62>`.
 
-.. _question-61:
+.. _question-62:
 
-Q61. What does the message "You should specify input for each scale value" mean?
+Q62. What does the message "You should specify input for each scale value" mean?
 #####################################################################################################################################################
 
 **A:** Most likely, you didn't specify inputs using ``--scale_values``. Specify inputs with the ``--input`` flag. For usage examples, refer to the FAQ :ref:`#63 <question-63>`.
 
-.. _question-62:
+.. _question-63:
 
-Q62. What does the message "Number of inputs and mean values does not match" mean?
+Q63. What does the message "Number of inputs and mean values does not match" mean?
 #####################################################################################################################################################
 
 **A:** The number of specified mean values and the number of inputs must be equal. For a usage example, refer to the :doc:`Converting a Caffe Model <openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_Caffe>` guide.
 
-.. _question-63:
+.. _question-64:
 
-Q63. What does the message "Number of inputs and scale values does not match" mean?
+Q64. What does the message "Number of inputs and scale values does not match" mean?
 #####################################################################################################################################################
 
 **A:** The number of specified scale values and the number of inputs must be equal.  For a usage example, refer to the :doc:`Converting a Caffe Model <openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_Caffe>` guide.
 
-.. _question-64:
+.. _question-65:
 
-Q64. What does the message "No class registered for match kind ... Supported match kinds are .. " mean?
+Q65. What does the message "No class registered for match kind ... Supported match kinds are .. " mean?
 #####################################################################################################################################################
 
 **A:** A replacement defined in the configuration file for sub-graph replacement, using node names patterns or start/end nodes, has the ``match_kind`` attribute. The attribute may have only one of the values: ``scope`` or ``points``. If a different value is provided, this error is displayed.
 
-.. _question-65:
-
-Q65. What does the message "No instance(s) is(are) defined for the custom replacement" mean?
-#####################################################################################################################################################
-
-**A:** A replacement defined in the configuration file for sub-graph replacement, using node names patterns or start/end nodes, has the ``instances`` attribute. This attribute is mandatory. This error will occur if the attribute is missing. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
-
 .. _question-66:
 
-Q66. What does the message "The instance must be a single dictionary for the custom replacement with id .." mean?
+Q66. What does the message "No instance(s) is(are) defined for the custom replacement" mean?
 #####################################################################################################################################################
 
-**A:** A replacement defined in the configuration file for sub-graph replacement, using start/end nodes, has the ``instances`` attribute. For this type of replacement, the instance must be defined with a dictionary with two keys ``start_points`` and ``end_points``. Values for these keys are lists with the start and end node names, respectively. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
+**A:** A replacement defined in the configuration file for sub-graph replacement, using node names patterns or start/end nodes, has the ``instances`` attribute. This attribute is mandatory. This error will occur if the attribute is missing. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`[Legacy] Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
 
 .. _question-67:
 
-Q67. What does the message "No instances are defined for replacement with id .. " mean?
+Q67. What does the message "The instance must be a single dictionary for the custom replacement with id .." mean?
+#####################################################################################################################################################
+
+**A:** A replacement defined in the configuration file for sub-graph replacement, using start/end nodes, has the ``instances`` attribute. For this type of replacement, the instance must be defined with a dictionary with two keys ``start_points`` and ``end_points``. Values for these keys are lists with the start and end node names, respectively. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`[Legacy] Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Transformation_Extensions>` guide.
+
+.. _question-68:
+
+Q68. What does the message "No instances are defined for replacement with id .. " mean?
 #####################################################################################################################################################
 
 **A:** A replacement for the specified id is not defined in the configuration file. For more information, refer to the FAQ :ref:`#65 <question-65>`.
 
-.. _question-68:
+.. _question-69:
 
-Q68. What does the message "Custom replacements configuration file .. does not exist" mean?
+Q69. What does the message "Custom replacements configuration file .. does not exist" mean?
 #####################################################################################################################################################
 
 **A:** The path to a custom replacement configuration file was provided with the ``--transformations_config`` flag, but it cannot be found. Make sure the specified path is correct and the file exists.
 
-.. _question-69:
+.. _question-70:
 
-Q69. What does the message "Failed to parse custom replacements configuration file .." mean?
+Q70. What does the message "Failed to parse custom replacements configuration file .." mean?
 #####################################################################################################################################################
 
 **A:** The file for custom replacement configuration provided with the ``--transformations_config`` flag cannot be parsed. In particular, it should have a valid JSON structure. For more details, refer to the `JSON Schema Reference <https://spacetelescope.github.io/understanding-json-schema/reference/index.html>`__ page.
 
-.. _question-70:
+.. _question-71:
 
-Q70. What does the message "One of the custom replacements in the configuration file .. does not contain attribute 'id'" mean?
+Q71. What does the message "One of the custom replacements in the configuration file .. does not contain attribute 'id'" mean?
 #####################################################################################################################################################
 
 **A:** Every custom replacement should declare a set of mandatory attributes and their values. For more details, refer to FAQ :ref:`#71 <question-71>`.
 
-.. _question-71:
+.. _question-72:
 
-Q71. What does the message "File .. validation failed" mean?
+Q72. What does the message "File .. validation failed" mean?
 #####################################################################################################################################################
 
 **A:** The file for custom replacement configuration provided with the ``--transformations_config`` flag cannot pass validation. Make sure you have specified ``id``, ``instances``, and ``match_kind`` for all the patterns.
 
-.. _question-72:
+.. _question-73:
 
-Q72. What does the message "Cannot update the file .. because it is broken" mean?
+Q73. What does the message "Cannot update the file .. because it is broken" mean?
 #####################################################################################################################################################
 
 **A:** The custom replacement configuration file provided with the ``--tensorflow_custom_operations_config_update`` cannot be parsed. Make sure that the file is correct and refer to FAQ :ref:`#68 <question-68>`, :ref:`#69 <question-69>`, :ref:`#70 <question-70>`, and :ref:`#71 <question-71>`.
 
-.. _question-73:
+.. _question-74:
 
-Q73. What does the message "End node .. is not reachable from start nodes: .." mean?
+Q74. What does the message "End node .. is not reachable from start nodes: .." mean?
 #####################################################################################################################################################
 
 **A:** This error occurs when you try to make a sub-graph match. It is detected that between the start and end nodes that were specified as inputs/outputs for the subgraph to find, there are nodes marked as outputs but there is no path from them to the input nodes. Make sure the subgraph you want to match does actually contain all the specified output nodes.
 
-.. _question-74:
-
-Q74. What does the message "Sub-graph contains network input node .." mean?
-#####################################################################################################################################################
-
-**A:** The start or end node for the sub-graph replacement using start/end nodes is specified incorrectly. Model Optimizer finds internal nodes of the sub-graph strictly "between" the start and end nodes, and then adds all input nodes to the sub-graph (and the inputs of their inputs, etc.) for these "internal" nodes. This error reports that Model Optimizer reached input node during this phase. This means that the start/end points are specified incorrectly in the configuration file. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
-
 .. _question-75:
 
-Q75. What does the message "... elements of ... were clipped to infinity while converting a blob for node [...] to ..." mean?
+Q75. What does the message "Sub-graph contains network input node .." mean?
 #####################################################################################################################################################
 
-**A:** This message may appear when the ``--compress_to_fp16`` (or deprecated ``--data_type``) command-line option is used. This option implies compression of all the model weights, biases, and other constant values to FP16. If a value of a constant is out of the range of valid FP16 values, the value is converted to positive or negative infinity. It may lead to incorrect results of inference or may not be a problem, depending on the model. The number of such elements and the total number of elements in the constant value is printed out together with the name of the node, where this value is used.
+**A:** The start or end node for the sub-graph replacement using start/end nodes is specified incorrectly. Model Optimizer finds internal nodes of the sub-graph strictly "between" the start and end nodes, and then adds all input nodes to the sub-graph (and the inputs of their inputs, etc.) for these "internal" nodes. This error reports that Model Optimizer reached input node during this phase. This means that the start/end points are specified incorrectly in the configuration file. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`[Legacy] Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Transformation_Extensions>` guide.
 
 .. _question-76:
 
-Q76. What does the message "... elements of ... were clipped to zero while converting a blob for node [...] to ..." mean?
+Q76. What does the message "... elements of ... were clipped to infinity while converting a blob for node [...] to ..." mean?
 #####################################################################################################################################################
 
-**A:** This message may appear when the ``--compress_to_fp16`` (or deprecated ``--data_type``) command-line option is used. This option implies conversion of all blobs in the mode to FP16. If a value in the blob is so close to zero that it cannot be represented as a valid FP16 value, it is converted to a true zero FP16 value. Depending on the model, it may lead to incorrect results of inference or may not be a problem. The number of such elements and the total number of elements in the blob are printed out together with a name of the node, where this blob is used.
+**A:** This message may appear when the ``--compress_to_fp16`` command-line option is used. This option implies compression of all the model weights, biases, and other constant values to FP16. If a value of a constant is out of the range of valid FP16 values, the value is converted to positive or negative infinity. It may lead to incorrect results of inference or may not be a problem, depending on the model. The number of such elements and the total number of elements in the constant value is printed out together with the name of the node, where this value is used.
 
 .. _question-77:
 
-Q77. What does the message "The amount of nodes matched pattern ... is not equal to 1" mean?
+Q77. What does the message "... elements of ... were clipped to zero while converting a blob for node [...] to ..." mean?
 #####################################################################################################################################################
 
-**A:** This error occurs when the ``SubgraphMatch.node_by_pattern`` function is used with a pattern that does not uniquely identify a single node in a sub-graph. Try to extend the pattern string to make unambiguous match to a single sub-graph node. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
+**A:** This message may appear when the ``--compress_to_fp16`` command-line option is used. This option implies conversion of all blobs in the mode to FP16. If a value in the blob is so close to zero that it cannot be represented as a valid FP16 value, it is converted to a true zero FP16 value. Depending on the model, it may lead to incorrect results of inference or may not be a problem. The number of such elements and the total number of elements in the blob are printed out together with a name of the node, where this blob is used.
 
 .. _question-78:
 
-Q78. What does the message "The topology contains no "input" layers" mean?
+Q78. What does the message "The amount of nodes matched pattern ... is not equal to 1" mean?
+#####################################################################################################################################################
+
+**A:** This error occurs when the ``SubgraphMatch.node_by_pattern`` function is used with a pattern that does not uniquely identify a single node in a sub-graph. Try to extend the pattern string to make unambiguous match to a single sub-graph node. For more details, refer to the **Graph Transformation Extensions** section in the :doc:`[Legacy] Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Transformation_Extensions>` guide.
+
+.. _question-79:
+
+Q79. What does the message "The topology contains no "input" layers" mean?
 #####################################################################################################################################################
 
 **A:** Your Caffe topology ``.prototxt`` file is intended for training. Model Optimizer expects a deployment-ready ``.prototxt`` file. To fix the problem, prepare a deployment-ready ``.prototxt`` file. Preparation of a deploy-ready topology usually results in removing ``data`` layer(s), adding ``input`` layer(s), and removing loss layer(s).
 
-.. _question-79:
+.. _question-80:
 
-Q79. What does the message "Warning: please expect that Model Optimizer conversion might be slow" mean?
+Q80. What does the message "Warning: please expect that Model Optimizer conversion might be slow" mean?
 #####################################################################################################################################################
 
 **A:** You are using an unsupported Python version. Use only versions 3.4 - 3.6 for the C++ ``protobuf`` implementation that is supplied with OpenVINO toolkit. You can still boost the conversion speed by building the protobuf library from sources. For complete instructions about building ``protobuf`` from sources, see the appropriate section in the :doc:`Converting a Model to Intermediate Representation <openvino_docs_MO_DG_Deep_Learning_Model_Optimizer_DevGuide>` guide.
 
-.. _question-80:
+.. _question-81:
 
-Q80. What does the message "Arguments --nd_prefix_name, --pretrained_model_name and --input_symbol should be provided. Please provide all or do not use any." mean?
+Q81. What does the message "Arguments --nd_prefix_name, --pretrained_model_name and --input_symbol should be provided. Please provide all or do not use any." mean?
 ####################################################################################################################################################################
 
 **A:** This error occurs if you did not provide the ``--nd_prefix_name``, ``--pretrained_model_name``, and ``--input_symbol`` parameters.
@@ -740,52 +703,51 @@ from one ``.params`` file and two additional ``.nd`` files (``*_args.nd``, ``*_a
 To do that, provide both CLI options or do not pass them if you want to convert an MXNet model without additional weights.
 For more information, refer to the :doc:`Converting an MXNet Model <openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_MxNet>` guide.
 
-.. _question-81:
+.. _question-82:
 
-Q81. What does the message "You should specify input for mean/scale values" mean?
+Q82. What does the message "You should specify input for mean/scale values" mean?
 #####################################################################################################################################################
 
 **A:** When the model has multiple inputs and you want to provide mean/scale values, you need to pass those values for each input. More specifically, the number of passed values should be the same as the number of inputs of the model.
 For more information, refer to the :doc:`Converting a Model to Intermediate Representation <openvino_docs_MO_DG_prepare_model_convert_model_Converting_Model>` guide.
 
-.. _question-82:
+.. _question-83:
 
-Q82. What does the message "Input with name ... not found!" mean?
+Q83. What does the message "Input with name ... not found!" mean?
 #####################################################################################################################################################
 
 **A:** When you passed the mean/scale values and specify names of input layers of the model, you might have used the name that does not correspond to any input layer. Make sure that you list only names of the input layers of your model when passing values with the ``--input`` option.
 For more information, refer to the :doc:`Converting a Model to Intermediate Representation <openvino_docs_MO_DG_prepare_model_convert_model_Converting_Model>` guide.
 
+.. _question-84:
 
-.. _question-83:
-
-Q83. What does the message "Specified input json ... does not exist" mean?
+Q84. What does the message "Specified input json ... does not exist" mean?
 #####################################################################################################################################################
 
 **A:** Most likely, ``.json`` file does not exist or has a name that does not match the notation of Apache MXNet. Make sure the file exists and has a correct name.
 For more information, refer to the :doc:`Converting an MXNet Model <openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_MxNet>` guide.
 
-.. _question-84:
+.. _question-85:
 
-Q84. What does the message "Unsupported Input model file type ... Model Optimizer support only .params and .nd files format" mean?
+Q85. What does the message "Unsupported Input model file type ... Model Optimizer support only .params and .nd files format" mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer for Apache MXNet supports only ``.params`` and ``.nd`` files formats. Most likely, you specified an unsupported file format in ``--input_model``.
 For more information, refer to :doc:`Converting an MXNet Model <openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_MxNet>`.
 
 
-.. _question-85:
+.. _question-86:
 
-Q85. What does the message "Operation ... not supported. Please register it as custom op" mean?
+Q86. What does the message "Operation ... not supported. Please register it as custom op" mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer tried to load the model that contains some unsupported operations.
 If you want to convert model that contains unsupported operations, you need to prepare extension for all such operations.
 For more information, refer to the :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>` guide.
 
-.. _question-86:
+.. _question-87:
 
-Q86. What does the message "Can not register Op ... Please, call function 'register_caffe_python_extractor' with parameter 'name'" mean?
+Q87. What does the message "Can not register Op ... Please, call function 'register_caffe_python_extractor' with parameter 'name'" mean?
 #####################################################################################################################################################
 
 **A:** This error appears if the class of implementation of ``Op`` for Python Caffe layer could not be used by Model Optimizer. Python layers should be handled differently comparing to ordinary Caffe layers.
@@ -837,52 +799,51 @@ The second call prevents Model Optimizer from using this extension as if it is a
 a layer with type ``Proposal``. Otherwise, this layer can be chosen as an implementation of extension that can lead to potential issues.
 For more information, refer to the :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>` guide.
 
-.. _question-87:
+.. _question-88:
 
-Q87. What does the message "Model Optimizer is unable to calculate output shape of Memory node .." mean?
+Q88. What does the message "Model Optimizer is unable to calculate output shape of Memory node .." mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer supports only ``Memory`` layers, in which ``input_memory`` goes before ``ScaleShift`` or the ``FullyConnected`` layer.
 This error message means that in your model the layer after input memory is not of the ``ScaleShift`` or ``FullyConnected`` type.
 This is a known limitation.
 
-.. _question-88:
+.. _question-89:
 
-Q88. What do the messages "File ...  does not appear to be a Kaldi file (magic number does not match)", "Kaldi model should start with <Nnet> tag" mean?
+Q89. What do the messages "File ...  does not appear to be a Kaldi file (magic number does not match)", "Kaldi model should start with <Nnet> tag" mean?
 #########################################################################################################################################################
 
 **A:** These error messages mean that Model Optimizer does not support your Kaldi model, because the ``checksum`` of the model is not
 16896 (the model should start with this number), or the model file does not contain the ``<Net>`` tag as a starting one.
 Make sure that you provide a path to a true Kaldi model and try again.
 
+.. _question-90:
 
-.. _question-89:
-
-Q89. What do the messages "Expect counts file to be one-line file." or "Expect counts file to contain list of integers" mean?
+Q90. What do the messages "Expect counts file to be one-line file." or "Expect counts file to contain list of integers" mean?
 #####################################################################################################################################################
 
 **A:** These messages mean that the file counts you passed contain not one line. The count file should start with
 ``[`` and end with  ``]``,  and integer values should be separated by spaces between those brackets.
 
-.. _question-90:
+.. _question-91:
 
-Q90. What does the message "Model Optimizer is not able to read Kaldi model .." mean?
+Q91. What does the message "Model Optimizer is not able to read Kaldi model .." mean?
 #####################################################################################################################################################
 
 **A:** There are multiple reasons why Model Optimizer does not accept a Kaldi topology, including:
 the file is not available or does not exist. Refer to FAQ :ref:`#88 <question-88>`.
 
-.. _question-91:
+.. _question-92:
 
-Q91. What does the message "Model Optimizer is not able to read counts file  .." mean?
+Q92. What does the message "Model Optimizer is not able to read counts file  .." mean?
 #####################################################################################################################################################
 
 **A:** There are multiple reasons why Model Optimizer does not accept a counts file, including:
 the file is not available or does not exist. Refer to FAQ :ref:`#89 <question-89>`.
 
-.. _question-92:
+.. _question-93:
 
-Q92. What does the message "For legacy MXNet models Model Optimizer does not support conversion of old MXNet models (trained with 1.0.0 version of MXNet and lower) with custom layers." mean?
+Q93. What does the message "For legacy MXNet models Model Optimizer does not support conversion of old MXNet models (trained with 1.0.0 version of MXNet and lower) with custom layers." mean?
 ###############################################################################################################################################################################################
 
 **A:** This message means that if you have a model with custom layers and its JSON file has been generated with Apache MXNet version
@@ -891,9 +852,21 @@ MXNet with unsupported layers or generate a new JSON file with Apache MXNet vers
 OpenVINO extension to use custom layers.
 For more information, refer to the :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>` guide.
 
-.. _question-93:
+.. _question-94:
 
-Q93. What does the message "Graph contains a cycle. Can not proceed .." mean?
+Q94. What does the message "Expected token ``</ParallelComponent>``, has ``...``" mean?
+#####################################################################################################################################################
+
+**A:** This error messages mean that Model Optimizer does not support your Kaldi model, because the Net contains ``ParallelComponent`` that does not end with the ``</ParallelComponent>`` tag.
+Make sure that you provide a path to a true Kaldi model and try again.
+
+.. _question-95:
+
+.. _question-96:
+
+.. _question-97:
+
+Q97. What does the message "Graph contains a cycle. Can not proceed .." mean?
 #####################################################################################################################################################
 
 **A:** Model Optimizer supports only straightforward models without cycles.
@@ -906,76 +879,52 @@ For Tensorflow:
 
 For all frameworks:
 
-1. :doc:`Replace cycle containing Sub-graph in Model Optimizer <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`
+1. :doc:`Replace cycle containing Sub-graph in Model Optimizer [Legacy Solution] <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`
 2. See :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>`
 
 or
+
 * Edit the model in its original framework to exclude cycle.
 
-.. _question-94:
+.. _question-98:
 
-Q94. What does the message "Can not transpose attribute '..' with value .. for node '..' .." mean?
-#####################################################################################################################################################
+.. _question-99:
 
-**A:** This message means that the model is not supported. It may be caused by using shapes larger than 4-D.
-There are two ways to avoid such message:
+.. _question-100:
 
-* :doc:`Cut off parts of the model <openvino_docs_MO_DG_prepare_model_convert_model_Cutting_Model>`.
-* Edit the network in its original framework to exclude such layers.
-
-.. _question-95:
-
-Q95. What does the message "Expected token ``</ParallelComponent>``, has ``...``" mean?
-#####################################################################################################################################################
-
-**A:** This error messages mean that Model Optimizer does not support your Kaldi model, because the Net contains ``ParallelComponent`` that does not end with the ``</ParallelComponent>`` tag.
-Make sure that you provide a path to a true Kaldi model and try again.
-
-.. _question-96:
-
-Q96. What does the message "Interp layer shape inference function may be wrong, please, try to update layer shape inference function in the file (extensions/ops/interp.op at the line ...)." mean?
+Q100. What does the message "Interp layer shape inference function may be wrong, please, try to update layer shape inference function in the file (extensions/ops/interp.op at the line ...)." mean?
 ####################################################################################################################################################################################################
 
 **A:** There are many flavors of Caffe framework, and most layers in them are implemented identically.
 However, there are exceptions. For example, the output value of layer Interp is calculated differently in Deeplab-Caffe and classic Caffe. Therefore, if your model contains layer Interp and the conversion of your model has failed, modify the ``interp_infer`` function in the ``extensions/ops/interp.op`` file according to the comments in the file.
 
-.. _question-97:
+.. _question-101:
 
-Q97. What does the message "Mean/scale values should ..." mean?
+Q101. What does the message "Mean/scale values should ..." mean?
 #####################################################################################################################################################
 
 **A:** It means that your mean/scale values have a wrong format. Specify mean/scale values in the form of ``layer_name(val1,val2,val3)``.
 You need to specify values for each input of the model. For more information, refer to the :doc:`Converting a Model to Intermediate Representation <openvino_docs_MO_DG_prepare_model_convert_model_Converting_Model>` guide.
 
-.. _question-98:
+.. _question-102:
 
-Q98. What does the message "Operation _contrib_box_nms is not supported ..." mean?
+Q102. What does the message "Operation _contrib_box_nms is not supported ..." mean?
 #####################################################################################################################################################
 
 **A:** It means that you are trying to convert a topology contains the ``_contrib_box_nms`` operation which is not supported directly. However, the sub-graph of operations including ``_contrib_box_nms`` could be replaced with the DetectionOutput layer if your topology is one of the ``gluoncv`` topologies. Specify the ``--enable_ssd_gluoncv`` command-line parameter for Model Optimizer to enable this transformation.
 
-.. _question-99:
+.. _question-103:
 
-Q99. What does the message "ModelOptimizer is not able to parse *.caffemodel" mean?
+Q103. What does the message "ModelOptimizer is not able to parse *.caffemodel" mean?
 #####################################################################################################################################################
 
 **A:** If a ``*.caffemodel`` file exists and is correct, the error occurred possibly because of the use of Python protobuf implementation. In some cases, error messages may appear during model parsing, for example: "``utf-8`` codec can't decode byte 0xe0 in position 4: invalid continuation byte in field: mo_caffe.SpatialTransformerParameter.transform_type". You can either use Python 3.7 or build the ``cpp`` implementation of ``protobuf`` yourself for your version of Python. For the complete instructions about building ``protobuf`` from sources, see the appropriate section in the :doc:`Converting Models with Model Optimizer <openvino_docs_MO_DG_Deep_Learning_Model_Optimizer_DevGuide>` guide.
 
+.. _question-104:
 
-.. _question-100:
+.. _question-105:
 
-Q100. What does the message "SyntaxError: 'yield' inside list comprehension" during MxNet model conversion mean?
-#####################################################################################################################################################
-
-**A:** The issue "SyntaxError: ``yield`` inside list comprehension" might occur during converting MXNet models (``mobilefacedet-v1-mxnet``, ``brain-tumor-segmentation-0001``) on Windows platform with Python 3.8 environment. This issue is caused by the API changes for ``yield expression`` in Python 3.8.
-The following workarounds are suggested to resolve this issue:
-1. Use Python 3.7 to convert MXNet models on Windows
-2. Update Apache MXNet by using ``pip install mxnet==1.7.0.post2``
-Note that it might have conflicts with previously installed PyPI dependencies.
-
-.. _question-101:
-
-Q101. What does the message "The IR preparation was executed by the legacy MO path. ..." mean?
+Q105. What does the message "The IR preparation was executed by the legacy MO path. ..." mean?
 #####################################################################################################################################################
 
 **A:** For the models in ONNX format, there are two available paths of IR conversion.
@@ -986,4 +935,4 @@ The new frontends support only paths to shared libraries (.dll and .so) for ``--
 Inputs freezing (enabled by ``--freeze_placeholder_with_value`` or ``--input`` arguments) is not supported by the new frontends.
 The IR conversion falls back to the old path if a user does not select any expected path of conversion explicitly (with ``--use_new_frontend`` or ``--use_legacy_frontend`` MO arguments) and unsupported pre-defined scenario is detected on the new frontend path.
 
-@endsphinxdirective
+@endsphinxdirective

docs/MO_DG/prepare_model/convert_model/Convert_Model_From_PyTorch.md

@@ -2,14 +2,61 @@
 
 @sphinxdirective
 
-The PyTorch framework is supported through export to the ONNX format. In order to optimize and deploy a model that was trained with it:
+This page provides instructions on how to convert a model from the PyTorch format to the OpenVINO IR format using Model Optimizer.
+Model Optimizer Python API allows the conversion of PyTorch models using the ``convert_model()`` method.
 
-1. `Export a PyTorch model to ONNX <#exporting-a-pytorch-model-to-onnx-format>`__.
-2. :doc:`Convert the ONNX model <openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_ONNX>` to produce an optimized :doc:`Intermediate Representation <openvino_docs_MO_DG_IR_and_opsets>` of the model based on the trained network topology, weights, and biases values.
+(Experimental) Converting a PyTorch model with PyTorch Frontend 
+###############################################################
+
+Example of PyTorch model conversion:
+
+.. code-block:: python
+
+   import torchvision
+   import torch
+   from openvino.tools.mo import convert_model
+   
+   model = torchvision.models.resnet50(pretrained=True)
+   ov_model = convert_model(model)
+
+Following PyTorch model formats are supported:
+
+* ``torch.nn.Module``
+* ``torch.jit.ScriptModule``
+* ``torch.jit.ScriptFunction``
+
+Converting certain PyTorch models may require model tracing, which needs ``input_shape`` or ``example_input`` parameters to be set.
+
+``example_input`` is used as example input for model tracing.
+``input_shape`` is used for constructing a float zero-filled torch.Tensor for model tracing.
+
+Example of using ``example_input``:
+
+.. code-block:: python
+
+   import torchvision
+   import torch
+   from openvino.tools.mo import convert_model
+   
+   model = torchvision.models.resnet50(pretrained=True)
+   ov_model = convert_model(model, example_input=torch.zeros(1, 3, 100, 100))
+
+``example_input`` accepts the following formats:
+
+* ``openvino.runtime.Tensor``
+* ``torch.Tensor``
+* ``np.ndarray``
+* ``list`` or ``tuple`` with tensors (``openvino.runtime.Tensor`` / ``torch.Tensor`` / ``np.ndarray``)
+* ``dictionary`` where key is the input name, value is the tensor (``openvino.runtime.Tensor`` / ``torch.Tensor`` / ``np.ndarray``)
 
 Exporting a PyTorch Model to ONNX Format
 ########################################
 
+Currently, the most robust method of converting PyTorch models is exporting a PyTorch model to ONNX and then converting it to IR. To convert and deploy a PyTorch model, follow these steps:
+
+1. `Export a PyTorch model to ONNX <#exporting-a-pytorch-model-to-onnx-format>`__.
+2. :doc:`Convert the ONNX model <openvino_docs_MO_DG_prepare_model_convert_model_Convert_Model_From_ONNX>` to produce an optimized :doc:`Intermediate Representation <openvino_docs_MO_DG_IR_and_opsets>` of the model based on the trained network topology, weights, and biases values.
+
 PyTorch models are defined in Python. To export them, use the ``torch.onnx.export()`` method. The code to
 evaluate or test the model is usually provided with its code and can be used for its initialization and export.
 The export to ONNX is crucial for this process, but it is covered by PyTorch framework, therefore, It will not be covered here in detail. 

docs/MO_DG/prepare_model/convert_model/Convert_Model_From_TensorFlow.md

@@ -167,6 +167,103 @@ Command-Line Interface (CLI) Examples Using TensorFlow-Specific Parameters
 
    mo --saved_model_dir BERT --input mask,word_ids,type_ids --input_shape [2,30],[2,30],[2,30]
 
+Conversion of TensorFlow models from memory using Python API
+############################################################
+
+MO Python API supports passing TensorFlow/TensorFlow2 models directly from memory.
+
+* ``tf.keras.Model``
+
+.. code-block:: python
+
+   model = tf.keras.applications.ResNet50(weights="imagenet")
+   ov_model = convert_model(model)
+
+
+* ``tf.keras.layers.Layer``. Requires setting the "input_shape".
+
+.. code-block:: python
+
+   import tensorflow_hub as hub
+
+   model = hub.KerasLayer("https://tfhub.dev/google/imagenet/mobilenet_v1_100_224/classification/5")
+   ov_model = convert_model(model, input_shape=[-1, 224, 224, 3])
+
+* ``tf.Module``. Requires setting the "input_shape".
+
+.. code-block:: python
+
+   class MyModule(tf.Module):
+      def __init__(self, name=None):
+         super().__init__(name=name)
+         self.variable1 = tf.Variable(5.0, name="var1")
+         self.variable2 = tf.Variable(1.0, name="var2")
+      def __call__(self, x):
+         return self.variable1 * x + self.variable2
+
+   model = MyModule(name="simple_module")
+   ov_model = convert_model(model, input_shape=[-1])
+
+* ``tf.compat.v1.Graph``
+
+.. code-block:: python
+
+   with tf.compat.v1.Session() as sess:
+      inp1 = tf.compat.v1.placeholder(tf.float32, [100], 'Input1')
+      inp2 = tf.compat.v1.placeholder(tf.float32, [100], 'Input2')
+      output = tf.nn.relu(inp1 + inp2, name='Relu')
+      tf.compat.v1.global_variables_initializer()
+      model = sess.graph
+   
+   ov_model = convert_model(model)  
+
+* ``tf.compat.v1.GraphDef``
+
+.. code-block:: python
+
+   with tf.compat.v1.Session() as sess:
+      inp1 = tf.compat.v1.placeholder(tf.float32, [100], 'Input1')
+      inp2 = tf.compat.v1.placeholder(tf.float32, [100], 'Input2')
+      output = tf.nn.relu(inp1 + inp2, name='Relu')
+      tf.compat.v1.global_variables_initializer()
+      model = sess.graph_def
+   
+   ov_model = convert_model(model)  
+
+* ``tf.function``
+
+.. code-block:: python
+
+   @tf.function(
+      input_signature=[tf.TensorSpec(shape=[1, 2, 3], dtype=tf.float32),
+                       tf.TensorSpec(shape=[1, 2, 3], dtype=tf.float32)])
+   def func(x, y):
+      return tf.nn.sigmoid(tf.nn.relu(x + y))
+   
+   ov_model = convert_model(func)  
+
+* ``tf.compat.v1.session``
+
+.. code-block:: python
+
+   with tf.compat.v1.Session() as sess:
+      inp1 = tf.compat.v1.placeholder(tf.float32, [100], 'Input1')
+      inp2 = tf.compat.v1.placeholder(tf.float32, [100], 'Input2')
+      output = tf.nn.relu(inp1 + inp2, name='Relu')
+      tf.compat.v1.global_variables_initializer()
+
+      ov_model = convert_model(sess)
+
+* ``tf.train.checkpoint``
+
+.. code-block:: python
+
+   model = tf.keras.Model(...)
+   checkpoint = tf.train.Checkpoint(model)
+   save_path = checkpoint.save(save_directory)
+   # ... 
+   checkpoint.restore(save_path)
+   ov_model = convert_model(checkpoint)
 
 Supported TensorFlow and TensorFlow 2 Keras Layers
 ##################################################

docs/MO_DG/prepare_model/convert_model/tf_specific/Convert_Object_Detection_API_Models.md

@@ -154,7 +154,7 @@ Models with ``keep_aspect_ratio_resizer`` were trained to recognize object in re
 Model Conversion Process in Detail
 ##################################
 
-This section is intended for users who want to understand how Model Optimizer performs Object Detection API models conversion in details. The information in this section is also useful for users having complex models that are not converted with Model Optimizer out of the box. It is highly recommended to read the **Graph Transformation Extensions** section in the :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` documentation first to understand sub-graph replacement concepts which are used here.
+This section is intended for users who want to understand how Model Optimizer performs Object Detection API models conversion in details. The information in this section is also useful for users having complex models that are not converted with Model Optimizer out of the box. It is highly recommended to read the **Graph Transformation Extensions** section in the :doc:`[Legacy] Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Transformation_Extensions>` documentation first to understand sub-graph replacement concepts which are used here.
 
 It is also important to open the model in the `TensorBoard <https://www.tensorflow.org/guide/summaries_and_tensorboard>`__ to see the topology structure. Model Optimizer can create an event file that can be then fed to the TensorBoard tool. Run Model Optimizer, providing two command line parameters:
 
@@ -164,4 +164,4 @@ It is also important to open the model in the `TensorBoard <https://www.tensorfl
 Implementation of the transformations for Object Detection API models is located in the `file <https://github.com/openvinotoolkit/openvino/blob/releases/2022/1/tools/mo/openvino/tools/mo/front/tf/ObjectDetectionAPI.py>`__. Refer to the code in this file to understand the details of the conversion process.
 
 
-@endsphinxdirective
+@endsphinxdirective

docs/MO_DG/prepare_model/customize_model_optimizer/Extending_Model_Optimizer_with_Caffe_Python_Layers.md

@@ -1,88 +1,107 @@
-# Extending Model Optimizer with Caffe Python Layers {#openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Extending_Model_Optimizer_With_Caffe_Python_Layers}
+# [LEGACY] Extending Model Optimizer with Caffe Python Layers {#openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Extending_Model_Optimizer_With_Caffe_Python_Layers}
+
+@sphinxdirective
+
+.. danger::
+
+   The code described here has been **deprecated!** Do not use it to avoid working with a legacy solution. It will be kept for some time to ensure backwards compatibility, but **you should not use** it in contemporary applications.
+
+   This guide describes a deprecated TensorFlow conversion method. The guide on the new and recommended method, using a new frontend, can be found in the  :doc:`Frontend Extensions <openvino_docs_Extensibility_UG_Frontend_Extensions>` article. 
 
 This article provides instructions on how to support a custom Caffe operation written only in Python. For example, the
-[Faster-R-CNN model](https://dl.dropboxusercontent.com/s/o6ii098bu51d139/faster_rcnn_models.tgz?dl=0) implemented in
+`Faster-R-CNN model <https://dl.dropboxusercontent.com/s/o6ii098bu51d139/faster_rcnn_models.tgz?dl=0>`__ implemented in
 Caffe contains a custom proposal layer written in Python. The layer is described in the
-[Faster-R-CNN prototxt](https://raw.githubusercontent.com/rbgirshick/py-faster-rcnn/master/models/pascal_voc/VGG16/faster_rcnn_end2end/test.prototxt) in the following way:
-```sh
-layer {
-  name: 'proposal'
-  type: 'Python'
-  bottom: 'rpn_cls_prob_reshape'
-  bottom: 'rpn_bbox_pred'
-  bottom: 'im_info'
-  top: 'rois'
-  python_param {
-    module: 'rpn.proposal_layer'
-    layer: 'ProposalLayer'
-    param_str: "'feat_stride': 16"
-  }
-}
-```
+`Faster-R-CNN prototxt <https://raw.githubusercontent.com/rbgirshick/py-faster-rcnn/master/models/pascal_voc/VGG16/faster_rcnn_end2end/test.prototxt>`__ in the following way:
+
+.. code-block:: sh
+
+   layer {
+     name: 'proposal'
+     type: 'Python'
+     bottom: 'rpn_cls_prob_reshape'
+     bottom: 'rpn_bbox_pred'
+     bottom: 'im_info'
+     top: 'rois'
+     python_param {
+       module: 'rpn.proposal_layer'
+       layer: 'ProposalLayer'
+       param_str: "'feat_stride': 16"
+     }
+   }
+
 
 This article describes only a procedure on how to extract operator attributes in Model Optimizer. The rest of the
 operation enabling pipeline and information on how to support other Caffe operations (written in C++) is described in
-the [Customize_Model_Optimizer](Customize_Model_Optimizer.md) guide.
+the :doc:`Customize Model Optimizer <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>` guide.
 
-## Writing Extractor for Caffe Python Layer
-Custom Caffe Python layers have an attribute `type` (defining the type of the operation) equal to `Python` and two
-mandatory attributes `module` and `layer` in the `python_param` dictionary. The `module` defines the Python module name
-with the layer implementation, while `layer` value is an operation type defined by a user. In order to extract
+========================================
+Writing Extractor for Caffe Python Layer
+========================================
+
+Custom Caffe Python layers have an attribute ``type`` (defining the type of the operation) equal to ``Python`` and two
+mandatory attributes ``module`` and ``layer`` in the ``python_param`` dictionary. The ``module`` defines the Python module name
+with the layer implementation, while ``layer`` value is an operation type defined by a user. In order to extract
 attributes for such an operation it is necessary to implement extractor class inherited from the
-`CaffePythonFrontExtractorOp` class instead of `FrontExtractorOp` class, used for standard framework layers. The `op`
-class attribute value should be set to the `module + "." + layer` value so the extractor is triggered for this kind of
+``CaffePythonFrontExtractorOp`` class instead of ``FrontExtractorOp`` class, used for standard framework layers. The ``op``
+class attribute value should be set to the ``module + "." + layer`` value so the extractor is triggered for this kind of
 operation.
 
 Below is a simplified example of the extractor for the custom operation Proposal from the mentioned Faster-R-CNN model.
-The full code with additional checks can be found [here](https://github.com/openvinotoolkit/openvino/blob/releases/2022/1/tools/mo/openvino/tools/mo/front/caffe/proposal_python_ext.py).
+The full code with additional checks can be found `here <https://github.com/openvinotoolkit/openvino/blob/releases/2022/1/tools/mo/openvino/tools/mo/front/caffe/proposal_python_ext.py>`__.
 
-The sample code uses operation `ProposalOp` which corresponds to `Proposal` operation described in the [Available Operations Sets](../../../ops/opset.md)
+The sample code uses operation ``ProposalOp`` which corresponds to ``Proposal`` operation described in the :doc:`Available Operations Sets <openvino_docs_ops_opset>`
 page. For a detailed explanation of the extractor, refer to the source code below.
 
-```py
-from openvino.tools.mo.ops.proposal import ProposalOp
-from openvino.tools.mo.front.extractor import CaffePythonFrontExtractorOp
+.. code-block:: py
 
+   from openvino.tools.mo.ops.proposal import ProposalOp
+   from openvino.tools.mo.front.extractor import CaffePythonFrontExtractorOp
+   
+   
+   class ProposalPythonFrontExtractor(CaffePythonFrontExtractorOp):
+       op = 'rpn.proposal_layer.ProposalLayer'  # module + "." + layer
+       enabled = True  # extractor is enabled
+   
+       @staticmethod
+       def extract_proposal_params(node, defaults):
+           param = node.pb.python_param  # get the protobuf message representation of the layer attributes
+           # parse attributes from the layer protobuf message to a Python dictionary
+           attrs = CaffePythonFrontExtractorOp.parse_param_str(param.param_str)
+           update_attrs = defaults
+   
+           # the operation expects ratio and scale values to be called "ratio" and "scale" while Caffe uses different names
+           if 'ratios' in attrs:
+               attrs['ratio'] = attrs['ratios']
+               del attrs['ratios']
+           if 'scales' in attrs:
+               attrs['scale'] = attrs['scales']
+               del attrs['scales']
+   
+           update_attrs.update(attrs)
+           ProposalOp.update_node_stat(node, update_attrs)  # update the node attributes
+   
+       @classmethod
+       def extract(cls, node):
+           # define default values for the Proposal layer attributes
+           defaults = {
+               'feat_stride': 16,
+               'base_size': 16,
+               'min_size': 16,
+               'ratio': [0.5, 1, 2],
+               'scale': [8, 16, 32],
+               'pre_nms_topn': 6000,
+               'post_nms_topn': 300,
+               'nms_thresh': 0.7
+           }
+           cls.extract_proposal_params(node, defaults)
+           return cls.enabled
 
-class ProposalPythonFrontExtractor(CaffePythonFrontExtractorOp):
-    op = 'rpn.proposal_layer.ProposalLayer'  # module + "." + layer
-    enabled = True  # extractor is enabled
+====================
+Additional Resources
+====================
 
-    @staticmethod
-    def extract_proposal_params(node, defaults):
-        param = node.pb.python_param  # get the protobuf message representation of the layer attributes
-        # parse attributes from the layer protobuf message to a Python dictionary
-        attrs = CaffePythonFrontExtractorOp.parse_param_str(param.param_str)
-        update_attrs = defaults
+* :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`
+* :doc:`Graph Traversal and Modification Using Ports and Connections <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer_Model_Optimizer_Ports_Connections>`
+* :doc:`Model Optimizer Extensions <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions>`
 
-        # the operation expects ratio and scale values to be called "ratio" and "scale" while Caffe uses different names
-        if 'ratios' in attrs:
-            attrs['ratio'] = attrs['ratios']
-            del attrs['ratios']
-        if 'scales' in attrs:
-            attrs['scale'] = attrs['scales']
-            del attrs['scales']
-
-        update_attrs.update(attrs)
-        ProposalOp.update_node_stat(node, update_attrs)  # update the node attributes
-
-    @classmethod
-    def extract(cls, node):
-        # define default values for the Proposal layer attributes
-        defaults = {
-            'feat_stride': 16,
-            'base_size': 16,
-            'min_size': 16,
-            'ratio': [0.5, 1, 2],
-            'scale': [8, 16, 32],
-            'pre_nms_topn': 6000,
-            'post_nms_topn': 300,
-            'nms_thresh': 0.7
-        }
-        cls.extract_proposal_params(node, defaults)
-        return cls.enabled
-```
-
-## See Also
-
-* [Customize_Model_Optimizer](Customize_Model_Optimizer.md)
+@endsphinxdirective

docs/MO_DG/prepare_model/customize_model_optimizer/Model_Optimizer_Extensions.md

@@ -0,0 +1,57 @@
+# [LEGACY] Model Optimizer Extensions {#openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions}
+
+@sphinxdirective
+
+.. toctree::
+   :maxdepth: 1
+   :hidden:
+
+   openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Operation
+   openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Extractor
+   openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Transformation_Extensions
+
+.. danger::
+
+   The code described here has been **deprecated!** Do not use it to avoid working with a legacy solution. It will be kept for some time to ensure backwards compatibility, but **you should not use** it in contemporary applications.
+
+   This guide describes a deprecated TensorFlow conversion method. The guide on the new and recommended method, using a new frontend, can be found in the  :doc:`Frontend Extensions <openvino_docs_Extensibility_UG_Frontend_Extensions>` article. 
+
+Model Optimizer extensions enable you to inject some logic to the model conversion pipeline without changing the Model
+Optimizer core code. There are three types of the Model Optimizer extensions:
+
+1. :doc:`Model Optimizer operation <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Operation>`.
+2. A :doc:`framework operation extractor <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Extractor>`.
+3. A :doc:`model transformation <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Transformation_Extensions>`, which can be executed during front, middle or back phase of the model conversion.
+
+An extension is just a plain text file with a Python code. The file should contain a class (or classes) inherited from
+one of extension base classes. Extension files should be saved to a directory with the following structure:
+
+.. code-block:: sh
+   
+   ./<MY_EXT>/
+              ops/                  - custom operations
+              front/                - framework independent front transformations
+                    <FRAMEWORK_1>/  - front transformations for <FRAMEWORK_1> models only and extractors for <FRAMEWORK_1> operations
+                    <FRAMEWORK_2>/  - front transformations for <FRAMEWORK_2> models only and extractors for <FRAMEWORK_2> operations
+                    ...
+              middle/               - middle transformations
+              back/                 - back transformations
+
+Model Optimizer uses the same layout internally to keep built-in extensions. The only exception is that the 
+``mo/ops/`` directory is also used as a source of the Model Optimizer operations due to historical reasons.
+
+.. note:: 
+   The name of a root directory with extensions should not be equal to "extensions" because it will result in a name conflict with the built-in Model Optimizer extensions.
+
+.. note:: 
+   Model Optimizer itself is built by using these extensions, so there is a huge number of examples of their usage in the Model Optimizer code.
+
+====================
+Additional Resources
+====================
+
+* :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`
+* :doc:`Graph Traversal and Modification Using Ports and Connections <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer_Model_Optimizer_Ports_Connections>`
+* :doc:`Extending Model Optimizer with Caffe Python Layers <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Extending_Model_Optimizer_With_Caffe_Python_Layers>`
+
+@endsphinxdirective

docs/MO_DG/prepare_model/customize_model_optimizer/Model_Optimizer_Extractor.md

@@ -0,0 +1,107 @@
+# [LEGACY] Operation Extractor {#openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Extractor}
+
+@sphinxdirective
+
+.. danger::
+
+   The code described here has been **deprecated!** Do not use it to avoid working with a legacy solution. It will be kept for some time to ensure backwards compatibility, but **you should not use** it in contemporary applications.
+
+   This guide describes a deprecated TensorFlow conversion method. The guide on the new and recommended method, using a new frontend, can be found in the  :doc:`Frontend Extensions <openvino_docs_Extensibility_UG_Frontend_Extensions>` article. 
+
+Model Optimizer runs specific extractor for each operation in the model during the model loading.
+
+There are several types of Model Optimizer extractor extensions:
+
+1. The generic one, which is described in this article.
+2. The special extractor for Caffe models with Python layers. This kind of extractor is described in the :doc:`Extending Model Optimizer with Caffe Python Layers <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Extending_Model_Optimizer_With_Caffe_Python_Layers>` guide.
+
+Generic extension provides a generic mechanism for the operation extractor applicable for all frameworks. Model Optimizer provides the ``mo.front.extractor.FrontExtractorOp`` class as a base class to implement the extractor. It has the ``extract`` class method, which gets the only parameter ``Node``, which corresponds to the graph node to extract data from. The operation description in the original framework format is stored in the attribute ``pb`` of the node. The extractor goal is to parse this attribute and save necessary attributes to the corresponding node of the graph. Consider the extractor for the ``Const`` TensorFlow operation (refer to the ``extensions/front/tf/const_ext.py`` file):
+
+.. code-block:: py
+
+   from openvino.tools.mo.front.extractor import FrontExtractorOp
+   from openvino.tools.mo.front.tf.extractors.utils import tf_dtype_extractor, tf_tensor_shape, tf_tensor_content
+   from openvino.tools.mo.ops.const import Const
+   
+   
+   class ConstExtractor(FrontExtractorOp):
+       # The "op" class attribute defines a type of the operation in the framework (in this case it is a TensorFlow), 
+       # for which the extractor should be triggered.
+       op = 'Const'
+       enabled = True  # The flag that indicates that this extractor is enabled.
+   
+       @classmethod
+       def extract(cls, node):  # The entry point of the extractor.
+           # The `node.pb` attribute stores the TensorFlow representation of the operation, which is a Protobuf message of the
+           # specific format. In particular, the message contains the attribute called "value" containing the description of
+           # the constant. The string "pb.attr["value"].tensor" is just a Python binding for Protobuf message parsing.
+           pb_tensor = node.pb.attr["value"].tensor
+           # Get the shape of the tensor from the protobuf message, using the helper function "tf_tensor_shape".
+           shape = tf_tensor_shape(pb_tensor.tensor_shape)
+           # Create a dictionary with necessary attributes.
+           attrs = {
+               'shape': shape,
+               # Get the tensor value, using "tf_tensor_content" helper function.
+               'value': tf_tensor_content(pb_tensor.dtype, shape, pb_tensor),
+               # Get the tensor data type, using "tf_dtype_extractor" helper function.
+               'data_type': tf_dtype_extractor(pb_tensor.dtype),
+           }
+           # Update the node attributes, using default attributes from the "Const" operation and attributes saved to the
+           # "attrs" dictionary.
+           Const.update_node_stat(node, attrs)
+           return cls.enabled
+
+Consider another example with an extractor of the ``Constant`` ONNX operation (refer to the ``extensions/front/onnx/const_ext.py`` file):
+
+.. code-block:: py
+
+   from onnx import numpy_helper
+   from onnx.numpy_helper import to_array
+   
+   from openvino.tools.mo.front.extractor import FrontExtractorOp
+   from openvino.tools.mo.front.onnx.extractors.utils import onnx_attr
+   from openvino.tools.mo.ops.const import Const
+   
+   
+   class ConstantExtractor(FrontExtractorOp):
+       op = 'Constant'
+       enabled = True
+   
+       @classmethod
+       def extract(cls, node):
+           # Use "onnx_attr" helper method, which parses the Protobuf representation of the operation saved in the "node".
+           # Gets the value of the attribute with name "value" as "TensorProto" type (specified with a keyword "t").
+           pb_value = onnx_attr(node, 'value', 't')
+           # Use "numpy_helper.to_array()" ONNX helper method to convert "TensorProto" object to a numpy array.
+           value = numpy_helper.to_array(pb_value)
+   
+           attrs = {
+               'data_type': value.dtype,
+               'value': value,
+           }
+           # Update the node attributes, using default attributes from the "Const" operation and attributes saved to the
+           # "attrs" dictionary.
+           Const.update_node_stat(node, attrs)
+           return cls.enabled
+
+The extractors for operations from different frameworks work similarly. The only difference is in the helper methods used to parse operation attributes encoded with a framework-specific representation.
+
+A common practice is to use ``update_node_stat()`` method of the dedicated ``Op`` class to update the node attributes. This method does the following:
+
+1. Sets values for common attributes like ``op``, ``type``, ``infer``, ``in_ports_count``, ``out_ports_count``, ``version`` to values specific to the dedicated operation (``Const`` operation in this case).
+2. Uses ``supported_attrs()`` and ``backend_attrs()`` methods, defined in the ``Op`` class to update specific node attribute ``IE``. The IR emitter uses the value stored in the ``IE`` attribute to pre-process attribute values and save them to IR.
+3. Optionally sets additional attributes provided to the ``update_node_stat()`` function as a second parameter. Usually these attributes are parsed from the particular instance of the operation.
+
+.. note:: 
+   Model Optimizer uses numpy arrays to store values and numpy arrays of ``np.int64`` type to store shapes in the graph.
+
+====================
+Additional Resources
+====================
+
+* :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`
+* :doc:`Graph Traversal and Modification Using Ports and Connections <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer_Model_Optimizer_Ports_Connections>`
+* :doc:`Model Optimizer Extensions <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions>`
+* :doc:`Extending Model Optimizer with Caffe Python Layers <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Extending_Model_Optimizer_With_Caffe_Python_Layers>`
+
+@endsphinxdirective

docs/MO_DG/prepare_model/customize_model_optimizer/Model_Optimizer_Operation.md

@@ -0,0 +1,107 @@
+# [LEGACY] Model Optimizer Operation {#openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Operation}
+
+@sphinxdirective
+
+.. danger::
+
+   The code described here has been **deprecated!** Do not use it to avoid working with a legacy solution. It will be kept for some time to ensure backwards compatibility, but **you should not use** it in contemporary applications.
+
+   This guide describes a deprecated TensorFlow conversion method. The guide on the new and recommended method, using a new frontend, can be found in the  :doc:`Frontend Extensions <openvino_docs_Extensibility_UG_Frontend_Extensions>` article. 
+
+Model Optimizer defines a ``mo.ops.Op`` class (``Op`` will be used later in the document to be short), which is a base class
+for an operation used in the Model Optimizer. The instance of the ``Op`` class serves several purposes:
+
+1. Stores the operation attributes.
+2. Stores the operation shape/value and type inference functions.
+3. Defines operation attributes to be saved to the corresponding IR section.
+4. Contains convenient methods to create a graph node from an ``Op`` object instance and connect it with the existing graph.
+5. Used in the extractors to store parsed attributes and operation specific attributes in the dedicated graph node.
+
+It is important to mention that there is no connection between the instance of the ``Op`` class and the ``Node`` object
+created from it. The ``Op`` class is just a container for attributes describing the operation. Model Optimizer uses the ``Op``
+class during a model conversion to create a node of the graph with attributes copied from the ``Op`` class instance. Graph
+manipulations are performed with graph ``Nodes`` and their attributes and does not involve ``Ops``.
+
+There are a number of common attributes used in the operations. Below is the list of these attributes with description.
+
+* ``id`` — **(Mandatory)** — unique identifier of a node in a graph. Generated automatically, equal to the number of nodes in the graph plus 1 if not specified.
+* ``name`` — **(Mandatory)** — name of the operation. Generated automatically, equal to the ``id`` if not specified.
+* ``type`` — **(Mandatory)** —  type of the operation according to the :doc:`opset specification <openvino_docs_ops_opset>`. For the internal Model Optimizer operations, this attribute should be set to ``None``. The model conversion fails if an operation with ``type`` equal to ``None`` comes to the IR emitting phase.
+* ``version`` — **(Mandatory)** —  the operation set (opset) name the operation belongs to. If not specified,  Model Optimizer sets it equal to ``experimental``. For more information about operation sets, refer to  :doc:`OpenVINO Model Representation <openvino_docs_OV_UG_Model_Representation>` section. 
+* ``op`` — Model Optimizer type of the operation. In many cases, the value of ``type`` is equal to the value of ``op``. However, when Model Optimizer cannot instantiate the opset operation during model loading, it creates an instance of an internal operation. Thus, the attribute ``op`` is used as a type of this internal operation. Later in the pipeline, the node created from an internal operation will be replaced during front, middle or back phase with node(s) created from the opset.
+* ``infer`` — the attribute defines a function calculating output tensor(s) shape and optional value(s). The attribute may be set to ``None`` for the internal Model Optimizer operations used during the front phase only. For more information  about the shape inference function, refer to the :ref:`Partial Inference <mo_partial_inference>`.
+* ``type_infer`` — the attribute defines a function calculating output tensor(s) data type. If the attribute is not defined, the default function is used. The function checks if the ``data_type`` node attribute is set and then propagates this type to the output tensor from the **port 0**. Otherwise, it propagates the data type of the tensor coming into the input **port 0** to the output tensor from the **port 0**.
+* ``in_ports_count`` — default number of input ports to be created for the operation. Additional ports can be created or redundant ports can be removed using dedicated ``Node`` class API methods.
+* ``out_ports_count`` — default number of output ports to be created for the operation. Additional ports can be created or redundant ports can be removed using dedicated ``Node`` class API methods.
+
+Below is an example of the Model Optimizer class for the :doc:`SoftMax <openvino_docs_ops_activation_SoftMax_1>` operation from
+the ``mo/ops/softmax.py`` file with the comments in code.
+
+.. code-block:: py
+   
+   class Softmax(Op):
+       # The class attribute defines a name of the operation so the operation class can be obtained using the
+       # "Op.get_op_class_by_name()" static method
+       op = 'SoftMax'
+   
+       # The operation works as an extractor by default. This is a legacy behavior, currently not recommended for use,
+       # thus "enabled" class attribute is set to False. The recommended approach is to use dedicated extractor extension.
+       enabled = False
+   
+       def __init__(self, graph: Graph, attrs: dict):
+           super().__init__(graph, {  # The constructor of the base class Op is called with additional default attributes.
+               'type': __class__.op,  # The operation is from the opset so the type is set to 'SoftMax'.
+               'op': __class__.op,  # Internal Model Optimizer operation has the same type.
+               'version': 'opset1',  # The operation corresponds to opset1.
+               'infer': Softmax.infer,  # Shape inference function is defined below.
+               'axis': 1,  # Default value for the "axis" attribute of the operation SoftMax.
+               'in_ports_count': 1,  # The operation has one input.
+               'out_ports_count': 1,  # The operation produces one output.
+           }, attrs)
+   
+       # The method returns operation specific attributes list. This method is important when implementing
+       # extractor inherited from CaffePythonFrontExtractorOp class to extract attribute for Caffe Python operation.
+       # However, it is currently used interchangeably with the "backend_attrs()" method. If the "backend_attrs()" is not used,
+       # then the "supported_attrs()" is used instead. In this particular case, the operation has just one attribute "axis".
+       def supported_attrs(self):
+           return ['axis']
+   
+       @staticmethod
+       def infer(node: Node):
+           "some code calculating output shape and values"
+
+There is a dedicated method called ``backend_attrs()`` defining a list of attributes to be saved to the IR. Consider an
+example from the ``mo/ops/pooling.py`` file:
+
+.. code-block:: py
+   
+      def backend_attrs(self):
+           return [
+               ('strides', lambda node: ','.join(map(str, node['stride'][node.spatial_dims]))),
+               ('kernel', lambda node: ','.join(map(str, node['window'][node.spatial_dims]))),
+   
+               ('pads_begin', lambda node: ','.join(map(str, get_backend_pad(node.pad, node.spatial_dims, 0)))),
+               ('pads_end', lambda node: ','.join(map(str, get_backend_pad(node.pad, node.spatial_dims, 1)))),
+   
+               ('pool-method', 'pool_method'),
+               ('exclude-pad', 'exclude_pad'),
+   
+               'rounding_type',
+               'auto_pad',
+           ]
+
+The ``backend_attrs()`` function returns a list of records. A record can be of one of the following formats:
+1. A string defining the attribute to be saved to the IR. If the value of the attribute is ``None``, the attribute is not saved. Examples of this case are ``rounding_type`` and ``auto_pad``.
+2. A tuple, where the first element is a string defining the name of the attribute as it will appear in the IR and the second element is a function to produce the value for this attribute. The function gets an instance of the ``Node`` as the only parameter and returns a string with the value to be saved to the IR. Examples of this case are ``strides``, ``kernel``, ``pads_begin`` and ``pads_end``.
+3. A tuple, where the first element is a string defining the name of the attribute as it will appear in the IR and the second element is the name of the ``Node`` attribute to get the value from. Examples of this case are ``pool-method`` and ``exclude-pad``.
+
+====================
+Additional Resources
+====================
+
+* :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`
+* :doc:`Graph Traversal and Modification Using Ports and Connections <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer_Model_Optimizer_Ports_Connections>`
+* :doc:`Model Optimizer Extensions <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions>`
+* :doc:`Extending Model Optimizer with Caffe Python Layers <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Extending_Model_Optimizer_With_Caffe_Python_Layers>`
+
+@endsphinxdirective

docs/MO_DG/prepare_model/customize_model_optimizer/Model_Optimizer_Ports_Connections.md

@@ -0,0 +1,183 @@
+# [LEGACY] Graph Traversal and Modification {#openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer_Model_Optimizer_Ports_Connections}
+
+@sphinxdirective
+
+.. danger::
+
+   The code described here has been **deprecated!** Do not use it to avoid working with a legacy solution. It will be kept for some time to ensure backwards compatibility, but **you should not use** it in contemporary applications.
+
+   This guide describes a deprecated TensorFlow conversion method. The guide on the new and recommended method, using a new frontend, can be found in the  :doc:`Frontend Extensions <openvino_docs_Extensibility_UG_Frontend_Extensions>` article. 
+
+There are three APIs for a graph traversal and transformation used in the Model Optimizer:
+
+1. The API provided with the ``networkx`` Python library for the ``networkx.MultiDiGraph`` class, which is the base class for
+the ``mo.graph.graph.Graph`` object. For example, the following methods belong to this API level: 
+
+* ``graph.add_edges_from([list])``,
+* ``graph.add_node(x, attrs)``, 
+* ``graph.out_edges(node_id)`` 
+* other methods where ``graph`` is a an instance of the ``networkx.MultiDiGraph`` class.
+
+**This is the lowest-level API. Avoid using it in the Model Optimizer transformations**. For more details, refer to the :ref:`Model Representation in Memory <mo_model_representation_in_memory>` section. 
+
+2. The API built around the ``mo.graph.graph.Node`` class. The ``Node`` class is the primary class to work with graph nodes
+and their attributes. Examples of such methods and functions are:
+
+* ``node.in_node(y)``, 
+* ``node.out_node(x)``,
+* ``node.get_outputs()``,
+* ``node.insert_node_after(n1, y)``,
+* ``create_edge(n1, n2)``
+
+**There are some "Node" class methods not recommended for use and some functions defined in the mo.graph.graph have been deprecated**. For more details, refer to the ``mo/graph/graph.py`` file. 
+
+3. The high-level API called Model Optimizer Graph API, which uses ``mo.graph.graph.Graph``, ``mo.graph.port.Port`` and
+``mo.graph.connection.Connection`` classes. For example, the following methods belong to this API level:
+
+* ``node.in_port(x)``, 
+* ``node.out_port(y)``, 
+* ``port.get_connection()``, 
+* ``connection.get_source()``,
+* ``connection.set_destination(dest_port)``
+
+**This is the recommended API for the Model Optimizer transformations and operations implementation**.
+
+The main benefit of using the Model Optimizer Graph API is that it hides some internal implementation details (the fact that
+the graph contains data nodes), provides API to perform safe and predictable graph manipulations, and adds operation
+semantic to the graph. This is achieved with introduction of concepts of ports and connections. 
+
+.. note:: 
+   This article is dedicated to the Model Optimizer Graph API only and does not cover other two non-recommended APIs.
+
+.. _mo_intro_ports:
+
+=====
+Ports
+=====
+
+An operation semantic describes how many inputs and outputs the operation has. For example, 
+:doc:`Parameter <openvino_docs_ops_infrastructure_Parameter_1>` and :doc:`Const <openvino_docs_ops_infrastructure_Constant_1>` operations have no
+inputs and have one output, :doc:`ReLU <openvino_docs_ops_activation_ReLU_1>` operation has one input and one output, 
+:doc:`Split <openvino_docs_ops_movement_Split_1>` operation has 2 inputs and a variable number of outputs depending on the value of the
+attribute ``num_splits``.
+
+Each operation node in the graph (an instance of the ``Node`` class) has 0 or more input and output ports (instances of
+the ``mo.graph.port.Port`` class). The ``Port`` object has several attributes:
+
+* ``node`` - the instance of the ``Node`` object the port belongs to.
+* ``idx`` - the port number. Input and output ports are numbered independently, starting from ``0``. Thus, 
+:doc:`ReLU <openvino_docs_ops_activation_ReLU_1>` operation has one input port (with index ``0``) and one output port (with index ``0``).
+* ``type`` - the type of the port. Could be equal to either ``"in"`` or ``"out"``.
+* ``data`` - the object that should be used to get attributes of the corresponding data node. This object has methods ``get_shape()`` / ``set_shape()`` and ``get_value()`` / ``set_value()`` to get/set shape/value of the corresponding data node. For example, ``in_port.data.get_shape()`` returns an input shape of a tensor connected to input port ``in_port`` (``in_port.type == 'in'``), ``out_port.data.get_value()`` returns a value of a tensor produced from output port ``out_port`` (``out_port.type == 'out'``).
+
+.. note:: 
+   Functions ``get_shape()`` and ``get_value()`` return ``None`` until the partial inference phase. For more information  about model conversion phases, refer to the :ref:`Model Conversion Pipeline <mo_model_conversion_pipeline>`. For information about partial inference phase, see the :ref:`Partial Inference <mo_partial_inference>`.
+
+There are several methods of the ``Node`` class to get the instance of a corresponding port:
+
+* ``in_port(x)`` and ``out_port(x)`` to get the input/output port with number ``x``.
+* ``in_ports()`` and ``out_ports()`` to get a dictionary, where key is a port number and the value is the corresponding input/output port.
+
+Attributes ``in_ports_count`` and ``out_ports_count`` of the ``Op`` class instance define default number of input and output
+ports to be created for the ``Node``. However, additional input/output ports can be added using methods
+``add_input_port()`` and ``add_output_port()``. Port also can be removed, using the ``delete_input_port()`` and
+``delete_output_port()`` methods.
+
+The ``Port`` class is just an abstraction that works with edges incoming/outgoing to/from a specific ``Node`` instance. For
+example, output port with ``idx = 1`` corresponds to the outgoing edge of a node with an attribute ``out = 1``, the input
+port with ``idx = 2`` corresponds to the incoming edge of a node with an attribute ``in = 2``.
+
+Consider the example of a graph part with 4 operation nodes "Op1", "Op2", "Op3", and "Op4" and a number of data nodes
+depicted with light green boxes.
+
+.. image:: _static/images/MO_ports_example_1.svg
+   :scale: 80 %
+   :align: center
+
+Operation nodes have input ports (yellow squares) and output ports (light purple squares). Input port may not be
+connected. For example, the input **port 2** of node **Op1** does not have incoming edge, while output port always has an
+associated data node (after the partial inference when the data nodes are added to the graph), which may have no
+consumers.
+
+Ports can be used to traverse a graph. The method ``get_source()`` of an input port returns an output port producing the
+tensor consumed by the input port. It is important that the method works the same during front, middle and back phases of a
+model conversion even though the graph structure changes (there are no data nodes in the graph during the front phase).
+
+Let's assume that there are 4 instances of ``Node`` object ``op1, op2, op3``, and ``op4`` corresponding to nodes **Op1**, **Op2**,
+**Op3**, and **Op4**, respectively. The result of ``op2.in_port(0).get_source()`` and ``op4.in_port(1).get_source()`` is the
+same object ``op1.out_port(1)`` of type ``Port``.
+
+The method ``get_destination()`` of an output port returns the input port of the node consuming this tensor. If there are
+multiple consumers of this tensor, the error is raised. The method ``get_destinations()`` of an output port returns a
+list of input ports consuming the tensor.
+
+The method ``disconnect()`` removes a node incoming edge corresponding to the specific input port. The method removes
+several edges if it is applied during the front phase for a node output port connected with multiple nodes.
+
+The method ``port.connect(another_port)`` connects output port ``port`` and input port ``another_port``. The method handles
+situations when the graph contains data nodes (middle and back phases) and does not create an edge between two nodes
+but also automatically creates data node or reuses existing data node. If the method is used during the front phase and
+data nodes do not exist, the method creates edge and properly sets ``in`` and ``out`` edge attributes.
+
+For example, applying the following two methods to the graph above will result in the graph depicted below:
+
+.. code-block:: py
+
+   op4.in_port(1).disconnect()
+   op3.out_port(0).connect(op4.in_port(1))
+
+.. image:: _static/images/MO_ports_example_2.svg
+   :scale: 80 %
+   :align: center
+
+.. note:: 
+   For a full list of available methods, refer to the ``Node`` class implementation in the ``mo/graph/graph.py`` and ``Port`` class implementation in the ``mo/graph/port.py`` files.
+
+===========
+Connections
+===========
+
+Connection is a concept introduced to easily and reliably perform graph modifications. Connection corresponds to a
+link between a source output port with one or more destination input ports or a link between a destination input port
+and source output port producing data. So each port is connected with one or more ports with help of a connection.
+Model Optimizer uses the ``mo.graph.connection.Connection`` class to represent a connection.
+
+There is only one ``get_connection()`` method of the ``Port`` class to get the instance of the corresponding ``Connection``
+object. If the port is not connected, the returned value is ``None``.
+
+For example, the ``op3.out_port(0).get_connection()`` method returns a ``Connection`` object encapsulating edges from node
+**Op3** to data node **data_3_0** and two edges from data node **data_3_0** to two ports of the node **Op4**.
+
+The ``Connection`` class provides methods to get source and destination(s) ports the connection corresponds to:
+
+* ``connection.get_source()`` - returns an output ``Port`` object producing the tensor.
+* ``connection.get_destinations()`` - returns a list of input ``Port`` consuming the data.
+* ``connection.get_destination()`` - returns a single input ``Port`` consuming the data. If there are multiple consumers, the exception is raised.
+
+The ``Connection`` class provides methods to modify a graph by changing a source or destination(s) of a connection. For
+example, the function call ``op3.out_port(0).get_connection().set_source(op1.out_port(0))`` changes source port of edges
+consuming data from port ``op3.out_port(0)`` to ``op1.out_port(0)``. The transformed graph from the sample above is depicted
+below:
+
+.. image:: _static/images/MO_connection_example_1.svg
+   :scale: 80 %
+   :align: center
+
+Another example is the ``connection.set_destination(dest_port)`` method. It disconnects ``dest_port`` and all input ports to which
+the connection is currently connected and connects the connection source port to ``dest_port``.
+
+Note that connection works seamlessly during front, middle, and back phases and hides the fact that the graph structure is
+different.
+
+.. note:: 
+   For a full list of available methods, refer to the ``Connection`` class implementation in the ``mo/graph/connection.py`` file.
+
+====================
+Additional Resources
+====================
+
+* :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`
+* :doc:`Model Optimizer Extensions <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions>`
+* :doc:`Extending Model Optimizer with Caffe Python Layers <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Extending_Model_Optimizer_With_Caffe_Python_Layers>`
+
+@endsphinxdirective

docs/MO_DG/prepare_model/customize_model_optimizer/Model_Optimizer_Transformation_Extensions.md

@@ -0,0 +1,599 @@
+# [LEGACY] Graph Transformation Extensions {#openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions_Model_Optimizer_Transformation_Extensions}
+
+@sphinxdirective
+
+.. danger::
+
+   The code described here has been **deprecated!** Do not use it to avoid working with a legacy solution. It will be kept for some time to ensure backwards compatibility, but **you should not use** it in contemporary applications.
+
+   This guide describes a deprecated TensorFlow conversion method. The guide on the new and recommended method, using a new frontend, can be found in the  :doc:`Frontend Extensions <openvino_docs_Extensibility_UG_Frontend_Extensions>` article. 
+
+Model Optimizer provides various base classes to implement :ref:`Front Phase Transformations <mo_front_phase_transformations>`,
+:ref:`Middle Phase Transformations <mo_middle_phase_transformations>`, and :ref:`Back Phase Transformations <mo_back_phase_transformations>`.
+All classes have the following common class attributes and methods:
+
+1. The ``enabled`` attribute specifies whether the transformation is enabled or not. The value can be changed during runtime to enable or disable execution of the transformation during a model conversion. Default value is ``True``.
+2. The ``id`` attribute specifies a unique transformation string identifier. This transformation identifier can be used to enable (disable) the transformation by setting environment variable ``MO_ENABLED_TRANSFORMS`` (``MO_DISABLED_TRANSFORMS``) with a comma separated list of ``ids``. The environment variables override the value of the ``enabled`` attribute of the transformation. Instead of using ``id`` attribute value you can add fully defined class name to ``MO_ENABLED_TRANSFORMS`` (``MO_DISABLED_TRANSFORMS``) variable, ``extensions.back.NonmalizeToNormalizeL2.NormalizeToNormalizeL2`` for example. It is an optional attribute.
+3. The ``run_not_recursively`` attribute specifies whether the transformation should be executed in the sub-graphs, for example, body of the :doc:`TensorIterator <openvino_docs_ops_infrastructure_TensorIterator_1>` and the :doc:`Loop <openvino_docs_ops_infrastructure_Loop_5>`. Default value is ``True``.
+4. The ``force_clean_up`` attribute specifies whether the graph clean up should be executed after the transformation. The graph cleanup removes nodes of the graph not reachable from the model inputs. Default value is ``False``.
+5. The ``force_shape_inference`` attribute specifies whether the nodes marked with ``need_shape_inference`` attribute equal to ``True`` should be re-inferred after the transformation. Model Optimizer sets this attribute automatically for nodes, input(s) of which were changed during the transformation, or you can set this attribute manually in the transformation for the specific nodes. Default value is ``False``.
+6. Attribute ``graph_condition`` specifies a list of functions with one parameter -- ``Graph`` object. The transformation is executed if and only if all functions return ``True``. If the attribute is not set, no check is performed.
+7. Method ``run_before()`` returns a list of transformation classes which this transformation should be executed before.
+8. Method ``run_after()`` returns a list of transformation classes which this transformation should be executed after.
+
+.. note:: 
+   Some of the transformation types have specific class attributes and methods, which are explained in the corresponding sections of this document.
+
+Model Optimizer builds a graph of dependencies between registered transformations and executes them in the topological
+order. To execute the transformation during a proper model conversion phase, Model Optimizer defines several
+anchor transformations that do nothing. All transformations are ordered with respect to these anchor transformations.
+The diagram below shows anchor transformations, some of built-in transformations and dependencies between them:
+
+.. image:: _static/images/MO_transformations_graph.svg
+
+User-defined transformations are executed after the corresponding ``Start`` and before the corresponding ``Finish`` anchor
+transformations by default (if ``run_before()`` and ``run_after()`` methods have not been overridden).
+
+.. note:: 
+   The ``PreMiddleStart`` and ``PostMiddleStart`` anchors were introduced due to historical reasons to refactor the Model Optimizer pipeline, which initially had a hardcoded order of transformations.
+
+.. _mo_front_phase_transformations:
+
+===========================
+Front Phase Transformations
+===========================
+
+There are several types of a front phase transformation:
+
+1. :ref:`Pattern-Defined Front Phase Transformations <pattern_defined_front_phase_transformations>` triggered for each sub-graph of the original graph isomorphic to the specified pattern.
+2. :ref:`Specific Operation Front Phase Transformations <specific_operation_front_phase_transformations>` triggered for the node with a specific ``op`` attribute value.
+3. :ref:`Generic Front Phase Transformations <generic_front_phase_transformations>`.
+4. Manually enabled transformation, defined with a JSON configuration file (for TensorFlow, ONNX, Apache MXNet, and PaddlePaddle models), specified using the ``--transformations_config`` command-line parameter:
+
+   1. :ref:`Node Name Pattern Front Phase Transformations <node_name_pattern_front_phase_transformations>`.
+   2. :ref:`Front Phase Transformations Using Start and End Points <start_end_points_front_phase_transformations>`.
+   3. :ref:`Generic Front Phase Transformations Enabled with Transformations Configuration File <generic_transformations_config_front_phase_transformations>`.
+
+.. _pattern_defined_front_phase_transformations:
+
+Pattern-Defined Front Phase Transformations
+###########################################
+
+This type of transformation is implemented using ``mo.front.common.replacement.FrontReplacementSubgraph`` and
+``mo.front.common.replacement.FrontReplacementPattern`` as base classes and works as follows:
+
+1. Define a sub-graph to be matched, using a list of nodes with attributes and edges connecting them (edges may also have attributes).
+2. Model Optimizer searches for all sub-graphs of the original graph, isomorphic to the specified sub-graph (pattern).
+3. Model Optimizer executes the defined function performing graph transformation for each instance of a matched sub-graph. You can override different functions in the base transformation class so the Model Optimizer works differently:
+
+   1. The ``replace_sub_graph(self, graph, match)`` override the method. In this case Model Optimizer only executes the overridden function, pass the ``graph`` object and a dictionary describing the matched sub-graph. You are required to write the transformation and connect the newly created nodes to the rest of the graph.
+   2. The ``generate_sub_graph(self, graph, match)`` override the method. This case is not recommended for use because it is the most complicated approach. It can be effectively replaced with one of two previous approaches. 
+
+The sub-graph pattern is defined in the ``pattern()`` function. This function should return a dictionary with two keys:
+``nodes`` and ``edges``:
+
+* The value for the ``nodes`` key is a list of tuples with two elements.
+
+  * The first element is an alias name for a node that will be used to define edges between nodes and in the transformation function.
+  * The second element is a dictionary with attributes. The key is a name of an attribute that should exist in the node. The value for the attribute can be some specific value to match or a function that gets a single parameter - the attribute value from the node. The function should return the result of attribute comparison with a dedicated value.
+
+* The value for the ``edges`` key is a list of tuples with two or three elements.
+
+  * The first element is the alias name of the node producing a tensor.
+  * The second element is the alias name of the node consuming the tensor.
+  * The third element (optional) is the dictionary with expected edge attributes. This dictionary usually contains attributes like ``in`` and ``out``, defining input and output ports.
+
+Consider the example of a front transformation implemented in the ``extensions/front/Mish_fusion.py`` file performing
+fusing of the sub-graph defining the :doc:`Mish <openvino_docs_ops_activation_Mish_4>` activation function into a single
+operation:
+
+.. code-block:: py
+
+   from openvino.tools.mo.front.Softplus_fusion import SoftplusFusion
+   from openvino.tools.mo.ops.activation_ops import Mish
+   from openvino.tools.mo.front.common.replacement import FrontReplacementSubgraph
+   from openvino.tools.mo.front.subgraph_matcher import SubgraphMatch
+   from openvino.tools.mo.graph.graph import Graph, rename_nodes
+   
+   
+   class MishFusion(FrontReplacementSubgraph):
+       """
+       The transformation looks for the pattern with Softplus defining the Mish function: Mish(x) = x * tanh(SoftPlus(x)).
+       """
+       enabled = True  # Transformation is enabled.
+   
+       def run_after(self):  # Run this transformation after "SoftplusFusion" transformation.
+           return [SoftplusFusion]
+   
+       def pattern(self):  # Define pattern according to formulae x * tanh(SoftPlus(x)).
+           return dict(
+               nodes=[
+                   ('mul', dict(op='Mul')),
+                   ('tanh', dict(op='Tanh')),
+                   ('softplus', dict(op='SoftPlus')),
+               ],
+               edges=[
+                   ('softplus', 'tanh'),
+                   ('tanh', 'mul'),
+               ])
+   
+       def replace_sub_graph(self, graph: Graph, match: [dict, SubgraphMatch]):  # Entry point for the transformation.
+           mul = match['mul']  # Get the Node corresponding to matched "mul" node.
+           mul_name = mul.soft_get('name', mul.id)
+           softplus = match['softplus']  # Get the Node corresponding to the matched "softplus" node.
+   
+           # Determine the input port of Mul which gets the 'input' node output.
+           input_port_idx = int(mul.in_port(0).get_connection().get_source().node.soft_get('op') == 'Tanh')
+   
+           # Check that the same tensor is provided as input to Mul and SoftPlus.
+           if mul.in_port(input_port_idx).get_source() != softplus.in_port(0).get_source():
+               return
+   
+           mish = Mish(graph, {}).create_node()  # Create Mish operation.
+           mish.in_port(0).connect(mul.in_port(input_port_idx).get_source())  # Connect input to the Mish.
+           mul.out_port(0).get_connection().set_source(mish.out_port(0))  # Reconnect outgoing edge from "mul" to Mish.
+   
+           # Rename the created Mish operation to have the name of the "mul" node, which produced the value equal to the
+           # Mish output.
+           rename_nodes([(mul, mul_name + '/TBR'), (mish, mul_name)])
+
+.. _specific_operation_front_phase_transformations:
+
+Specific Operation Front Phase Transformations
+##############################################
+
+This type of transformation is implemented using ``mo.front.common.replacement.FrontReplacementOp`` as base class and
+works as follows:
+
+1. Define an operation type to trigger the transformation.
+2. Model Optimizer searches for all nodes in the graph with the attribute ``op`` equal to the specified value.
+3. Model Optimizer executes the defined function performing graph transformation for each instance of a matched node. You can override different functions in the base transformation class and Model Optimizer works differently:
+
+   1. The ``replace_sub_graph(self, graph, match)`` override method. In this case, Model Optimizer only executes the overridden function. Pass the ``graph`` object and a dictionary with a single key ``op`` with the matched node as value. You are required to write the transformation and connect the newly created nodes to the rest of the graph.
+   2. The ``replace_op(self, graph, node)`` override method. In this case, Model Optimizer executes the overridden function. Pass the ``graph`` object and the matched node as ``node`` parameter. If the function returns an ``id`` of some node, then the ``Node`` with this ``id`` is connected to the consumers of the matched node. After applying the transformation, the matched node is removed from the graph.
+
+The ``FrontReplacementOp`` class provides a simpler mechanism to match a single operation with specific value of the ``op``
+(write the ``op`` attribute in the class instead of defining a ``pattern()`` function) attribute and perform the
+transformation.
+
+Consider an example transformation from the ``extensions/front/Pack.py`` file, which replaces ``Pack`` operation from
+the TensorFlow:
+
+.. code-block:: py
+   
+   from openvino.tools.mo.front.common.partial_infer.utils import int64_array
+   from openvino.tools.mo.front.common.replacement import FrontReplacementOp
+   from openvino.tools.mo.front.tf.graph_utils import create_op_with_const_inputs
+   from openvino.tools.mo.graph.graph import Node, Graph, rename_nodes
+   from openvino.tools.mo.ops.concat import Concat
+   from openvino.tools.mo.ops.unsqueeze import Unsqueeze
+   
+   
+   class Pack(FrontReplacementOp):
+       op = "Pack"  # Trigger transformation for all nodes in the graph with the op = "Pack" attribute 
+       enabled = True  # Transformation is enabled.
+   
+       def replace_op(self, graph: Graph, node: Node):  # Entry point for the transformation.
+           # Create a Concat operation with a number of inputs equal to a number of inputs to Pack.
+           out_node = Concat(graph, {'axis': node.axis, 'in_ports_count': len(node.in_ports())}).create_node()
+           pack_name = node.soft_get('name', node.id)
+   
+           for ind in node.in_ports():
+               # Add dimension of size 1 to all inputs of the Pack operation and add them as Concat inputs.
+               unsqueeze_node = create_op_with_const_inputs(graph, Unsqueeze, {1: int64_array([node.axis])},
+                                                            {'name': node.soft_get('name', node.id) + '/Unsqueeze'})
+               node.in_port(ind).get_connection().set_destination(unsqueeze_node.in_port(0))
+               unsqueeze_node.out_port(0).connect(out_node.in_port(ind))
+   
+           # Rename the created Concat operation to have the name of the "pack" node, which produced the value equal to the
+           # Concat output.
+           rename_nodes([(node, pack_name + '/TBR'), (out_node, pack_name)])
+           return [out_node.id]  # Reconnect the Pack operation consumers to get input from Concat instead.
+
+
+.. _generic_front_phase_transformations:
+
+Generic Front Phase Transformations
+###################################
+
+Model Optimizer provides a mechanism to implement generic front phase transformation. This type of transformation is
+implemented using ``mo.front.common.replacement.FrontReplacementSubgraph`` or
+``mo.front.common.replacement.FrontReplacementPattern`` as base classes. Make sure the transformation is enabled before trying to execute it. 
+Then, Model Optimizer executes the ``find_and_replace_pattern(self, graph)`` method and
+provides a ``Graph`` object as an input.
+
+Consider the example of a generic front transformation from the ``extensions/front/SqueezeNormalize.py`` file performing
+normalization of the :doc:`Squeeze <openvino_docs_ops_shape_Squeeze_1>` operation. Older version of the operation had a list of
+axes to squeeze as an attribute, but now it is a separate input. For backward compatibility, the Model Optimizer
+operation supports both semantics. Before IR generation, however, the operation should be normalized according to the
+specification.
+
+.. code-block:: py
+
+   import logging as log
+   
+   from openvino.tools.mo.front.common.partial_infer.utils import int64_array
+   from openvino.tools.mo.front.common.replacement import FrontReplacementPattern
+   from openvino.tools.mo.graph.graph import Graph
+   from openvino.tools.mo.ops.const import Const
+   from openvino.tools.mo.utils.error import Error
+   
+   
+   class SqueezeNormalize(FrontReplacementPattern):
+       """
+       Normalizes inputs of the Squeeze layers. The layers should have two inputs: the input with data and input with the
+       dimensions to squeeze. If the second input is omitted then all dimensions of size 1 should be removed.
+       """
+       enabled = True  # The transformation is enabled.
+   
+       def find_and_replace_pattern(self, graph: Graph):  # The function is called unconditionally.
+           for squeeze_node in graph.get_op_nodes(op='Squeeze'):  # Iterate over all nodes with op='Squeeze'.
+               # If the operation has only 1 input node and no 'squeeze_dims' Node attribute, then convert the attribute to
+               # the operation input.
+               if len(squeeze_node.in_nodes()) == 1 and squeeze_node.has_valid('squeeze_dims'):
+                   dims_node = Const(graph, {'name': squeeze_node.id + '/Dims',
+                                             'value': int64_array(squeeze_node.squeeze_dims)}).create_node()
+                   squeeze_node.in_port(1).connect(dims_node.out_port(0))
+                   del squeeze_node['squeeze_dims']
+               # If two inputs already exist, that means the operation is already normalized.
+               elif len(squeeze_node.in_nodes()) == 2:
+                   log.debug('The Squeeze node "{}" is already normalized'.format(squeeze_node.name))
+               # In all other cases, raise an error.
+               else:
+                   raise Error('The Squeeze layer "{}" should either have 2 inputs or one input and an "squeeze_dims" '
+                               'attribute'.format(squeeze_node.soft_get('name')))
+
+For the details on implementation and how these front phase transformations work, refer to the ``mo/front/common/replacement.py``
+file.
+
+.. _node_name_pattern_front_phase_transformations:
+
+Node Name Pattern Front Phase Transformations
+#############################################
+
+TensorFlow uses a mechanism of scope to group related operation nodes. It is a good practice to put nodes performing
+particular task into the same scope. This approach divides a graph into logical blocks that are easier to review in the
+TensorBoard. The scope, in fact, just defines a common name prefix for the nodes belonging to it.
+
+For example, Inception topologies contain several types of so-called **Inception blocks**. Some of them are equal to each
+other, but located in different places of the network. For example, Inception V4 from the
+`TensorFlow-Slim image classification model library <https://github.com/tensorflow/models/tree/master/research/slim>`__ has
+``Mixed_5b``, ``Mixed_5c`` and ``Mixed_5d`` inception blocks with exactly the same nodes, with the same set of attributes.
+
+Consider a situation when these Inception blocks are implemented extremely efficiently using a single Inference
+Engine operation called ``InceptionBlock`` and these blocks in the model need to be replaced with instances of this operation.
+Model Optimizer provides mechanism to trigger the transformation for a sub-graph of operations defined by the node name
+regular expressions (scope). In this particular case, some of the patterns are: ``.*InceptionV4/Mixed_5b``,
+``.*InceptionV4/Mixed_5c`` and ``.*InceptionV4/Mixed_5d``. Each pattern starts with ``.*``, because the ``InceptionV4`` prefix 
+is added to all nodes names during a model freeze.
+
+This type of transformation is implemented using ``mo.front.tf.replacement.FrontReplacementFromConfigFileSubGraph`` as a
+base class and works as follows:
+
+1. Prepare a JSON configuration file template defining node names patterns.
+2. Run Model Optimizer with the ``--tensorflow_custom_operations_config_update`` command-line parameter, and Model Optimizer adds information about input and output nodes of the specified sub-graphs.
+3. Model Optimizer executes the defined transformation **only** when you specify the path to the configuration file updated in step 2 using the ``--transformations_config`` command-line parameter.
+
+Consider the following possible configuration file template for the Inception Block transformation:
+
+.. code-block:: json
+
+   [
+       {
+           "custom_attributes": {
+               "attr1_key": "attr1_value",
+               "attr2_key": 123456
+           },
+           "id": "InceptionBlockTransformation",
+           "instances": [
+               ".*InceptionV4/Mixed_5b",
+               ".*InceptionV4/Mixed_5c",
+               ".*InceptionV4/Mixed_5d"
+           ],
+           "match_kind": "scope"
+       }
+   ]
+
+The configuration file contains a list of dictionaries. Each dictionary defines one transformation. Each transformation
+is defined with several parameters:
+
+* ``id`` - **(Mandatory)** — is a unique identifier of the transformation. It is used in the Python code that implements the transformation to link the class and the transformation description from the configuration file.
+* ``match_kind`` - **(Mandatory)** —  is a string that specifies the matching algorithm. For the node name pattern case, the value should be equal to ``scope``. Another possible values are described in the dedicated sections below.
+* ``instances`` - **(Mandatory)** —  specifies instances of the sub-graph to be matched. It contains a list of node names prefixes patterns for the match kind of the ``scope`` type.
+* ``custom_attributes`` - **(Optional)** —  is a dictionary with attributes that can be used in the transformation code.
+
+After running Model Optimizer with additional ``--tensorflow_custom_operations_config_update`` parameter pointing to
+the template configuration file, the content of the file should be updated with two new sections ``inputs`` and ``outputs``.
+The file content after the update is as follows:
+
+.. code-block:: json
+
+   [
+       {
+           "id": "InceptionBlockTransformation",
+           "custom_attributes": {
+               "attr1_key": "attr1_value",
+               "attr2_key": 123456
+           },
+           "instances": [
+               ".*InceptionV4/Mixed_5b",
+               ".*InceptionV4/Mixed_5c",
+               ".*InceptionV4/Mixed_5d"
+           ],
+           "match_kind": "scope",
+           "inputs": [
+               [
+                   {
+                       "node": "Branch_2/Conv2d_0a_1x1/Conv2D$",
+                       "port": 0
+                   },
+                   {
+                       "node": "Branch_3/AvgPool_0a_3x3/AvgPool$",
+                       "port": 0
+                   },
+                   {
+                       "node": "Branch_1/Conv2d_0a_1x1/Conv2D$",
+                       "port": 0
+                   },
+                   {
+                       "node": "Branch_0/Conv2d_0a_1x1/Conv2D$",
+                       "port": 0
+                   }
+               ]
+           ],
+           "outputs": [
+               {
+                   "node": "concat$",
+                   "port": 0
+               }
+           ]
+       }
+   ]
+
+The value for ``inputs`` key is a list of lists describing input tensors of the sub-graph. Each element of the top-level
+list corresponds to one unique input tensor of the sub-graph. Each internal list describes a list of nodes consuming
+this tensor and port numbers, where the tensor is consumed. Model Optimizer generates regular expressions for the input
+nodes names to uniquely identify them in each instance of the sub-graph, defined by the ``instances``. Denote these nodes
+as input nodes of the sub-graph.
+
+In the InceptionV4 topology, the ``InceptionV4/Mixed_5b`` block has four input tensors from outside of the sub-graph,
+but all of them are produced by the ``InceptionV4/Mixed_5a/concat`` node. Therefore, the top-level list of the ``inputs``
+contains one list corresponding to this tensor. Four input nodes of the sub-graph consume the tensor produced by
+``InceptionV4/Mixed_5a/concat`` node. In this case, all four input nodes consume input tensor into "port 0".
+
+The order of items in the internal list describing nodes does not matter, but the order of elements in the top-level
+list is important. This order defines how Model Optimizer attaches input tensors to a new generated
+node if the sub-graph is replaced with a single node. The ``i``-th input node of the sub-graph is obtained using 
+``match.single_input_node(i)`` call in the sub-graph transformation code. More information about API is given below. If it is
+necessary to change the order of input tensors, the configuration file can be edited in the text editor.
+
+The value for the ``outputs`` key is a list describing nodes of the sub-graph producing tensor, that goes outside of the
+sub-graph or does not have child nodes. Denote these nodes as output nodes of the sub-graph. The order of elements in
+the list is important. The ``i``-th element of the list describes the ``i``-th output tensor of the sub-graph, which could be
+obtained using ``match.output_node(i)`` call. The order of elements can be manually changed in the configuration file.
+Model Optimizer uses this order to connect output edges if the sub-graph is replaced with a single node.
+
+For more examples of this type of transformation, refer to the :doc:`Converting TensorFlow Object Detection API Models <openvino_docs_MO_DG_prepare_model_convert_model_tf_specific_Convert_Object_Detection_API_Models>` guide.
+
+.. _start_end_points_front_phase_transformations:
+
+Front Phase Transformations Using Start and End Points
+######################################################
+
+This type of transformation is implemented using ``mo.front.tf.replacement.FrontReplacementFromConfigFileSubGraph`` as a
+base class and works as follows:
+
+1. Prepare a JSON configuration file that defines the sub-graph to match, using two lists of node names: "start" and "end" nodes.
+2. Model Optimizer executes the defined transformation **only** when you specify the path to the configuration file using the ``--transformations_config`` command-line parameter . Model Optimizer performs the following steps to match the sub-graph:
+
+   1. Starts a graph traversal from every start node following the direction of the graph edges. The search stops in an end node or in the case of a node without consumers. All visited nodes are added to the matched sub-graph.
+   2. Starts another graph traversal from each non-start node of the sub-graph, i.e. every node except nodes from the "start" list. In this step, the edges are traversed in the opposite edge direction. All newly visited nodes are added to the matched sub-graph. This step is needed to add nodes required for calculation values of internal nodes of the matched sub-graph.
+   3. Checks that all "end" nodes were reached from "start" nodes. If not, it exits with an error.
+   4. Checks that there are no :doc:`Parameter <openvino_docs_ops_infrastructure_Parameter_1>` operations among added nodes. If they exist, the sub-graph depends on the inputs of the model. Such configuration is considered incorrect so  Model Optimizer exits with an error.
+
+This algorithm finds all nodes "between" start and end nodes and nodes needed for calculation of non-input nodes of the
+matched sub-graph.
+
+The example of a JSON configuration file for a transformation with start and end points is
+``extensions/front/tf/ssd_support_api_v1.15.json``:
+
+.. code-block:: json
+   
+   [
+       {
+           "custom_attributes": {
+               "code_type": "caffe.PriorBoxParameter.CENTER_SIZE",
+               "pad_mode": "caffe.ResizeParameter.CONSTANT",
+               "resize_mode": "caffe.ResizeParameter.WARP",
+               "clip_before_nms": false,
+               "clip_after_nms": true
+           },
+           "id": "ObjectDetectionAPISSDPostprocessorReplacement",
+           "include_inputs_to_sub_graph": true,
+           "include_outputs_to_sub_graph": true,
+           "instances": {
+               "end_points": [
+                   "detection_boxes",
+                   "detection_scores",
+                   "num_detections"
+               ],
+               "start_points": [
+                   "Postprocessor/Shape",
+                   "Postprocessor/scale_logits",
+                   "Postprocessor/Tile",
+                   "Postprocessor/Reshape_1",
+                   "Postprocessor/Cast_1"
+               ]
+           },
+           "match_kind": "points"
+       }
+   ]
+
+The format of the file is similar to the one provided as an example in the
+:ref:`Node Name Pattern Front Phase Transformations <node_name_pattern_front_phase_transformations>` section. The difference is in
+the value of the ``match_kind`` parameter, which should be equal to the ``points`` and the format of the ``instances`` parameter,
+which should be a dictionary with two keys ``start_points`` and ``end_points``, defining start and end node names
+respectively.
+
+.. note:: 
+   The ``include_inputs_to_sub_graph`` and ``include_outputs_to_sub_graph`` parameters are redundant and should be always equal to ``true``.
+
+.. note:: 
+   This sub-graph match algorithm has a limitation that each start node must have only one input. Therefore, it is not possible to specify, for example, the :doc:`Convolution <openvino_docs_ops_convolution_Convolution_1>` node as input because it has two inputs: data tensor and tensor with weights.
+
+For other examples of transformations with points, refer to the
+:doc:`Converting TensorFlow Object Detection API Models <openvino_docs_MO_DG_prepare_model_convert_model_tf_specific_Convert_Object_Detection_API_Models>` guide.
+
+.. _generic_transformations_config_front_phase_transformations:
+
+Generic Front Phase Transformations Enabled with Transformations Configuration File
+###################################################################################
+
+This type of transformation works similarly to the :ref:`Generic Front Phase Transformations <generic_front_phase_transformations)`
+but require a JSON configuration file to enable it similarly to
+:ref:`Node Name Pattern Front Phase Transformations <node_name_pattern_front_phase_transformations>` and
+:ref:`Front Phase Transformations Using Start and End Points <start_end_points_front_phase_transformations>`.
+
+The base class for this type of transformation is
+``mo.front.common.replacement.FrontReplacementFromConfigFileGeneral``. Model Optimizer executes the 
+``transform_graph(self, graph, replacement_descriptions)`` method and provides the ``Graph`` object and dictionary with values
+parsed from the `custom_attributes` attribute of the provided JSON configuration file.
+
+The example of the configuration file for this type of transformation is ``extensions/front/tf/yolo_v1_tiny.json``:
+
+.. code-block:: json
+   
+   [
+     {
+       "id": "TFYOLO",
+       "match_kind": "general",
+       "custom_attributes": {
+         "classes": 20,
+         "coords": 4,
+         "num": 2,
+         "do_softmax": 0
+       }
+     }
+   ]
+
+and the corresponding transformation file is ``./extensions/front/YOLO.py``:
+
+.. code-block:: py
+   
+   from openvino.tools.mo.front.no_op_eraser import NoOpEraser
+   from openvino.tools.mo.front.standalone_const_eraser import StandaloneConstEraser
+   from openvino.tools.mo.ops.regionyolo import RegionYoloOp
+   from openvino.tools.mo.front.tf.replacement import FrontReplacementFromConfigFileGeneral
+   from openvino.tools.mo.graph.graph import Node, Graph
+   from openvino.tools.mo.ops.result import Result
+   from openvino.tools.mo.utils.error import Error
+   
+   
+   class YoloRegionAddon(FrontReplacementFromConfigFileGeneral):
+       """
+       Replaces all Result nodes in graph with YoloRegion->Result nodes chain.
+       YoloRegion node attributes are taken from configuration file
+       """
+       replacement_id = 'TFYOLO'  # The identifier matching the "id" attribute in the JSON file.
+   
+       def run_after(self):
+           return [NoOpEraser, StandaloneConstEraser]
+   
+       def transform_graph(self, graph: Graph, replacement_descriptions):
+           op_outputs = [n for n, d in graph.nodes(data=True) if 'op' in d and d['op'] == 'Result']
+           for op_output in op_outputs:
+               last_node = Node(graph, op_output).in_node(0)
+               op_params = dict(name=last_node.id + '/YoloRegion', axis=1, end_axis=-1)
+               op_params.update(replacement_descriptions)
+               region_layer = RegionYoloOp(graph, op_params)
+               region_layer_node = region_layer.create_node([last_node])
+               # In here, 'axis' from 'dim_attrs' can be removed to avoid permutation from axis = 1 to axis = 2.
+               region_layer_node.dim_attrs.remove('axis')
+               Result(graph).create_node([region_layer_node])
+               graph.remove_node(op_output)
+
+The configuration file has only 3 parameters: ``id`` identifier of the transformation , ``match_kind`` (which should be equal
+to ``general``) and the ``custom_attributes`` dictionary with custom attributes accessible in the transformation.
+
+.. _mo_middle_phase_transformations:
+
+============================
+Middle Phase Transformations
+============================
+
+There are two types of middle phase transformations:
+
+1. :ref:`Pattern-Defined Middle Phase Transformations <pattern_defined_middle_phase_transformations>` triggered for each sub-graph of the original graph, isomorphic to the specified pattern.
+2. :ref:`Generic Middle Phase Transformations <generic_middle_phase_transformations>`.
+
+.. _pattern_defined_middle_phase_transformations:
+
+Pattern-Defined Middle Phase Transformations
+############################################
+
+This type of transformation is implemented using ``mo.middle.replacement.MiddleReplacementPattern`` as a base class and
+works similarly to the :ref:`Pattern-Defined Middle Phase Transformations <pattern_defined_middle_phase_transformations>`
+The are two differences:
+
+1. The transformation entry function name is ``replace_pattern(self, graph, match)``.
+2. The pattern defining the graph should contain data nodes because the structure of the graph is different between front and middle phases. For more information about the graph structure changes, refer to the :ref:`Partial Inference <mo_partial_inference>`.
+
+For the example of a pattern-defined middle transformation, refer to the ``extensions/middle/L2NormToNorm.py`` file.
+
+.. _generic_middle_phase_transformations:
+
+Generic Middle Phase Transformations
+####################################
+
+Model Optimizer provides a mechanism to implement generic middle phase transformations. This type of transformation is
+implemented using ``mo.middle.replacement.MiddleReplacementPattern`` as a base class and works similarly to the
+:ref:`Generic Front Phase Transformations <generic_front_phase_transformations>`. The only difference is that the
+transformation entry function name is ``find_and_replace_pattern(self, graph: Graph)``.
+
+For the example of this transformation, refer to the ``extensions/middle/CheckForCycle.py`` file.
+
+.. _mo_back_phase_transformations:
+
+==========================
+Back Phase Transformations
+==========================
+
+There are two types of back phase transformations:
+
+1. :ref:`Pattern-Defined Back Phase Transformations <pattern_defined_back_phase_transformations>` triggered for each sub-graph of the original graph, isomorphic to the specified pattern.
+2. :ref:`Generic Back Phase Transformations <generic_back_phase_transformations>`.
+
+.. note:: 
+   The graph layout during the back phase is always NCHW. However, during the front and middle phases it could be NHWC if the original model was using it. For more details, refer to :ref:`Model Conversion Pipeline <mo_model_conversion_pipeline>`.
+
+.. _pattern_defined_back_phase_transformations:
+
+Pattern-Defined Back Phase Transformations
+##########################################
+
+This type of transformation is implemented using ``mo.back.replacement.MiddleReplacementPattern`` as a base class and
+works the same way as :ref:`Pattern-Defined Middle Phase Transformations <pattern_defined_middle_phase_transformations>`.
+
+For the example of a pattern-defined back transformation, refer to the ``extensions/back/ShufflenetReLUReorder.py`` file.
+
+.. _generic_back_phase_transformations:
+
+Generic Back Phase Transformations
+##################################
+
+Model Optimizer provides mechanism to implement generic back phase transformations. This type of transformation is
+implemented using ``mo.back.replacement.BackReplacementPattern`` as a base class and works the same way as
+:ref:`Generic Middle Phase Transformations <generic_middle_phase_transformations>`.
+
+For the example of this transformation, refer to the ``extensions/back/GatherNormalizer.py`` file.
+
+====================
+Additional Resources
+====================
+
+* :doc:`Model Optimizer Extensibility <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer>`
+* :doc:`Graph Traversal and Modification Using Ports and Connections <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Customize_Model_Optimizer_Model_Optimizer_Ports_Connections>`
+* :doc:`Model Optimizer Extensions <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Model_Optimizer_Extensions>`
+* :doc:`Extending Model Optimizer with Caffe Python Layers <openvino_docs_MO_DG_prepare_model_customize_model_optimizer_Extending_Model_Optimizer_With_Caffe_Python_Layers>`
+
+@endsphinxdirective

docs/OV_Runtime_UG/auto_device_selection.md

@@ -16,7 +16,7 @@ This article introduces how Automatic Device Selection works and how to use it f
 
 
 How AUTO Works
-####################
+##############
 
 The Automatic Device Selection mode, or AUTO for short, uses a "virtual" or a "proxy" device, 
 which does not bind to a specific type of hardware, but rather selects the processing unit for inference automatically. 
@@ -33,19 +33,19 @@ The logic behind the choice is as follows:
 4. If model’s precision is FP32 but there is no device capable of supporting it, offload the model to a device supporting FP16.
 
 
-+----------+------------------------------------------------------+-------------------------------------+
-| Device   || Supported                                           || Supported                          |
-| Priority || Device                                              || model precision                    |
-+==========+======================================================+=====================================+
-| 1        || dGPU                                                | FP32, FP16, INT8, BIN               |
-|          || (e.g. Intel® Iris® Xe MAX)                          |                                     |
-+----------+------------------------------------------------------+-------------------------------------+
-| 2        || iGPU                                                | FP32, FP16, BIN                     |
-|          || (e.g. Intel® UHD Graphics 620 (iGPU))               |                                     |
-+----------+------------------------------------------------------+-------------------------------------+
-| 3        || Intel® CPU                                          | FP32, FP16, INT8, BIN               |
-|          || (e.g. Intel® Core™ i7-1165G7)                       |                                     |
-+----------+------------------------------------------------------+-------------------------------------+
++----------+-----------------------------------------------------+------------------------------------+
+| Device   | Supported                                           | Supported                          |
+| Priority | Device                                              | model precision                    |
++==========+=====================================================+====================================+
+| 1        | dGPU                                                | FP32, FP16, INT8, BIN              |
+|          | (e.g. Intel® Iris® Xe MAX)                          |                                    |
++----------+-----------------------------------------------------+------------------------------------+
+| 2        | iGPU                                                | FP32, FP16, BIN                    |
+|          | (e.g. Intel® UHD Graphics 620 (iGPU))               |                                    |
++----------+-----------------------------------------------------+------------------------------------+
+| 3        | Intel® CPU                                          | FP32, FP16, INT8, BIN              |
+|          | (e.g. Intel® Core™ i7-1165G7)                       |                                    |
++----------+-----------------------------------------------------+------------------------------------+
 
 
 To put it simply, when loading the model to the first device on the list fails, AUTO will try to load it to the next device in line, until one of them succeeds.
@@ -63,12 +63,12 @@ Note that if you choose to exclude CPU from the priority list or disable the ini
 This mechanism can be easily observed in the :ref:`Using AUTO with Benchmark app sample <using-auto-with-openvino-samples-and-benchmark-app>` section, showing how the first-inference latency (the time it takes to compile the model and perform the first inference) is reduced when using AUTO. For example:
 
 
-.. code-block: sh
+.. code-block:: sh
 
    benchmark_app -m ../public/alexnet/FP32/alexnet.xml -d GPU -niter 128
 
 
-.. code-block: sh
+.. code-block:: sh
 
    benchmark_app -m ../public/alexnet/FP32/alexnet.xml -d AUTO -niter 128
 
@@ -80,70 +80,70 @@ This mechanism can be easily observed in the :ref:`Using AUTO with Benchmark app
 
 
 Using AUTO
-####################
+##########
 
 Following the OpenVINO™ naming convention, the Automatic Device Selection mode is assigned the label of "AUTO". It may be defined with no additional parameters, resulting in defaults being used, or configured further with the following setup options:
 
 
-+-----------------------------------------------+----------------------------------------------------------------------+
-| | Property                                    | | Values and Description                                             |
-+===============================================+======================================================================+
-| | <device candidate list>                     | | **Values**:                                                        |
-| |                                             | |       empty                                                        |
-| |                                             | |       ``AUTO``                                                     |
-| |                                             | |       ``AUTO: <device names>`` (comma-separated, no spaces)        |
-| |                                             | |                                                                    |
-| |                                             | | Lists the devices available for selection.                         |
-| |                                             | | The device sequence will be taken as priority from high to low.    |
-| |                                             | | If not specified, ``AUTO`` will be used as default,                |
-| |                                             | | and all devices will be "viewed" as candidates.                    |
-+-----------------------------------------------+----------------------------------------------------------------------+
-| | ``ov::device::priorities``                  | | **Values**:                                                        |
-| |                                             | |       ``<device names>`` (comma-separated, no spaces)              |
-| |                                             | |                                                                    |
-| |                                             | | Specifies the devices for AUTO to select.                          |
-| |                                             | | The device sequence will be taken as priority from high to low.    |
-| |                                             | | This configuration is optional.                                    |
-+-----------------------------------------------+----------------------------------------------------------------------+
-| | ``ov::hint::performance_mode``              | | **Values**:                                                        |
-| |                                             | |       ``ov::hint::PerformanceMode::LATENCY``                       |
-| |                                             | |       ``ov::hint::PerformanceMode::THROUGHPUT``                    |
-| |                                             | |       ``ov::hint::PerformanceMode::CUMULATIVE_THROUGHPUT``         |
-| |                                             | |                                                                    |
-| |                                             | | Specifies the performance option preferred by the application.     |
-+-----------------------------------------------+----------------------------------------------------------------------+
-| | ``ov::hint::model_priority``                | | **Values**:                                                        |
-| |                                             | |       ``ov::hint::Priority::HIGH``                                 |
-| |                                             | |       ``ov::hint::Priority::MEDIUM``                               |
-| |                                             | |       ``ov::hint::Priority::LOW``                                  |
-| |                                             | |                                                                    |
-| |                                             | | Indicates the priority for a model.                                |
-| |                                             | | IMPORTANT: This property is not fully supported yet.               |
-+-----------------------------------------------+----------------------------------------------------------------------+
-| | ``ov::execution_devices``                   | | Lists the runtime target devices on which the inferences are being |
-| |                                             | | executed.                                                          |
-| |                                             | | Examples of returning results could be ``(CPU)``(``CPU`` is a      |
-| |                                             | | temporary device, indicating that CPU is used for acceleration at  |
-| |                                             | | the model compilation stage), ``CPU``, ``GPU``, ``CPU GPU``,       |
-| |                                             | | ``GPU.0``, etc.                                                    |
-+-----------------------------------------------+----------------------------------------------------------------------+
-| | ``ov::intel_auto::enable_startup_fallback`` | | **Values**:                                                        |
-| |                                             | |       ``true``                                                     |
-| |                                             | |       ``false``                                                    |
-| |                                             | |                                                                    |
-| |                                             | | Enables/disables CPU as acceleration (or the helper device) in the |
-| |                                             | | beginning. The default value is ``true``, indicating that CPU is   |
-| |                                             | | used as acceleration by default.                                   |
-+-----------------------------------------------+----------------------------------------------------------------------+
-| | ``ov::intel_auto::enable_runtime_fallback`` | | **Values**:                                                        |
-| |                                             | |       ``true``                                                     |
-| |                                             | |       ``false``                                                    |
-| |                                             | |                                                                    |
-| |                                             | | Enables/disables runtime fallback to other devices and performs    |
-| |                                             | | the failed inference request again, if inference request fails on  |
-| |                                             | | the currently selected device.                                     |
-| |                                             | | The default value is ``true``.                                     |
-+-----------------------------------------------+----------------------------------------------------------------------+
++----------------------------------------------+--------------------------------------------------------------------+
+| Property                                     | Values and Description                                             |
++==============================================+====================================================================+
+| <device candidate list>                      | **Values**:                                                        |
+|                                              |       empty                                                        |
+|                                              |       ``AUTO``                                                     |
+|                                              |       ``AUTO: <device names>`` (comma-separated, no spaces)        |
+|                                              |                                                                    |
+|                                              | Lists the devices available for selection.                         |
+|                                              | The device sequence will be taken as priority from high to low.    |
+|                                              | If not specified, ``AUTO`` will be used as default,                |
+|                                              | and all devices will be "viewed" as candidates.                    |
++----------------------------------------------+--------------------------------------------------------------------+
+| ``ov::device::priorities``                   | **Values**:                                                        |
+|                                              |       ``<device names>`` (comma-separated, no spaces)              |
+|                                              |                                                                    |
+|                                              | Specifies the devices for AUTO to select.                          |
+|                                              | The device sequence will be taken as priority from high to low.    |
+|                                              | This configuration is optional.                                    |
++----------------------------------------------+--------------------------------------------------------------------+
+| ``ov::hint::performance_mode``               | **Values**:                                                        |
+|                                              |       ``ov::hint::PerformanceMode::LATENCY``                       |
+|                                              |       ``ov::hint::PerformanceMode::THROUGHPUT``                    |
+|                                              |       ``ov::hint::PerformanceMode::CUMULATIVE_THROUGHPUT``         |
+|                                              |                                                                    |
+|                                              | Specifies the performance option preferred by the application.     |
++----------------------------------------------+--------------------------------------------------------------------+
+| ``ov::hint::model_priority``                 | **Values**:                                                        |
+|                                              |       ``ov::hint::Priority::HIGH``                                 |
+|                                              |       ``ov::hint::Priority::MEDIUM``                               |
+|                                              |       ``ov::hint::Priority::LOW``                                  |
+|                                              |                                                                    |
+|                                              | Indicates the priority for a model.                                |
+|                                              | IMPORTANT: This property is not fully supported yet.               |
++----------------------------------------------+--------------------------------------------------------------------+
+| ``ov::execution_devices``                    | Lists the runtime target devices on which the inferences are being |
+|                                              | executed.                                                          |
+|                                              | Examples of returning results could be ``(CPU)``(``CPU`` is a      |
+|                                              | temporary device, indicating that CPU is used for acceleration at  |
+|                                              | the model compilation stage), ``CPU``, ``GPU``, ``CPU GPU``,       |
+|                                              | ``GPU.0``, etc.                                                    |
++----------------------------------------------+--------------------------------------------------------------------+
+| ``ov::intel_auto::enable_startup_fallback``  | **Values**:                                                        |
+|                                              |       ``true``                                                     |
+|                                              |       ``false``                                                    |
+|                                              |                                                                    |
+|                                              | Enables/disables CPU as acceleration (or the helper device) in the |
+|                                              | beginning. The default value is ``true``, indicating that CPU is   |
+|                                              | used as acceleration by default.                                   |
++----------------------------------------------+--------------------------------------------------------------------+
+| ``ov::intel_auto::enable_runtime_fallback``  | **Values**:                                                        |
+|                                              |       ``true``                                                     |
+|                                              |       ``false``                                                    |
+|                                              |                                                                    |
+|                                              | Enables/disables runtime fallback to other devices and performs    |
+|                                              | the failed inference request again, if inference request fails on  |
+|                                              | the currently selected device.                                     |
+|                                              | The default value is ``true``.                                     |
++----------------------------------------------+--------------------------------------------------------------------+
 
 Inference with AUTO is configured similarly to when device plugins are used:
 you compile the model on the plugin with configuration and execute inference.
@@ -162,18 +162,22 @@ To specify the priority of devices, enter the device names in the priority order
 
 See the following code for using AUTO and specifying devices:
 
+.. tab-set::
 
-.. tab:: C++
+    .. tab-item:: C++
+        :sync: cpp
 
-   .. doxygensnippet:: docs/snippets/AUTO0.cpp
-      :language: cpp
-      :fragment: [part0]
+        .. doxygensnippet:: docs/snippets/AUTO0.cpp
+            :language: cpp
+            :fragment: [part0]
 
-.. tab:: Python
+    .. tab-item:: Python
+        :sync: py
 
-   .. doxygensnippet:: docs/snippets/ov_auto.py
-      :language: python
-      :fragment: [part0]
+        .. doxygensnippet:: docs/snippets/ov_auto.py
+           :language: python
+           :fragment: [part0]
+    
 
 
 Note that OpenVINO Runtime lets you use "GPU" as an alias for "GPU.0" in function calls. More details on enumerating devices can be found in :doc:`Working with devices <openvino_docs_OV_UG_Working_with_devices>`.
@@ -183,22 +187,25 @@ Checking Available Devices
 
 To check what devices are present in the system, you can use Device API, as listed below. For information on how to use it, see :doc:`Query device properties and configuration <openvino_docs_OV_UG_query_api>`.
 
+.. tab-set::
 
-.. tab:: C++
+    .. tab-item:: C++
+        :sync: cpp
+        
+        .. code-block:: sh
+           
+           ov::runtime::Core::get_available_devices()
+        
+        See the Hello Query Device C++ Sample for reference.
 
-   .. code-block:: sh
-
-      ov::runtime::Core::get_available_devices()
-
-   See the Hello Query Device C++ Sample for reference.
-
-.. tab:: Python
-
-   .. code-block:: sh
-
-      openvino.runtime.Core.available_devices
-
-   See the Hello Query Device Python Sample for reference.
+    .. tab-item:: Python
+        :sync: py
+         
+        .. code-block:: sh
+        
+           openvino.runtime.Core.available_devices
+        
+        See the Hello Query Device Python Sample for reference.
 
 
 Excluding Devices from Device Candidate List
@@ -206,18 +213,21 @@ Excluding Devices from Device Candidate List
 
 You can also exclude hardware devices from AUTO, for example, to reserve CPU for other jobs. AUTO will not use the device for inference then. To do that, add a minus sign ``(-)`` before CPU in ``AUTO: <device names>``, as in the following example:
 
+.. tab-set::
 
-.. tab:: C++
+    .. tab-item:: C++
+        :sync: cpp
+        
+        .. code-block:: sh
+           
+           ov::CompiledModel compiled_model = core.compile_model(model, "AUTO:-CPU");
 
-   .. code-block:: sh
-
-      ov::CompiledModel compiled_model = core.compile_model(model, "AUTO:-CPU");
-
-.. tab:: Python
-
-   .. code-block:: sh
-
-      compiled_model = core.compile_model(model=model, device_name="AUTO:-CPU")
+    .. tab-item:: Python
+        :sync: py
+        
+        .. code-block:: sh
+           
+           compiled_model = core.compile_model(model=model, device_name="AUTO:-CPU")
 
 
 AUTO will then query all available devices and remove CPU from the candidate list.
@@ -230,6 +240,11 @@ Performance Hints for AUTO
 
 The ``ov::hint::performance_mode`` property enables you to specify a performance option for AUTO to be more efficient for particular use cases. The default hint for AUTO is ``LATENCY``.
 
+The THROUGHPUT and CUMULATIVE_THROUGHPUT hints below only improve performance in an asynchronous inference pipeline. For information on asynchronous inference, see the `Async API documentation <https://docs.openvino.ai/latest/openvino_docs_OV_UG_Infer_request.html#doxid-openvino-docs-o-v-u-g-infer-request>`__ . The following notebooks provide examples of how to set up an asynchronous pipeline:
+
+* :doc:`Image Classification Async Sample <openvino_inference_engine_samples_classification_sample_async_README>`
+* `Notebook - Asynchronous Inference with OpenVINO™ <https://docs.openvino.ai/latest/notebooks/115-async-api-with-output.html>`__
+* `Notebook - Automatic Device Selection with OpenVINO <https://docs.openvino.ai/latest/notebooks/106-auto-device-with-output.html>`__
 
 LATENCY
 --------------------
@@ -257,33 +272,65 @@ While ``LATENCY`` and ``THROUGHPUT`` can select one target device with your pref
 
 CUMULATIVE_THROUGHPUT has similar behavior as :doc:`the Multi-Device execution mode (MULTI) <openvino_docs_OV_UG_Running_on_multiple_devices>`. The only difference is that CUMULATIVE_THROUGHPUT uses the devices specified by AUTO, which means that it's not mandatory to add devices manually, while with MULTI, you need to specify the devices before inference.
 
-With the CUMULATIVE_THROUGHPUT option:
+If device priority is specified when using CUMULATIVE_THROUGHPUT, AUTO will run inference requests on devices based on the priority. In the following example, AUTO will always try to use GPU first, and then use CPU if GPU is busy:
 
-* If ``AUTO`` without any device names is specified, and the system has more than two GPU devices, AUTO will remove CPU from the device candidate list to keep GPU running at full capacity.
-* If device priority is specified, AUTO will run inference requests on devices based on the priority. In the following example, AUTO will always try to use GPU first, and then use CPU if GPU is busy:
+.. tab-set::
+   
+    .. tab-item:: C++
+        :sync: cpp
 
-  .. code-block: sh
+        .. code-block:: sh
+   
+           ov::CompiledModel compiled_model = core.compile_model(model, "AUTO:GPU,CPU", ov::hint::performance_mode(ov::hint::PerformanceMode::CUMULATIVE_THROUGHPUT));
+   
+    .. tab-item:: Python
+        :sync: py
 
-     ov::CompiledModel compiled_model = core.compile_model(model, "AUTO:GPU,CPU", ov::hint::performance_mode(ov::hint::PerformanceMode::CUMULATIVE_THROUGHPUT));
+        .. code-block:: sh
+         
+           compiled_model = core.compile_model(model, "AUTO:GPU,CPU", {"PERFORMANCE_HINT" : {"CUMULATIVE_THROUGHPUT"}})
 
 
+If AUTO is used without specifying any device names, and if there are multiple GPUs in the system, CUMULATIVE_THROUGHPUT mode will use all of the GPUs by default. If the system has more than two GPU devices, AUTO will remove CPU from the device candidate list to keep the GPUs running at full capacity. A full list of system devices and their unique identifiers can be queried using ov::Core::get_available_devices (for more information, see :doc:`Query Device Properties <openvino_docs_OV_UG_query_api>`). To explicitly specify which GPUs to use, set their priority when compiling with AUTO:
+
+.. tab-set::
+   
+    .. tab-item:: C++
+        :sync: cpp
+
+        .. code-block:: sh
+   
+           ov::CompiledModel compiled_model = core.compile_model(model, "AUTO:GPU.1,GPU.0", ov::hint::performance_mode(ov::hint::PerformanceMode::CUMULATIVE_THROUGHPUT));
+
+   
+    .. tab-item:: Python
+        :sync: py
+
+        .. code-block:: sh
+         
+           compiled_model = core.compile_model(model, "AUTO:GPU.1,GPU.0", {"PERFORMANCE_HINT" : {"CUMULATIVE_THROUGHPUT"})
+
 Code Examples
 --------------------
 
 To enable performance hints for your application, use the following code:
 
 
-.. tab:: C++
+.. tab-set::
 
-   .. doxygensnippet:: docs/snippets/AUTO3.cpp
-      :language: cpp
-      :fragment: [part3]
+    .. tab-item:: C++
+        :sync: cpp
 
-.. tab:: Python
+        .. doxygensnippet:: docs/snippets/AUTO3.cpp
+            :language: cpp
+            :fragment: [part3]
 
-   .. doxygensnippet:: docs/snippets/ov_auto.py
-      :language: python
-      :fragment: [part3]
+    .. tab-item:: Python
+        :sync: py
+
+        .. doxygensnippet:: docs/snippets/ov_auto.py
+           :language: python
+           :fragment: [part3]
 
 
 Disabling Auto-Batching for THROUGHPUT and CUMULATIVE_THROUGHPUT
@@ -297,18 +344,21 @@ Configuring Model Priority
 
 The ``ov::hint::model_priority`` property enables you to control the priorities of models in the Auto-Device plugin. A high-priority model will be loaded to a supported high-priority device. A lower-priority model will not be loaded to a device that is occupied by a higher-priority model.
 
+.. tab-set::
 
-.. tab:: C++
+    .. tab-item:: C++
+        :sync: cpp
 
-   .. doxygensnippet:: docs/snippets/AUTO4.cpp
-      :language: cpp
-      :fragment: [part4]
+        .. doxygensnippet:: docs/snippets/AUTO4.cpp
+            :language: cpp
+            :fragment: [part4]
 
-.. tab:: Python
+    .. tab-item:: Python
+        :sync: py
 
-   .. doxygensnippet:: docs/snippets/ov_auto.py
-      :language: python
-      :fragment: [part4]
+        .. doxygensnippet:: docs/snippets/ov_auto.py
+           :language: python
+           :fragment: [part4]
 
 
 Checking Target Runtime Devices
@@ -317,17 +367,22 @@ Checking Target Runtime Devices
 To query the runtime target devices on which the inferences are being executed using AUTO, you can use the ``ov::execution_devices`` property. It must be used with ``get_property``, for example:
 
 
-.. tab:: C++
+.. tab-set::
 
-   .. doxygensnippet:: docs/snippets/AUTO7.cpp
-      :language: cpp
-      :fragment: [part7]
+    .. tab-item:: C++
+        :sync: cpp
 
-.. tab:: Python
+        .. doxygensnippet:: docs/snippets/AUTO7.cpp
+            :language: cpp
+            :fragment: [part7]
+
+    .. tab-item:: Python
+        :sync: py
+
+        .. doxygensnippet:: docs/snippets/ov_auto.py
+           :language: python
+           :fragment: [part7]
 
-   .. doxygensnippet:: docs/snippets/ov_auto.py
-      :language: python
-      :fragment: [part7]
 
 
 Configuring Individual Devices and Creating the Auto-Device plugin on Top
@@ -335,17 +390,21 @@ Configuring Individual Devices and Creating the Auto-Device plugin on Top
 
 Although the methods described above are currently the preferred way to execute inference with AUTO, the following steps can be also used as an alternative. It is currently available as a legacy feature and used if AUTO is incapable of utilizing the Performance Hints option.
 
-.. tab:: C++
+.. tab-set::
 
-   .. doxygensnippet:: docs/snippets/AUTO5.cpp
-      :language: cpp
-      :fragment: [part5]
+    .. tab-item:: C++
+        :sync: cpp
 
-.. tab:: Python
+        .. doxygensnippet:: docs/snippets/AUTO5.cpp
+            :language: cpp
+            :fragment: [part5]
 
-   .. doxygensnippet:: docs/snippets/ov_auto.py
-      :language: python
-      :fragment: [part5]
+    .. tab-item:: Python
+        :sync: py
+
+        .. doxygensnippet:: docs/snippets/ov_auto.py
+           :language: python
+           :fragment: [part5]
 
 
 .. _using-auto-with-openvino-samples-and-benchmark-app:
@@ -357,13 +416,13 @@ To see how the Auto-Device plugin is used in practice and test its performance,
 
 For unlimited device choice:
 
-.. code-block:sh
+.. code-block:: sh
 
    benchmark_app –d AUTO –m <model> -i <input> -niter 1000
 
 For limited device choice:
 
-.. code-block:sh
+.. code-block:: sh
 
    benchmark_app –d AUTO:CPU,GPU,GNA –m <model> -i <input> -niter 1000
 

docs/OV_Runtime_UG/model_representation.md

@@ -1,210 +1,226 @@
 # Model Representation in OpenVINO™ Runtime {#openvino_docs_OV_UG_Model_Representation}
 
-In OpenVINO™ Runtime, a model is represented by the `ov::Model` class.
+@sphinxdirective
 
-The `ov::Model` object stores shared pointers to `ov::op::v0::Parameter`, `ov::op::v0::Result`, and `ov::op::Sink` operations, which are inputs, outputs, and sinks of the graph.
-Sinks of the graph have no consumers and are not included in the results vector. All other operations hold each other via shared pointers, in which a child operation holds its parent via a hard link. If an operation has no consumers and is neither the `Result` nor the `Sink` operation
-whose shared pointer counter is zero, the operation will be destructed and not be accessible anymore. 
+In OpenVINO™ Runtime, a model is represented by the ``:ref:`ov::Model <doxid-classov_1_1_model>```  class.
 
-Each operation in `ov::Model` has the `std::shared_ptr<ov::Node>` type.
+The ``:ref:`ov::Model <doxid-classov_1_1_model>``` object stores shared pointers to ``:ref:`ov::op::v0::Parameter <doxid-classov_1_1op_1_1v0_1_1_parameter>```, ``:ref:`ov::op::v0::Result <doxid-classov_1_1op_1_1v0_1_1_result>```, and ``:ref:`ov::op::Sink <doxid-classov_1_1op_1_1_sink>``` operations, which are inputs, outputs, and sinks of the graph. Sinks of the graph have no consumers and are not included in the results vector. All other operations hold each other via shared pointers, in which a child operation holds its parent via a hard link. If an operation has no consumers and is neither the ``Result`` nor the ``Sink`` operation whose shared pointer counter is zero, the operation will be destructed and not be accessible anymore.
 
-## How OpenVINO Runtime Works with Models
+Each operation in ``:ref:`ov::Model <doxid-classov_1_1_model>``` has the ``std::shared_ptr<:ref:`ov::Node <doxid-classov_1_1_node>`>`` type.
+
+How OpenVINO Runtime Works with Models
+#########################################
 
 OpenVINO™ Runtime enables you to use different approaches to work with model inputs/outputs:
-   - The `ov::Model::inputs()`/`ov::Model::outputs()` methods are used to get vectors of all input/output ports.
-   - For a model that has only one input or output, you can use the `ov::Model::input()` or `ov::Model::output()` methods without any arguments to get input or output port respectively.
-   - The `ov::Model::input()` and `ov::Model::output()` methods can be used with the index of inputs or outputs from the framework model to get specific ports by index.
-   - You can use the tensor name of input or output from the original framework model together with the `ov::Model::input()` or `ov::Model::output()` methods to get specific ports. It means that you do not need to have any additional mapping of names from framework to OpenVINO as it was before. OpenVINO™ Runtime allows the usage of native framework tensor names, for example:
 
-        @sphinxtabset
+* The ``:ref:`ov::Model::inputs() <doxid-classov_1_1_model_1ac28a4c66071e165c4f98906ab489e5d5>``` / ``:ref:`ov::Model::outputs() <doxid-classov_1_1_model_1af6e381008712ce22d6f4b93b87303dd8>```  methods are used to get vectors of all input/output ports.
 
-        @sphinxtab{C++}
+* For a model that has only one input or output, you can use the ``:ref:`ov::Model::input() <doxid-classov_1_1_model_1a5deeced6688795bc6cdad9ce74d972e7>``` or ``:ref:`ov::Model::output() <doxid-classov_1_1_model_1a54c76c98bc7dd8fb04e866d06134efc7>```  methods without any arguments to get input or output port respectively.
 
-        @snippet docs/snippets/ov_model_snippets.cpp all_inputs_ouputs
+* The ``:ref:`ov::Model::input() <doxid-classov_1_1_model_1a5deeced6688795bc6cdad9ce74d972e7>``` and ``:ref:`ov::Model::output() <doxid-classov_1_1_model_1a54c76c98bc7dd8fb04e866d06134efc7>```  methods can be used with the index of inputs or outputs from the framework model to get specific ports by index.
 
-        @endsphinxtab
+* You can use the tensor name of input or output from the original framework model together with the ``:ref:`ov::Model::input() <doxid-classov_1_1_model_1a5deeced6688795bc6cdad9ce74d972e7>``` or ``:ref:`ov::Model::output() <doxid-classov_1_1_model_1a54c76c98bc7dd8fb04e866d06134efc7>``` methods to get specific ports. It means that you do not need to have any additional mapping of names from framework to OpenVINO as it was before. OpenVINO Runtime allows the usage of native framework tensor names, for example:
 
-        @sphinxtab{Python}
+.. tab-set::
 
-        @snippet docs/snippets/ov_model_snippets.py all_inputs_ouputs
+   .. tab-item:: C++
+      :sync: cpp
 
-        @endsphinxtab
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.cpp
+         :language: cpp
+         :fragment: [all_inputs_ouputs]
 
-        @endsphinxtabset
+   .. tab-item:: Python
+      :sync: python
 
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.py
+         :language: cpp
+         :fragment: [all_inputs_ouputs]
 
-@sphinxdirective 
 
 For details on how to build a model in OpenVINO™ Runtime, see the :ref:`Build a Model in OpenVINO Runtime <ov_ug_build_model>`  section.
 
-@endsphinxdirective 
+OpenVINO™ Runtime model representation uses special classes to work with model data types and shapes. The ``:ref:`ov::element::Type <doxid-classov_1_1element_1_1_type>```  is used for data types. See the section below for representation of shapes.
 
-OpenVINO™ Runtime model representation uses special classes to work with model data types and shapes. The `ov::element::Type` is used for data types. See the section below for representation of shapes.
-
-## Representation of Shapes
+Representation of Shapes
+###########################
 
 OpenVINO™ Runtime provides two types for shape representation: 
 
-* `ov::Shape` - Represents static (fully defined) shapes.
+* ``:ref:`ov::Shape <doxid-classov_1_1_shape>``` - Represents static (fully defined) shapes.
 
-* `ov::PartialShape` - Represents dynamic shapes. This means that the rank or some of dimensions are dynamic (dimension defines an interval or undefined). 
+* ``:ref:`ov::PartialShape <doxid-classov_1_1_partial_shape>``` - Represents dynamic shapes. This means that the rank or some of dimensions are dynamic (dimension defines an interval or undefined). 
 
-`ov::PartialShape` can be converted to `ov::Shape` by using the `get_shape()` method if all dimensions are static; otherwise, the conversion will throw an exception. For example: 
+``:ref:`ov::PartialShape <doxid-classov_1_1_partial_shape>``` can be converted to ``:ref:`ov::Shape <doxid-classov_1_1_shape>``` by using the ``get_shape()`` method if all dimensions are static; otherwise, the conversion will throw an exception. For example: 
 
-@sphinxtabset
+.. tab-set::
 
-@sphinxtab{C++}
+   .. tab-item:: C++
+      :sync: cpp
 
-@snippet docs/snippets/ov_model_snippets.cpp ov:partial_shape
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.cpp
+         :language: cpp
+         :fragment: [ov:partial_shape]
 
-@endsphinxtab
+   .. tab-item:: Python
+      :sync: python
 
-@sphinxtab{Python}
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.py
+         :language: cpp
+         :fragment: [ov:partial_shape]
 
-@snippet docs/snippets/ov_model_snippets.py ov:partial_shape
 
-@endsphinxtab
+However, in most cases, before getting static shape using the ``get_shape()`` method, you need to check if that shape is static.
 
-@endsphinxtabset
+Representation of Operations
+################################
 
-However, in most cases, before getting static shape using the `get_shape()` method, you need to check if that shape is static.
+The ``ov::Op`` class represents any abstract operation in the model representation. Use this class to create :doc:`custom operations <openvino_docs_Extensibility_UG_add_openvino_ops>`.
 
-## Representation of Operations
+Representation of Operation Sets
+######################################
 
-The `ov::Op` class represents any abstract operation in the model representation. Use this class to create [custom operations](../Extensibility_UG/add_openvino_ops.md).
-
-## Representation of Operation Sets
-
-An operation set (opset) is a collection of operations that can be used to construct a model. The `ov::OpSet` class provides the functionality to work with operation sets.
-For each operation set, OpenVINO™ Runtime provides a separate namespace, for example `opset8`.
+An operation set (opset) is a collection of operations that can be used to construct a model. The ``:ref:`ov::OpSet <doxid-classov_1_1_op_set>``` class provides the functionality to work with operation sets.
+For each operation set, OpenVINO™ Runtime provides a separate namespace, for example ``opset8``.
 
 Each OpenVINO™ Release introduces new operations and adds them to new operation sets, within which the new operations would change the behavior of previous operations. Using operation sets helps you avoid changing your application when new operations are introduced.
-For a complete list of operation sets supported in OpenVINO™ toolkit, see the [Available Operations Sets](../ops/opset.md).
-To add the support for custom operations, see [OpenVINO Extensibility Mechanism](../Extensibility_UG/Intro.md).
-
-@sphinxdirective 
+For a complete list of operation sets supported in OpenVINO™ toolkit, see the :doc:`Available Operations Sets <openvino_docs_ops_opset>`.
+To add the support for custom operations, see :doc:`OpenVINO Extensibility Mechanism <openvino_docs_Extensibility_UG_Intro>`.
 
 .. _ov_ug_build_model:
 
-@endsphinxdirective
-
-## Building a Model in OpenVINO™ Runtime
+Building a Model in OpenVINO™ Runtime
+###########################################
 
 You can create a model from source. This section illustrates how to construct a model composed of operations from an available operation set.
 
-Operation set `opsetX` integrates a list of pre-compiled operations that work for this purpose. In other words, `opsetX` defines a set of operations for building a graph.
+Operation set ``opsetX`` integrates a list of pre-compiled operations that work for this purpose. In other words, ``opsetX`` defines a set of operations for building a graph.
 
-To build an `ov::Model` instance from `opset8` operations, include the following files:
+To build an ``:ref:`ov::Model <doxid-classov_1_1_model>``` instance from ``opset8`` operations, include the following files:
 
-@sphinxtabset
+.. tab-set::
 
-@sphinxtab{C++}
+   .. tab-item:: C++
+      :sync: cpp
 
-@snippet docs/snippets/ov_model_snippets.cpp ov:include
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.cpp
+         :language: cpp
+         :fragment: [ov:include]
 
-@endsphinxtab
+   .. tab-item:: Python
+      :sync: python
 
-@sphinxtab{Python}
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.py
+         :language: cpp
+         :fragment: [import]
 
-@snippet docs/snippets/ov_model_snippets.py import
-
-@endsphinxtab
-
-@endsphinxtabset
 
 The following code demonstrates how to create a simple model:
 
-@sphinxtabset
+.. tab-set::
 
-@sphinxtab{C++}
+   .. tab-item:: C++
+      :sync: cpp
 
-@snippet docs/snippets/ov_model_snippets.cpp ov:create_simple_model
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.cpp
+         :language: cpp
+         :fragment: [ov:create_simple_model]
 
-@endsphinxtab
+   .. tab-item:: Python
+      :sync: python
 
-@sphinxtab{Python}
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.py
+         :language: cpp
+         :fragment: [ov:create_simple_model]
 
-@snippet docs/snippets/ov_model_snippets.py ov:create_simple_model
-
-@endsphinxtab
-
-@endsphinxtabset
 
 The following code creates a model with several outputs:
 
-@sphinxtabset
+.. tab-set::
 
-@sphinxtab{C++}
+   .. tab-item:: C++
+      :sync: cpp
 
-@snippet docs/snippets/ov_model_snippets.cpp ov:create_advanced_model
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.cpp
+         :language: cpp
+         :fragment: [ov:create_advanced_model]
 
-@endsphinxtab
+   .. tab-item:: Python
+      :sync: python
 
-@sphinxtab{Python}
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.py
+         :language: cpp
+         :fragment: [ov:create_advanced_model]
 
-@snippet docs/snippets/ov_model_snippets.py ov:create_advanced_model
 
-@endsphinxtab
-
-@endsphinxtabset
-
-## Model Debugging Capabilities
+Model Debugging Capabilities
+###########################################
 
 OpenVINO™ provides several debug capabilities:
-   - To receive additional messages about applied model modifications, rebuild the OpenVINO™ Runtime library with the `-DENABLE_OPENVINO_DEBUG=ON` option.
-   - Model can be visualized to image from the xDot format:
 
-        @sphinxtabset
+* To receive additional messages about applied model modifications, rebuild the OpenVINO™ Runtime library with the ``-DENABLE_OPENVINO_DEBUG=ON`` option.
 
-        @sphinxtab{C++}
+* Model can be visualized to image from the xDot format:
 
-        @snippet docs/snippets/ov_model_snippets.cpp ov:visualize
+.. tab-set::
 
-        @endsphinxtab
+   .. tab-item:: C++
+      :sync: cpp
 
-        @sphinxtab{Python}
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.cpp
+         :language: cpp
+         :fragment: [ov:visualize]
+      
+   .. tab-item:: Python
+      :sync: python
 
-        @snippet docs/snippets/ov_model_snippets.py ov:visualize
-
-        @endsphinxtab
-
-        @endsphinxtabset
-
-    
-        `ov::pass::VisualizeTree` can be parametrized via environment variables:
-
-        OV_VISUALIZE_TREE_OUTPUT_SHAPES=1       - visualize shapes
-
-        OV_VISUALIZE_TREE_OUTPUT_TYPES=1        - visualize types
-
-        OV_VISUALIZE_TREE_MIN_MAX_DENORMAL=1    - pretty denormal values
-
-        OV_VISUALIZE_TREE_RUNTIME_INFO=1        - print runtime information
-
-        OV_VISUALIZE_TREE_IO=1                  - print I/O ports
-
-        OV_VISUALIZE_TREE_MEMBERS_NAME=1        - print member names
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.py
+         :language: cpp
+         :fragment: [ov:visualize]
 
 
+.. code-block:: sh
+   
+   `ov::pass::VisualizeTree` can be parametrized via environment variables:
 
-   - Also model can be serialized to IR:
+   OV_VISUALIZE_TREE_OUTPUT_SHAPES=1       - visualize shapes
 
-     @sphinxtabset
+   OV_VISUALIZE_TREE_OUTPUT_TYPES=1        - visualize types
 
-     @sphinxtab{C++}
+   OV_VISUALIZE_TREE_MIN_MAX_DENORMAL=1    - pretty denormal values
 
-     @snippet docs/snippets/ov_model_snippets.cpp ov:serialize
+   OV_VISUALIZE_TREE_RUNTIME_INFO=1        - print runtime information
 
-     @endsphinxtab
+   OV_VISUALIZE_TREE_IO=1                  - print I/O ports
 
-     @sphinxtab{Python}
+   OV_VISUALIZE_TREE_MEMBERS_NAME=1        - print member names
 
-     @snippet docs/snippets/ov_model_snippets.py ov:serialize
 
-     @endsphinxtab
+* Also model can be serialized to IR:
 
-## Additional Resources
+.. tab-set::
+
+   .. tab-item:: C++
+      :sync: cpp
+
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.cpp
+         :language: cpp
+         :fragment: [ov:serialize]
+
+   .. tab-item:: Python
+      :sync: python
+
+      .. doxygensnippet:: docs/snippets/ov_model_snippets.py
+         :language: cpp
+         :fragment: [ov:serialize]
+
+
+Additional Resources
+########################
+
+* :doc:`Available Operation Sets <openvino_docs_ops_opset>`.
+* :doc:`OpenVINO™ Runtime Extensibility Developer Guide <openvino_docs_Extensibility_UG_Intro>`.
+* :doc:`Transformations Developer Guide <openvino_docs_transformations>`.
+
+@endsphinxdirective
 
-* [Available Operation Sets](../ops/opset.md)
-* [OpenVINO™ Runtime Extensibility Developer Guide](../Extensibility_UG/Intro.md)
-* [Transformations Developer Guide](../Extensibility_UG/ov_transformations.md).

docs/OV_Runtime_UG/ov_dynamic_shapes.md

@@ -39,23 +39,55 @@ The decision about using dynamic shapes should be based on proper benchmarking o
 Unlike statically shaped models, dynamically shaped ones require different inference time, depending on input data shape or input tensor content.
 Furthermore, using the dynamic shapes can bring more overheads in memory and running time of each inference call depending on hardware plugin and model used.
 
-Handling Dynamic Shapes Natively
-################################
+Handling Dynamic Shapes
+#######################
 
-This section describes how to handle dynamically shaped models natively with OpenVINO Runtime API version 2022.1 and higher.
-There are three main parts in the flow that differ from static shapes:
+This section describes how to handle dynamically shaped models with OpenVINO Runtime API version 2022.1 and higher. When using dynamic shapes, there are three main differences in the workflow than with static shapes:
 
-* Configure the model.
-* Prepare data for inference.
-* Read resulting data after inference.
+* Configuring the model
+* Preparing and inferencing dynamic data
+* Dynamic shapes in outputs
 
 Configuring the Model
 +++++++++++++++++++++
 
-To avoid the methods mentioned in the previous section, there is a way to specify one or multiple dimensions to be dynamic, directly in the model inputs.
-This is achieved with the same reshape method that is used for alternating static shape of inputs.
-Dynamic dimensions are specified as ``-1`` or the ``ov::Dimension()`` instead of a positive number used for static dimensions:
+Model input dimensions can be specified as dynamic using the model.reshape method. To set a dynamic dimension, use ``-1``, ``ov::Dimension()`` (C++), or ``ov.Dimension()`` (Python) as the value for that dimension.
 
+.. note::
+   
+   Some models may already have dynamic shapes out of the box and do not require additional configuration. This can either be because it was generated with dynamic shapes from the source framework, or because it was converted with Model Optimizer to use dynamic shapes. For more information, see the Dynamic Dimensions “Out of the Box” section.
+
+The examples below show how to set dynamic dimensions with a model that has a static ``[1, 3, 224, 224]`` input shape (such as `mobilenet-v2 <https://docs.openvino.ai/latest/omz_models_model_mobilenet_v2.html>`__). The first example shows how to change the first dimension (batch size) to be dynamic. In the second example, the third and fourth dimensions (height and width) are set as dynamic.
+
+.. tab-set::
+
+    .. tab-item:: C++
+       :sync: cpp
+
+       .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.cpp
+          :language: cpp
+          :fragment: [ov_dynamic_shapes:reshape_undefined]
+
+    .. tab-item:: Python
+       :sync: py
+
+       .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.py
+          :language: cpp
+          :fragment: [reshape_undefined]
+       
+       With Python, you may also pass all dimensions as a string and use ``?`` for the dynamic dimensions (e.g. ``model.reshape(“1, 3, ?, ?”)``).
+
+    .. tab-item:: C
+       :sync: c
+
+       .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.c
+          :language: cpp
+          :fragment: [ov_dynamic_shapes:reshape_undefined]
+
+
+
+
+The examples above assume that the model has a single input layer. To change models with multiple input layers (such as NLP models), iterate over all the input layers, update the shape per layer, and apply the model.reshape method. For example, the following code sets the second dimension as dynamic in every input layer:
 
 .. tab-set::
 
@@ -64,48 +96,24 @@ Dynamic dimensions are specified as ``-1`` or the ``ov::Dimension()`` instead of
 
         .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.cpp
             :language: cpp
-            :fragment: ov_dynamic_shapes:reshape_undefined
+            :fragment: ov_dynamic_shapes:reshape_multiple_inputs
 
     .. tab-item:: Python
         :sync: py
 
         .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.py
            :language: python
-           :fragment: reshape_undefined
-
-    .. tab-item:: C
-        :sync: c
-
-        .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.c
-           :language: cpp
-           :fragment: ov_dynamic_shapes:reshape_undefined
+           :fragment: reshape_multiple_inputs
 
 
-To simplify the code, the examples assume that the model has a single input and single output.
-However, there are no limitations on the number of inputs and outputs to apply dynamic shapes.
+For more examples of how to change multiple input layers, see :doc:`Changing Input Shapes <openvino_docs_OV_UG_ShapeInference>`.
 
 Undefined Dimensions "Out Of the Box"
-+++++++++++++++++++++++++++++++++++++
+-------------------------------------
 
-Dynamic dimensions may appear in the input model without calling the ``reshape`` method.
-Many DL frameworks support undefined dimensions.
-If such a model is converted with Model Optimizer or read directly by the ``Core::read_model``, undefined dimensions are preserved.
-Such dimensions are automatically treated as dynamic ones.
-Therefore, there is no need to call the ``reshape`` method, if undefined dimensions are already configured in the original or the IR model.
-
-If the input model has undefined dimensions that will not change during inference. It is recommended to set them to static values, using the same ``reshape`` method of the model.
-From the API perspective, any combination of dynamic and static dimensions can be configured.
-
-Model Optimizer provides identical capability to reshape the model during the conversion, including specifying dynamic dimensions.
-Use this capability to save time on calling ``reshape`` method in the end application.
-To get information about setting input shapes using Model Optimizer, refer to :doc:`Setting Input Shapes <openvino_docs_MO_DG_prepare_model_convert_model_Converting_Model>`.
-
-Dimension Bounds
-++++++++++++++++++++
-
-Apart from a dynamic dimension, the lower and/or upper bounds can also be specified. They define a range of allowed values for the dimension.
-The bounds are coded as arguments for the ``ov::Dimension``:
+Many DL frameworks support generating models with dynamic (or undefined) dimensions. If such a model is converted with Model Optimizer or read directly by ``Core::read_model``, its dynamic dimensions are preserved. These models do not need any additional configuration to use them with dynamic shapes.
 
+To check if a model already has dynamic dimensions, first load it with the ``read_model()`` method, then check the ``partial_shape`` property of each layer. If the model has any dynamic dimensions, they will be reported as ``?``. For example, the following code will print the name and dimensions of each input layer:
 
 .. tab-set::
 
@@ -114,17 +122,55 @@ The bounds are coded as arguments for the ``ov::Dimension``:
 
         .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.cpp
             :language: cpp
-            :fragment: ov_dynamic_shapes:reshape_bounds
+            :fragment: ov_dynamic_shapes:check_inputs
 
     .. tab-item:: Python
         :sync: py
 
+        .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.py
+           :language: python
+           :fragment: check_inputs
+
+
+If the input model already has dynamic dimensions, that will not change during inference. If the inputs will not be used dynamically, it is recommended to set them to static values using the ``reshape`` method to save application memory and potentially improve inference speed. The OpenVINO API supports any combination of static and dynamic dimensions.
+
+Static and dynamic dimensions can also be set when converting the model with Model Optimizer. It has identical capabilities to the ``reshape`` method, so you can save time by converting the model with dynamic shapes beforehand rather than in the application code. To get information about setting input shapes using Model Optimizer,  refer to :doc:`Setting Input Shapes <openvino_docs_MO_DG_prepare_model_convert_model_Converting_Model>`.
+
+Dimension Bounds
+----------------
+
+The lower and/or upper bounds of a dynamic dimension can also be specified. They define a range of allowed values for the dimension. Dimension bounds can be set by passing the lower and upper bounds into the ``reshape`` method using the options shown below. 
+
+.. tab-set::
+    
+    .. tab-item:: C++
+        :sync: cpp
+        
+        The dimension bounds can be coded as arguments for ``ov::Dimension``, as shown in these examples:
+        
+        .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.cpp
+            :language: cpp
+            :fragment: ov_dynamic_shapes:reshape_bounds
+    
+    .. tab-item:: Python
+        :sync: py
+        
+        Each of these options are equivalent:
+        
+        - Pass the lower and upper bounds directly into the ``reshape`` method, e.g. ``model.reshape([1, 10), (8,512)])``
+        - Pass the lower and upper bounds using ov.Dimension, e.g. ``model.reshape([ov.Dimension(1, 10), (8, 512)])``
+        - Pass the dimension ranges as strings, e.g. ``model.reshape(“1..10, 8..512”)``
+        
+        The examples below show how to set dynamic dimension bounds for a mobilenet-v2 model with a default static shape of ``[1,3,224,224]``.
+
         .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.py
            :language: python
            :fragment: reshape_bounds
-
+    
     .. tab-item:: C
         :sync: c
+        
+        The dimension bounds can be coded as arguments for `ov_dimension <https://docs.openvino.ai/latest/structov_dimension.html#doxid-structov-dimension>`__, as shown in these examples:
 
         .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.c
            :language: cpp
@@ -143,13 +189,12 @@ Depending on the plugin, specifying the upper bounds can be required. For inform
 
 If the lower and upper bounds for a dimension are known, it is recommended to specify them, even if a plugin can execute a model without the bounds.
 
-Setting Input Tensors
-+++++++++++++++++++++
+Preparing and Inferencing Dynamic Data
+++++++++++++++++++++++++++++++++++++++
 
-Preparing a model with the ``reshape`` method is the first step.
-The second step is passing a tensor with an appropriate shape to infer request.
-This is similar to the :doc:`regular steps <openvino_docs_OV_UG_Integrate_OV_with_your_application>`. However, tensors can now be passed with different shapes for the same executable model and even for the same inference request:
+After configuring a model with the ``reshape`` method, the next steps are to create tensors with the appropriate data shape and pass them to the model as an inference request. This is similar to the regular steps described in :doc:`Integrate OpenVINO™ with Your Application <openvino_docs_OV_UG_Integrate_OV_with_your_application>`. However, tensors can now be passed into the model with different shapes.
 
+The sample below shows how a model can accept different input shapes. In the first case, the model runs inference on a 1x128 input shape and returns a result. In the second case, a 1x200 input shape is used, which the model can still handle because it is dynamically shaped.
 
 .. tab-set::
 
@@ -166,7 +211,7 @@ This is similar to the :doc:`regular steps <openvino_docs_OV_UG_Integrate_OV_wit
         .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.py
            :language: python
            :fragment: set_input_tensor
-
+    
     .. tab-item:: C
         :sync: c
 
@@ -175,49 +220,15 @@ This is similar to the :doc:`regular steps <openvino_docs_OV_UG_Integrate_OV_wit
            :fragment: ov_dynamic_shapes:set_input_tensor
 
 
-In the example above, the ``set_input_tensor`` is used to specify input tensors.
-The real dimension of the tensor is always static, because it is a particular tensor and it does not have any dimension variations in contrast to model inputs.
-
-Similar to static shapes, ``get_input_tensor`` can be used instead of ``set_input_tensor``.
-In contrast to static input shapes, when using ``get_input_tensor`` for dynamic inputs, the ``set_shape`` method for the returned tensor should be called to define the shape and allocate memory.
-Without doing so, the tensor returned by ``get_input_tensor`` is an empty tensor. The shape of the tensor is not initialized and memory is not allocated, because infer request does not have information about the real shape that will be provided.
-Setting shape for an input tensor is required when the corresponding input has at least one dynamic dimension, regardless of the bounds.
-Contrary to previous example, the following one shows the same sequence of two infer requests, using ``get_input_tensor`` instead of ``set_input_tensor``:
-
-
-.. tab-set::
-
-    .. tab-item:: C++
-        :sync: cpp
-
-        .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.cpp
-            :language: cpp
-            :fragment: ov_dynamic_shapes:get_input_tensor
-
-    .. tab-item:: Python
-        :sync: py
-
-        .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.py
-           :language: python
-           :fragment: get_input_tensor
-
-    .. tab-item:: C
-        :sync: c
-
-        .. doxygensnippet:: docs/snippets/ov_dynamic_shapes.c
-           :language: cpp
-           :fragment: ov_dynamic_shapes:get_input_tensor
+For more information on how to apply input data to a model and run inference, see :doc:`OpenVINO™ Inference Request <openvino_docs_OV_UG_Infer_request>`.
 
 
 Dynamic Shapes in Outputs
 +++++++++++++++++++++++++
 
-Examples above are valid approaches when dynamic dimensions in output may be implied by propagation of dynamic dimension from the inputs.
-For example, batch dimension in an input shape is usually propagated through the whole model and appears in the output shape.
-It also applies to other dimensions, like sequence length for NLP models or spatial dimensions for segmentation models, that are propagated through the entire network.
+When using dynamic dimensions in the input of a model, one or more output dimensions may also be dynamic depending on how the dynamic inputs are propagated through the model. For example, the batch dimension in an input shape is usually propagated through the whole model and appears in the output shape. It also applies to other dimensions, like sequence length for NLP models or spatial dimensions for segmentation models, that are propagated through the entire network.
 
-Whether the output has dynamic dimensions or not can be verified by querying the output partial shape after the model is read or reshaped.
-The same applies to inputs. For example:
+To determine if the output has dynamic dimensions, the ``partial_shape`` property of the model’s output layers can be queried after the model has been read or reshaped. The same property can be queried for model inputs. For example:
 
 
 .. tab-set::
@@ -244,9 +255,9 @@ The same applies to inputs. For example:
            :fragment: ov_dynamic_shapes:print_dynamic
 
 
-When there are dynamic dimensions in corresponding inputs or outputs, the ``?`` or ranges like ``1..10`` appear.
+If the output has any dynamic dimensions, they will be reported as ``?`` or as a range (e.g.``1..10``).
 
-It can also be verified in a more programmatic way:
+Output layers can also be checked for dynamic dimensions using the ``partial_shape.is_dynamic()`` property. This can be used on an entire output layer, or on an individual dimension, as shown in these examples:
 
 
 .. tab-set::
@@ -273,9 +284,9 @@ It can also be verified in a more programmatic way:
            :fragment: ov_dynamic_shapes:detect_dynamic
 
 
-If at least one dynamic dimension exists in an output of a model, a shape of the corresponding output tensor will be set as the result of inference call.
-Before the first inference, memory for such a tensor is not allocated and has the ``[0]`` shape.
-If the ``set_output_tensor`` method is called with a pre-allocated tensor, the inference will call the ``set_shape`` internally, and the initial shape is replaced by the calculated shape.
-Therefore, setting a shape for output tensors in this case is useful only when pre-allocating enough memory for output tensor. Normally, the ``set_shape`` method of a ``Tensor`` re-allocates memory only if a new shape requires more storage.
+If at least one dynamic dimension exists in the output layer of a model, the actual shape of the output tensor will be determined during inference. Before the first inference, the output tensor’s memory is not allocated and has a shape of ``[0]``.
+
+To pre-allocate space in memory for the output tensor, use the ``set_output_tensor`` method with the expected shape of the output. This will call the ``set_shape`` method internally, which will cause the initial shape to be replaced by the calculated shape.
+
+@endsphinxdirective
 
-@endsphinxdirective

docs/OV_Runtime_UG/performance_hints.md

@@ -13,14 +13,13 @@ The hints, in contrast, respect the actual model, so the parameters for optimal
 Performance Hints: Latency and Throughput
 #########################################
 
-As discussed in the :doc:`Optimization Guide <openvino_docs_deployment_optimization_guide_dldt_optimization_guide>` there are a few different metrics associated with inference speed.
-Throughput and latency are some of the most widely used metrics that measure the overall performance of an application.
+As discussed in the :doc:`Optimization Guide <openvino_docs_deployment_optimization_guide_dldt_optimization_guide>` there are a few different metrics associated with inference speed. Throughput and latency are some of the most widely used metrics that measure the overall performance of an application.
 
-Therefore, in order to ease the configuration of the device, OpenVINO offers two dedicated hints, namely `ov::hint::PerformanceMode::THROUGHPUT <enumov_1_1hint_1_1PerformanceMode.html#doxid-group-ov-runtime-cpp-prop-api-1gga032aa530efa40760b79af14913d48d73a50f9b1f40c078d242af7ec323ace44b3>`__ and `ov::hint::PerformanceMode::LATENCY <enumov_1_1hint_1_1PerformanceMode.html#doxid-group-ov-runtime-cpp-prop-api-1gga032aa530efa40760b79af14913d48d73a501069dd75f76384ba18f133fdce99c2>`__.
+Therefore, in order to ease the configuration of the device, OpenVINO offers two dedicated hints, namely ``ov::hint::PerformanceMode::THROUGHPUT`` and ``ov::hint::PerformanceMode::LATENCY``. A special ``ov::hint::PerformanceMode::UNDEFINED`` hint acts the same as specifying no hint. 
 
 For more information on conducting performance measurements with the ``benchmark_app``, refer to the last section in this document.
 
-Keep in mind that a typical model may take significantly more time to load with the ``ov::hint::PerformanceMode::THROUGHPUT`` and consume much more memory, compared to the ``ov::hint::PerformanceMode::LATENCY``.
+Keep in mind that a typical model may take significantly more time to load with the ``ov::hint::PerformanceMode::THROUGHPUT`` and consume much more memory, compared to the ``ov::hint::PerformanceMode::LATENCY``. Also, the `THROUGHPUT` and `LATENCY` hints only improve performance in an asynchronous inference pipeline. For information on asynchronous inference, see the :ref:`Prefer Async API <prefer-async-api>` section of this document.
 
 Performance Hints: How It Works
 ###############################
@@ -32,7 +31,7 @@ Additionally, the optimal batch size is selected for the GPU and the :doc:`autom
 The resulting (device-specific) settings can be queried back from the instance of the ``ov:Compiled_Model``.
 Be aware that the ``benchmark_app`` outputs the actual settings for the ``THROUGHPUT`` hint. See the example of the output below:
 
-   .. code-block:: sh
+.. code-block:: sh
 
    $benchmark_app -hint tput -d CPU -m 'path to your favorite model'
    ...
@@ -108,11 +107,18 @@ While an application is free to create more requests if needed (for example to s
 Keep in mind that ``ov::hint::PerformanceMode::LATENCY`` does not necessarily imply using single inference request. For example, multi-socket CPUs can deliver as many requests at the same minimal latency as the number of NUMA nodes in the system.
 To make your application fully scalable, make sure to query the ``ov::optimal_number_of_infer_requests`` directly.
 
+.. _prefer-async-api:
+
 Prefer Async API
 ################
 
-The API of the inference requests offers Sync and Async execution. The ``ov::InferRequest::infer()`` is inherently synchronous and simple to operate (as it serializes the execution flow in the current application thread). The Async "splits" the ``infer()`` into ``ov::InferRequest::start_async()`` and ``ov::InferRequest::wait()`` (or callbacks). For more information, refer to the doc:`API examples <openvino_docs_OV_UG_Infer_request>`.
-Although the Synchronous API can be somewhat easier to start with, it is recommended to use the Asynchronous (callbacks-based) API in the production code. It is the most general and scalable way to implement the flow control for any possible number of requests (and thus both latency and throughput scenarios).
+The API of the inference requests offers Sync and Async execution. The ``ov::InferRequest::infer()`` is inherently synchronous and simple to operate (as it serializes the execution flow in the current application thread). The Async "splits" the ``infer()`` into ``ov::InferRequest::start_async()`` and ``ov::InferRequest::wait()`` (or callbacks). For more information on synchronous and asynchronous modes, refer to the :doc:`OpenVINO Inference Request documentation <openvino_docs_OV_UG_Infer_request>`.
+
+Although the synchronous API can be easier to start with, it is recommended to use the asynchronous (callbacks-based) API in production code. It is the most general and scalable way to implement the flow control for any possible number of requests. The ``THROUGHPUT`` and ``LATENCY`` performance hints automatically configure the Asynchronous pipeline to use the optimal number of processing streams and inference requests. 
+
+.. note::
+   
+   **Important:** Performance Hints only work when asynchronous execution mode is used. They do not affect the performance of a synchronous pipeline.
 
 Combining the Hints and Individual Low-Level Settings
 #####################################################

docs/OV_Runtime_UG/precision_control.md

@@ -0,0 +1,45 @@
+# Precision Control {#openvino_docs_OV_UG_Precision_Control}
+
+@sphinxdirective
+
+The choice of data types is essential to the inference runtime, which can have a huge impact on the performance and other metrics. Usually 2 types of precision are identified:
+
+1. Model storage precision (IR precision),
+2. Model inference precision.
+
+Previously, these 2 precisions were interrelated, and model storage precision could affect the inference precision in some devices (e.g. GPU did ``f16`` inference only for ``f16`` IRs).
+
+With the ``2023.0`` release this behavior has been changed and the inference precision no longer depends on the precision of IR. Now users have several knobs to find the balance between model performance and accuracy.
+
+Essentially, the IR precision becomes a way of compressing the model by reducing the precision of the weights, and it does not affect how the devices execute the model. This change clears up a lot of confusion where, for example, you couldn't execute a high-performance model on the GPU by default, and the behavior between devicess was different. 
+
+This guide will focus on how to control inference precision. And using lower precision is important for performance because compute bandwidth tends to be higher for smaller data types, and hardware often has special blocks for efficient multiply-accumulate operations with smaller data types only (e.g. Intel Xᵉ Matrix Extensions (XMX) on GPU and Intel Advanced Matrix Extensions (AMX) on CPU do not support ``f32``). Also, I/O operations requires less memory due to the smaller tensor byte size. This guide will focus on how to control inference precision.
+
+
+Execution Mode
+##############
+
+``ov::hint::execution_mode`` is a high-level hint to control whether the user wants to keep the best accuracy (**ACCURACY mode**) or if the device can do some optimizations that may lower the accuracy for performance reasons (**PERFORMANCE mode**)
+
+* In **ACCURACY mode**, the device cannot convert floating point tensors to a smaller floating point type, so devices try to keep the accuracy metrics as close as possible to the original values ​​obtained after training relative to the device's real capabilities. This means that most devices will infer with ``f32`` precision if your device supports it.
+* In **PERFORMANCE mode**, the device can convert to smaller data types and apply other optimizations that may have some impact on accuracy rates, although we still try to minimize accuracy loss and may use mixed precision execution in some cases.
+
+If the model has been quantized using :doc:`OpenVINO optimization tools <ptq_introduction>` or any other method, the quantized operators will be executed with the target integer precision if the device has hardware acceleration for that type. For example, quantized ``int8`` primitives are executed with ``int8`` precision for both **ACCURACY** and **PERFORMANCE modes** if the device provides higher compute bandwidth for 8-bit data types compared to any available floating-point type. On the other hand, devices without hardware acceleration for the ``int8`` data type can keep such operators in floating point precision, and the exact floating point type will be affected by ``execution_mode`` and ``inference_precision`` properties.
+
+Inference Precision
+###################
+
+``ov::hint::inference_precision`` precision is a lower-level property that allows you to specify the exact precision the user wants, but is less portable. For example, CPU supports ``f32`` inference precision and ``bf16`` on some platforms, GPU supports ``f32`` and ``f16`` while GNA supports ``i8`` and ``i16``, so if a user wants to an application that uses multiple devices, they have to handle all these combinations manually or let OV do it automatically by using higher level ``execution_mode`` property. Another thing is that ``inference_precision`` is also a hint, so the value provided is not guaranteed to be used by Runtime (mainly in cases where the current device does not have the required hardware capabilities).
+
+.. note::
+
+   All devices (except GNA) only support floating-point data types (``f32``, ``f16``, ``bf16``) as a value for ``inference_precision`` attribute, because quantization cannot be done in Runtime. The GNA plugin has the ability to perform model quantization on ``core.compile_model()`` call, so it supports integer data types in addition to ``f32``.
+
+
+Additional Resources
+####################
+
+* :doc:`Supported Devices <openvino_docs_OV_UG_Working_with_devices>`
+
+@endsphinxdirective
+

docs/OV_Runtime_UG/supported_plugins/CPU.md

@@ -6,7 +6,7 @@
 @sphinxdirective
 
 
-The CPU plugin is a part of the Intel® Distribution of OpenVINO™ toolkit. It is developed to achieve high performance inference of neural networks on Intel® x86-64 CPUs.
+The CPU plugin is a part of the Intel® Distribution of OpenVINO™ toolkit. It is developed to achieve high performance inference of neural networks on Intel® x86-64 CPUs.The newer 11th generation and later Intel® CPUs provide even further performance boost, especially with INT8 models.
 For an in-depth description of CPU plugin, see:
 
 - `CPU plugin developers documentation <https://github.com/openvinotoolkit/openvino/blob/master/docs/dev/cmake_options_for_custom_comiplation.md>`__.
@@ -108,8 +108,8 @@ to query ``ov::device::capabilities`` property, which should contain ``BF16`` in
 If the model has been converted to ``bf16``, the ``ov::hint::inference_precision`` is set to ``ov::element::bf16`` and can be checked via 
 the ``ov::CompiledModel::get_property`` call. The code below demonstrates how to get the element type:
 
-.. doxygensnippet:: snippets/cpu/Bfloat16Inference1.cpp
-   :language: py
+.. doxygensnippet:: docs/snippets/cpu/Bfloat16Inference1.cpp
+   :language: cpp
    :fragment: [part1]
 
 To infer the model in ``f32`` precision instead of ``bf16`` on targets with native ``bf16`` support, set the ``ov::hint::inference_precision`` to ``ov::element::f32``.
@@ -444,7 +444,6 @@ Currently, the ``sparse weights decompression feature`` is supported with the fo
 2. Feature is only supported for Matrix Multiplication operations.
 3. HW target must have Intel AMX extension support (e.g., Intel® 4th Generation Xeon® processors (code name Sapphire Rapids)).
 4. The number of input and output channels of the weights must be a multiple of 64.
-5. Current feature implementation supports only sparse rate higher than 0.5.
 
 Additional Resources
 ###########################################################

docs/OV_Runtime_UG/supported_plugins/GPU.md

@@ -125,8 +125,8 @@ Floating-point precision of a GPU primitive is selected based on operation preci
 
 .. note::
 
-   Hardware acceleration for ``i8``/``u8`` precision may be unavailable on some platforms. In such cases, a model is executed in the floating-point precision taken from IR. 
-   Hardware support of ``u8``/``i8`` acceleration can be queried via the `ov::device::capabilities` property.
+   The newer generation Intel Iris Xe and Xe MAX GPUs provide accelerated performance for i8/u8 models. Hardware acceleration for ``i8``/``u8`` precision may be unavailable on older generation platforms. In such cases, a model is executed in the floating-point precision taken from IR. 
+   Hardware support of ``u8``/``i8`` acceleration can be queried via the ``ov::device::capabilities`` property.
 
 :doc:`Hello Query Device C++ Sample<openvino_inference_engine_samples_hello_query_device_README>` can be used to print out the supported data types for all detected devices.
 
@@ -230,16 +230,40 @@ For more details, see the :doc:`optimization guide<openvino_docs_deployment_opti
 Dynamic Shapes
 +++++++++++++++++++++++++++++++++++++++
 
-The GPU plugin supports dynamic shapes for batch dimension only (specified as ``N`` in the :doc:`layouts terms<openvino_docs_OV_UG_Layout_Overview>`) with a fixed upper bound. 
-Any other dynamic dimensions are unsupported. Internally, GPU plugin creates ``log2(N)`` (``N`` - is an upper bound for batch dimension here) 
-low-level execution graphs for batch sizes equal to powers of 2 to emulate dynamic behavior, so that incoming infer request 
-with a specific batch size is executed via a minimal combination of internal networks. For example, batch size 33 may be executed via 2 internal networks with batch size 32 and 1.
 
-.. note:: 
+.. note::
 
-   Such approach requires much more memory and the overall model compilation time is significantly longer, compared to the static batch scenario.
+   Currently, dynamic shape support for GPU is a preview feature and has the following limitations:
+   
+   - It mainly supports NLP models (Natural Language Processing). Not all operations and optimization passes support dynamic shapes.
+     As a result, a given model may crash or experience significant performance drops.   
+   - Due to the dominant runtime overhead on the host device, dynamic shapes may perform worse than static shapes on a discrete GPU.
+   - Dynamic rank is not supported.
 
-The code snippet below demonstrates how to use dynamic batching in simple scenarios:
+The general description of what dynamic shapes are and how they are used can be found in
+:doc:`dynamic shapes guide <openvino_docs_OV_UG_DynamicShapes>`. 
+To support dynamic shape execution, the following basic infrastructures are implemented:
+
+- Runtime shape inference: infers output shapes of each primitive for a new input shape at runtime.
+- Shape agnostic kernels: new kernels that can run arbitrary shapes. If a shape-agnostic kernel is not available, 
+  the required kernel is compiled at runtime for each shape.
+- Asynchronous kernel compilation: even when a shape-agnostic kernel is available, 
+  the GPU plugin compiles an optimal kernel for the given shape and preserves it in the in-memory cache for future use.
+- In-memory cache: preserves kernels compiled at runtime and weights reordered for the specific kernels.
+
+Bounded dynamic batch
+-----------------------------------------------------------
+
+It is worth noting that the internal behavior differs in the case of bounded-batch dynamic shapes, 
+which means that only the batch dimension is dynamic and it has a fixed upper bound.
+
+While general dynamic shapes can run on one compiled model, for the bounded dynamic batch the GPU plugin creates ``log2(N)`` 
+low-level execution graphs in batch sizes equal to the powers of 2, to emulate the dynamic behavior (``N`` - is the upper bound for the batch dimension here).
+As a result, the incoming infer request with a specific batch size is executed via the minimal combination of internal networks.
+For example, a batch size of 33 may be executed via two internal networks with batch sizes of 32 and 1.
+This approach is adopted for performance reasons, but it requires more memory and increased compilation time for multiple copies of internal networks.
+
+The code snippet below demonstrates examples of a bounded dynamic batch:
 
 .. tab-set::
 
@@ -258,13 +282,65 @@ The code snippet below demonstrates how to use dynamic batching in simple scenar
          :fragment: dynamic_batch
 
 
-For more details, see the :doc:`dynamic shapes guide<openvino_docs_OV_UG_DynamicShapes>`.
+Notes for performance and memory consumption in dynamic shapes
+--------------------------------------------------------------
+
+- Extra CPU utilization during inference:
+
+  - Shape inference for new input shapes
+  - Kernel compilation in runtime for optimal kernel
+  - Unfusion of the fused subgraph when fusing is not allowed for a runtime shape
+
+- Higher memory consumption for in-memory cache
+
+  - Optimal kernels and weights from the previously used shapes are preserved in in-memory cache for future use
+
+
+Recommendations for performance improvement
+-----------------------------------------------------------
+
+- Use static shapes whenever possible
+
+  - Static models can benefit from more aggressive optimizations, such as, constant propagation, fusing, and reorder optimization.
+    If the same shape is used for a dynamic and a static model, performance is worse in the dynamic one.
+    It is, therefore, recommended to reshape dynamic models to static ones, if the scenario allows.
+
+- Use bounded dynamic shapes whenever possible
+
+  - The GPU plugin needs to reallocate memory if the current shape is larger than the maximum of the previous shapes, which causes additional overhead.
+  - Using a bounded dynamic shape will help to reduce such overhead. For example, use ``{ov::Dimension(1, 10), ov::Dimension(1, 384)}`` 
+    instead of ``{ov::Dimension(-1), ov::Dimension(-1)}``.
+  - Note that a bounded dynamic *batch* is handled differently as mentioned above.
+
+- Use permanent cache, e.g., OpenVino model_cache, to reduce the runtime re-compilation overhead
+
+  - GPU plugin deploys in-memory cache to store compiled kernels for previously used shapes,
+    but the size of such an in-memory cache is limited. Therefore, it is recommended to use 
+    a permanent cache such as OpenVino model_cache. For more details, See 
+    :doc:`Model caching overview <openvino_docs_OV_UG_Model_caching_overview>`.
+
+- The longer the inference sequence, the better throughput can be obtained, because it can
+  leverage more compilation time during inference.
+
+  - If the primitive has a shape-agnostic kernel and the static shape kernel for the current
+    shape does not exist in the in-memory cache, the shape-agnostic kernel is used. Then, as
+    mentioned above, optimal kernels for the current shapes are also asynchronously compiled
+    in parallel for future use. If the application process removes the CompiledModel object
+    and the GPU plugin is unusable, any not-yet-started compilation tasks for optimal kernels
+    will be canceled. However, if the application process allows enough time for the enqueued
+    asynchronous compilation tasks, the more optimal kernels become available, enabling better
+    throughput. For example, running 200 inputs of 
+    ``{[1, 1], ..., [1, 50], [1, 1], ... , [1, 50], [1, 1], ..., [1, 50], [1, 1], ..., [1, 50]}`` 
+    may achieve better throughput than running 100 inputs of ``{[1, 1], ..., [1, 50], [1, 1], ... , [1,50]}``.
+
 
 Preprocessing Acceleration
 +++++++++++++++++++++++++++++++++++++++
 
 The GPU plugin has the following additional preprocessing options:
-- The ``ov::intel_gpu::memory_type::surface`` and ``ov::intel_gpu::memory_type::buffer`` values for the ``ov::preprocess::InputTensorInfo::set_memory_type()`` preprocessing method. These values are intended to be used to provide a hint for the plugin on the type of input Tensors that will be set in runtime to generate proper kernels.
+- The ``ov::intel_gpu::memory_type::surface`` and ``ov::intel_gpu::memory_type::buffer`` values for the 
+  ``ov::preprocess::InputTensorInfo::set_memory_type()`` preprocessing method. These values are intended 
+  to be used to provide a hint for the plugin on the type of input Tensors that will be set in runtime to generate proper kernels.
 
 .. tab-set::
 

docs/OV_Runtime_UG/supported_plugins/Supported_Devices.md

@@ -5,7 +5,7 @@
 
 
 The OpenVINO runtime can infer various models of different input and output formats. Here, you can find configurations 
-supported by OpenVINO devices, which are CPU, GPU, or GNA (Gaussian neural accelerator coprocessor).
+supported by OpenVINO devices, which are CPU, GPU, or GNA (Gaussian neural accelerator coprocessor). Currently, 11th generation and later processors (currently up to 13th generation) provide a further performance boost, especially with INT8 models.
 
 .. note::
 
@@ -66,17 +66,17 @@ This page shows supported and optimal configurations for each plugin.
 Terminology
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-===================  =============================================
- Acronym/Term         Description                                 
-===================  =============================================
- FP32 format          Single-precision floating-point format       
- BF16 format          Brain floating-point format                  
- FP16 format          Half-precision floating-point format         
- I16 format           2-byte signed integer format                 
- I8 format            1-byte signed integer format                 
- U16 format           2-byte unsigned integer format               
- U8 format            1-byte unsigned integer format               
-===================  =============================================
++------------------+----------------------------------------------+
+| Acronym/Term     |   Description                                |
++==================+==============================================+
+| FP32 format      |   Single-precision floating-point format     |
+| BF16 format      |   Brain floating-point format                |
+| FP16 format      |   Half-precision floating-point format       |
+| I16 format       |   2-byte signed integer format               |
+| I8 format        |   1-byte signed integer format               |
+| U16 format       |   2-byte unsigned integer format             |
+| U8 format        |   1-byte unsigned integer format             |
++------------------+----------------------------------------------+
 
 NHWC, NCHW, and NCDHW refer to the data ordering in batches of images:
 
@@ -98,31 +98,31 @@ For example, the CHW value at index (c,h,w) is physically located at index (c\*H
 Supported Model Formats
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-==================  ===========================  ============================  ==========================
- Plugin              FP32                         FP16                          I8                              
-==================  ===========================  ============================  ========================== 
- CPU plugin          Supported and preferred      Supported                     Supported                                                        
- GPU plugin          Supported                    Supported and preferred       Supported                                                        
- GNA plugin          Supported                    Supported                     Not supported                                                    
- Arm® CPU plugin     Supported and preferred      Supported                     Supported (partially)                                            
-==================  ===========================  ============================  ==========================
++------------------+--------------------------+--------------------------+------------------------+
+| Plugin           | FP32                     | FP16                     | I8                     |
++==================+==========================+===================================================+ 
+| CPU plugin       | Supported and preferred  | Supported                | Supported              |
+| GPU plugin       | Supported                | Supported and preferred  | Supported              |
+| GNA plugin       | Supported                | Supported                | Not supported          |
+| Arm® CPU plugin  | Supported and preferred  | Supported                | Supported (partially)  |
++------------------+--------------------------+--------------------------+------------------------+
 
 
 For :doc:`Multi-Device <openvino_docs_OV_UG_Running_on_multiple_devices>` and
 :doc:`Heterogeneous <openvino_docs_OV_UG_Hetero_execution>` executions, the supported models formats depends 
-on the actual underlying devices. *Generally, FP16 is preferable as it is most ubiquitous and performant*.
+on the actual underlying devices.
 
 Supported Input Precision
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-=================  ===========  ===============  ==============  ===============  ==============  =================
- Plugin             FP32         FP16             U8              U16              I8              I16            
-=================  ===========  ===============  ==============  ===============  ==============  =================
- CPU plugin         Supported    Supported        Supported       Supported        Supported       Supported      
- GPU plugin         Supported    Supported\*      Supported\*     Supported\*      Not supported   Supported\*    
- GNA plugin         Supported    Not supported    Supported       Not supported    Supported       Supported      
- Arm® CPU plugin    Supported    Supported        Supported       Supported        Not supported   Not supported  
-=================  ===========  ===============  ==============  ===============  ==============  =================
++------------------+------------+----------------+--------------+----------------+----------------+----------------+
+| Plugin           | FP32       | FP16           | U8           |  U16           |  I8            | I16            |
++==================+============+================+==============+================+================+================+
+| CPU plugin       | Supported  | Supported      | Supported    | Supported      | Supported      | Supported      |
+| GPU plugin       | Supported  | Supported\*    | Supported\*  | Supported\*    | Not supported  | Supported\*    |
+| GNA plugin       | Supported  | Not supported  | Supported    | Not supported  | Supported      | Supported      |
+| Arm® CPU plugin  | Supported  | Supported      | Supported    | Supported      | Not supported  | Not supported  |
++------------------+------------+----------------+--------------+----------------+----------------+----------------+
 
 \* - Supported via ``SetBlob`` only, ``GetBlob`` returns FP32
 
@@ -133,14 +133,14 @@ depends on the actual underlying devices. *Generally, U8 is preferable as it is
 Supported Output Precision
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-==================  ==========  ================
- Plugin              FP32        FP16          
-==================  ==========  ================
- CPU plugin          Supported   Supported     
- GPU plugin          Supported   Supported     
- GNA plugin          Supported   Not supported 
- Arm® CPU plugin     Supported   Supported     
-==================  ==========  ================
++------------------+-----------------------------+
+| Plugin           | FP32       | FP16           |
++==================+============+================+
+| CPU plugin       | Supported  | Supported      |
+| GPU plugin       | Supported  | Supported      |
+| GNA plugin       | Supported  | Not supported  |
+| Arm® CPU plugin  | Supported  | Supported      |
++------------------+------------+----------------+
 
 For :doc:`Multi-Device <openvino_docs_OV_UG_Running_on_multiple_devices>` and
 :doc:`Heterogeneous <openvino_docs_OV_UG_Hetero_execution>` executions, the supported output precision 
@@ -149,23 +149,23 @@ depends on the actual underlying devices. *Generally, FP32 is preferable as it i
 Supported Input Layout
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-==================  ===============  ============  ============  ============
- Plugin              NCDHW            NCHW          NHWC          NC           
-==================  ===============  ============  ============  ============
- CPU plugin          Supported        Supported     Supported     Supported     
- GPU plugin          Supported        Supported     Supported     Supported     
- GNA plugin          Not supported    Supported     Supported     Supported     
- Arm® CPU plugin     Not supported    Supported     Supported     Supported     
-==================  ===============  ============  ============  ============
++------------------+----------------+------------+------------+------------+
+| Plugin           | NCDHW          | NCHW       | NHWC       | NC         |
++==================+================+============+============+============+
+| CPU plugin       | Supported      | Supported  | Supported  | Supported  |
+| GPU plugin       | Supported      | Supported  | Supported  | Supported  |
+| GNA plugin       | Not supported  | Supported  | Supported  | Supported  |
+| Arm® CPU plugin  | Not supported  | Supported  | Supported  | Supported  |
++------------------+----------------+------------+------------+------------+
 
 Supported Output Layout
 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
-======================  =======  ======  =====  ====  ====
- Number of dimensions    5        4       3      2     1    
-======================  =======  ======  =====  ====  ====
- Layout                  NCDHW    NCHW    CHW    NC    C    
-======================  =======  ======  =====  ====  ====
++-----------------------+--------+-------+------+-----+----+
+| Number of dimensions  | 5      | 4     | 3    | 2   | 1  |
++=======================+========+=======+======+=====+====+
+| Layout                | NCDHW  | NCHW  | CHW  | NC  | C  |
++-----------------------+--------+-------+------+-----+----+
 
 
 For setting relevant configuration, refer to the
@@ -179,154 +179,154 @@ Supported Layers
 The following layers are supported by the plugins:
 
 
-==============================  ==============  ===============  ==============  ==================
-Layers                          GPU             CPU              GNA             Arm® CPU    
-==============================  ==============  ===============  ==============  ==================  
-Abs                             Supported       Supported\*\*    Not Supported   Supported       
-Acos                            Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Acosh                           Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Activation-Clamp                Supported       Supported\*\*\*  Supported       Supported       
-Activation-ELU                  Supported       Supported\*\*\*  Not Supported   Supported       
-Activation-Exp                  Supported       Supported\*\*\*  Supported       Supported       
-Activation-Leaky ReLU           Supported       Supported\*\*\*  Supported       Not Supported   
-Activation-Not                  Supported       Supported\*\*\*  Not Supported   Not Supported   
-Activation-PReLU                Supported       Supported\*\*\*  Not Supported   Supported       
-Activation-ReLU                 Supported       Supported\*\*\*  Supported       Supported       
-Activation-ReLU6                Supported       Supported\*\*\*  Not Supported   Not Supported   
-Activation-Sigmoid/Logistic     Supported       Supported\*\*\*  Supported       Supported       
-Activation-TanH                 Supported       Supported\*\*\*  Supported       Supported       
-ArgMax                          Supported       Supported\*\*    Not Supported   Not Supported   
-Asin                            Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Asinh                           Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Atan                            Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Atanh                           Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-BatchNormalization              Supported       Supported        Not Supported   Supported       
-BinaryConvolution               Supported       Supported        Not Supported   Not Supported   
-Broadcast                       Supported       Supported\*\*    Not Supported   Supported       
-Ceil                            Supported       Supported\*\*    Not Supported   Supported       
-Concat                          Supported       Supported\*\*\*  Supported       Supported       
-Const                           Supported       Supported        Supported       Supported       
-Convolution-Dilated             Supported       Supported        Not Supported   Supported       
-Convolution-Dilated 3D          Supported       Supported        Not Supported   Not Supported   
-Convolution-Grouped             Supported       Supported        Not Supported   Supported       
-Convolution-Grouped 3D          Supported       Supported        Not Supported   Not Supported   
-Convolution-Ordinary            Supported       Supported        Supported\*     Supported       
-Convolution-Ordinary 3D         Supported       Supported        Not Supported   Not Supported   
-Cos                             Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Cosh                            Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Crop                            Supported       Supported        Supported       Not Supported   
-CTCGreedyDecoder                Supported\*\*   Supported\*\*    Not Supported   Supported\*\*\*\*
-Deconvolution                   Supported       Supported        Not Supported   Not Supported   
-Deconvolution 3D                Supported       Supported        Not Supported   Not Supported   
-DeformableConvolution           Supported       Supported        Not Supported   Not Supported   
-DepthToSpace                    Supported       Supported\*\*    Not Supported   Supported\*     
-DetectionOutput                 Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Eltwise-And                     Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Add                     Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Div                     Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Equal                   Supported       Supported\*\*\*  Not Supported   Supported\*     
-Eltwise-FloorMod                Supported       Supported\*\*\*  Not Supported   Supported\*\*\*\*
-Eltwise-Greater                 Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-GreaterEqual            Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Less                    Supported       Supported\*\*\*  Not Supported   Supported\*     
-Eltwise-LessEqual               Supported       Supported\*\*\*  Not Supported   Supported\*     
-Eltwise-LogicalAnd              Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-LogicalOr               Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-LogicalXor              Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Max                     Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Min                     Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Mul                     Supported       Supported\*\*\*  Supported       Supported       
-Eltwise-NotEqual                Supported       Supported\*\*\*  Not Supported   Supported\*     
-Eltwise-Pow                     Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Prod                    Supported       Supported\*\*\*  Supported       Not Supported   
-Eltwise-SquaredDiff             Supported       Supported\*\*\*  Not Supported   Supported       
-Eltwise-Sub                     Supported       Supported\*\*\*  Supported       Supported       
-Eltwise-Sum                     Supported       Supported\*\*\*  Supported       Supported\*\*\*\*
-Erf                             Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Exp                             Supported       Supported        Supported       Supported       
-FakeQuantize                    Not Supported   Supported        Not Supported   Supported\*     
-Fill                            Not Supported   Supported\*\*    Not Supported   Not Supported   
-Flatten                         Supported       Supported        Not Supported   Not Supported   
-Floor                           Supported       Supported\*\*    Not Supported   Supported       
-FullyConnected (Inner Product)  Supported       Supported\*\*\*  Supported       Supported       
-Gather                          Supported       Supported\*\*    Not Supported   Supported\*     
-GatherTree                      Not Supported   Supported\*\*    Not Supported   Supported\*\*\*\*
-Gemm                            Supported       Supported        Not Supported   Not Supported   
-GRN                             Supported\*\*   Supported\*\*    Not Supported   Supported       
-HardSigmoid                     Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Interp                          Supported\*\*   Supported\*\*    Not Supported   Supported\*     
-Log                             Supported       Supported\*\*    Supported       Supported       
-LRN (Norm)                      Supported       Supported        Not Supported   Supported\*     
-LSTMCell                        Supported       Supported        Supported       Supported       
-GRUCell                         Supported       Supported        Supported       Supported       
-RNNCell                         Supported       Supported        Not Supported   Supported       
-LSTMSequence                    Supported       Supported        Supported       Supported\*\*\*\*
-GRUSequence                     Supported       Supported        Supported       Supported\*\*\*\*
-RNNSequence                     Supported       Supported        Not Supported   Supported\*\*\*\*
-LogSoftmax                      Supported       Supported\*\*    Not Supported   Supported       
-Memory                          Not Supported   Supported        Supported       Not Supported   
-MVN                             Supported       Supported\*\*    Not Supported   Supported\*     
-Neg                             Supported       Supported\*\*    Not Supported   Supported       
-NonMaxSuppression               Not Supported   Supported\*\*    Not Supported   Supported\*\*\*\*
-Normalize                       Supported       Supported\*\*    Not Supported   Supported\*     
-OneHot                          Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Pad                             Supported       Supported\*\*    Not Supported   Supported\*     
-Permute                         Supported       Supported        Supported\*     Not Supported   
-Pooling(AVG,MAX)                Supported       Supported        Supported       Supported       
-Pooling(AVG,MAX) 3D             Supported       Supported        Not Supported   Supported\*     
-Power                           Supported       Supported\*\*    Supported\*     Supported       
-PowerFile                       Not Supported   Supported\*\*    Not Supported   Not Supported   
-PriorBox                        Supported       Supported\*\*    Not Supported   Supported       
-PriorBoxClustered               Supported\*\*   Supported\*\*    Not Supported   Supported       
-Proposal                        Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-PSROIPooling                    Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Range                           Not Supported   Supported\*\*    Not Supported   Not Supported   
-Reciprocal                      Supported       Supported\*\*    Not Supported   Not Supported   
-ReduceAnd                       Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-ReduceL1                        Supported       Supported\*\*    Not Supported   Supported       
-ReduceL2                        Supported       Supported\*\*    Not Supported   Supported       
-ReduceLogSum                    Supported       Supported\*\*    Not Supported   Supported       
-ReduceLogSumExp                 Supported       Supported\*\*    Not Supported   Not Supported   
-ReduceMax                       Supported       Supported\*\*    Not Supported   Supported       
-ReduceMean                      Supported       Supported\*\*    Not Supported   Supported       
-ReduceMin                       Supported       Supported\*\*    Not Supported   Supported       
-ReduceOr                        Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-ReduceProd                      Supported       Supported\*\*    Not Supported   Supported       
-ReduceSum                       Supported       Supported\*\*    Not Supported   Supported       
-ReduceSumSquare                 Supported       Supported\*\*    Not Supported   Not Supported   
-RegionYolo                      Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-ReorgYolo                       Supported       Supported\*\*    Not Supported   Supported       
-Resample                        Supported       Supported\*\*    Not Supported   Not Supported   
-Reshape                         Supported       Supported\*\*\*  Supported       Supported       
-ReverseSequence                 Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-RNN                             Not Supported   Supported        Not Supported   Supported       
-ROIPooling                      Supported\*     Supported        Not Supported   Supported\*\*\*\*
-ScaleShift                      Supported       Supported\*\*\*  Supported       Not Supported   
-ScatterUpdate                   Not Supported   Supported\*\*    Not Supported   Not Supported   
-Select                          Supported       Supported        Not Supported   Supported       
-Selu                            Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-ShuffleChannels                 Supported       Supported\*\*    Not Supported   Supported       
-Sign                            Supported       Supported\*\*    Not Supported   Supported       
-Sin                             Supported       Supported\*\*    Not Supported   Supported       
-Sinh                            Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-SimplerNMS                      Supported       Supported\*\*    Not Supported   Not Supported   
-Slice                           Supported       Supported\*\*\*  Supported       Not Supported   
-SoftMax                         Supported       Supported\*\*\*  Not Supported   Supported       
-Softplus                        Supported       Supported\*\*    Not Supported   Supported       
-Softsign                        Supported       Supported\*\*    Supported       Not Supported   
-SpaceToDepth                    Not Supported   Supported\*\*    Not Supported   Supported\*     
-SpatialTransformer              Not Supported   Supported\*\*    Not Supported   Not Supported   
-Split                           Supported       Supported\*\*\*  Supported       Supported       
-Squeeze                         Supported       Supported\*\*    Supported       Supported       
-StridedSlice                    Supported       Supported\*\*    Not Supported   Supported\*     
-Tan                             Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-TensorIterator                  Not Supported   Supported        Supported       Supported       
-Tile                            Supported\*\*   Supported\*\*\*  Not Supported   Supported       
-TopK                            Supported       Supported\*\*    Not Supported   Supported\*\*\*\*
-Unpooling                       Supported       Not Supported    Not Supported   Not Supported   
-Unsqueeze                       Supported       Supported\*\*    Supported       Supported       
-Upsampling                      Supported       Not Supported    Not Supported   Not Supported   
-==============================  ==============  ===============  ==============  ==================
++--------------------------------+----------------+-----------------+----------------+--------------------+
+| Layers                         | GPU            | CPU             | GNA            | Arm® CPU           |
++================================+================+=================+================+====================+  
+| Abs                            | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Acos                           | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Acosh                          | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Activation-Clamp               | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Activation-ELU                 | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Activation-Exp                 | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Activation-Leaky ReLU          | Supported      | Supported\*\*\* | Supported      | Not Supported      |
+| Activation-Not                 | Supported      | Supported\*\*\* | Not Supported  | Not Supported      |
+| Activation-PReLU               | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Activation-ReLU                | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Activation-ReLU6               | Supported      | Supported\*\*\* | Not Supported  | Not Supported      |
+| Activation-Sigmoid/Logistic    | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Activation-TanH                | Supported      | Supported\*\*\* | Supported      | Supported          |
+| ArgMax                         | Supported      | Supported\*\*   | Not Supported  | Not Supported      |
+| Asin                           | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Asinh                          | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Atan                           | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Atanh                          | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| BatchNormalization             | Supported      | Supported       | Not Supported  | Supported          |
+| BinaryConvolution              | Supported      | Supported       | Not Supported  | Not Supported      |
+| Broadcast                      | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Ceil                           | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Concat                         | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Const                          | Supported      | Supported       | Supported      | Supported          |
+| Convolution-Dilated            | Supported      | Supported       | Not Supported  | Supported          |
+| Convolution-Dilated 3D         | Supported      | Supported       | Not Supported  | Not Supported      |
+| Convolution-Grouped            | Supported      | Supported       | Not Supported  | Supported          |
+| Convolution-Grouped 3D         | Supported      | Supported       | Not Supported  | Not Supported      |
+| Convolution-Ordinary           | Supported      | Supported       | Supported\*    | Supported          |
+| Convolution-Ordinary 3D        | Supported      | Supported       | Not Supported  | Not Supported      |
+| Cos                            | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Cosh                           | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Crop                           | Supported      | Supported       | Supported      | Not Supported      |
+| CTCGreedyDecoder               | Supported\*\*  | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Deconvolution                  | Supported      | Supported       | Not Supported  | Not Supported      |
+| Deconvolution 3D               | Supported      | Supported       | Not Supported  | Not Supported      |
+| DeformableConvolution          | Supported      | Supported       | Not Supported  | Not Supported      |
+| DepthToSpace                   | Supported      | Supported\*\*   | Not Supported  | Supported\*        |
+| DetectionOutput                | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Eltwise-And                    | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Add                    | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Div                    | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Equal                  | Supported      | Supported\*\*\* | Not Supported  | Supported\*        |
+| Eltwise-FloorMod               | Supported      | Supported\*\*\* | Not Supported  | Supported\*\*\*\*  |
+| Eltwise-Greater                | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-GreaterEqual           | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Less                   | Supported      | Supported\*\*\* | Not Supported  | Supported\*        |
+| Eltwise-LessEqual              | Supported      | Supported\*\*\* | Not Supported  | Supported\*        |
+| Eltwise-LogicalAnd             | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-LogicalOr              | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-LogicalXor             | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Max                    | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Min                    | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Mul                    | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Eltwise-NotEqual               | Supported      | Supported\*\*\* | Not Supported  | Supported\*        |
+| Eltwise-Pow                    | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Prod                   | Supported      | Supported\*\*\* | Supported      | Not Supported      |
+| Eltwise-SquaredDiff            | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Eltwise-Sub                    | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Eltwise-Sum                    | Supported      | Supported\*\*\* | Supported      | Supported\*\*\*\*  |
+| Erf                            | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Exp                            | Supported      | Supported       | Supported      | Supported          |
+| FakeQuantize                   | Not Supported  | Supported       | Not Supported  | Supported\*        |
+| Fill                           | Not Supported  | Supported\*\*   | Not Supported  | Not Supported      |
+| Flatten                        | Supported      | Supported       | Not Supported  | Not Supported      |
+| Floor                          | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| FullyConnected (Inner Product) | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Gather                         | Supported      | Supported\*\*   | Not Supported  | Supported\*        |
+| GatherTree                     | Not Supported  | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Gemm                           | Supported      | Supported       | Not Supported  | Not Supported      |
+| GRN                            | Supported\*\*  | Supported\*\*   | Not Supported  | Supported          |
+| HardSigmoid                    | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Interp                         | Supported\*\*  | Supported\*\*   | Not Supported  | Supported\*        |
+| Log                            | Supported      | Supported\*\*   | Supported      | Supported          |
+| LRN (Norm)                     | Supported      | Supported       | Not Supported  | Supported\*        |
+| LSTMCell                       | Supported      | Supported       | Supported      | Supported          |
+| GRUCell                        | Supported      | Supported       | Supported      | Supported          |
+| RNNCell                        | Supported      | Supported       | Not Supported  | Supported          |
+| LSTMSequence                   | Supported      | Supported       | Supported      | Supported\*\*\*\*  |
+| GRUSequence                    | Supported      | Supported       | Supported      | Supported\*\*\*\*  |
+| RNNSequence                    | Supported      | Supported       | Not Supported  | Supported\*\*\*\*  |
+| LogSoftmax                     | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Memory                         | Not Supported  | Supported       | Supported      | Not Supported      |
+| MVN                            | Supported      | Supported\*\*   | Not Supported  | Supported\*        |
+| Neg                            | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| NonMaxSuppression              | Not Supported  | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Normalize                      | Supported      | Supported\*\*   | Not Supported  | Supported\*        |
+| OneHot                         | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Pad                            | Supported      | Supported\*\*   | Not Supported  | Supported\*        |
+| Permute                        | Supported      | Supported       | Supported\*    | Not Supported      |
+| Pooling(AVG,MAX)               | Supported      | Supported       | Supported      | Supported          |
+| Pooling(AVG,MAX) 3D            | Supported      | Supported       | Not Supported  | Supported\*        |
+| Power                          | Supported      | Supported\*\*   | Supported\*    | Supported          |
+| PowerFile                      | Not Supported  | Supported\*\*   | Not Supported  | Not Supported      |
+| PriorBox                       | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| PriorBoxClustered              | Supported\*\*  | Supported\*\*   | Not Supported  | Supported          |
+| Proposal                       | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| PSROIPooling                   | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Range                          | Not Supported  | Supported\*\*   | Not Supported  | Not Supported      |
+| Reciprocal                     | Supported      | Supported\*\*   | Not Supported  | Not Supported      |
+| ReduceAnd                      | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| ReduceL1                       | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| ReduceL2                       | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| ReduceLogSum                   | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| ReduceLogSumExp                | Supported      | Supported\*\*   | Not Supported  | Not Supported      |
+| ReduceMax                      | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| ReduceMean                     | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| ReduceMin                      | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| ReduceOr                       | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| ReduceProd                     | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| ReduceSum                      | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| ReduceSumSquare                | Supported      | Supported\*\*   | Not Supported  | Not Supported      |
+| RegionYolo                     | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| ReorgYolo                      | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Resample                       | Supported      | Supported\*\*   | Not Supported  | Not Supported      |
+| Reshape                        | Supported      | Supported\*\*\* | Supported      | Supported          |
+| ReverseSequence                | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| RNN                            | Not Supported  | Supported       | Not Supported  | Supported          |
+| ROIPooling                     | Supported\*    | Supported       | Not Supported  | Supported\*\*\*\*  |
+| ScaleShift                     | Supported      | Supported\*\*\* | Supported      | Not Supported      |
+| ScatterUpdate                  | Not Supported  | Supported\*\*   | Not Supported  | Not Supported      |
+| Select                         | Supported      | Supported       | Not Supported  | Supported          |
+| Selu                           | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| ShuffleChannels                | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Sign                           | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Sin                            | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Sinh                           | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| SimplerNMS                     | Supported      | Supported\*\*   | Not Supported  | Not Supported      |
+| Slice                          | Supported      | Supported\*\*\* | Supported      | Not Supported      |
+| SoftMax                        | Supported      | Supported\*\*\* | Not Supported  | Supported          |
+| Softplus                       | Supported      | Supported\*\*   | Not Supported  | Supported          |
+| Softsign                       | Supported      | Supported\*\*   | Supported      | Not Supported      |
+| SpaceToDepth                   | Not Supported  | Supported\*\*   | Not Supported  | Supported\*        |
+| SpatialTransformer             | Not Supported  | Supported\*\*   | Not Supported  | Not Supported      |
+| Split                          | Supported      | Supported\*\*\* | Supported      | Supported          |
+| Squeeze                        | Supported      | Supported\*\*   | Supported      | Supported          |
+| StridedSlice                   | Supported      | Supported\*\*   | Not Supported  | Supported\*        |
+| Tan                            | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| TensorIterator                 | Not Supported  | Supported       | Supported      | Supported          |
+| Tile                           | Supported\*\*  | Supported\*\*\* | Not Supported  | Supported          |
+| TopK                           | Supported      | Supported\*\*   | Not Supported  | Supported\*\*\*\*  |
+| Unpooling                      | Supported      | Not Supported   | Not Supported  | Not Supported      |
+| Unsqueeze                      | Supported      | Supported\*\*   | Supported      | Supported          |
+| Upsampling                     | Supported      | Not Supported   | Not Supported  | Not Supported      |
++--------------------------------+----------------+-----------------+----------------+--------------------+
 
 
 \* - support is limited to the specific parameters. Refer to "Known Layer Limitations" section for the device :doc:`from the list of supported <openvino_docs_OV_UG_supported_plugins_Supported_Devices>`.

docs/_static/images/MO_connection_example_1.svg

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:fd1e2d8f82ce07f5d463d6480293935443785979fe16b555cd8e60fb2f253928
+size 55232

docs/_static/images/MO_conversion_pipeline.svg

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:db6f798882e0301f0cf83f1eba90560b5151266612fef2bc5f16a12cf192f0a0
+size 128446

docs/_static/images/MO_graph_after_extractors.svg

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:e9d5ee3d23d232fc10072189c0bf18d76f5d5d7217091d81a1ac465d129c034e
+size 88648

docs/_static/images/MO_graph_after_loader.svg

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:e882e25b5117e4d17a3b94944f58470c0337fafa5afc2ec6aa01f498c442c5f3
+size 73933

docs/_static/images/MO_graph_before_partial_inference.svg

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:7799a6c30352fa74d7d98f993d9ad7b148d975d96778762df410d69133abf8a8
+size 158171

docs/_static/images/MO_ports_example_1.svg

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:8340d5ca434fe74d19f397c1acd0c92b4ad3b16a563975dc1603a6bf8ef03eb6
+size 55262

docs/_static/images/MO_ports_example_2.svg

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:aed3820019aa5b9d4741c146bd4596e6850ea714e6e44fefe6cccf4707e5f152
+size 55270

docs/_static/images/MO_transformations_graph.svg

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:edbc2911e5aa5a672d8ebaf82b3d06f6915e44b8760ac18f88fba1d2e99fddd6
+size 349693

docs/dev/cmake_options_for_custom_comiplation.md

@@ -34,7 +34,7 @@ This document provides description and default values for CMake options that can
 * Frontends to work with models from frameworks:
     * `ENABLE_OV_ONNX_FRONTEND` enables [ONNX] frontend plugin for OpenVINO Runtime:
         * `ON` is default.
-    * `ENABLE_OV_PDPD_FRONTEND` enables [PDPD] frontend plugin for OpenVINO Runtime:
+    * `ENABLE_OV_PADDLE_FRONTEND` enables [PDPD] frontend plugin for OpenVINO Runtime:
         * `ON` is default.
     * `ENABLE_OV_TF_FRONTEND` enables [TensorFlow] frontend plugin for OpenVINO Runtime:
         * `ON` is default.

docs/img/MO_connection_example_1.png

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:1e432a8beb8290adec0d498f5c4aff63eed36c7fdf4bade3db0e0b0bdc5ff70f
-size 26737

docs/img/MO_conversion_pipeline.png

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:bb7beec6a00edbde13eca331d513f72b35b442f41f3a0c0e84f5185a1dcbf9ec
-size 50220

docs/img/MO_graph_after_extractors.png

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:bae3a4992d6d4f157674496b6230ae68f0cc33a58e4f305eeb935c09b5278409
-size 28518

docs/img/MO_graph_after_loader.png

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:c9bc3815efa5c7a2e2b3db4bfdc229b991c86346b086a74e5b02fa512cb3811f
-size 26772

docs/img/MO_graph_before_partial_inference.png

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:22f39675a2dab15ff466094d623444ae2bf3d9447113bc4528e19ef275932260
-size 51382

docs/img/MO_ports_example_1.png

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:86866c2c0a192eaaa78875ef324334d2d50eb488aa5a6ed980cb3b0d21f35953
-size 26142

docs/img/MO_ports_example_2.png

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:0540bb419eacf351d9e311c8b25c057c0c02f070b8615ae351e7cd21e3a9e020
-size 25934

docs/img/MO_transformations_graph.png

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:1fd333909d651648152c881122cdc6261e40737a96b2ef4eb291cce9da84e713
-size 133129

docs/install_guides/installing-openvino-from-archive-windows.md

@@ -1,7 +1,7 @@
 # Install OpenVINO™ Runtime on Windows from an Archive File {#openvino_docs_install_guides_installing_openvino_from_archive_windows}
 
 @sphinxdirective
-
+ 
 With the OpenVINO™ 2022.3 release, you can download and use archive files to install OpenVINO Runtime. The archive files contain pre-built binaries and library files needed for OpenVINO Runtime, as well as code samples.
 
 Installing OpenVINO Runtime from archive files is recommended for C++ developers. If you are working with Python, the PyPI package has everything needed for Python development and deployment on CPU and GPUs. See the :doc:`Install OpenVINO from PyPI <openvino_docs_install_guides_installing_openvino_pip>` page for instructions on how to install OpenVINO Runtime for Python using PyPI.
@@ -106,7 +106,7 @@ Step 1: Download and Install OpenVINO Core Components
 
    .. note::
 
-      If you have already installed a previous release of OpenVINO 2022, a symbolic link to the ``openvino_2022`` folder may already exist. If you want to override it, nagivate to the ``C:\Program Files (x86)\Intel`` folder and delete the existing linked folder before running the ``mklink`` command.
+      If you have already installed a previous release of OpenVINO 2022, a symbolic link to the ``openvino_2022`` folder may already exist. If you want to override it, navigate to the ``C:\Program Files (x86)\Intel`` folder and delete the existing linked folder before running the ``mklink`` command.
 
 
 Congratulations, you finished the installation! The ``C:\Program Files (x86)\Intel\openvino_2022`` folder now contains the core components for OpenVINO. If you used a different path in Step 1, you will find the ``openvino_2022`` folder there. The path to the ``openvino_2022`` directory is also referred as ``<INSTALL_DIR>`` throughout the OpenVINO documentation.

docs/install_guides/installing-openvino-runtime.md

@@ -14,10 +14,10 @@
 
 You can choose how to install OpenVINO™ Runtime according to your operating system: 
 
-* `Install OpenVINO Runtime on Linux <openvino_docs_install_guides_installing_openvino_linux_header>`
-* `Install OpenVINO Runtime on Windows <openvino_docs_install_guides_installing_openvino_windows_header>`
-* `Install OpenVINO Runtime on macOS <openvino_docs_install_guides_installing_openvino_macos_header>`
-* `Install OpenVINO Runtime on Raspbian OS <openvino_docs_install_guides_installing_openvino_raspbian>`
+* :doc:`Install OpenVINO Runtime on Linux <openvino_docs_install_guides_installing_openvino_linux_header>`
+* :doc:`Install OpenVINO Runtime on Windows <openvino_docs_install_guides_installing_openvino_windows_header>`
+* :doc:`Install OpenVINO Runtime on macOS <openvino_docs_install_guides_installing_openvino_macos_header>`
+* :doc:`Install OpenVINO Runtime on Raspbian OS <openvino_docs_install_guides_installing_openvino_raspbian>`
 
 Enjoy your journey with OpenVINO.
 

docs/install_guides/pre-release-note.md

@@ -1,2 +0,0 @@
-
-> **NOTE**: This version is pre-release software and has not undergone full release validation or qualification. No support is offered on pre-release software and APIs/behavior are subject to change.  It should NOT be incorporated into any production software/solution and instead should be used only for early testing and integration while awaiting a final release version of this software.

docs/install_guides/pypi-openvino-dev.md

@@ -1,8 +1,5 @@
 # OpenVINO™ Development Tools 
 
-<!--- The note below is intended for master branch only for pre-release purpose. Remove it for offical releases. --->
-> **NOTE**: This version is pre-release software and has not undergone full release validation or qualification. No support is offered on pre-release software and APIs/behavior are subject to change. It should NOT be incorporated into any production software/solution and instead should be used only for early testing and integration while awaiting a final release version of this software.
-
 Intel® Distribution of OpenVINO™ toolkit is an open-source toolkit for optimizing and deploying AI inference. It can be used to develop applications and solutions based on deep learning tasks, such as: emulation of human vision, automatic speech recognition, natural language processing, recommendation systems, etc. It provides high-performance and rich deployment options, from edge to cloud.
 
 OpenVINO™ Development Tools enables you to download models from Open Model Zoo, convert your own models to OpenVINO IR, as well as optimize and tune pre-trained deep learning models. See [What's in the Package](#whats-in-the-package) for more information.

docs/install_guides/pypi-openvino-rt.md

@@ -1,8 +1,5 @@
 # OpenVINO™ Runtime
 
-<!--- The note below is intended for master branch only for pre-release purpose. Remove it for offical releases. --->
-> **NOTE**: This version is pre-release software and has not undergone full release validation or qualification. No support is offered on pre-release software and APIs/behavior are subject to change. It should NOT be incorporated into any production software/solution and instead should be used only for early testing and integration while awaiting a final release version of this software.
-
 Intel® Distribution of OpenVINO™ toolkit is an open-source toolkit for optimizing and deploying AI inference. It can be used to develop applications and solutions based on deep learning tasks, such as: emulation of human vision, automatic speech recognition, natural language processing, recommendation systems, etc. It provides high-performance and rich deployment options, from edge to cloud.
 
 If you have already finished developing your models and converting them to the OpenVINO model format, you can install OpenVINO Runtime to deploy your applications on various devices. The [OpenVINO™ Runtime](https://docs.openvino.ai/nightly/openvino_docs_OV_UG_OV_Runtime_User_Guide.html) Python package includes a set of libraries for an easy inference integration with your products.

docs/install_guides/troubleshooting-steps.md

@@ -4,7 +4,7 @@
 
 If you run into issues while installing or configuring OpenVINO™, you can try the following methods to do some quick checks first. 
 
-Check the versions of OpenVINO Runtime and Developement Tools
+Check the versions of OpenVINO Runtime and Development Tools
 #############################################################
 
 * To check the version of OpenVINO Development Tools, use the following command:
@@ -79,7 +79,7 @@ Verify that OpenVINO is correctly installed
 
 * If you installed OpenVINO Runtime from YUM, use the ``yum list installed 'openvino*'`` command to list the installed OpenVINO packages.
 
-Check if GPU drvier is installed
+Check if GPU driver is installed
 ################################
 
 :doc:`Additional configurations <openvino_docs_install_guides_configurations_header>` may be required in order to use OpenVINO with different hardware such as Intel® GPUs.

docs/ops/activation/Elu_1.md

@@ -1,5 +1,7 @@
 # Elu {#openvino_docs_ops_activation_Elu_1}
 
+@sphinxdirective
+
 **Versioned name**: *Elu-1*
 
 **Category**: *Activation function*
@@ -8,15 +10,16 @@
 
 **Detailed Description**
 
-*Elu* operation is introduced in this [article](https://arxiv.org/abs/1511.07289v3).
+*Elu* operation is introduced in this `article <https://arxiv.org/abs/1511.07289v3>`__.
 It performs element-wise activation function on a given input tensor, based on the following mathematical formula:
 
-\f[
-Elu(x) = \left\{\begin{array}{r}
-    x \qquad \mbox{if } x >  0 \\
-    \alpha(e^{x} - 1) \quad \mbox{if } x \leq 0
-\end{array}\right.
-\f]
+.. math::
+   
+   Elu(x) = \left\begin{array}{r}
+       x \qquad \mbox{if } x >  0 \\
+       \alpha(e^{x} - 1) \quad \mbox{if } x \leq 0
+   \end{array}\right.
+
 
 where α corresponds to *alpha* attribute.
 
@@ -28,16 +31,16 @@ where α corresponds to *alpha* attribute.
 
   * **Description**: scale for the negative factor
   * **Range of values**: non-negative arbitrary floating-point number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Required**: *yes*
 
 **Inputs**:
 
-*   **1**: A tensor of type *T* and arbitrary shape. **Required.**
+* **1**: A tensor of type *T* and arbitrary shape. **Required.**
 
 **Outputs**:
 
-*   **1**: The result of element-wise *Elu* function applied to the input tensor. A tensor of type *T* and the same shape as input tensor.
+* **1**: The result of element-wise *Elu* function applied to the input tensor. A tensor of type *T* and the same shape as input tensor.
 
 **Types**
 
@@ -45,20 +48,22 @@ where α corresponds to *alpha* attribute.
 
 **Example**
 
-```xml
-<layer ... type="Elu">
-    <data alpha="1.0"/>
-    <input>
-        <port id="0">
-            <dim>1</dim>
-            <dim>128</dim>
-        </port>
-    </input>
-    <output>
-        <port id="1">
-            <dim>1</dim>
-            <dim>128</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+   
+   <layer ... type="Elu">
+       <data alpha="1.0"/>
+       <input>
+           <port id="0">
+               <dim>1</dim>
+               <dim>128</dim>
+           </port>
+       </input>
+       <output>
+           <port id="1">
+               <dim>1</dim>
+               <dim>128</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective

docs/ops/activation/Exp_1.md

@@ -1,5 +1,7 @@
 # Exp {#openvino_docs_ops_activation_Exp_1}
 
+@sphinxdirective
+
 **Versioned name**: *Exp-1*
 
 **Category**: *Activation function*
@@ -10,19 +12,19 @@
 
 *Exp* performs element-wise exponential activation function on a given input tensor. The mathematical formula is as follows:
 
-\f[
-exp(x) = e^{x}
-\f]
+.. math::
+   
+   exp(x) = e^{x}
 
 **Attributes**: *Exp* operation has no attributes.
 
 **Inputs**
 
-*   **1**: A tensor of type *T* and arbitrary shape. **Required.**
+* **1**: A tensor of type *T* and arbitrary shape. **Required.**
 
 **Outputs**
 
-*   **1**: The result of element-wise *Exp* function applied to the input tensor. A tensor of type *T* and the same shape as input tensor.
+* **1**: The result of element-wise *Exp* function applied to the input tensor. A tensor of type *T* and the same shape as input tensor.
 
 **Types**
 
@@ -30,19 +32,22 @@ exp(x) = e^{x}
 
 **Example**
 
-```xml
-<layer ... type="Exp">
-    <input>
-        <port id="0">
-            <dim>1</dim>
-            <dim>256</dim>
-        </port>
-    </input>
-    <output>
-        <port id="1">
-            <dim>1</dim>
-            <dim>256</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+   
+   <layer ... type="Exp">
+       <input>
+           <port id="0">
+               <dim>1</dim>
+               <dim>256</dim>
+           </port>
+       </input>
+       <output>
+           <port id="1">
+               <dim>1</dim>
+               <dim>256</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/activation/HSigmoid_5.md

@@ -1,5 +1,7 @@
 # HSigmoid {#openvino_docs_ops_activation_HSigmoid_5}
 
+@sphinxdirective
+
 **Versioned name**: *HSigmoid-5*
 
 **Category**: *Activation function*
@@ -9,11 +11,12 @@
 **Detailed description**: For each element from the input tensor calculates corresponding
 element in the output tensor with the following formula:
 
-\f[
-HSigmoid(x) = \frac{min(max(x + 3,\ 0),\ 6)}{6}
-\f]
+.. math::
 
-The HSigmoid operation is introduced in the following [article](https://arxiv.org/pdf/1905.02244.pdf).
+   HSigmoid(x) = \frac{min(max(x + 3,\ 0),\ 6)}{6}
+
+
+The HSigmoid operation is introduced in the following `article <https://arxiv.org/pdf/1905.02244.pdf>`__.
 
 **Attributes**: operations has no attributes.
 
@@ -31,17 +34,20 @@ The HSigmoid operation is introduced in the following [article](https://arxiv.or
 
 **Examples**
 
-```xml
-<layer ... type="HSigmoid">
-    <input>
-        <port id="0">
-            <dim>256</dim>
-        </port>
-    </input>
-    <output>
-        <port id="1">
-            <dim>256</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="HSigmoid">
+       <input>
+           <port id="0">
+               <dim>256</dim>
+           </port>
+       </input>
+       <output>
+           <port id="1">
+               <dim>256</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/activation/HSwish_4.md

@@ -1,5 +1,7 @@
 # HSwish {#openvino_docs_ops_activation_HSwish_4}
 
+@sphinxdirective
+
 **Versioned name**: *HSwish-4*
 
 **Category**: *Activation function*
@@ -9,11 +11,12 @@
 **Detailed description**: For each element from the input tensor calculates corresponding
 element in the output tensor with the following formula:
 
-\f[
-HSwish(x) = x \cdot \frac{min(max(x + 3,\ 0),\ 6)}{6}
-\f]
+.. math::
 
-The HSwish operation is introduced in the following [article](https://arxiv.org/pdf/1905.02244.pdf).
+   HSwish(x) = x \cdot \frac{min(max(x + 3,\ 0),\ 6)}{6}
+
+
+The HSwish operation is introduced in the following `article <https://arxiv.org/pdf/1905.02244.pdf>`__.
 
 **Attributes**: operation has no attributes.
 
@@ -32,19 +35,22 @@ The HSwish operation is introduced in the following [article](https://arxiv.org/
 
 **Example**
 
-```xml
-<layer ... type="HSwish">
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="HSwish">
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/activation/HardSigmoid_1.md

@@ -1,5 +1,7 @@
 # HardSigmoid {#openvino_docs_ops_activation_HardSigmoid_1}
 
+@sphinxdirective
+
 **Versioned name**: *HardSigmoid-1*
 
 **Category**: *Activation function*
@@ -10,22 +12,23 @@
 
 **Mathematical Formulation**
 
-For each element from the input tensor calculates corresponding
- element in the output tensor with the following formula:
+For each element from the input tensor calculates corresponding 
+element in the output tensor with the following formula:
 
- \f[
- y = max(0,\ min(1,\ \alpha x + \beta))
- \f]
+.. math::
 
- where α corresponds to `alpha` scalar input and β corresponds to `beta` scalar input.
+   y = max(0,\ min(1,\ \alpha x + \beta))
+
+
+where α corresponds to ``alpha`` scalar input and β corresponds to ``beta`` scalar input.
 
 **Inputs**
 
 * **1**: An tensor of type *T*. **Required.**
 
-* **2**: `alpha` 0D tensor (scalar) of type *T*. **Required.**
+* **2**: ``alpha`` 0D tensor (scalar) of type *T*. **Required.**
 
-* **3**: `beta` 0D tensor (scalar) of type *T*. **Required.**
+* **3**: ``beta`` 0D tensor (scalar) of type *T*. **Required.**
 
 **Outputs**
 
@@ -37,21 +40,23 @@ For each element from the input tensor calculates corresponding
 
 **Examples**
 
-```xml
-<layer ... type="HardSigmoid">
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1"/>
-        <port id="2"/>
-    </input>
-    <output>
-        <port id="3">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="HardSigmoid">
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+           <port id="1"/>
+           <port id="2"/>
+       </input>
+       <output>
+           <port id="3">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective

docs/ops/activation/LogSoftmax_5.md

@@ -1,16 +1,23 @@
 # LogSoftMax {#openvino_docs_ops_activation_LogSoftmax_5}
 
+@sphinxdirective
+
 **Versioned name**: *LogSoftmax-5*
 
 **Category**: *Activation function*
 
 **Short description**: LogSoftmax computes the natural logarithm of softmax values for the given input.
 
-**Note**:  This is recommended to not compute LogSoftmax directly as Log(Softmax(x, axis)), more numeric stable is to compute LogSoftmax as:
-\f[
-t = (x - ReduceMax(x,\ axis)) \\
-LogSoftmax(x, axis) = t - Log(ReduceSum(Exp(t),\ axis))
-\f]
+.. note::
+
+   This is recommended to not compute LogSoftmax directly as Log(Softmax(x, axis)), more numeric stable is to compute LogSoftmax as:
+
+
+.. math::
+
+   t = (x - ReduceMax(x,\ axis)) \\
+   LogSoftmax(x, axis) = t - Log(ReduceSum(Exp(t),\ axis))
+
 
 **Attributes**
 
@@ -24,11 +31,11 @@ LogSoftmax(x, axis) = t - Log(ReduceSum(Exp(t),\ axis))
 
 **Inputs**:
 
-*   **1**: Input tensor *x* of type *T* with enough number of dimension to be compatible with *axis* attribute. **Required.**
+* **1**: Input tensor *x* of type *T* with enough number of dimension to be compatible with *axis* attribute. **Required.**
 
 **Outputs**:
 
-*   **1**: The resulting tensor of the same shape and of type *T*.
+* **1**: The resulting tensor of the same shape and of type *T*.
 
 **Types**
 
@@ -36,27 +43,33 @@ LogSoftmax(x, axis) = t - Log(ReduceSum(Exp(t),\ axis))
 
 **Mathematical Formulation**
 
-\f[
-y_{c} = ln\left(\frac{e^{Z_{c}}}{\sum_{d=1}^{C}e^{Z_{d}}}\right)
-\f]
-where \f$C\f$ is a size of tensor along *axis* dimension.
+.. math::
+
+   y_{c} = ln\left(\frac{e^{Z_{c}}}{\sum_{d=1}^{C}e^{Z_{d}}}\right)
+
+
+where :math:`C` is a size of tensor along *axis* dimension.
 
 **Example**
 
-```xml
-<layer ... type="LogSoftmax" ... >
-    <data axis="1" />
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="3">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="LogSoftmax" ... >
+       <data axis="1" />
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="3">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective
+

docs/ops/activation/Mish_4.md

@@ -1,5 +1,7 @@
 # Mish {#openvino_docs_ops_activation_Mish_4}
 
+@sphinxdirective
+
 **Versioned name**: *Mish-4*
 
 **Category**: *Activation function*
@@ -8,23 +10,24 @@
 
 **Detailed description**
 
-*Mish* is a self regularized non-monotonic neural activation function proposed in this [article](https://arxiv.org/abs/1908.08681v2).
+*Mish* is a self regularized non-monotonic neural activation function proposed in this `article <https://arxiv.org/abs/1908.08681v2>`__.
 
 *Mish* performs element-wise activation function on a given input tensor, based on the following mathematical formula:
 
-\f[
-Mish(x) = x\cdot\tanh\big(SoftPlus(x)\big) = x\cdot\tanh\big(\ln(1+e^{x})\big)
-\f]
+.. math::
+
+   Mish(x) = x\cdot\tanh\big(SoftPlus(x)\big) = x\cdot\tanh\big(\ln(1+e^{x})\big)
+
 
 **Attributes**: *Mish* operation has no attributes.
 
 **Inputs**:
 
-*   **1**: A tensor of type *T* and arbitrary shape. **Required.**
+* **1**: A tensor of type *T* and arbitrary shape. **Required.**
 
 **Outputs**:
 
-*   **1**: The result of element-wise *Mish* function applied to the input tensor. A tensor of type *T* and the same shape as input tensor.
+* **1**: The result of element-wise *Mish* function applied to the input tensor. A tensor of type *T* and the same shape as input tensor.
 
 **Types**
 
@@ -32,19 +35,23 @@ Mish(x) = x\cdot\tanh\big(SoftPlus(x)\big) = x\cdot\tanh\big(\ln(1+e^{x})\big)
 
 **Example**
 
-```xml
-<layer ... type="Mish">
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="3">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block: cpp
+
+   <layer ... type="Mish">
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="3">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective
+

docs/ops/activation/PReLU_1.md

@@ -1,5 +1,7 @@
 # PReLU {#openvino_docs_ops_activation_PReLU_1}
 
+@sphinxdirective
+
 **Versioned name**: *PReLU-1*
 
 **Category**: *Activation function*
@@ -8,37 +10,37 @@
 
 **Detailed description**
 
-*PReLU* operation is introduced in this [article](https://arxiv.org/abs/1502.01852v1).
+*PReLU* operation is introduced in this `article <https://arxiv.org/abs/1502.01852v1>`__.
 
 *PReLU* performs element-wise parametric *ReLU* operation on a given input tensor, based on the following mathematical formula:
 
-\f[
-PReLU(x) = \left\{\begin{array}{r}
-    x \quad \mbox{if } x \geq  0 \\
-    \alpha x \quad \mbox{if } x < 0
-\end{array}\right.
-\f]
+.. math::
 
-where α is a learnable parameter and corresponds to the negative slope, defined by the second input `slope`.
+   \text{PReLU}(x) = \begin{cases}
+   x & \text{if } x \geq 0 \\
+   \alpha x & \text{if } x < 0
+   \end{cases}
+
+where α is a learnable parameter and corresponds to the negative slope, defined by the second input ``slope``.
 
 Another mathematical representation that may be found in other references:
 
-\f[
-PReLU(x) = \max(0, x) + \alpha\cdot\min(0, x)
-\f]
+.. math::
+
+	PReLU(x) = \max(0, x) + \alpha\cdot\min(0, x)
 
 
 **Attributes**: *PReLU* operation has no attributes.
 
 **Inputs**
 
-* **1**: `data`. A tensor of type *T* and arbitrary shape. **Required.**
-* **2**: `slope`. A tensor of type *T* and rank greater or equal to 1. Tensor with negative slope values. **Required.**
-* **Note**: Channels dimension corresponds to the second dimension of `data` input tensor. If `slope` input rank is 1 and its dimension is equal to the second dimension of `data` input, then per channel broadcast is applied. Otherwise `slope` input is broadcasted with numpy rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md).
+* **1**: ``data``. A tensor of type *T* and arbitrary shape. **Required.**
+* **2**: ``slope``. A tensor of type *T* and rank greater or equal to 1. Tensor with negative slope values. **Required.**
+* **Note**: Channels dimension corresponds to the second dimension of ``data`` input tensor. If ``slope`` input rank is 1 and its dimension is equal to the second dimension of ``data`` input, then per channel broadcast is applied. Otherwise ``slope`` input is broadcasted with numpy rules, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`.
 
 **Outputs**
 
-* **1**: The result of element-wise *PReLU* operation applied to `data` input tensor with negative slope values from `slope` input tensor. A tensor of type *T* and the same shape as `data` input tensor.
+* **1**: The result of element-wise *PReLU* operation applied to ``data`` input tensor with negative slope values from ``slope`` input tensor. A tensor of type *T* and the same shape as ``data`` input tensor.
 
 **Types**
 
@@ -46,70 +48,75 @@ PReLU(x) = \max(0, x) + \alpha\cdot\min(0, x)
 
 **Examples**
 
-*Example: 1D input tensor `data`*
+Example: 1D input tensor ``data``
 
-```xml
-<layer ... type="Prelu">
-    <input>
-        <port id="0">
-            <dim>128</dim>
-        </port>
-        <port id="1">
-            <dim>1</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>128</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block::  cpp  
 
-*Example: 2D input tensor `data`*
+    <layer ... type="Prelu">
+        <input>
+            <port id="0">
+                <dim>128</dim>
+            </port>
+            <port id="1">
+                <dim>1</dim>
+            </port>
+        </input>
+        <output>
+            <port id="2">
+                <dim>128</dim>
+            </port>
+        </output>
+    </layer>
 
-```xml
-<layer ... type="Prelu">
-    <input>
-        <port id="0">
-            <dim>20</dim>
-            <dim>128</dim>
-        </port>
-        <port id="1">
-            <dim>128</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>20</dim>
-            <dim>128</dim>
-        </port>
-    </output>
-</layer>
-```
 
-*Example: 4D input tensor `data`*
+Example: 2D input tensor ``data``
+
+.. code-block::  cpp  
+
+    <layer ... type="Prelu">
+        <input>
+            <port id="0">
+                <dim>20</dim>
+                <dim>128</dim>
+            </port>
+            <port id="1">
+                <dim>128</dim>
+            </port>
+        </input>
+        <output>
+            <port id="2">
+                <dim>20</dim>
+                <dim>128</dim>
+            </port>
+        </output>
+    </layer>
+
+Example: 4D input tensor ``data``
+
+.. code-block::  cpp  
+
+    <layer ... type="Prelu">
+        <input>
+            <port id="0">
+                <dim>1</dim>
+                <dim>20</dim>
+                <dim>128</dim>
+                <dim>128</dim>
+            </port>
+            <port id="1">
+                <dim>20</dim>
+            </port>
+        </input>
+        <output>
+            <port id="2">
+                <dim>1</dim>
+                <dim>20</dim>
+                <dim>128</dim>
+                <dim>128</dim>
+            </port>
+        </output>
+    </layer>
+
+@endsphinxdirective
+
 
-```xml
-<layer ... type="Prelu">
-    <input>
-        <port id="0">
-            <dim>1</dim>
-            <dim>20</dim>
-            <dim>128</dim>
-            <dim>128</dim>
-        </port>
-        <port id="1">
-            <dim>20</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>1</dim>
-            <dim>20</dim>
-            <dim>128</dim>
-            <dim>128</dim>
-        </port>
-    </output>
-</layer>
-```

docs/ops/arithmetic/Abs_1.md

@@ -35,7 +35,7 @@ No attributes available.
 
 *Example 1*
 
-.. code-block:: console
+.. code-block:: cpp
     
     <layer ... type="Abs">
         <input>

docs/ops/arithmetic/Acos_1.md

@@ -34,7 +34,7 @@ No attributes available.
 
 *Example 1*
 
-.. code-block:: console
+.. code-block:: cpp
    
    <layer ... type="Acos">
        <input>

docs/ops/arithmetic/Acosh_3.md

@@ -30,7 +30,7 @@
 
 **Examples**
 
-.. code-block:: console
+.. code-block:: cpp
    
    <layer ... type="Acosh">
        <input>

docs/ops/arithmetic/Add_1.md

@@ -49,7 +49,7 @@ After broadcasting *Add* performs addition operation for the input tensors *a* a
 
 *Example 1*
 
-.. code-block:: console
+.. code-block:: cpp
    
    <layer ... type="Add">
        <data auto_broadcast="none"/>

docs/ops/arithmetic/Asin_1.md

@@ -34,7 +34,7 @@ No attributes available.
 
 *Example 1*
 
-.. code-block:: console
+.. code-block:: cpp
    
    <layer ... type="Asin">
        <input>

docs/ops/arithmetic/Asinh_3.md

@@ -30,7 +30,7 @@
 
 **Example**
 
-.. code-block:: console
+.. code-block:: cpp
    
    <layer ... type="Asinh">
        <input>

docs/ops/arithmetic/Atan_1.md

@@ -30,7 +30,7 @@
 
 **Examples**
 
-.. code-block:: console
+.. code-block:: cpp
    
    <layer ... type="Atan">
        <input>

docs/ops/arithmetic/Atanh_3.md

@@ -45,7 +45,7 @@ Unsigned Intragral type put:
 
 **Examples**
 
-.. code-block:: console
+.. code-block:: cpp
    
    <layer ... type="Atanh">
        <input>

docs/ops/arithmetic/Erf_1.md

@@ -1,5 +1,7 @@
 # Erf {#openvino_docs_ops_arithmetic_Erf_1}
 
+@sphinxdirective
+
 **Versioned name**: *Erf-1*
 
 **Category**: *Arithmetic unary*
@@ -10,9 +12,9 @@
 
 *Erf* performs element-wise erf operation on a given input tensor, based on the following mathematical formula:
 
-\f[
-erf(x) = \pi^{-1} \int_{-x}^{x} e^{-t^2} dt
-\f]
+.. math::
+   
+   erf(x) = \pi^{-1} \int_{-x}^{x} e^{-t^2} dt
 
 **Attributes**: *Erf* operation has no attributes.
 
@@ -28,22 +30,24 @@ erf(x) = \pi^{-1} \int_{-x}^{x} e^{-t^2} dt
 
 * *T*: any supported numeric type.
 
-
 **Example**
 
-```xml
-<layer ... type="Erf">
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+   
+   <layer ... type="Erf">
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/arithmetic/Log_1.md

@@ -1,5 +1,7 @@
 # Log  {#openvino_docs_ops_arithmetic_Log_1}
 
+@sphinxdirective
+
 **Versioned name**: *Log-1*
 
 **Category**: *Arithmetic unary*
@@ -8,13 +10,14 @@
 
 **Detailed description**: *Log* does the following with the input tensor *a*:
 
-\f[
-a_{i} = log(a_{i})
-\f]
+.. math::
+
+   a_{i} = log(a_{i})
+
 
 **Attributes**:
 
-    No attributes available.
+No attributes available.
 
 **Inputs**
 
@@ -32,19 +35,22 @@ a_{i} = log(a_{i})
 
 *Example 1*
 
-```xml
-<layer ... type="Log">
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="Log">
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective

docs/ops/arithmetic/Maximum_1.md

@@ -1,5 +1,7 @@
 # Maximum  {#openvino_docs_ops_arithmetic_Maximum_1}
 
+@sphinxdirective
+
 **Versioned name**: *Maximum-1*
 
 **Category**: *Arithmetic binary*
@@ -7,13 +9,14 @@
 **Short description**: *Maximum* performs element-wise maximum operation with two given tensors applying broadcasting rule specified in the *auto_broadcast* attribute.
 
 **Detailed description**
-As a first step input tensors *a* and *b* are broadcasted if their shapes differ. Broadcasting is performed according to `auto_broadcast` attribute specification. As a second step *Maximum* operation is computed element-wise on the input tensors *a* and *b* according to the formula below:
+As a first step input tensors *a* and *b* are broadcasted if their shapes differ. Broadcasting is performed according to ``auto_broadcast`` attribute specification. As a second step *Maximum* operation is computed element-wise on the input tensors *a* and *b* according to the formula below:
 
 After broadcasting *Maximum* does the following with the input tensors *a* and *b*:
 
-\f[
-o_{i} = max(a_{i},\ b_{i})
-\f]
+.. math::
+
+   o_{i} = max(a_{i},\ b_{i})
+
 
 **Attributes**:
 
@@ -21,8 +24,10 @@ o_{i} = max(a_{i},\ b_{i})
 
   * **Description**: specifies rules used for auto-broadcasting of input tensors.
   * **Range of values**:
+
     * *none* - no auto-broadcasting is allowed, all input shapes must match
-    * *numpy* - numpy broadcasting rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md)
+    * *numpy* - numpy broadcasting rules, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`
+
   * **Type**: string
   * **Default value**: "numpy"
   * **Required**: *no*
@@ -44,52 +49,58 @@ o_{i} = max(a_{i},\ b_{i})
 
 *Example 1 - no broadcasting*
 
-```xml
-<layer ... type="Maximum">
-    <data auto_broadcast="none"/>
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="Maximum">
+       <data auto_broadcast="none"/>
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
 
 *Example 2: numpy broadcasting*
-```xml
-<layer ... type="Maximum">
-    <data auto_broadcast="numpy"/>
-    <input>
-        <port id="0">
-            <dim>8</dim>
-            <dim>1</dim>
-            <dim>6</dim>
-            <dim>1</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>1</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>8</dim>
-            <dim>7</dim>
-            <dim>6</dim>
-            <dim>5</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block:: cpp
+
+   <layer ... type="Maximum">
+       <data auto_broadcast="numpy"/>
+       <input>
+           <port id="0">
+               <dim>8</dim>
+               <dim>1</dim>
+               <dim>6</dim>
+               <dim>1</dim>
+           </port>
+           <port id="1">
+               <dim>7</dim>
+               <dim>1</dim>
+               <dim>5</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>8</dim>
+               <dim>7</dim>
+               <dim>6</dim>
+               <dim>5</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective
+

docs/ops/arithmetic/Minimum_1.md

@@ -1,5 +1,7 @@
 # Minimum  {#openvino_docs_ops_arithmetic_Minimum_1}
 
+@sphinxdirective
+
 **Versioned name**: *Minimum-1*
 
 **Category**: *Arithmetic binary*
@@ -7,11 +9,12 @@
 **Short description**: *Minimum* performs element-wise minimum operation with two given tensors applying broadcasting rule specified in the *auto_broadcast* attribute.
 
 **Detailed description**
-As a first step input tensors *a* and *b* are broadcasted if their shapes differ. Broadcasting is performed according to `auto_broadcast` attribute specification. As a second step *Minimum* operation is computed element-wise on the input tensors *a* and *b* according to the formula below:
+As a first step input tensors *a* and *b* are broadcasted if their shapes differ. Broadcasting is performed according to ``auto_broadcast`` attribute specification. As a second step *Minimum* operation is computed element-wise on the input tensors *a* and *b* according to the formula below:
+
+.. math::
+
+   o_{i} = min(a_{i},\ b_{i})
 
-\f[
-o_{i} = min(a_{i},\ b_{i})
-\f]
 
 **Attributes**:
 
@@ -19,8 +22,10 @@ o_{i} = min(a_{i},\ b_{i})
 
   * **Description**: specifies rules used for auto-broadcasting of input tensors.
   * **Range of values**:
+
     * *none* - no auto-broadcasting is allowed, all input shapes must match
-    * *numpy* - numpy broadcasting rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md)
+    * *numpy* - numpy broadcasting rules, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`
+
   * **Type**: string
   * **Default value**: "numpy"
   * **Required**: *no*
@@ -42,52 +47,58 @@ o_{i} = min(a_{i},\ b_{i})
 
 *Example 1 - no broadcasting*
 
-```xml
-<layer ... type="Minimum">
-    <data auto_broadcast="none"/>
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="Minimum">
+       <data auto_broadcast="none"/>
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
 
 *Example 2: numpy broadcasting*
-```xml
-<layer ... type="Minimum">
-    <data auto_broadcast="numpy"/>
-    <input>
-        <port id="0">
-            <dim>8</dim>
-            <dim>1</dim>
-            <dim>6</dim>
-            <dim>1</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>1</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>8</dim>
-            <dim>7</dim>
-            <dim>6</dim>
-            <dim>5</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block:: cpp
+
+   <layer ... type="Minimum">
+       <data auto_broadcast="numpy"/>
+       <input>
+           <port id="0">
+               <dim>8</dim>
+               <dim>1</dim>
+               <dim>6</dim>
+               <dim>1</dim>
+           </port>
+           <port id="1">
+               <dim>7</dim>
+               <dim>1</dim>
+               <dim>5</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>8</dim>
+               <dim>7</dim>
+               <dim>6</dim>
+               <dim>5</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective
+

docs/ops/arithmetic/Mod_1.md

@@ -1,5 +1,7 @@
 # Mod  {#openvino_docs_ops_arithmetic_Mod_1}
 
+@sphinxdirective
+
 **Versioned name**: *Mod-1*
 
 **Category**: *Arithmetic binary*
@@ -7,13 +9,14 @@
 **Short description**: *Mod* performs an element-wise modulo operation with two given tensors applying broadcasting rule specified in the *auto_broadcast* attribute.
 
 **Detailed description**
-As a first step input tensors *a* and *b* are broadcasted if their shapes differ. Broadcasting is performed according to `auto_broadcast` attribute specification. As a second step *Mod* operation is computed element-wise on the input tensors *a* and *b* according to the formula below:
+As a first step input tensors *a* and *b* are broadcasted if their shapes differ. Broadcasting is performed according to ``auto_broadcast`` attribute specification. As a second step *Mod* operation is computed element-wise on the input tensors *a* and *b* according to the formula below:
 
-\f[
-o_{i} = a_{i} \mod b_{i}
-\f]
+.. math::
 
-*Mod* operation computes a reminder of a truncated division. It is the same behaviour like in C programming language: `truncated(x / y) * y + truncated_mod(x, y) = x`. The sign of the result is equal to a sign of a dividend. The result of division by zero is undefined.
+   o_{i} = a_{i} \mod b_{i}
+
+
+*Mod* operation computes a reminder of a truncated division. It is the same behavior like in C programming language: ``truncated(x / y) * y + truncated_mod(x, y) = x``. The sign of the result is equal to a sign of a dividend. The result of division by zero is undefined.
 
 **Attributes**:
 
@@ -21,8 +24,10 @@ o_{i} = a_{i} \mod b_{i}
 
   * **Description**: specifies rules used for auto-broadcasting of input tensors.
   * **Range of values**:
+
     * *none* - no auto-broadcasting is allowed, all input shapes must match
-    * *numpy* - numpy broadcasting rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md)
+    * *numpy* - numpy broadcasting rules, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`
+
   * **Type**: string
   * **Default value**: "numpy"
   * **Required**: *no*
@@ -45,52 +50,57 @@ o_{i} = a_{i} \mod b_{i}
 
 *Example 1 - no broadcasting*
 
-```xml
-<layer ... type="Mod">
-    <data auto_broadcast="none"/>
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="Mod">
+       <data auto_broadcast="none"/>
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
 
 *Example 2: numpy broadcasting*
-```xml
-<layer ... type="Mod">
-    <data auto_broadcast="numpy"/>
-    <input>
-        <port id="0">
-            <dim>8</dim>
-            <dim>1</dim>
-            <dim>6</dim>
-            <dim>1</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>1</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>8</dim>
-            <dim>7</dim>
-            <dim>6</dim>
-            <dim>5</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block:: cpp
+
+   <layer ... type="Mod">
+       <data auto_broadcast="numpy"/>
+       <input>
+           <port id="0">
+               <dim>8</dim>
+               <dim>1</dim>
+               <dim>6</dim>
+               <dim>1</dim>
+           </port>
+           <port id="1">
+               <dim>7</dim>
+               <dim>1</dim>
+               <dim>5</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>8</dim>
+               <dim>7</dim>
+               <dim>6</dim>
+               <dim>5</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective

docs/ops/arithmetic/Multiply_1.md

@@ -1,5 +1,7 @@
 # Multiply {#openvino_docs_ops_arithmetic_Multiply_1}
 
+@sphinxdirective
+
 **Versioned name**: *Multiply-1*
 
 **Category**: *Arithmetic binary*
@@ -7,12 +9,13 @@
 **Short description**: *Multiply* performs element-wise multiplication operation with two given tensors applying broadcasting rule specified in the *auto_broacast* attribute.
 
 **Detailed description**
-Before performing arithmetic operation, input tensors *a* and *b* are broadcasted if their shapes are different and `auto_broadcast` attribute is not `none`. Broadcasting is performed according to `auto_broadcast` value.
+Before performing arithmetic operation, input tensors *a* and *b* are broadcasted if their shapes are different and ``auto_broadcast`` attribute is not ``none``. Broadcasting is performed according to ``auto_broadcast`` value.
 After broadcasting *Multiply* performs multiplication operation for the input tensors *a* and *b* using the formula below:
 
-\f[
-o_{i} = a_{i} \cdot b_{i}
-\f]
+.. math::
+
+   o_{i} = a_{i} \cdot b_{i}
+
 
 **Attributes**:
 
@@ -20,9 +23,11 @@ o_{i} = a_{i} \cdot b_{i}
 
   * **Description**: specifies rules used for auto-broadcasting of input tensors.
   * **Range of values**:
+
     * *none* - no auto-broadcasting is allowed, all input shapes must match,
-    * *numpy* - numpy broadcasting rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md),
-    * *pdpd* - PaddlePaddle-style implicit broadcasting, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md).
+    * *numpy* - numpy broadcasting rules, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`,
+    * *pdpd* - PaddlePaddle-style implicit broadcasting, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`.
+
   * **Type**: string
   * **Default value**: "numpy"
   * **Required**: *no*
@@ -45,52 +50,58 @@ o_{i} = a_{i} \cdot b_{i}
 
 *Example 1*
 
-```xml
-<layer ... type="Multiply">
-    <data auto_broadcast="none"/>
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="Multiply">
+       <data auto_broadcast="none"/>
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
 
 *Example 2: broadcast*
-```xml
-<layer ... type="Multiply">
-    <data auto_broadcast="numpy"/>
-    <input>
-        <port id="0">
-            <dim>8</dim>
-            <dim>1</dim>
-            <dim>6</dim>
-            <dim>1</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>1</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>8</dim>
-            <dim>7</dim>
-            <dim>6</dim>
-            <dim>5</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block:: cpp
+
+   <layer ... type="Multiply">
+       <data auto_broadcast="numpy"/>
+       <input>
+           <port id="0">
+               <dim>8</dim>
+               <dim>1</dim>
+               <dim>6</dim>
+               <dim>1</dim>
+           </port>
+           <port id="1">
+               <dim>7</dim>
+               <dim>1</dim>
+               <dim>5</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>8</dim>
+               <dim>7</dim>
+               <dim>6</dim>
+               <dim>5</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective
+

docs/ops/arithmetic/Negative_1.md

@@ -1,5 +1,7 @@
 # Negative  {#openvino_docs_ops_arithmetic_Negative_1}
 
+@sphinxdirective
+
 **Versioned name**: *Negative-1*
 
 **Category**: *Arithmetic unary*
@@ -10,9 +12,9 @@
 
 *Negative* performs element-wise negative operation on a given input tensor, based on the following mathematical formula:
 
-\f[
-a_{i} = -a_{i}
-\f]
+.. math::
+
+	a_{i} = -a_{i}
 
 **Attributes**: *Negative* operation has no attributes.
 
@@ -30,19 +32,21 @@ a_{i} = -a_{i}
 
 **Example**
 
-```xml
-<layer ... type="Negative">
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block::  cpp 
+
+    <layer ... type="Negative">
+        <input>
+            <port id="0">
+                <dim>256</dim>
+                <dim>56</dim>
+            </port>
+        </input>
+        <output>
+            <port id="1">
+                <dim>256</dim>
+                <dim>56</dim>
+            </port>
+        </output>
+    </layer>
+
+@endsphinxdirective

docs/ops/arithmetic/Power_1.md

@@ -1,5 +1,8 @@
 # Power  {#openvino_docs_ops_arithmetic_Power_1}
 
+@sphinxdirective
+
+
 **Versioned name**: *Power-1*
 
 **Category**: *Arithmetic binary*
@@ -9,9 +12,9 @@
 **Detailed description**
 As a first step input tensors *a* and *b* are broadcasted if their shapes differ. Broadcasting is performed according to `auto_broadcast` attribute specification. As a second step *Power* operation is computed element-wise on the input tensors *a* and *b* according to the formula below:
 
-\f[
-o_{i} = {a_{i} ^ b_{i}}
-\f]
+.. math::
+
+    o_i = a_i^{b_i}
 
 **Attributes**:
 
@@ -19,8 +22,9 @@ o_{i} = {a_{i} ^ b_{i}}
 
   * **Description**: specifies rules used for auto-broadcasting of input tensors.
   * **Range of values**:
+
     * *none* - no auto-broadcasting is allowed, all input shapes must match
-    * *numpy* - numpy broadcasting rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md)
+    * *numpy* - numpy broadcasting rules, description is available in   description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`
   * **Type**: string
   * **Default value**: "numpy"
   * **Required**: *no*
@@ -43,52 +47,58 @@ o_{i} = {a_{i} ^ b_{i}}
 
 *Example 1 - no broadcasting*
 
-```xml
-<layer ... type="Power">
-    <data auto_broadcast="none"/>
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block::  cpp   
+
+    <layer ... type="Power">
+        <data auto_broadcast="none"/>
+        <input>
+            <port id="0">
+                <dim>256</dim>
+                <dim>56</dim>
+            </port>
+            <port id="1">
+                <dim>256</dim>
+                <dim>56</dim>
+            </port>
+        </input>
+        <output>
+            <port id="2">
+                <dim>256</dim>
+                <dim>56</dim>
+            </port>
+        </output>
+    </layer>
+
 
 *Example 2: numpy broadcasting*
-```xml
-<layer ... type="Power">
-    <data auto_broadcast="numpy"/>
-    <input>
-        <port id="0">
-            <dim>8</dim>
-            <dim>1</dim>
-            <dim>6</dim>
-            <dim>1</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>1</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>8</dim>
-            <dim>7</dim>
-            <dim>6</dim>
-            <dim>5</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block::  cpp  
+
+    <layer ... type="Power">
+        <data auto_broadcast="numpy"/>
+        <input>
+            <port id="0">
+                <dim>8</dim>
+                <dim>1</dim>
+                <dim>6</dim>
+                <dim>1</dim>
+            </port>
+            <port id="1">
+                <dim>7</dim>
+                <dim>1</dim>
+                <dim>5</dim>
+            </port>
+        </input>
+        <output>
+            <port id="2">
+                <dim>8</dim>
+                <dim>7</dim>
+                <dim>6</dim>
+                <dim>5</dim>
+            </port>
+        </output>
+    </layer>
+
+@endsphinxdirective
+
+

docs/ops/comparison/Equal_1.md

@@ -1,4 +1,6 @@
-# Equal  {#openvino_docs_ops_comparison_Equal_1}
+# Equal {#openvino_docs_ops_comparison_Equal_1}
+
+@sphinxdirective
 
 **Versioned name**: *Equal-1*
 
@@ -11,9 +13,9 @@ Before performing arithmetic operation, input tensors *a* and *b* are broadcaste
 
 After broadcasting *Equal* does the following with the input tensors *a* and *b*:
 
-\f[
-o_{i} = a_{i} == b_{i}
-\f]
+.. math::
+   
+   o_{i} = a_{i} == b_{i}
 
 **Attributes**:
 
@@ -21,10 +23,11 @@ o_{i} = a_{i} == b_{i}
 
   * **Description**: specifies rules used for auto-broadcasting of input tensors.
   * **Range of values**:
+    
     * *none* - no auto-broadcasting is allowed, all input shapes should match,
-    * *numpy* - numpy broadcasting rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md),
-    * *pdpd* - PaddlePaddle-style implicit broadcasting, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md).
-  * **Type**: string
+    * *numpy* - numpy broadcasting rules, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`,
+    * *pdpd* - PaddlePaddle-style implicit broadcasting, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`.
+  * **Type**: ``string``
   * **Default value**: "numpy"
   * **Required**: *no*
 
@@ -40,58 +43,62 @@ o_{i} = a_{i} == b_{i}
 **Types**
 
 * *T*: arbitrary supported type.
-* *T_BOOL*: `boolean`.
+* *T_BOOL*: ``boolean``.
 
 **Examples**
 
 *Example 1: no broadcast*
 
-```xml
-<layer ... type="Equal">
-    <data auto_broadcast="none"/>
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+   
+   <layer ... type="Equal">
+       <data auto_broadcast="none"/>
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
 
 *Example 2: numpy broadcast*
-```xml
-<layer ... type="Equal">
-    <data auto_broadcast="numpy"/>
-    <input>
-        <port id="0">
-            <dim>8</dim>
-            <dim>1</dim>
-            <dim>6</dim>
-            <dim>1</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>1</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>8</dim>
-            <dim>7</dim>
-            <dim>6</dim>
-            <dim>5</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block:: cpp
+   
+   <layer ... type="Equal">
+       <data auto_broadcast="numpy"/>
+       <input>
+           <port id="0">
+               <dim>8</dim>
+               <dim>1</dim>
+               <dim>6</dim>
+               <dim>1</dim>
+           </port>
+           <port id="1">
+               <dim>7</dim>
+               <dim>1</dim>
+               <dim>5</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>8</dim>
+               <dim>7</dim>
+               <dim>6</dim>
+               <dim>5</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/comparison/IsFinite_10.md

@@ -1,21 +1,23 @@
 # IsFinite {#openvino_docs_ops_comparison_IsFinite_10}
 
+@sphinxdirective
+
 **Versioned name**: *IsFinite-10*
 
 **Category**: *Comparison*
 
 **Short description**: *IsFinite* performs element-wise test for finiteness (not Infinity and not NaN) on elements of a given input tensor. It returns the boolean mask of a given tensor which maps
-`NaN` and `Infinity` to `False` and all other values to `True`
+``NaN`` and ``Infinity`` to ``False`` and all other values to ``True``
 *IsFinite* operation has no attributes.
 
-**Detailed description**: *IsFinite* returns the boolean mask of the input tensor in which `False` corresponds to `NaN` and `Infinity` and `True` to all other values.
+**Detailed description**: *IsFinite* returns the boolean mask of the input tensor in which ``False`` corresponds to ``NaN`` and ``Infinity`` and ``True`` to all other values.
 * The output tensor has the same shape as the input tensor.
-* The `i`'th element of the output tensor is `False` if `i`'th element of the input tensor is `NaN` or `Inf`. Otherwise, it is `True`.
-* For example, for a given input tensor `[NaN, 2.1, 3.7, Inf]` the output tensor is `[False, True, True, False]`.
+* The ``i``'th element of the output tensor is ``False`` if ``i``'th element of the input tensor is ``NaN`` or ``Inf``. Otherwise, it is ``True``.
+* For example, for a given input tensor ``[NaN, 2.1, 3.7, Inf]`` the output tensor is ``[False, True, True, False]``.
 
 **Attributes**
 
-    *IsFinite* operation has no attributes.
+*IsFinite* operation has no attributes.
 
 **Inputs**
 
@@ -23,7 +25,7 @@
 
 **Outputs**
 
-* **1**: The result of element-wise *IsFinite* operation. A tensor of type `boolean` and the same shape as input tensor.
+* **1**: The result of element-wise *IsFinite* operation. A tensor of type ``boolean`` and the same shape as input tensor.
 
 **Types**
 
@@ -31,34 +33,39 @@
 
 **Examples**
 
-```xml
-<layer ... type="IsFinite">
-    <input>
-        <port id="0" precision="FP32">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="1" precision="BOOL">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="IsFinite">
+       <input>
+           <port id="0" precision="FP32">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="1" precision="BOOL">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
+
+.. code-block:: cpp
+
+   <layer ... type="IsFinite">
+       <input>
+           <port id="0" precision="FP32">
+               <dim>4</dim> < !-- Input value is: [NaN, 2.1, 3.7, Inf] -->
+           </port>
+       </input>
+       <output>
+           <port id="1" precision="BOOL">
+               <dim>4</dim> < !-- Output value is: [False, True, True, False] -->
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective
 
-```xml
-<layer ... type="IsFinite">
-    <input>
-        <port id="0" precision="FP32">
-            <dim>4</dim>                <!-- Input value is: [NaN, 2.1, 3.7, Inf] -->
-        </port>
-    </input>
-    <output>
-        <port id="1" precision="BOOL">
-            <dim>4</dim>                <!-- Output value is: [False, True, True, False] -->
-        </port>
-    </output>
-</layer>
-```

docs/ops/comparison/IsInf_10.md

@@ -1,12 +1,14 @@
 # IsInf {#openvino_docs_ops_comparison_IsInf_10}
 
+@sphinxdirective
+
 **Versioned name**: *IsInf-10*
 
 **Category**: *Comparison*
 
 **Short description**: *IsInf* performs element-wise mapping of infinite values to True.
 
-**Detailed description**: *IsInf* performs element-wise mapping of infinite values to true and other values to false. Attributes `detect_negative` and `detect_positive` can be used to control the mapping of negative and positive infinities. Setting both `detect_negative` and `detect_positive` to false will map all values to false.
+**Detailed description**: *IsInf* performs element-wise mapping of infinite values to true and other values to false. Attributes ``detect_negative`` and ``detect_positive`` can be used to control the mapping of negative and positive infinities. Setting both ``detect_negative`` and ``detect_positive`` to false will map all values to false.
 
 **Attributes**
 
@@ -14,29 +16,29 @@
 
   * **Description**: specifies rules used for mapping values with negative infinity.
   * **Range of values**:
-    * `false` - map negative infinity to `false`
-    * `true` - map negative infinity to `true`
-  * **Type**: `boolean`
-  * **Default value**: `true`
+    * ``false`` - map negative infinity to ``false``
+    * ``true`` - map negative infinity to ``true``
+  * **Type**: ``boolean``
+  * **Default value**: ``true``
   * **Required**: *no*
 
 * *detect_positive*
 
   * **Description**: specifies rules used for mapping values with positive infinity.
   * **Range of values**:
-    * `false` - map positive infinity to `false`
-    * `true` - map positive infinity to `true`
-  * **Type**: `boolean`
-  * **Default value**: `true`
+    * ``false`` - map positive infinity to ``false``
+    * ``true`` - map positive infinity to ``true``
+  * **Type**: ``boolean``
+  * **Default value**: ``true``
   * **Required**: *no*
 
 **Inputs**
 
-* **1**: `data` - Input tensor of type `T_IN` with data and arbitrary shape. **Required.**
+* **1**: ``data`` - Input tensor of type ``T_IN`` with data and arbitrary shape. **Required.**
 
 **Outputs**
 
-* **1**: The result of the element-wise mapping of infinite values applied to the input tensor. A tensor of the `boolean` type and shape equal to the input tensor.
+* **1**: The result of the element-wise mapping of infinite values applied to the input tensor. A tensor of the ``boolean`` type and shape equal to the input tensor.
 
 **Types**
 
@@ -44,20 +46,24 @@
 
 **Example**
 
-```xml
-<layer ... type="IsInf" ...>
-    <data detect_negative="true" detect_positive="true"/>
-    <input>
-        <port id="0" precision="FP32">
-            <dim>256</dim>
-            <dim>128</dim>
-        </port>
-    </input>
-    <output>
-        <port id="0" precision="BOOL">
-            <dim>256</dim>
-            <dim>128</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="IsInf" ...>
+       <data detect_negative="true" detect_positive="true"/>
+       <input>
+           <port id="0" precision="FP32">
+               <dim>256</dim>
+               <dim>128</dim>
+           </port>
+       </input>
+       <output>
+           <port id="0" precision="BOOL">
+               <dim>256</dim>
+               <dim>128</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective
+

docs/ops/comparison/IsNaN_10.md

@@ -1,27 +1,29 @@
 # IsNaN {#openvino_docs_ops_comparison_IsNaN_10}
 
+@sphinxdirective
+
 **Versioned name**: *IsNaN-10*
 
 **Category**: *Comparison*
 
-**Short description**: *IsNaN* returns the boolean mask of a given tensor which maps `NaN` to `True`.
+**Short description**: *IsNaN* returns the boolean mask of a given tensor which maps ``NaN`` to ``True``.
 
-**Detailed description**: *IsNaN* returns the boolean mask of the input tensor in which `True` corresponds to `NaN` and `False` to other values.
+**Detailed description**: *IsNaN* returns the boolean mask of the input tensor in which ``True`` corresponds to ``NaN`` and ``False`` to other values.
 The output tensor has the same shape as the input tensor.
-The `i`'th element of the output tensor is `True` if  `i`'th element of the input tensor is `NaN`. Otherwise, it is `False`.
-For example, for the given input tensor `[NaN, 2.1, 3.7, NaN, Inf]` the output tensor is `[True, False, False, True, False]`.
+The ``i``'th element of the output tensor is ``True`` if  ``i``'th element of the input tensor is ``NaN``. Otherwise, it is ``False``.
+For example, for the given input tensor ``[NaN, 2.1, 3.7, NaN, Inf]`` the output tensor is ``[True, False, False, True, False]``.
 
 **Attributes**
 
-    *IsNaN* operation has no attributes.
+*IsNaN* operation has no attributes.
 
 **Inputs**:
 
-*   **1**: A tensor of type *T_IN* and arbitrary shape. **Required.**
+* **1**: A tensor of type *T_IN* and arbitrary shape. **Required.**
 
 **Outputs**:
 
-*   **1**: A `boolean` tensor of the same shape as the input tensor.
+* **1**: A ``boolean`` tensor of the same shape as the input tensor.
 
 **Types**
 
@@ -29,19 +31,22 @@ For example, for the given input tensor `[NaN, 2.1, 3.7, NaN, Inf]` the output t
 
 **Example**
 
-```xml
-<layer ... type="IsNaN">
-    <input>
-        <port id="0" precision="FP32">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-     </input>
-    <output>
-        <port id="1" precision="BOOL">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="IsNaN">
+       <input>
+           <port id="0" precision="FP32">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+        </input>
+       <output>
+           <port id="1" precision="BOOL">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective

docs/ops/comparison/LessEqual_1.md

@@ -1,5 +1,7 @@
 # LessEqual {#openvino_docs_ops_comparison_LessEqual_1}
 
+@sphinxdirective
+
 **Versioned name**: *LessEqual-1*
 
 **Category**: *Comparison binary*
@@ -7,13 +9,14 @@
 **Short description**: *LessEqual* performs element-wise comparison operation with two given tensors applying broadcast rules specified in the *auto_broadcast* attribute.
 
 **Detailed description**
-Before performing arithmetic operation, input tensors *a* and *b* are broadcasted if their shapes are different and `auto_broadcast` attributes is not `none`. Broadcasting is performed according to `auto_broadcast` value.
+Before performing arithmetic operation, input tensors *a* and *b* are broadcasted if their shapes are different and ``auto_broadcast`` attributes is not ``none``. Broadcasting is performed according to ``auto_broadcast`` value.
 
 After broadcasting *LessEqual* does the following with the input tensors *a* and *b*:
 
-\f[
-o_{i} = a_{i} \leq b_{i}
-\f]
+.. math::
+
+   o_{i} = a_{i} \leq b_{i}
+
 
 **Attributes**:
 
@@ -21,9 +24,11 @@ o_{i} = a_{i} \leq b_{i}
 
   * **Description**: specifies rules used for auto-broadcasting of input tensors.
   * **Range of values**:
+
     * *none* - no auto-broadcasting is allowed, all input shapes should match,
-    * *numpy* -  numpy broadcasting rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md),
-    * *pdpd* - PaddlePaddle-style implicit broadcasting, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md).
+    * *numpy* -  numpy broadcasting rules, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`,
+    * *pdpd* - PaddlePaddle-style implicit broadcasting, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`.
+
   * **Type**: string
   * **Default value**: "numpy"
   * **Required**: *no*
@@ -45,52 +50,57 @@ o_{i} = a_{i} \leq b_{i}
 
 *Example 1: no broadcast*
 
-```xml
-<layer ... type="LessEqual">
-    <data auto_broadcast="none"/>
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="LessEqual">
+       <data auto_broadcast="none"/>
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
 
 *Example 2: numpy broadcast*
-```xml
-<layer ... type="LessEqual">
-    <data auto_broadcast="numpy"/>
-    <input>
-        <port id="0">
-            <dim>8</dim>
-            <dim>1</dim>
-            <dim>6</dim>
-            <dim>1</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>1</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>8</dim>
-            <dim>7</dim>
-            <dim>6</dim>
-            <dim>5</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block:: cpp
+
+   <layer ... type="LessEqual">
+       <data auto_broadcast="numpy"/>
+       <input>
+           <port id="0">
+               <dim>8</dim>
+               <dim>1</dim>
+               <dim>6</dim>
+               <dim>1</dim>
+           </port>
+           <port id="1">
+               <dim>7</dim>
+               <dim>1</dim>
+               <dim>5</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>8</dim>
+               <dim>7</dim>
+               <dim>6</dim>
+               <dim>5</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective

docs/ops/comparison/Less_1.md

@@ -1,5 +1,7 @@
 # Less {#openvino_docs_ops_comparison_Less_1}
 
+@sphinxdirective
+
 **Versioned name**: *Less-1*
 
 **Category**: *Comparison binary*
@@ -7,13 +9,13 @@
 **Short description**: *Less* performs element-wise comparison operation with two given tensors applying multi-directional broadcast rules.
 
 **Detailed description**
-Before performing arithmetic operation, input tensors *a* and *b* are broadcasted if their shapes are different and `auto_broadcast` attributes is not `none`. Broadcasting is performed according to `auto_broadcast` value.
+Before performing arithmetic operation, input tensors *a* and *b* are broadcasted if their shapes are different and ``auto_broadcast`` attributes is not ``none``. Broadcasting is performed according to ``auto_broadcast`` value.
 
 After broadcasting *Less* does the following with the input tensors *a* and *b*:
 
-\f[
-o_{i} = a_{i} < b_{i}
-\f]
+.. math::
+
+   o_{i} = a_{i} < b_{i}
 
 
 **Attributes**:
@@ -22,10 +24,12 @@ o_{i} = a_{i} < b_{i}
 
   * **Description**: specifies rules used for auto-broadcasting of input tensors.
   * **Range of values**:
+
     * *none* - no auto-broadcasting is allowed, all input shapes should match
-    * *numpy* - numpy broadcasting rules, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md)
-    * *pdpd* - PaddlePaddle-style implicit broadcasting, description is available in [Broadcast Rules For Elementwise Operations](../broadcast_rules.md)
-  * **Type**: `string`
+    * *numpy* - numpy broadcasting rules, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`
+    * *pdpd* - PaddlePaddle-style implicit broadcasting, description is available in :doc:`Broadcast Rules For Elementwise Operations <openvino_docs_ops_broadcast_rules>`
+
+  * **Type**: ``string``
   * **Default value**: "numpy"
   * **Required**: *no*
 
@@ -46,50 +50,56 @@ o_{i} = a_{i} < b_{i}
 
 *Example 1*
 
-```xml
-<layer ... type="Less">
-    <input>
-        <port id="0">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-        <port id="1">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>256</dim>
-            <dim>56</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+
+   <layer ... type="Less">
+       <input>
+           <port id="0">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+           <port id="1">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>256</dim>
+               <dim>56</dim>
+           </port>
+       </output>
+   </layer>
+
 
 *Example 2: broadcast*
-```xml
-<layer ... type="Less">
-    <input>
-        <port id="0">
-            <dim>8</dim>
-            <dim>1</dim>
-            <dim>6</dim>
-            <dim>1</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>1</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>8</dim>
-            <dim>7</dim>
-            <dim>6</dim>
-            <dim>5</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block:: cpp
+
+   <layer ... type="Less">
+       <input>
+           <port id="0">
+               <dim>8</dim>
+               <dim>1</dim>
+               <dim>6</dim>
+               <dim>1</dim>
+           </port>
+           <port id="1">
+               <dim>7</dim>
+               <dim>1</dim>
+               <dim>5</dim>
+           </port>
+       </input>
+       <output>
+           <port id="2">
+               <dim>8</dim>
+               <dim>7</dim>
+               <dim>6</dim>
+               <dim>5</dim>
+           </port>
+       </output>
+   </layer>
+
+
+@endsphinxdirective
+

docs/ops/condition/If_8.md

@@ -1,65 +1,70 @@
 ## If {#openvino_docs_ops_infrastructure_If_8}
 
+@sphinxdirective
+
 **Versioned name**: *If-8*
 
 **Category**: *Condition*
 
-**Short description**: *If* operation contains two internal networks(subgraphs) such as `then_body` and `else_body`, 
-and performs one of them depending on `cond` value. If `cond` is  `True`, `then_body` is executed. If `cond` is  `False`, 
-the operation executes the `else_body` subgraph. 
+**Short description**: *If* operation contains two internal networks(subgraphs) such as ``then_body`` and ``else_body``, 
+and performs one of them depending on ``cond`` value. If ``cond`` is  ``True``, ``then_body`` is executed. If ``cond`` is  ``False``, 
+the operation executes the ``else_body`` subgraph. 
 
 **Detailed description**
 
-*If* must not contain empty subgraphs. Each of them must have at least one operation `Result`. 
+*If* must not contain empty subgraphs. Each of them must have at least one operation ``Result``. 
 Also the number of outputs from *If* always must be greater than zero and equal to the number of outputs from each subgraph.
 
 **If attributes**:
 
 * **Subgraphs**:
 
-    `then_body`/`else_body` are subgraphs that are executed depending on the `cond` value. 
-    The subgraph is described operation by operation as a typical IR network. 
-    The subgraph has inputs (`Parameter` operations) and outputs (`Result` operations).
-    
-    * **Subgraph's inputs** - inputs to the subgraph which associated with *If* inputs via *port_map*. 
+  ``then_body``/``else_body`` are subgraphs that are executed depending on the ``cond`` value. 
+  The subgraph is described operation by operation as a typical IR network. 
+  The subgraph has inputs (``Parameter`` operations) and outputs (``Result`` operations).
+
+  * **Subgraph's inputs** - inputs to the subgraph which associated with *If* inputs via *port_map*. 
+
     The subgraph can have any number of inputs (even zero).
-    
-    * **Subgraph's outputs** - outputs from the subgraph which associated with *If* outputs via *port_map*.
+
+  * **Subgraph's outputs** - outputs from the subgraph which associated with *If* outputs via *port_map*.
+
     The subgraph must contain at least one output. Each *If* output is associated with one output from the subgraph. 
-    Therefore the number of `then_body` outputs is equal to the number of outputs from *If* and 
-    the number of `else_body` outputs.
+    Therefore the number of ``then_body`` outputs is equal to the number of outputs from *If* and 
+    the number of ``else_body`` outputs.
     The type of the subgraph output and the type of the associated output from *If* must be equal.
-    
+
 
 * **Port maps**:
-    
-    *port_map* is a set of rules to map input or output data tensors of *If* operation onto the subgraph data tensors. 
-    The `port_map` entries can be `input` and `output`. Each entry describes a corresponding mapping rule. 
-    *If* has two *port_maps*: `then_port_map` for `then_body` and `else_port_map` for `else_body`.
 
-    * **Port map attributes**:
+  *port_map* is a set of rules to map input or output data tensors of *If* operation onto the subgraph data tensors. 
+  The ``port_map`` entries can be ``input`` and ``output``. Each entry describes a corresponding mapping rule. 
+  *If* has two *port_maps*: ``then_port_map`` for ``then_body`` and ``else_port_map`` for ``else_body``.
 
-        * *external_port_id*
-            * **Description**: *external_port_id* is a port ID of *If* operation.
-            * **Range of values**: IDs of the *If* inputs and outputs
-            * **Type**: `unsigned int`
-            * **Default value**: None
-            * **Required**: *yes*
+  * **Port map attributes**:
 
-        * *internal_layer_id*
+    * *external_port_id*
 
-            * **Description**: *internal_layer_id* is a `Parameter` or `Result` operation ID inside 
-            the subgraph to map to.
-            * **Range of values**: IDs of the `Parameter` or `Result` operations in the subgraph
-            * **Type**: `unsigned int`
-            * **Default value**: None
-            * **Required**: *yes* 
+      * **Description**: *external_port_id* is a port ID of *If* operation.
+      * **Range of values**: IDs of the *If* inputs and outputs
+      * **Type**: ``unsigned int``
+      * **Default value**: None
+      * **Required**: *yes*
+
+    * *internal_layer_id*
+
+      * **Description**: *internal_layer_id* is a ``Parameter`` or ``Result`` operation ID inside 
+      the subgraph to map to.
+      * **Range of values**: IDs of the ``Parameter`` or ``Result`` operations in the subgraph
+      * **Type**: ``unsigned int``
+      * **Default value**: None
+      * **Required**: *yes* 
 
 **If Inputs**
 
 
-* **cond**: A scalar or 1D tensor with 1 element of `boolean` type specifying which subgraph to execute. 
-`True` value means to execute the `then_body`, `False` - `else_body`. *Required*.
+* **cond**: A scalar or 1D tensor with 1 element of ``boolean`` type specifying which subgraph to execute. 
+``True`` value means to execute the ``then_body``, ``False`` - ``else_body``. *Required*.
 
 * **Multiple other inputs**: Tensors of different types and shapes. *Optional*.
 
@@ -81,146 +86,152 @@ Also the number of outputs from *If* always must be greater than zero and equal
 **Examples**
 
 *Example 1: a typical If structure*
-```xml
-    <layer id="6" name="if/cond" type="If" version="opset8">
-        <input>
-            <port id="0"/>
-            <port id="1">
-                <dim>2</dim>
-                <dim>4</dim>
-            </port>
-            <port id="2">
-                <dim>2</dim>
-                <dim>4</dim>
-            </port>
-            <port id="3">
-                <dim>2</dim>
-                <dim>4</dim>
-            </port>
-        </input>
-        <output>
-            <port id="4" names="if/cond/Identity:0,if/cond:0" precision="FP32">
-                <dim>2</dim>
-                <dim>4</dim>
-            </port>
-        </output>
-        <then_port_map>
-            <input external_port_id="1" internal_layer_id="0"/>
-            <input external_port_id="2" internal_layer_id="1"/>
-            <output external_port_id="0" internal_layer_id="3"/>
-        </then_port_map>
-        <else_port_map>
-            <input external_port_id="1" internal_layer_id="0"/>
-            <input external_port_id="3" internal_layer_id="1"/>
-            <output external_port_id="0" internal_layer_id="3"/>
-        </else_port_map>
-        <then_body>
-            <layers>
-                <layer id="0" name="add_x" type="Parameter" version="opset1">
-                    <data element_type="f32" shape="2,4"/>
-                    <output>
-                        <port id="0" names="add_x:0" precision="FP32">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </output>
-                </layer>
-                <layer id="1" name="add_z" type="Parameter" version="opset1">
-                    <data element_type="f32" shape="2,4"/>
-                    <output>
-                        <port id="0" names="add_z:0" precision="FP32">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </output>
-                </layer>
-                <layer id="2" name="Add" type="Add" version="opset1">
-                    <data auto_broadcast="numpy"/>
-                    <input>
-                        <port id="0">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                        <port id="1">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </input>
-                    <output>
-                        <port id="2" names="Add:0" precision="FP32">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </output>
-                </layer>
-                <layer id="3" name="Identity/sink_port_0" type="Result" version="opset1">
-                    <input>
-                        <port id="0">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </input>
-                </layer>
-            </layers>
-            <edges>
-                <edge from-layer="0" from-port="0" to-layer="2" to-port="0"/>
-                <edge from-layer="1" from-port="0" to-layer="2" to-port="1"/>
-                <edge from-layer="2" from-port="2" to-layer="3" to-port="0"/>
-            </edges>
-        </then_body>
-        <else_body>
-            <layers>
-                <layer id="0" name="add_x" type="Parameter" version="opset1">
-                    <data element_type="f32" shape="2,4"/>
-                    <output>
-                        <port id="0" names="add_x:0" precision="FP32">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </output>
-                </layer>
-                <layer id="1" name="add_w" type="Parameter" version="opset1">
-                    <data element_type="f32" shape="2,4"/>
-                    <output>
-                        <port id="0" names="add_w:0" precision="FP32">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </output>
-                </layer>
-                <layer id="2" name="Add" type="Add" version="opset1">
-                    <data auto_broadcast="numpy"/>
-                    <input>
-                        <port id="0">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                        <port id="1">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </input>
-                    <output>
-                        <port id="2" names="Add:0" precision="FP32">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </output>
-                </layer>
-                <layer id="3" name="Identity/sink_port_0" type="Result" version="opset1">
-                    <input>
-                        <port id="0">
-                            <dim>2</dim>
-                            <dim>4</dim>
-                        </port>
-                    </input>
-                </layer>
-            </layers>
-            <edges>
-                <edge from-layer="0" from-port="0" to-layer="2" to-port="0"/>
-                <edge from-layer="1" from-port="0" to-layer="2" to-port="1"/>
-                <edge from-layer="2" from-port="2" to-layer="3" to-port="0"/>
-            </edges>
-        </else_body>
-    </layer>
-```
+
+
+.. code-block:: cpp
+
+   <layer id="6" name="if/cond" type="If" version="opset8">
+       <input>
+           <port id="0"/>
+           <port id="1">
+               <dim>2</dim>
+               <dim>4</dim>
+           </port>
+           <port id="2">
+               <dim>2</dim>
+               <dim>4</dim>
+           </port>
+           <port id="3">
+               <dim>2</dim>
+               <dim>4</dim>
+           </port>
+       </input>
+       <output>
+           <port id="4" names="if/cond/Identity:0,if/cond:0" precision="FP32">
+               <dim>2</dim>
+               <dim>4</dim>
+           </port>
+       </output>
+       <then_port_map>
+           <input external_port_id="1" internal_layer_id="0"/>
+           <input external_port_id="2" internal_layer_id="1"/>
+           <output external_port_id="0" internal_layer_id="3"/>
+       </then_port_map>
+       <else_port_map>
+           <input external_port_id="1" internal_layer_id="0"/>
+           <input external_port_id="3" internal_layer_id="1"/>
+           <output external_port_id="0" internal_layer_id="3"/>
+       </else_port_map>
+       <then_body>
+           <layers>
+               <layer id="0" name="add_x" type="Parameter" version="opset1">
+                   <data element_type="f32" shape="2,4"/>
+                   <output>
+                       <port id="0" names="add_x:0" precision="FP32">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </output>
+               </layer>
+               <layer id="1" name="add_z" type="Parameter" version="opset1">
+                   <data element_type="f32" shape="2,4"/>
+                   <output>
+                       <port id="0" names="add_z:0" precision="FP32">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </output>
+               </layer>
+               <layer id="2" name="Add" type="Add" version="opset1">
+                   <data auto_broadcast="numpy"/>
+                   <input>
+                       <port id="0">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                       <port id="1">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </input>
+                   <output>
+                       <port id="2" names="Add:0" precision="FP32">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </output>
+               </layer>
+               <layer id="3" name="Identity/sink_port_0" type="Result" version="opset1">
+                   <input>
+                       <port id="0">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </input>
+               </layer>
+           </layers>
+           <edges>
+               <edge from-layer="0" from-port="0" to-layer="2" to-port="0"/>
+               <edge from-layer="1" from-port="0" to-layer="2" to-port="1"/>
+               <edge from-layer="2" from-port="2" to-layer="3" to-port="0"/>
+           </edges>
+       </then_body>
+       <else_body>
+           <layers>
+               <layer id="0" name="add_x" type="Parameter" version="opset1">
+                   <data element_type="f32" shape="2,4"/>
+                   <output>
+                       <port id="0" names="add_x:0" precision="FP32">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </output>
+               </layer>
+               <layer id="1" name="add_w" type="Parameter" version="opset1">
+                   <data element_type="f32" shape="2,4"/>
+                   <output>
+                       <port id="0" names="add_w:0" precision="FP32">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </output>
+               </layer>
+               <layer id="2" name="Add" type="Add" version="opset1">
+                   <data auto_broadcast="numpy"/>
+                   <input>
+                       <port id="0">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                       <port id="1">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </input>
+                   <output>
+                       <port id="2" names="Add:0" precision="FP32">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </output>
+               </layer>
+               <layer id="3" name="Identity/sink_port_0" type="Result" version="opset1">
+                   <input>
+                       <port id="0">
+                           <dim>2</dim>
+                           <dim>4</dim>
+                       </port>
+                   </input>
+               </layer>
+           </layers>
+           <edges>
+               <edge from-layer="0" from-port="0" to-layer="2" to-port="0"/>
+               <edge from-layer="1" from-port="0" to-layer="2" to-port="1"/>
+               <edge from-layer="2" from-port="2" to-layer="3" to-port="0"/>
+           </edges>
+       </else_body>
+   </layer>
+
+
+@endsphinxdirective
+

docs/ops/condition/NonZero_3.md

@@ -1,5 +1,7 @@
 # NonZero {#openvino_docs_ops_condition_NonZero_3}
 
+@sphinxdirective
+
 **Versioned name**: *NonZero-3*
 
 **Category**: *Condition*
@@ -7,18 +9,19 @@
 **Short description**: *NonZero* returns the indices of the non-zero elements of the input tensor.
 
 **Detailed description**: *NonZero* returns the indices of the non-zero elements of the input tensor (in row-major order - by dimension).
-* The output tensor has shape `[rank(input), num_non_zero]`.
-* For example, for the tensor `[[1, 0], [1, 1]]` the output will be `[[0, 1, 1], [0, 0, 1]]`.
-* The output is a collection of tuples, each tuple has `rank(input)` elements and contains indices for a single non-zero element.
-* The `i`'th element of each output dimension is a part of `i`'th tuple.
-* In given example the tuples would be: `[0, 0]`, `[1, 0]`, `[1, 1]`.
+
+* The output tensor has shape ``[rank(input), num_non_zero]``.
+* For example, for the tensor ``[[1, 0], [1, 1]]`` the output will be ``[[0, 1, 1], [0, 0, 1]]``.
+* The output is a collection of tuples, each tuple has ``rank(input)`` elements and contains indices for a single non-zero element.
+* The ``i``'th element of each output dimension is a part of ``i``'th tuple.
+* In given example the tuples would be: ``[0, 0]``, ``[1, 0]``, ``[1, 1]``.
 
 **Attributes**
 
 * *output_type*
 
   * **Description**: the output tensor type
-  * **Range of values**: `i64` or `i32`
+  * **Range of values**: ``i64`` or ``i32``
   * **Type**: string
   * **Default value**: "i64"
   * **Required**: *no*
@@ -29,32 +32,35 @@
 
 **Outputs**:
 
-*   **1**: tensor with indices of non-zero elements of shape `[rank(data), num_non_zero]` of type *T_OUT*.
+*   **1**: tensor with indices of non-zero elements of shape ``[rank(data), num_non_zero]`` of type *T_OUT*.
 
 **Types**
 
 * *T*: any type.
 
-* *T_OUT*: Depending on *output_type* attribute can be `int64` or `int32`.
+* *T_OUT*: Depending on *output_type* attribute can be ``int64`` or ``int32``.
 
 **Example**
 
-```xml
-<layer ... type="NonZero">
-    <data output_type="i64"/>
-    <input>
-        <port id="0">
-            <dim>3</dim>
-            <dim>10</dim>
-            <dim>100</dim>
-            <dim>200</dim>
-        </port>
-     </input>
-    <output>
-        <port id="1">
-            <dim>4</dim>
-            <dim>-1</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block::  cpp
+
+    <layer ... type="NonZero">
+        <data output_type="i64"/>
+        <input>
+            <port id="0">
+                <dim>3</dim>
+                <dim>10</dim>
+                <dim>100</dim>
+                <dim>200</dim>
+            </port>
+        </input>
+        <output>
+            <port id="1">
+                <dim>4</dim>
+                <dim>-1</dim>
+            </port>
+        </output>
+    </layer>
+
+
+@endsphinxdirective

docs/ops/detection/ExperimentalDetectronDetectionOutput_6.md

@@ -1,5 +1,7 @@
 # ExperimentalDetectronDetectionOutput {#openvino_docs_ops_detection_ExperimentalDetectronDetectionOutput_6}
 
+@sphinxdirective
+
 **Versioned name**: *ExperimentalDetectronDetectionOutput-6*
 
 **Category**: *Object detection*
@@ -9,48 +11,45 @@ the detection output using information on location and score predictions.
 
 **Detailed description**: The operation performs the following steps:
 
-1.  Applies deltas to boxes sizes [x<sub>1</sub>, y<sub>1</sub>, x<sub>2</sub>, y<sub>2</sub>] and takes coordinates of
+1. Applies deltas to boxes sizes [x 1, y 1, x 2, y 2] and takes coordinates of
 refined boxes according to the formulas:
 
-`x1_new = ctr_x + (dx - 0.5 * exp(min(d_log_w, max_delta_log_wh))) * box_w`
+``x1_new = ctr_x + (dx - 0.5 * exp(min(d_log_w, max_delta_log_wh))) * box_w``
 
-`y0_new = ctr_y + (dy - 0.5 * exp(min(d_log_h, max_delta_log_wh))) * box_h`
+``y0_new = ctr_y + (dy - 0.5 * exp(min(d_log_h, max_delta_log_wh))) * box_h``
 
-`x1_new = ctr_x + (dx + 0.5 * exp(min(d_log_w, max_delta_log_wh))) * box_w - 1.0`
+``x1_new = ctr_x + (dx + 0.5 * exp(min(d_log_w, max_delta_log_wh))) * box_w - 1.0``
 
-`y1_new = ctr_y + (dy + 0.5 * exp(min(d_log_h, max_delta_log_wh))) * box_h - 1.0`
+``y1_new = ctr_y + (dy + 0.5 * exp(min(d_log_h, max_delta_log_wh))) * box_h - 1.0``
 
-* `box_w` and `box_h` are width and height of box, respectively:
+* ``box_w`` and ``box_h`` are width and height of box, respectively:
 
-`box_w = x1 - x0 + 1.0`
+``box_w = x1 - x0 + 1.0``
 
-`box_h = y1 - y0 + 1.0`
+``box_h = y1 - y0 + 1.0``
 
-* `ctr_x` and `ctr_y` are center location of a box:
+* ``ctr_x`` and ``ctr_y`` are center location of a box:
 
-`ctr_x = x0 + 0.5f * box_w`
+``ctr_x = x0 + 0.5f * box_w``
 
-`ctr_y = y0 + 0.5f * box_h`
+``ctr_y = y0 + 0.5f * box_h``
 
-* `dx`, `dy`, `d_log_w` and `d_log_h` are deltas calculated according to the formulas below, and `deltas_tensor` is a
+* ``dx``, ``dy``, ``d_log_w`` and ``d_log_h`` are deltas calculated according to the formulas below, and ``deltas_tensor`` is a
 second input:
 
-`dx = deltas_tensor[roi_idx, 4 * class_idx + 0] / deltas_weights[0]`
+``dx = deltas_tensor[roi_idx, 4 * class_idx + 0] / deltas_weights[0]``
 
-`dy = deltas_tensor[roi_idx, 4 * class_idx + 1] / deltas_weights[1]`
+``dy = deltas_tensor[roi_idx, 4 * class_idx + 1] / deltas_weights[1]``
 
-`d_log_w = deltas_tensor[roi_idx, 4 * class_idx + 2] / deltas_weights[2]`
+``d_log_w = deltas_tensor[roi_idx, 4 * class_idx + 2] / deltas_weights[2]``
 
-`d_log_h = deltas_tensor[roi_idx, 4 * class_idx + 3] / deltas_weights[3]`
+``d_log_h = deltas_tensor[roi_idx, 4 * class_idx + 3] / deltas_weights[3]``
 
-2.  If *class_agnostic_box_regression* is `true` removes predictions for background classes.
-3.  Clips boxes to the image.
-4.  Applies *score_threshold* on detection scores.
-5.  Applies non-maximum suppression class-wise with *nms_threshold* and returns *post_nms_count* or less detections per
-class.
-6.  Returns *max_detections_per_image* detections if total number of detections is more than *max_detections_per_image*;
-otherwise, returns total number of detections and the output tensor is filled with undefined values for rest output
-tensor elements.
+2. If *class_agnostic_box_regression* is ``true`` removes predictions for background classes.
+3. Clips boxes to the image.
+4. Applies *score_threshold* on detection scores.
+5. Applies non-maximum suppression class-wise with *nms_threshold* and returns *post_nms_count* or less detections per class.
+6. Returns *max_detections_per_image* detections if total number of detections is more than *max_detections_per_image*; otherwise, returns total number of detections and the output tensor is filled with undefined values for rest output tensor elements.
 
 **Attributes**:
 
@@ -59,7 +58,7 @@ tensor elements.
     * **Description**: The *score_threshold* attribute specifies a threshold to consider only detections whose score are
     larger than the threshold.
     * **Range of values**: non-negative floating-point number
-    * **Type**: float
+    * **Type**: ``float``
     * **Default value**: None
     * **Required**: *yes*
 
@@ -67,7 +66,7 @@ tensor elements.
 
     * **Description**: The *nms_threshold* attribute specifies a threshold to be used in the NMS stage.
     * **Range of values**: non-negative floating-point number
-    * **Type**: float
+    * **Type**: ``float``
     * **Default value**: None
     * **Required**: *yes*
 
@@ -75,7 +74,7 @@ tensor elements.
 
     * **Description**: The *num_classes* attribute specifies the number of detected classes.
     * **Range of values**: non-negative integer number
-    * **Type**: int
+    * **Type**: ``int``
     * **Default value**: None
     * **Required**: *yes*
 
@@ -83,7 +82,7 @@ tensor elements.
 
     * **Description**: The *post_nms_count* attribute specifies the maximal number of detections per class.
     * **Range of values**: non-negative integer number
-    * **Type**: int
+    * **Type**: ``int``
     * **Default value**: None
     * **Required**: *yes*
 
@@ -91,18 +90,18 @@ tensor elements.
 
     * **Description**: The *max_detections_per_image* attribute specifies maximal number of detections per image.
     * **Range of values**: non-negative integer number
-    * **Type**: int
+    * **Type**: ``int``
     * **Default value**: None
     * **Required**: *yes*
 
 * *class_agnostic_box_regression*
 
-    * **Description**: *class_agnostic_box_regression* attribute is a flag that specifies whether to delete background
-    classes or not.
+    * **Description**: *class_agnostic_box_regression* attribute is a flag that specifies whether to delete background classes or not.
     * **Range of values**:
-      * `true` means background classes should be deleted
-      * `false` means background classes should not be deleted
-    * **Type**: boolean
+
+      * ``true`` means background classes should be deleted
+      * ``false`` means background classes should not be deleted
+    * **Type**: ``boolean``
     * **Default value**: false
     * **Required**: *no*
 
@@ -110,7 +109,7 @@ tensor elements.
 
     * **Description**: The *max_delta_log_wh* attribute specifies maximal delta of logarithms for width and height.
     * **Range of values**: floating-point number
-    * **Type**: float
+    * **Type**: ``float``
     * **Default value**: None
     * **Required**: *yes*
 
@@ -118,76 +117,68 @@ tensor elements.
 
     * **Description**: The *deltas_weights* attribute specifies weights for bounding boxes sizes deltas.
     * **Range of values**: a list of non-negative floating-point numbers
-    * **Type**: float[]
+    * **Type**: ``float[]``
     * **Default value**: None
     * **Required**: *yes*
 
 **Inputs**
 
-* **1**: A 2D tensor of type *T* with input ROIs, with shape `[number_of_ROIs, 4]` providing the ROIs as 4-tuples:
-[x<sub>1</sub>, y<sub>1</sub>, x<sub>2</sub>, y<sub>2</sub>]. The batch dimension of first, second, and third inputs
-should be the same. **Required.**
-
-* **2**: A 2D tensor of type *T* with shape `[number_of_ROIs, num_classes * 4]` providing deltas for input boxes.
- **Required.**
-
-* **3**: A 2D tensor of type *T* with shape `[number_of_ROIs, num_classes]` providing detections scores. **Required.**
-
-* **4**: A 2D tensor of type *T* with shape `[1, 3]` contains three elements
- `[image_height, image_width, scale_height_and_width]` providing input image size info. **Required.**
+* **1**: A 2D tensor of type *T* with input ROIs, with shape ``[number_of_ROIs, 4]`` providing the ROIs as 4-tuples: [x 1, y 1, x 2, y 2]. The batch dimension of first, second, and third inputs should be the same. **Required.**
+* **2**: A 2D tensor of type *T* with shape ``[number_of_ROIs, num_classes * 4]`` providing deltas for input boxes. **Required.**
+* **3**: A 2D tensor of type *T* with shape ``[number_of_ROIs, num_classes]`` providing detections scores. **Required.**
+* **4**: A 2D tensor of type *T* with shape ``[1, 3]`` contains three elements ``[image_height, image_width, scale_height_and_width]`` providing input image size info. **Required.**
 
 **Outputs**
 
-* **1**: A 2D tensor of type *T* with shape `[max_detections_per_image, 4]` providing boxes indices.
-
-* **2**: A 1D tensor of type *T_IND* with shape `[max_detections_per_image]` providing classes indices.
-
-* **3**: A 1D tensor of type *T* with shape `[max_detections_per_image]` providing scores indices.
+* **1**: A 2D tensor of type *T* with shape ``[max_detections_per_image, 4]`` providing boxes indices.
+* **2**: A 1D tensor of type *T_IND* with shape ``[max_detections_per_image]`` providing classes indices.
+* **3**: A 1D tensor of type *T* with shape ``[max_detections_per_image]`` providing scores indices.
 
 **Types**
 
 * *T*: any supported floating-point type.
-
-* *T_IND*: `int64` or `int32`.
-
+* *T_IND*: ``int64`` or ``int32``.
 
 **Example**
 
-```xml
-<layer ... type="ExperimentalDetectronDetectionOutput" version="opset6">
-    <data class_agnostic_box_regression="false" deltas_weights="10.0,10.0,5.0,5.0" max_delta_log_wh="4.135166645050049" max_detections_per_image="100" nms_threshold="0.5" num_classes="81" post_nms_count="2000" score_threshold="0.05000000074505806"/>
-    <input>
-        <port id="0">
-            <dim>1000</dim>
-            <dim>4</dim>
-        </port>
-        <port id="1">
-            <dim>1000</dim>
-            <dim>324</dim>
-        </port>
-        <port id="2">
-            <dim>1000</dim>
-            <dim>81</dim>
-        </port>
-        <port id="3">
-            <dim>1</dim>
-            <dim>3</dim>
-        </port>
-    </input>
-    <output>
-        <port id="4" precision="FP32">
-            <dim>100</dim>
-            <dim>4</dim>
-        </port>
-        <port id="5" precision="I32">
-            <dim>100</dim>
-        </port>
-        <port id="6" precision="FP32">
-            <dim>100</dim>
-        </port>
-        <port id="7" precision="I32">
-            <dim>100</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+   
+   <layer ... type="ExperimentalDetectronDetectionOutput" version="opset6">
+       <data class_agnostic_box_regression="false" deltas_weights="10.0,10.0,5.0,5.0" max_delta_log_wh="4.135166645050049" max_detections_per_image="100" nms_threshold="0.5" num_classes="81" post_nms_count="2000" score_threshold="0.05000000074505806"/>
+       <input>
+           <port id="0">
+               <dim>1000</dim>
+               <dim>4</dim>
+           </port>
+           <port id="1">
+               <dim>1000</dim>
+               <dim>324</dim>
+           </port>
+           <port id="2">
+               <dim>1000</dim>
+               <dim>81</dim>
+           </port>
+           <port id="3">
+               <dim>1</dim>
+               <dim>3</dim>
+           </port>
+       </input>
+       <output>
+           <port id="4" precision="FP32">
+               <dim>100</dim>
+               <dim>4</dim>
+           </port>
+           <port id="5" precision="I32">
+               <dim>100</dim>
+           </port>
+           <port id="6" precision="FP32">
+               <dim>100</dim>
+           </port>
+           <port id="7" precision="I32">
+               <dim>100</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/detection/ExperimentalDetectronGenerateProposalsSingleImage_6.md

@@ -1,75 +1,69 @@
 # ExperimentalDetectronGenerateProposalsSingleImage {#openvino_docs_ops_detection_ExperimentalDetectronGenerateProposalsSingleImage_6}
 
+@sphinxdirective
+
 **Versioned name**: *ExperimentalDetectronGenerateProposalsSingleImage-6*
 
 **Category**: *Object detection*
 
-**Short description**: The *ExperimentalDetectronGenerateProposalsSingleImage* operation computes ROIs and their scores
-based on input data.
+**Short description**: The *ExperimentalDetectronGenerateProposalsSingleImage* operation computes ROIs and their scores based on input data.
 
 **Detailed description**: The operation performs the following steps:
 
-1.  Transposes and reshapes predicted bounding boxes deltas and scores to get them into the same order as the anchors.
-2.  Transforms anchors into proposals using deltas and clips proposals to an image.
-3.  Removes predicted boxes with either height or width < *min_size*.
-4.  Sorts all `(proposal, score)` pairs by score from highest to lowest; order of pairs with equal scores is undefined.
-5.  Takes top *pre_nms_count* proposals, if total number of proposals is less than *pre_nms_count* takes all proposals.
-6.  Applies non-maximum suppression with *nms_threshold*.
-7.  Takes top *post_nms_count* proposals and returns these top proposals and their scores. If total number of proposals
-is less than *post_nms_count* returns output tensors filled with zeroes.
+1. Transposes and reshapes predicted bounding boxes deltas and scores to get them into the same order as the anchors.
+2. Transforms anchors into proposals using deltas and clips proposals to an image.
+3. Removes predicted boxes with either height or width < *min_size*.
+4. Sorts all ``(proposal, score)`` pairs by score from highest to lowest; order of pairs with equal scores is undefined.
+5. Takes top *pre_nms_count* proposals, if total number of proposals is less than *pre_nms_count* takes all proposals.
+6. Applies non-maximum suppression with *nms_threshold*.
+7. Takes top *post_nms_count* proposals and returns these top proposals and their scores. If total number of proposals is less than *post_nms_count* returns output tensors filled with zeroes.
 
 **Attributes**:
 
 * *min_size*
 
-    * **Description**: The *min_size* attribute specifies minimum box width and height.
-    * **Range of values**: non-negative floating-point number
-    * **Type**: float
-    * **Default value**: None
-    * **Required**: *yes*
+  * **Description**: The *min_size* attribute specifies minimum box width and height.
+  * **Range of values**: non-negative floating-point number
+  * **Type**: ``float``
+  * **Default value**: None
+  * **Required**: *yes*
 
 * *nms_threshold*
 
-    * **Description**: The *nms_threshold* attribute specifies threshold to be used in the NMS stage.
-    * **Range of values**: non-negative floating-point number
-    * **Type**: float
-    * **Default value**: None
-    * **Required**: *yes*
+  * **Description**: The *nms_threshold* attribute specifies threshold to be used in the NMS stage.
+  * **Range of values**: non-negative floating-point number
+  * **Type**: ``float``
+  * **Default value**: None
+  * **Required**: *yes*
 
 * *pre_nms_count*
 
-    * **Description**: The *pre_nms_count* attribute specifies number of top-n proposals before NMS.
-    * **Range of values**: non-negative integer number
-    * **Type**: int
-    * **Default value**: None
-    * **Required**: *yes*
+  * **Description**: The *pre_nms_count* attribute specifies number of top-n proposals before NMS.
+  * **Range of values**: non-negative integer number
+  * **Type**: ``int``
+  * **Default value**: None
+  * **Required**: *yes*
 
 * *post_nms_count*
 
-    * **Description**: The *post_nms_count* attribute specifies number of top-n proposals after NMS.
-    * **Range of values**: non-negative integer number
-    * **Type**: int
-    * **Default value**: None
-    * **Required**: *yes*
+  * **Description**: The *post_nms_count* attribute specifies number of top-n proposals after NMS.
+  * **Range of values**: non-negative integer number
+  * **Type**: ``int``
+  * **Default value**: None
+  * **Required**: *yes*
 
 **Inputs**
 
-* **1**: A 1D tensor of type *T* with 3 elements `[image_height, image_width, scale_height_and_width]` providing input
-image size info. **Required.**
-
-* **2**: A 2D tensor of type *T* with shape `[height * width * number_of_channels, 4]` providing anchors. **Required.**
-
-* **3**: A 3D tensor of type *T* with shape `[number_of_channels * 4, height, width]` providing deltas for anchors.
+* **1**: A 1D tensor of type *T* with 3 elements ``[image_height, image_width, scale_height_and_width]`` providing input image size info. **Required.**
+* **2**: A 2D tensor of type *T* with shape ``[height * width * number_of_channels, 4]`` providing anchors. **Required.**
+* **3**: A 3D tensor of type *T* with shape ``[number_of_channels * 4, height, width]`` providing deltas for anchors.
 Height and width for third and fourth inputs should be equal. **Required.**
-
-* **4**: A 3D tensor of type *T* with shape `[number_of_channels, height, width]` providing proposals scores.
-**Required.**
+* **4**: A 3D tensor of type *T* with shape ``[number_of_channels, height, width]`` providing proposals scores. **Required.**
 
 **Outputs**
 
-* **1**: A 2D tensor of type *T* with shape `[post_nms_count, 4]` providing ROIs.
-
-* **2**: A 1D tensor of type *T* with shape `[post_nms_count]` providing ROIs scores.
+* **1**: A 2D tensor of type *T* with shape ``[post_nms_count, 4]`` providing ROIs.
+* **2**: A 1D tensor of type *T* with shape ``[post_nms_count]`` providing ROIs scores.
 
 **Types**
 
@@ -77,36 +71,39 @@ Height and width for third and fourth inputs should be equal. **Required.**
 
 **Example**
 
-```xml
-<layer ... type="ExperimentalDetectronGenerateProposalsSingleImage" version="opset6">
-    <data min_size="0.0" nms_threshold="0.699999988079071" post_nms_count="1000" pre_nms_count="1000"/>
-    <input>
-        <port id="0">
-            <dim>3</dim>
-        </port>
-        <port id="1">
-            <dim>12600</dim>
-            <dim>4</dim>
-        </port>
-        <port id="2">
-            <dim>12</dim>
-            <dim>50</dim>
-            <dim>84</dim>
-        </port>
-        <port id="3">
-            <dim>3</dim>
-            <dim>50</dim>
-            <dim>84</dim>
-        </port>
-    </input>
-    <output>
-        <port id="4" precision="FP32">
-            <dim>1000</dim>
-            <dim>4</dim>
-        </port>
-        <port id="5" precision="FP32">
-            <dim>1000</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+   
+   <layer ... type="ExperimentalDetectronGenerateProposalsSingleImage" version="opset6">
+       <data min_size="0.0" nms_threshold="0.699999988079071" post_nms_count="1000" pre_nms_count="1000"/>
+       <input>
+           <port id="0">
+               <dim>3</dim>
+           </port>
+           <port id="1">
+               <dim>12600</dim>
+               <dim>4</dim>
+           </port>
+           <port id="2">
+               <dim>12</dim>
+               <dim>50</dim>
+               <dim>84</dim>
+           </port>
+           <port id="3">
+               <dim>3</dim>
+               <dim>50</dim>
+               <dim>84</dim>
+           </port>
+       </input>
+       <output>
+           <port id="4" precision="FP32">
+               <dim>1000</dim>
+               <dim>4</dim>
+           </port>
+           <port id="5" precision="FP32">
+               <dim>1000</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/detection/ExperimentalDetectronPriorGridGenerator_6.md

@@ -1,83 +1,73 @@
 # ExperimentalDetectronPriorGridGenerator {#openvino_docs_ops_detection_ExperimentalDetectronPriorGridGenerator_6}
 
+@sphinxdirective
+
 **Versioned name**: *ExperimentalDetectronPriorGridGenerator-6*
 
 **Category**: *Object detection*
 
 **Short description**: The *ExperimentalDetectronPriorGridGenerator* operation generates prior grids of specified sizes.
 
-**Detailed description**: The operation takes coordinates of centres of boxes and adds strides with offset `0.5` to them to
-calculate coordinates of prior grids.
+**Detailed description**: The operation takes coordinates of centres of boxes and adds strides with offset `0.5` to them to calculate coordinates of prior grids.
 
-Numbers of generated cells is `featmap_height` and `featmap_width` if *h* and *w* are zeroes; otherwise, *h* and *w*,
-respectively. Steps of generated grid are `image_height` / `layer_height` and `image_width` / `layer_width` if
-*stride_h* and *stride_w* are zeroes; otherwise, *stride_h* and *stride_w*, respectively.
+Numbers of generated cells is ``featmap_height`` and ``featmap_width`` if *h* and *w* are zeroes; otherwise, *h* and *w*, respectively. Steps of generated grid are ``image_height`` / ``layer_height`` and ``image_width`` / ``layer_width`` if *stride_h* and *stride_w* are zeroes; otherwise, *stride_h* and *stride_w*, respectively.
 
-`featmap_height`, `featmap_width`, `image_height` and `image_width` are spatial dimensions values from second and third
-inputs, respectively.
+``featmap_height``, ``featmap_width``, ``image_height`` and ``image_width`` are spatial dimensions values from second and third inputs, respectively.
 
 **Attributes**:
 
 * *flatten*
 
-    * **Description**: The *flatten* attribute specifies whether the output tensor should be 2D or 4D.
-    * **Range of values**:
-      * `true` - the output tensor should be a 2D tensor
-      * `false` - the output tensor should be a 4D tensor
-    * **Type**: boolean
-    * **Default value**: true
-    * **Required**: *no*
+  * **Description**: The *flatten* attribute specifies whether the output tensor should be 2D or 4D.
+  * **Range of values**:
+     
+    * ``true`` - the output tensor should be a 2D tensor
+    * ``false`` - the output tensor should be a 4D tensor
+  * **Type**: ``boolean``
+  * **Default value**: true
+  * **Required**: *no*
 
 * *h*
 
-    * **Description**: The *h* attribute specifies number of cells of the generated grid with respect to height.
-    * **Range of values**: non-negative integer number less or equal than `featmap_height`
-    * **Type**: int
-    * **Default value**: 0
-    * **Required**: *no*
+  * **Description**: The *h* attribute specifies number of cells of the generated grid with respect to height.
+  * **Range of values**: non-negative integer number less or equal than ``featmap_height``
+  * **Type**: ``int``
+  * **Default value**: 0
+  * **Required**: *no*
 
 * *w*
 
-    * **Description**: The *w* attribute specifies number of cells of the generated grid with respect to width.
-    * **Range of values**: non-negative integer number less or equal than `featmap_width`
-    * **Type**: int
-    * **Default value**: 0
-    * **Required**: *no*
+  * **Description**: The *w* attribute specifies number of cells of the generated grid with respect to width.
+  * **Range of values**: non-negative integer number less or equal than ``featmap_width``
+  * **Type**: ``int``
+  * **Default value**: 0
+  * **Required**: *no*
 
 * *stride_x*
 
-    * **Description**: The *stride_x* attribute specifies the step of generated grid with respect to x coordinate.
-    * **Range of values**: non-negative float number
-    * **Type**: float
-    * **Default value**: 0.0
-    * **Required**: *no*
+  * **Description**: The *stride_x* attribute specifies the step of generated grid with respect to x coordinate.
+  * **Range of values**: non-negative float number
+  * **Type**: ``float``
+  * **Default value**: 0.0
+  * **Required**: *no*
 
 * *stride_y*
 
-    * **Description**: The *stride_y* attribute specifies the step of generated grid with respect to y coordinate.
-    * **Range of values**: non-negative float number
-    * **Type**: float
-    * **Default value**: 0.0
-    * **Required**: *no*
+  * **Description**: The *stride_y* attribute specifies the step of generated grid with respect to y coordinate.
+  * **Range of values**: non-negative float number
+  * **Type**: ``float``
+  * **Default value**: 0.0
+  * **Required**: *no*
 
 **Inputs**
 
-* **1**: A 2D tensor of type *T* with shape `[number_of_priors, 4]` contains priors. **Required.**
-
-* **2**: A 4D tensor of type *T* with input feature map `[1, number_of_channels, featmap_height, featmap_width]`. This
-operation uses only sizes of this input tensor, not its data.**Required.**
-
-* **3**: A 4D tensor of type *T* with input image `[1, number_of_channels, image_height, image_width]`. The number of
-channels of both feature map and input image tensors must match. This operation uses only sizes of this input tensor,
-not its data. **Required.**
+* **1**: A 2D tensor of type *T* with shape ``[number_of_priors, 4]`` contains priors. **Required.**
+* **2**: A 4D tensor of type *T* with input feature map ``[1, number_of_channels, featmap_height, featmap_width]``. This operation uses only sizes of this input tensor, not its data.**Required.**
+* **3**: A 4D tensor of type *T* with input image ``[1, number_of_channels, image_height, image_width]``. The number of channels of both feature map and input image tensors must match. This operation uses only sizes of this input tensor, not its data. **Required.**
 
 **Outputs**
 
-* **1**: A tensor of type *T* with priors grid with shape `[featmap_height * featmap_width * number_of_priors, 4]`
-if flatten is `true` or `[featmap_height, featmap_width, number_of_priors, 4]`, otherwise.
-If 0 < *h* < `featmap_height` and/or 0 < *w* < `featmap_width` the output data size is less than
-`featmap_height` * `featmap_width` * `number_of_priors` * 4 and the output tensor is filled with undefined values for
-rest output tensor elements.
+* **1**: A tensor of type *T* with priors grid with shape ``[featmap_height * featmap_width * number_of_priors, 4]`` if flatten is ``true`` or ``[featmap_height, featmap_width, number_of_priors, 4]``, otherwise. If 0 < *h* < ``featmap_height`` and/or 0 < *w* < ``featmap_width`` the output data size is less than ``featmap_height`` * ``featmap_width`` * ``number_of_priors`` * 4 and the output tensor is filled with undefined values for rest output tensor elements.
 
 **Types**
 
@@ -85,32 +75,35 @@ rest output tensor elements.
 
 **Example**
 
-```xml
-<layer ... type="ExperimentalDetectronPriorGridGenerator" version="opset6">
-    <data flatten="true" h="0" stride_x="32.0" stride_y="32.0" w="0"/>
-    <input>
-        <port id="0">
-            <dim>3</dim>
-            <dim>4</dim>
-        </port>
-        <port id="1">
-            <dim>1</dim>
-            <dim>256</dim>
-            <dim>25</dim>
-            <dim>42</dim>
-        </port>
-        <port id="2">
-            <dim>1</dim>
-            <dim>3</dim>
-            <dim>800</dim>
-            <dim>1344</dim>
-        </port>
-    </input>
-    <output>
-        <port id="3" precision="FP32">
-            <dim>3150</dim>
-            <dim>4</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+   
+   <layer ... type="ExperimentalDetectronPriorGridGenerator" version="opset6">
+       <data flatten="true" h="0" stride_x="32.0" stride_y="32.0" w="0"/>
+       <input>
+           <port id="0">
+               <dim>3</dim>
+               <dim>4</dim>
+           </port>
+           <port id="1">
+               <dim>1</dim>
+               <dim>256</dim>
+               <dim>25</dim>
+               <dim>42</dim>
+           </port>
+           <port id="2">
+               <dim>1</dim>
+               <dim>3</dim>
+               <dim>800</dim>
+               <dim>1344</dim>
+           </port>
+       </input>
+       <output>
+           <port id="3" precision="FP32">
+               <dim>3150</dim>
+               <dim>4</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/detection/ExperimentalDetectronROIFeatureExtractor_6.md

@@ -1,88 +1,75 @@
 # ExperimentalDetectronROIFeatureExtractor {#openvino_docs_ops_detection_ExperimentalDetectronROIFeatureExtractor_6}
 
+@sphinxdirective
+
 **Versioned name**: *ExperimentalDetectronROIFeatureExtractor-6*
 
 **Category**: *Object detection*
 
-**Short description**: *ExperimentalDetectronROIFeatureExtractor* is the [ROIAlign](ROIAlign_3.md) operation applied
-over a feature pyramid.
+**Short description**: *ExperimentalDetectronROIFeatureExtractor* is the :doc:`ROIAlign <openvino_docs_ops_detection_ROIAlign_3>` operation applied over a feature pyramid.
 
-**Detailed description**: *ExperimentalDetectronROIFeatureExtractor* maps input ROIs to the levels of the pyramid
-depending on the sizes of ROIs and parameters of the operation, and then extracts features via ROIAlign from
-corresponding pyramid levels.
+**Detailed description**: *ExperimentalDetectronROIFeatureExtractor* maps input ROIs to the levels of the pyramid depending on the sizes of ROIs and parameters of the operation, and then extracts features via ROIAlign from corresponding pyramid levels.
 
 Operation applies the *ROIAlign* algorithm to the pyramid layers:
 
-`output[i, :, :, :] = ROIAlign(inputPyramid[j], rois[i])`
+``output[i, :, :, :] = ROIAlign(inputPyramid[j], rois[i])``
 
-`j = PyramidLevelMapper(rois[i])`
+``j = PyramidLevelMapper(rois[i])``
 
 PyramidLevelMapper maps the ROI to the pyramid level using the following formula:
 
-`j = floor(2 + log2(sqrt(w * h) / 224)`
+``j = floor(2 + log2(sqrt(w * h) / 224)``
 
-Here 224 is the canonical ImageNet pre-training size, 2 is the pyramid starting level, and `w`, `h` are the ROI width and height.
+Here 224 is the canonical ImageNet pre-training size, 2 is the pyramid starting level, and ``w``, ``h`` are the ROI width and height.
 
-For more details please see the following source:
-[Feature Pyramid Networks for Object Detection](https://arxiv.org/pdf/1612.03144.pdf).
+For more details please see the following source: `Feature Pyramid Networks for Object Detection <https://arxiv.org/pdf/1612.03144.pdf>`__.
 
 **Attributes**:
 
 * *output_size*
 
-    * **Description**: The *output_size* attribute specifies the width and height of the output tensor.
-    * **Range of values**: a positive integer number
-    * **Type**: int
-    * **Default value**: None
-    * **Required**: *yes*
+  * **Description**: The *output_size* attribute specifies the width and height of the output tensor.
+  * **Range of values**: a positive integer number
+  * **Type**: ``int``
+  * **Default value**: None
+  * **Required**: *yes*
 
 * *sampling_ratio*
 
-    * **Description**: The *sampling_ratio* attribute specifies the number of sampling points per the output value. If 0,
-    then use adaptive number computed as `ceil(roi_width / output_width)`, and likewise for height.
-    * **Range of values**: a non-negative integer number
-    * **Type**: int
-    * **Default value**: None
-    * **Required**: *yes*
+  * **Description**: The *sampling_ratio* attribute specifies the number of sampling points per the output value. If 0, then use adaptive number computed as ``ceil(roi_width / output_width)``, and likewise for height.
+  * **Range of values**: a non-negative integer number
+  * **Type**: ``int``
+  * **Default value**: None
+  * **Required**: *yes*
 
 * *pyramid_scales*
 
-    * **Description**: The *pyramid_scales* enlists `image_size / layer_size[l]` ratios for pyramid layers `l=1,...,L`,
-    where `L` is the number of pyramid layers, and `image_size` refers to network's input image. Note that pyramid's
-    largest layer may have smaller size than input image, e.g. `image_size` is `800 x 1344` in the XML example below.
-    * **Range of values**: a list of positive integer numbers
-    * **Type**: int[]
-    * **Default value**: None
-    * **Required**: *yes*
+  * **Description**: The *pyramid_scales* enlists ``image_size / layer_size[l]`` ratios for pyramid layers ``l=1,...,L``, where ``L`` is the number of pyramid layers, and ``image_size`` refers to network's input image. Note that pyramid's largest layer may have smaller size than input image, e.g. ``image_size`` is ``800 x 1344`` in the XML example below.
+  * **Range of values**: a list of positive integer numbers
+  * **Type**: ``int[]``
+  * **Default value**: None
+  * **Required**: *yes*
 
 * *aligned*
 
-    * **Description**: The *aligned* attribute specifies add offset (`-0.5`) to ROIs sizes or not.
-    * **Range of values**:
-      * `true` - add offset to ROIs sizes
-      * `false` - do not add offset to ROIs sizes
-    * **Type**: boolean
-    * **Default value**: false
-    * **Required**: *no*
+  * **Description**: The *aligned* attribute specifies add offset (``-0.5``) to ROIs sizes or not.
+  * **Range of values**:
+    
+    * ``true`` - add offset to ROIs sizes
+    * ``false`` - do not add offset to ROIs sizes
+  * **Type**: boolean
+  * **Default value**: false
+  * **Required**: *no*
 
 **Inputs**:
 
-*   **1**: 2D input tensor of type *T* with shape `[number_of_ROIs, 4]` providing the ROIs as 4-tuples:
-[x<sub>1</sub>, y<sub>1</sub>, x<sub>2</sub>, y<sub>2</sub>]. Coordinates *x* and *y* are refer to the network's input
-*image_size*. **Required.**
-
-*   **2**, ..., **L**: Pyramid of 4D input tensors with feature maps. Shape must be
-`[1, number_of_channels, layer_size[l], layer_size[l]]`. The number of channels must be the same for all layers of the
-pyramid. The layer width and height must equal to the `layer_size[l] = image_size / pyramid_scales[l]`. **Required.**
+* **1**: 2D input tensor of type *T* with shape ``[number_of_ROIs, 4]`` providing the ROIs as 4-tuples: [x 1, y 1, x<sub>2</sub>, y<sub>2</sub>]. Coordinates *x* and *y* are refer to the network's input *image_size*. **Required.**
+* **2**, ..., **L**: Pyramid of 4D input tensors with feature maps. Shape must be ``[1, number_of_channels, layer_size[l], layer_size[l]]``. The number of channels must be the same for all layers of the pyramid. The layer width and height must equal to the ``layer_size[l] = image_size / pyramid_scales[l]``. **Required.**
 
 **Outputs**:
 
-*   **1**: 4D output tensor of type *T* with ROIs features. Shape must be
-`[number_of_ROIs, number_of_channels, output_size, output_size]`. Channels number is the same as for all images in the
-input pyramid.
-
-*   **2**: 2D output tensor of type *T* with reordered ROIs according to their mapping to the pyramid levels. Shape
-must be the same as for 1 input: `[number_of_ROIs, 4]`.
+* **1**: 4D output tensor of type *T* with ROIs features. Shape must be ``[number_of_ROIs, number_of_channels, output_size, output_size]``. Channels number is the same as for all images in the input pyramid.
+* **2**: 2D output tensor of type *T* with reordered ROIs according to their mapping to the pyramid levels. Shape must be the same as for 1 input: ``[number_of_ROIs, 4]``.
 
 **Types**
 
@@ -90,50 +77,53 @@ must be the same as for 1 input: `[number_of_ROIs, 4]`.
 
 **Example**
 
-```xml
-<layer ... type="ExperimentalDetectronROIFeatureExtractor" version="opset6">
-    <data aligned="false" output_size="7" pyramid_scales="4,8,16,32,64" sampling_ratio="2"/>
-    <input>
-        <port id="0">
-            <dim>1000</dim>
-            <dim>4</dim>
-        </port>
-        <port id="1">
-            <dim>1</dim>
-            <dim>256</dim>
-            <dim>200</dim>
-            <dim>336</dim>
-        </port>
-        <port id="2">
-            <dim>1</dim>
-            <dim>256</dim>
-            <dim>100</dim>
-            <dim>168</dim>
-        </port>
-        <port id="3">
-            <dim>1</dim>
-            <dim>256</dim>
-            <dim>50</dim>
-            <dim>84</dim>
-        </port>
-        <port id="4">
-            <dim>1</dim>
-            <dim>256</dim>
-            <dim>25</dim>
-            <dim>42</dim>
-        </port>
-    </input>
-    <output>
-        <port id="5" precision="FP32">
-            <dim>1000</dim>
-            <dim>256</dim>
-            <dim>7</dim>
-            <dim>7</dim>
-        </port>
-        <port id="6" precision="FP32">
-            <dim>1000</dim>
-            <dim>4</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block:: cpp
+   
+   <layer ... type="ExperimentalDetectronROIFeatureExtractor" version="opset6">
+       <data aligned="false" output_size="7" pyramid_scales="4,8,16,32,64" sampling_ratio="2"/>
+       <input>
+           <port id="0">
+               <dim>1000</dim>
+               <dim>4</dim>
+           </port>
+           <port id="1">
+               <dim>1</dim>
+               <dim>256</dim>
+               <dim>200</dim>
+               <dim>336</dim>
+           </port>
+           <port id="2">
+               <dim>1</dim>
+               <dim>256</dim>
+               <dim>100</dim>
+               <dim>168</dim>
+           </port>
+           <port id="3">
+               <dim>1</dim>
+               <dim>256</dim>
+               <dim>50</dim>
+               <dim>84</dim>
+           </port>
+           <port id="4">
+               <dim>1</dim>
+               <dim>256</dim>
+               <dim>25</dim>
+               <dim>42</dim>
+           </port>
+       </input>
+       <output>
+           <port id="5" precision="FP32">
+               <dim>1000</dim>
+               <dim>256</dim>
+               <dim>7</dim>
+               <dim>7</dim>
+           </port>
+           <port id="6" precision="FP32">
+               <dim>1000</dim>
+               <dim>4</dim>
+           </port>
+       </output>
+   </layer>
+
+@endsphinxdirective
+

docs/ops/detection/PSROIPooling_1.md

@@ -1,12 +1,14 @@
 # PSROIPooling {#openvino_docs_ops_detection_PSROIPooling_1}
 
+@sphinxdirective
+
 **Versioned name**: *PSROIPooling-1*
 
 **Category**: *Object detection*
 
 **Short description**: *PSROIPooling* computes position-sensitive pooling on regions of interest specified by input.
 
-**Detailed description**: [Reference](https://arxiv.org/pdf/1703.06211.pdf).
+**Detailed description**: `Reference <https://arxiv.org/pdf/1703.06211.pdf>`__.
 
 *PSROIPooling* operation takes two input blobs: with feature maps and with regions of interests (box coordinates).
 The latter is specified as five element tuples: *[batch_id, x_1, y_1, x_2, y_2]*.
@@ -18,14 +20,14 @@ ROIs coordinates are specified in absolute values for the average mode and in no
 
   * **Description**: *output_dim* is a pooled output channel number.
   * **Range of values**: a positive integer
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *group_size*
 
   * **Description**: *group_size* is the number of groups to encode position-sensitive score maps.
   * **Range of values**: a positive integer
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Default value**: 1
   * **Required**: *no*
 
@@ -33,12 +35,14 @@ ROIs coordinates are specified in absolute values for the average mode and in no
 
   * **Description**: *spatial_scale* is a multiplicative spatial scale factor to translate ROI coordinates from their input scale to the scale used when pooling.
   * **Range of values**: a positive floating-point number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Required**: *yes*
 
 * *mode*
+
   * **Description**: *mode* specifies mode for pooling.
   * **Range of values**:
+
     * *average* - perform average pooling
     * *bilinear* - perform pooling with bilinear interpolation
   * **Type**: string
@@ -46,25 +50,27 @@ ROIs coordinates are specified in absolute values for the average mode and in no
   * **Required**: *no*
 
 * *spatial_bins_x*
+
   * **Description**: *spatial_bins_x* specifies numbers of bins to divide the input feature maps over width. Used for "bilinear" mode only.
   * **Range of values**: a positive integer
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Default value**: 1
   * **Required**: *no*
 
 * *spatial_bins_y*
+
   * **Description**: *spatial_bins_y* specifies numbers of bins to divide the input feature maps over height.  Used for "bilinear" mode only.
   * **Range of values**: a positive integer
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Default value**: 1
   * **Required**: *no*
 
 **Inputs**:
 
-*   **1**: 4D input tensor with shape `[N, C, H, W]` and type *T*  with feature maps. **Required.**
+*   **1**: 4D input tensor with shape ``[N, C, H, W]`` and type *T*  with feature maps. **Required.**
 
-*   **2**: 2D input tensor with shape `[num_boxes, 5]`. It contains a list of five element tuples that describe a region of interest: `[batch_id, x_1, y_1, x_2, y_2]`. **Required.**
-Batch indices must be in the range of `[0, N-1]`.
+*   **2**: 2D input tensor with shape ``[num_boxes, 5]``. It contains a list of five element tuples that describe a region of interest: ``[batch_id, x_1, y_1, x_2, y_2]``. **Required.**
+Batch indices must be in the range of ``[0, N-1]``.
 
 **Outputs**:
 
@@ -76,28 +82,33 @@ Batch indices must be in the range of `[0, N-1]`.
 
 **Example**
 
-```xml
-<layer ... type="PSROIPooling" ... >
-    <data group_size="6" mode="bilinear" output_dim="360" spatial_bins_x="3" spatial_bins_y="3" spatial_scale="1"/>
-    <input>
-        <port id="0">
-            <dim>1</dim>
-            <dim>3240</dim>
-            <dim>38</dim>
-            <dim>38</dim>
-        </port>
-        <port id="1">
-            <dim>100</dim>
-            <dim>5</dim>
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>100</dim>
-            <dim>360</dim>
-            <dim>6</dim>
-            <dim>6</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block::  cpp   
+
+  <layer ... type="PSROIPooling" ... >
+      <data group_size="6" mode="bilinear" output_dim="360" spatial_bins_x="3" spatial_bins_y="3" spatial_scale="1"/>
+      <input>
+          <port id="0">
+              <dim>1</dim>
+              <dim>3240</dim>
+              <dim>38</dim>
+              <dim>38</dim>
+          </port>
+          <port id="1">
+              <dim>100</dim>
+              <dim>5</dim>
+          </port>
+      </input>
+      <output>
+          <port id="2">
+              <dim>100</dim>
+              <dim>360</dim>
+              <dim>6</dim>
+              <dim>6</dim>
+          </port>
+      </output>
+  </layer>
+
+
+@endsphinxdirective
+
+

docs/ops/detection/PriorBoxClustered_1.md

@@ -1,5 +1,8 @@
 # PriorBoxClustered {#openvino_docs_ops_detection_PriorBoxClustered_1}
 
+@sphinxdirective
+
+
 **Versioned name**: *PriorBoxClustered-1*
 
 **Category**: *Object detection*
@@ -9,38 +12,59 @@
 **Detailed description**
 
 Let
-\f[
-W \equiv image\_width, \quad H \equiv image\_height.
-\f]
+
+.. math::
+
+	W \equiv image\_width, \quad H \equiv image\_height.
 
 Then calculations of *PriorBoxClustered* can be written as
-    \f[
-    center_x=(w+offset)*step
-    \f]
-    \f[
-    center_y=(h+offset)*step
-    \f]
-    \f[
-    w \subset \left( 0, W \right )
-    \f]
-    \f[
-    h \subset \left( 0, H \right )
-    \f]
-For each \f$s = \overline{0, W - 1}\f$ calculates the prior boxes coordinates:
-    \f[
-    xmin = \frac{center_x - \frac{width_s}{2}}{W}
-    \f]
-    \f[
-    ymin = \frac{center_y - \frac{height_s}{2}}{H}
-    \f]
-    \f[
-    xmax = \frac{center_x - \frac{width_s}{2}}{W}
-    \f]
-    \f[
-    ymax = \frac{center_y - \frac{height_s}{2}}{H}
-    \f]
-If *clip* is defined, the coordinates of prior boxes are recalculated with the formula:
-\f$coordinate = \min(\max(coordinate,0), 1)\f$
+
+.. math::
+
+	center_x=(w+offset)*step
+
+
+.. math::
+
+	center_y=(h+offset)*step
+
+
+
+.. math::
+
+	w \subset \left( 0, W \right )
+
+
+
+.. math::
+
+	h \subset \left( 0, H \right )
+
+For each :math:`s = \overline{0, W - 1}` calculates the prior boxes coordinates:
+
+.. math::
+
+	xmin = \frac{center_x - \frac{width_s}{2}}{W}
+
+
+
+.. math::
+
+	ymin = \frac{center_y - \frac{height_s}{2}}{H}
+
+
+
+.. math::
+
+	xmax = \frac{center_x - \frac{width_s}{2}}{W}
+
+
+
+.. math::
+
+	ymax = \frac{center_y - \frac{height_s}{2}}{H}
+
+If *clip* is defined, the coordinates of prior boxes are recalculated with the formula: :math:`coordinate = \min(\max(coordinate,0), 1)`
 
 **Attributes**
 
@@ -48,17 +72,18 @@ If *clip* is defined, the coordinates of prior boxes are recalculated with the f
 
   * **Description**: *width (height)* specifies desired boxes widths (heights) in pixels.
   * **Range of values**: floating-point positive numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Default value**: 1.0
   * **Required**: *no*
 
 * *clip*
 
-  * **Description**: *clip* is a flag that denotes if each value in the output tensor should be clipped within `[0,1]`.
+  * **Description**: *clip* is a flag that denotes if each value in the output tensor should be clipped within ``[0,1]``.
   * **Range of values**:
+
     * false or 0 - clipping is not performed
-    * true or 1  - each value in the output tensor is within `[0,1]`
-  * **Type**: `boolean`
+    * true or 1  - each value in the output tensor is within ``[0,1]``
+  * **Type**: ``boolean``
   * **Default value**: true
   * **Required**: *no*
 
@@ -66,7 +91,7 @@ If *clip* is defined, the coordinates of prior boxes are recalculated with the f
 
   * **Description**: *step (step_w, step_h)* is a distance between box centers. For example, *step* equal 85 means that the distance between neighborhood prior boxes centers is 85. If both *step_h* and *step_w* are 0 then they are updated with value of *step*. If after that they are still 0 then they are calculated as input image width(height) divided with first input width(height). 
   * **Range of values**: floating-point positive number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Default value**: 0.0
   * **Required**: *no*
 
@@ -74,26 +99,26 @@ If *clip* is defined, the coordinates of prior boxes are recalculated with the f
 
   * **Description**: *offset* is a shift of box respectively to top left corner. For example, *offset* equal 85 means that the shift of neighborhood prior boxes centers is 85.
   * **Range of values**: floating-point positive number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Required**: *yes*
 
 * *variance*
 
   * **Description**: *variance* denotes a variance of adjusting bounding boxes. The attribute could be 0, 1 or 4 elements.
   * **Range of values**: floating-point positive numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Default value**: []
   * **Required**: *no*
 
 **Inputs**:
 
-*   **1**: `output_size` - 1D tensor of type *T_INT* with two elements `[height, width]`. Specifies the spatial size of generated grid with boxes. Required.
+*   **1**: ``output_size`` - 1D tensor of type *T_INT* with two elements ``[height, width]``. Specifies the spatial size of generated grid with boxes. Required.
 
-*   **2**: `image_size` - 1D tensor of type *T_INT* with two elements `[image_height, image_width]` that specifies shape of the image for which boxes are generated. Optional.
+*   **2**: ``image_size`` - 1D tensor of type *T_INT* with two elements ``[image_height, image_width]`` that specifies shape of the image for which boxes are generated. Optional.
 
 **Outputs**:
 
-*   **1**: 2D tensor of shape `[2, 4 * height * width * priors_per_point]` and type *T_OUT* with box coordinates. The `priors_per_point` is the number of boxes generated per each grid element. The number depends on layer attribute values.
+*   **1**: 2D tensor of shape ``[2, 4 * height * width * priors_per_point]`` and type *T_OUT* with box coordinates. The ``priors_per_point`` is the number of boxes generated per each grid element. The number depends on layer attribute values.
 
 **Types**
 
@@ -102,22 +127,26 @@ If *clip* is defined, the coordinates of prior boxes are recalculated with the f
 
 **Example**
 
-```xml
-<layer type="PriorBoxClustered" ... >
-    <data clip="false" height="44.0,10.0,30.0,19.0,94.0,32.0,61.0,53.0,17.0" offset="0.5" step="16.0" variance="0.1,0.1,0.2,0.2" width="86.0,13.0,57.0,39.0,68.0,34.0,142.0,50.0,23.0"/>
-    <input>
-        <port id="0">
-            <dim>2</dim>        <!-- [10, 19] -->
-        </port>
-        <port id="1">
-            <dim>2</dim>        <!-- [180, 320] -->
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>2</dim>
-            <dim>6840</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block::  cpp  
+
+  <layer type="PriorBoxClustered" ... >
+      <data clip="false" height="44.0,10.0,30.0,19.0,94.0,32.0,61.0,53.0,17.0" offset="0.5" step="16.0" variance="0.1,0.1,0.2,0.2" width="86.0,13.0,57.0,39.0,68.0,34.0,142.0,50.0,23.0"/>
+      <input>
+          <port id="0">
+              <dim>2</dim>        < !-- [10, 19] -->
+          </port>
+          <port id="1">
+              <dim>2</dim>        < !-- [180, 320] -->
+          </port>
+      </input>
+      <output>
+          <port id="2">
+              <dim>2</dim>
+              <dim>6840</dim>
+          </port>
+      </output>
+  </layer>
+
+@endsphinxdirective
+
+

docs/ops/detection/PriorBox_1.md

@@ -1,5 +1,8 @@
 # PriorBox {#openvino_docs_ops_detection_PriorBox_1}
 
+
+@sphinxdirective
+
 **Versioned name**: *PriorBox-1*
 
 **Category**: *Object detection*
@@ -9,37 +12,51 @@
 **Detailed description**:
 
 *PriorBox* computes coordinates of prior boxes by following:
+
 1.  First calculates *center_x* and *center_y* of prior box:
-    \f[
-    W \equiv Width \quad Of \quad Image \\
-    H \equiv Height \quad Of \quad Image
-    \f]
-    *   If step equals 0:
-        \f[
-        center_x=(w+0.5) \\
-        center_y=(h+0.5)
-        \f]
-    *   else:
-        \f[
-        center_x=(w+offset)*step \\
-        center_y=(h+offset)*step \\
-        w \subset \left( 0, W \right ) \\
-        h \subset \left( 0, H \right )
-        \f]
-2.  Then, for each \f$ s \subset \left( 0, min\_sizes \right ) \f$ calculates coordinates of prior boxes:
-    \f[
-    xmin = \frac{\frac{center_x - s}{2}}{W}
-    \f]
-    \f[
-    ymin = \frac{\frac{center_y - s}{2}}{H}
-    \f]
-    \f[
-    xmax = \frac{\frac{center_x + s}{2}}{W}
-    \f]
-    \f[
-    ymin = \frac{\frac{center_y + s}{2}}{H}
-    \f]
-3. If *clip* attribute is set to true, each output value is clipped between \f$ \left< 0, 1 \right> \f$.
+
+.. math::
+   
+  W \equiv Width \quad Of \quad Image \\ H \equiv Height \quad Of \quad Image
+   
+   
+* If step equals 0:
+     
+.. math::
+     
+   center_x=(w+0.5) \\ center_y=(h+0.5)
+   
+* else:
+     
+.. math::
+     
+   center_x=(w+offset)*step \\ center_y=(h+offset)*step \\ w \subset \left( 0, W \right ) \\ h \subset \left( 0, H \right )
+
+2.  Then, for each :math:`s \subset \left( 0, min\_sizes \right )` calculates coordinates of prior boxes:
+
+.. math::
+   
+  	xmin = \frac{\frac{center_x - s}{2}}{W}
+   
+   
+   
+.. math::
+   
+   	ymin = \frac{\frac{center_y - s}{2}}{H}
+   
+   
+   
+.. math::
+   
+   	xmax = \frac{\frac{center_x + s}{2}}{W}
+   
+   
+   
+.. math::
+   
+   	ymin = \frac{\frac{center_y + s}{2}}{H}
+
+3. If *clip* attribute is set to true, each output value is clipped between :math:`\left< 0, 1 \right>`.
 
 **Attributes**:
 
@@ -47,7 +64,7 @@
 
   * **Description**: *min_size (max_size)* is the minimum (maximum) box size (in pixels).
   * **Range of values**: positive floating-point numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Default value**: []
   * **Required**: *no*
 
@@ -55,27 +72,29 @@
 
   * **Description**: *aspect_ratio* is a variance of aspect ratios. Duplicate values are ignored.
   * **Range of values**: set of positive integer numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Default value**: []
   * **Required**: *no*
 
 * *flip*
 
-  * **Description**: *flip* is a flag that denotes that each *aspect_ratio* is duplicated and flipped. For example, *flip* equals 1 and *aspect_ratio* equals to `[4.0,2.0]` mean that aspect_ratio is equal to `[4.0,2.0,0.25,0.5]`.
+  * **Description**: *flip* is a flag that denotes that each *aspect_ratio* is duplicated and flipped. For example, *flip* equals 1 and *aspect_ratio* equals to ``[4.0,2.0]`` mean that aspect_ratio is equal to ``[4.0,2.0,0.25,0.5]``.
   * **Range of values**:
+
     * false or 0 - each *aspect_ratio* is flipped
     * true or 1  - each *aspect_ratio* is not flipped
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: false
   * **Required**: *no*
 
 * *clip*
 
-  * **Description**: *clip* is a flag that denotes if each value in the output tensor should be clipped to `[0,1]` interval.
+  * **Description**: *clip* is a flag that denotes if each value in the output tensor should be clipped to ``[0,1]`` interval.
   * **Range of values**:
+
     * false or 0 - clipping is not performed
-    * true or 1 - each value in the output tensor is clipped to `[0,1]` interval.
-  * **Type**: `boolean`
+    * true or 1 - each value in the output tensor is clipped to ``[0,1]`` interval.
+  * **Type**: ``boolean``
   * **Default value**: false
   * **Required**: *no*
 
@@ -83,7 +102,7 @@
 
   * **Description**: *step* is a distance between box centers.
   * **Range of values**: floating-point non-negative number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Default value**: 0
   * **Required**: *no*
 
@@ -91,14 +110,14 @@
 
   * **Description**: *offset* is a shift of box respectively to top left corner.
   * **Range of values**: floating-point non-negative number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Required**: *yes*
 
 * *variance*
 
   * **Description**: *variance* denotes a variance of adjusting bounding boxes. The attribute could contain 0, 1 or 4 elements.
   * **Range of values**: floating-point positive numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Default value**: []
   * **Required**: *no*
 
@@ -106,45 +125,46 @@
 
   * **Description**: *scale_all_sizes* is a flag that denotes type of inference. For example, *scale_all_sizes* equals 0 means that *max_size* attribute is ignored.
   * **Range of values**:
+
     * false - *max_size* is ignored
     * true  - *max_size* is used
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: true
   * **Required**: *no*
 
 * *fixed_ratio*
 
-    * **Description**: *fixed_ratio* is an aspect ratio of a box.
-    * **Range of values**: a list of positive floating-point numbers
-    * **Type**: `float[]`
-    * **Default value**: []
-    * **Required**: *no*
+  * **Description**: *fixed_ratio* is an aspect ratio of a box.
+  * **Range of values**: a list of positive floating-point numbers
+  * **Type**: ``float[]``
+  * **Default value**: []
+  * **Required**: *no*
 
 * *fixed_size*
 
-    * **Description**: *fixed_size* is an initial box size (in pixels).
-    * **Range of values**: a list of positive floating-point numbers
-    * **Type**: `float[]`
-    * **Default value**: []
-    * **Required**: *no*
+  * **Description**: *fixed_size* is an initial box size (in pixels).
+  * **Range of values**: a list of positive floating-point numbers
+  * **Type**: ``float[]``
+  * **Default value**: []
+  * **Required**: *no*
 
 * *density*
 
-    * **Description**: *density* is the square root of the number of boxes of each type.
-    * **Range of values**: a list of positive floating-point numbers
-    * **Type**: `float[]`
-    * **Default value**: []
-    * **Required**: *no*
+  * **Description**: *density* is the square root of the number of boxes of each type.
+  * **Range of values**: a list of positive floating-point numbers
+  * **Type**: ``float[]``
+  * **Default value**: []
+  * **Required**: *no*
 
 **Inputs**:
 
-*   **1**: `output_size` - 1D tensor of type *T_INT* with two elements `[height, width]`. Specifies the spatial size of generated grid with boxes. **Required.**
+*   **1**: ``output_size`` - 1D tensor of type *T_INT* with two elements ``[height, width]``. Specifies the spatial size of generated grid with boxes. **Required.**
 
-*   **2**: `image_size` - 1D tensor of type *T_INT* with two elements `[image_height, image_width]` that specifies shape of the image for which boxes are generated. **Required.**
+*   **2**: ``image_size`` - 1D tensor of type *T_INT* with two elements ``[image_height, image_width]`` that specifies shape of the image for which boxes are generated. **Required.**
 
 **Outputs**:
 
-*   **1**: 2D tensor of shape `[2, 4 * height * width * priors_per_point]` and type *T_OUT* with box coordinates. The `priors_per_point` is the number of boxes generated per each grid element. The number depends on operation attribute values.
+*   **1**: 2D tensor of shape ``[2, 4 * height * width * priors_per_point]`` and type *T_OUT* with box coordinates. The ``priors_per_point`` is the number of boxes generated per each grid element. The number depends on operation attribute values.
 
 **Types**
 
@@ -153,22 +173,26 @@
 
 **Example**
 
-```xml
-<layer type="PriorBox" ...>
-    <data aspect_ratio="2.0" clip="false" density="" fixed_ratio="" fixed_size="" flip="true" max_size="38.46" min_size="16.0" offset="0.5" step="16.0" variance="0.1,0.1,0.2,0.2"/>
-    <input>
-        <port id="0">
-            <dim>2</dim>        <!-- values: [24, 42] -->
-        </port>
-        <port id="1">
-            <dim>2</dim>        <!-- values: [384, 672] -->
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>2</dim>
-            <dim>16128</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block::  cpp 
+
+  <layer type="PriorBox" ...>
+      <data aspect_ratio="2.0" clip="false" density="" fixed_ratio="" fixed_size="" flip="true" max_size="38.46" min_size="16.0" offset="0.5" step="16.0" variance="0.1,0.1,0.2,0.2"/>
+      <input>
+          <port id="0">
+              <dim>2</dim>        < !-- values: [24, 42] -->
+          </port>
+          <port id="1">
+              <dim>2</dim>        < !-- values: [384, 672] -->
+          </port>
+      </input>
+      <output>
+          <port id="2">
+              <dim>2</dim>
+              <dim>16128</dim>
+          </port>
+      </output>
+  </layer>
+
+
+@endsphinxdirective
+

docs/ops/detection/PriorBox_8.md

@@ -1,5 +1,7 @@
 # PriorBox {#openvino_docs_ops_detection_PriorBox_8}
 
+@sphinxdirective
+
 **Versioned name**: *PriorBox-8*
 
 **Category**: *Object detection*
@@ -9,37 +11,48 @@
 **Detailed description**:
 
 *PriorBox* computes coordinates of prior boxes by the following rules:
+
 1.  First, it calculates *center_x* and *center_y* of a prior box:
-    \f[
-    W \equiv Width \quad Of \quad Image \\
-    H \equiv Height \quad Of \quad Image
-    \f]
-    *   If step equals 0:
-        \f[
-        center_x=(w+0.5) \\
-        center_y=(h+0.5)
-        \f]
-    *   else:
-        \f[
-        center_x=(w+offset)*step \\
-        center_y=(h+offset)*step \\
-        w \subset \left( 0, W \right ) \\
-        h \subset \left( 0, H \right )
-        \f]
-2.  Then, it calculates coordinates of prior boxes for each \f$ s \subset \left( 0, min\_sizes \right ) \f$:
-    \f[
-    xmin = \frac{\frac{center_x - s}{2}}{W}
-    \f]
-    \f[
-    ymin = \frac{\frac{center_y - s}{2}}{H}
-    \f]
-    \f[
-    xmax = \frac{\frac{center_x + s}{2}}{W}
-    \f]
-    \f[
-    ymin = \frac{\frac{center_y + s}{2}}{H}
-    \f]
-3. If *clip* attribute is set to true, each output value is clipped between \f$ \left< 0, 1 \right> \f$.
+
+.. math::
+   
+  W \equiv Width \quad Of \quad Image \\ H \equiv Height \quad Of \quad Image
+
+*   If step equals 0:
+
+.. math::
+     
+  center_x=(w+0.5) \\ center_y=(h+0.5)
+
+*   else:
+
+.. math::
+    
+  center_x=(w+offset)*step \\ center_y=(h+offset)*step \\ w \subset \left( 0, W \right ) \\ h \subset \left( 0, H \right )
+
+2.  Then, it calculates coordinates of prior boxes for each :math:`s \subset \left( 0, min\_sizes \right )` :
+
+.. math::
+   
+  xmin = \frac{\frac{center_x - s}{2}}{W}
+   
+   
+  
+ .. math::
+   
+  ymin = \frac{\frac{center_y - s}{2}}{H}
+   
+     
+.. math::
+   
+  xmax = \frac{\frac{center_x + s}{2}}{W}
+   
+     
+.. math::
+   
+  ymin = \frac{\frac{center_y + s}{2}}{H}
+
+3. If *clip* attribute is set to true, each output value is clipped between :math:`\left< 0, 1 \right>`.
 
 **Attributes**:
 
@@ -47,7 +60,7 @@
 
   * **Description**: *min_size (max_size)* is the minimum (maximum) box size in pixels.
   * **Range of values**: positive floating-point numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Default value**: []
   * **Required**: *no*
 
@@ -55,27 +68,29 @@
 
   * **Description**: *aspect_ratio* is a variance of aspect ratios. Duplicate values are ignored.
   * **Range of values**: a set of positive integer numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Default value**: []
   * **Required**: *no*
 
 * *flip*
 
-  * **Description**: *flip* is a flag that denotes that each *aspect_ratio* is duplicated and flipped. For example, *flip* equals 1 and *aspect_ratio* equals `[4.0,2.0]`, meaning that the aspect_ratio is equal to `[4.0,2.0,0.25,0.5]`.
+  * **Description**: *flip* is a flag that denotes that each *aspect_ratio* is duplicated and flipped. For example, *flip* equals 1 and *aspect_ratio* equals ``[4.0,2.0]``, meaning that the aspect_ratio is equal to ``[4.0,2.0,0.25,0.5]``.
   * **Range of values**:
+  
     * false or 0 - each *aspect_ratio* is flipped
     * true or 1  - each *aspect_ratio* is not flipped
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: false
   * **Required**: *no*
 
 * *clip*
 
-  * **Description**: *clip* is a flag that denotes if each value in the output tensor should be clipped to the `[0,1]` interval.
+  * **Description**: *clip* is a flag that denotes if each value in the output tensor should be clipped to the ``[0,1]`` interval.
   * **Range of values**:
+
     * false or 0 - clipping is not performed
-    * true or 1 - each value in the output tensor is clipped to the `[0,1]` interval.
-  * **Type**: `boolean`
+    * true or 1 - each value in the output tensor is clipped to the ``[0,1]`` interval.
+  * **Type**: ``boolean``
   * **Default value**: false
   * **Required**: *no*
 
@@ -106,6 +121,7 @@
 
   * **Description**: *scale_all_sizes* is a flag that denotes type of inference. For example, *scale_all_sizes* equals 0 means that *max_size* attribute is ignored.
   * **Range of values**:
+
     * false - *max_size* is ignored
     * true  - *max_size* is used
   * **Type**: `boolean`
@@ -114,47 +130,48 @@
 
 * *fixed_ratio*
 
-    * **Description**: *fixed_ratio* is an aspect ratio of a box.
-    * **Range of values**: a list of positive floating-point numbers
-    * **Type**: `float[]`
-    * **Default value**: []
-    * **Required**: *no*
+  * **Description**: *fixed_ratio* is an aspect ratio of a box.
+  * **Range of values**: a list of positive floating-point numbers
+  * **Type**: ``float[]``
+  * **Default value**: []
+  * **Required**: *no*
 
 * *fixed_size*
 
-    * **Description**: *fixed_size* is an initial box size in pixels.
-    * **Range of values**: a list of positive floating-point numbers
-    * **Type**: `float[]`
-    * **Default value**: []
-    * **Required**: *no*
+  * **Description**: *fixed_size* is an initial box size in pixels.
+  * **Range of values**: a list of positive floating-point numbers
+  * **Type**: ``float[]``
+  * **Default value**: []
+  * **Required**: *no*
 
 * *density*
 
-    * **Description**: *density* is the square root of the number of boxes of each type.
-    * **Range of values**: a list of positive floating-point numbers
-    * **Type**: `float[]`
-    * **Default value**: []
-    * **Required**: *no*
+  * **Description**: *density* is the square root of the number of boxes of each type.
+  * **Range of values**: a list of positive floating-point numbers
+  * **Type**: ``float[]``
+  * **Default value**: []
+  * **Required**: *no*
 
 * *min_max_aspect_ratios_order*
 
   * **Description**: *min_max_aspect_ratios_order* is a flag that denotes the order of output prior box. If set true, the output prior box is in [min, max, aspect_ratios] order, which is consistent with Caffe. Note that the order affects the weights order of the preceding convolution layer and does not affect the final detection results.
   * **Range of values**:
+
     * false - the output prior box is in [min, aspect_ratios, max] order
     * true  - the output prior box is in [min, max, aspect_ratios] order
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: true
   * **Required**: *no*
 
 **Inputs**:
 
-*   **1**: `output_size` - 1D tensor of type *T_INT* with two elements `[height, width]`. Specifies the spatial size of generated grid with boxes. **Required.**
+*   **1**: ``output_size`` - 1D tensor of type *T_INT* with two elements ``[height, width]``. Specifies the spatial size of generated grid with boxes. **Required.**
 
-*   **2**: `image_size` - 1D tensor of type *T_INT* with two elements `[image_height, image_width]`. Specifies shape of the image for which boxes are generated. **Required.**
+*   **2**: ``image_size`` - 1D tensor of type *T_INT* with two elements ``[image_height, image_width]``. Specifies shape of the image for which boxes are generated. **Required.**
 
 **Outputs**:
 
-*   **1**: 2D tensor of shape `[2, 4 * height * width * priors_per_point]` and type *T_OUT* with box coordinates. The `priors_per_point` is the number of boxes generated per each grid element. The number depends on operation attribute values.
+*   **1**: 2D tensor of shape ``[2, 4 * height * width * priors_per_point]`` and type *T_OUT* with box coordinates. The ``priors_per_point`` is the number of boxes generated per each grid element. The number depends on operation attribute values.
 
 **Types**
 
@@ -163,22 +180,25 @@
 
 **Example**
 
-```xml
-<layer type="PriorBox" ...>
-    <data aspect_ratio="2.0" clip="false" density="" fixed_ratio="" fixed_size="" flip="true" max_size="38.46" min_size="16.0" offset="0.5" step="16.0" variance="0.1,0.1,0.2,0.2"/>
-    <input>
-        <port id="0">
-            <dim>2</dim>        <!-- values: [24, 42] -->
-        </port>
-        <port id="1">
-            <dim>2</dim>        <!-- values: [384, 672] -->
-        </port>
-    </input>
-    <output>
-        <port id="2">
-            <dim>2</dim>
-            <dim>16128</dim>
-        </port>
-    </output>
-</layer>
-```
+.. code-block::  cpp 
+
+  <layer type="PriorBox" ...>
+      <data aspect_ratio="2.0" clip="false" density="" fixed_ratio="" fixed_size="" flip="true" max_size="38.46" min_size="16.0" offset="0.5" step="16.0" variance="0.1,0.1,0.2,0.2"/>
+      <input>
+          <port id="0">
+              <dim>2</dim>        < !-- values: [24, 42] -->
+          </port>
+          <port id="1">
+              <dim>2</dim>        < !-- values: [384, 672] -->
+          </port>
+      </input>
+      <output>
+          <port id="2">
+              <dim>2</dim>
+              <dim>16128</dim>
+          </port>
+      </output>
+  </layer>
+
+@endsphinxdirective
+

docs/ops/detection/Proposal_1.md

@@ -1,5 +1,7 @@
 # Proposal {#openvino_docs_ops_detection_Proposal_1}
 
+@sphinxdirective
+
 **Versioned name**: *Proposal-1*
 
 **Category**: *Object detection*
@@ -8,16 +10,19 @@
 
 **Detailed description**
 
-*Proposal* has three inputs: a tensor with probabilities whether particular bounding box corresponds to background and foreground, a tensor with bbox_deltas for each of the bounding boxes, a tensor with input image size in the [`image_height`, `image_width`, `scale_height_and_width`] or [`image_height`, `image_width`, `scale_height`, `scale_width`] format. The produced tensor has two dimensions `[batch_size * post_nms_topn, 5]`, and for each output box contains batch index and box coordinates.
+*Proposal* has three inputs: a tensor with probabilities whether particular bounding box corresponds to background and foreground, a tensor with bbox_deltas for each of the bounding boxes, a tensor with input image size in the [``image_height``, ``image_width``, ``scale_height_and_width``] or [``image_height``, ``image_width``, ``scale_height``, ``scale_width``] format. The produced tensor has two dimensions ``[batch_size * post_nms_topn, 5]``, and for each output box contains batch index and box coordinates.
 *Proposal* layer does the following with the input tensor:
+
 1.  Generates initial anchor boxes. Left top corner of all boxes is at (0, 0). Width and height of boxes are calculated from *base_size* with *scale* and *ratio* attributes.
 2.  For each point in the first input tensor:
-    *   pins anchor boxes to the image according to the second input tensor that contains four deltas for each box: for *x* and *y* of center, for *width* and for *height*
-    *   finds out score in the first input tensor
+
+  * pins anchor boxes to the image according to the second input tensor that contains four deltas for each box: for *x* and *y* of center, for *width* and for *height*
+  * finds out score in the first input tensor
+
 3.  Filters out boxes with size less than *min_size*
 4.  Sorts all proposals (*box*, *score*) by score from highest to lowest
 5.  Takes top *pre_nms_topn* proposals
-6.  Calculates intersections for boxes and filter out all boxes with \f$intersection/union > nms\_thresh\f$
+6.  Calculates intersections for boxes and filter out all boxes with :math:`intersection/union > nms\_thresh`
 7.  Takes top *post_nms_topn* proposals
 8.  Returns top proposals, if there is not enough proposals to fill the whole output tensor, the valid proposals will be terminated with a single -1.
 
@@ -27,61 +32,63 @@
 
   * **Description**: *base_size* is the size of the anchor to which *scale* and *ratio* attributes are applied.
   * **Range of values**: a positive integer number
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *pre_nms_topn*
+
   * **Description**: *pre_nms_topn* is the number of bounding boxes before the NMS operation. For example, *pre_nms_topn* equal to 15 means to take top 15 boxes with the highest scores.
   * **Range of values**: a positive integer number
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *post_nms_topn*
+
   * **Description**: *post_nms_topn* is the number of bounding boxes after the NMS operation. For example, *post_nms_topn* equal to 15 means to take after NMS top 15 boxes with the highest scores.
   * **Range of values**: a positive integer number
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *nms_thresh*
 
   * **Description**: *nms_thresh* is the minimum value of the proposal to be taken into consideration. For example, *nms_thresh* equal to 0.5 means that all boxes with prediction probability less than 0.5 are filtered out.
   * **Range of values**: a positive floating-point number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Required**: *yes*
 
 * *feat_stride*
 
   * **Description**: *feat_stride* is the step size to slide over boxes (in pixels). For example, *feat_stride* equal to 16 means that all boxes are analyzed with the slide 16.
   * **Range of values**: a positive integer
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *min_size*
 
   * **Description**: *min_size* is the minimum size of box to be taken into consideration. For example, *min_size* equal 35 means that all boxes with box size less than 35 are filtered out.
   * **Range of values**: a positive integer number
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *ratio*
 
   * **Description**: *ratio* is the ratios for anchor generation.
   * **Range of values**: a list of floating-point numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Required**: *yes*
 
 * *scale*
 
   * **Description**: *scale* is the scales for anchor generation.
   * **Range of values**: a list of floating-point numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Required**: *yes*
 
 * *clip_before_nms*
 
   * **Description**: *clip_before_nms* flag that specifies whether to perform clip bounding boxes before non-maximum suppression or not.
   * **Range of values**: true or false
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: true
   * **Required**: *no*
 
@@ -89,7 +96,7 @@
 
   * **Description**: *clip_after_nms* is a flag that specifies whether to perform clip bounding boxes after non-maximum suppression or not.
   * **Range of values**: true or false
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: false
   * **Required**: *no*
 
@@ -97,7 +104,7 @@
 
   * **Description**: *normalize* is a flag that specifies whether to perform normalization of output boxes to *[0,1]* interval or not.
   * **Range of values**: true or false
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: false
   * **Required**: *no*
 
@@ -105,7 +112,7 @@
 
   * **Description**: *box_size_scale* specifies the scale factor applied to bbox_deltas of box sizes before decoding.
   * **Range of values**: a positive floating-point number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Default value**: 1.0
   * **Required**: *no*
 
@@ -113,7 +120,7 @@
 
   * **Description**: *box_coordinate_scale* specifies the scale factor applied to bbox_deltas of box coordinates before decoding.
   * **Range of values**: a positive floating-point number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Default value**: 1.0
   * **Required**: *no*
 
@@ -121,6 +128,7 @@
 
   * **Description**: *framework* specifies how the box coordinates are calculated.
   * **Range of values**:
+  
     * "" (empty string) - calculate box coordinates like in Caffe*
     * *tensorflow* - calculate box coordinates like in the TensorFlow* Object Detection API models
   * **Type**: string
@@ -129,15 +137,15 @@
 
 **Inputs**:
 
-*   **1**: 4D tensor of type *T* and shape `[batch_size, 2*K, H, W]` with class prediction scores. **Required.**
+*   **1**: 4D tensor of type *T* and shape ``[batch_size, 2*K, H, W]`` with class prediction scores. **Required.**
 
-*   **2**: 4D tensor of type *T* and shape `[batch_size, 4*K, H, W]` with deltas for each bounding box. **Required.**
+*   **2**: 4D tensor of type *T* and shape ``[batch_size, 4*K, H, W]`` with deltas for each bounding box. **Required.**
 
-*   **3**: 1D tensor of type *T* with 3 or 4 elements:  `[image_height, image_width, scale_height_and_width]` or `[image_height, image_width, scale_height, scale_width]`. **Required.**
+*   **3**: 1D tensor of type *T* with 3 or 4 elements:  ``[image_height, image_width, scale_height_and_width]`` or ``[image_height, image_width, scale_height, scale_width]``. **Required.**
 
 **Outputs**:
 
-*   **1**: Tensor of type *T* and shape `[batch_size * post_nms_topn, 5]`.
+*   **1**: Tensor of type *T* and shape ``[batch_size * post_nms_topn, 5]``.
 
 **Types**
 
@@ -145,11 +153,13 @@
 
 **Example**
 
-```xml
-<layer ... type="Proposal" ... >
-    <data base_size="16" feat_stride="16" min_size="16" nms_thresh="0.6" post_nms_topn="200" pre_nms_topn="6000"
-     ratio="2.67" scale="4.0,6.0,9.0,16.0,24.0,32.0"/>
-    <input> ... </input>
-    <output> ... </output>
-</layer>
-```
+.. code-block::  cpp 
+
+  <layer ... type="Proposal" ... >
+      <data base_size="16" feat_stride="16" min_size="16" nms_thresh="0.6" post_nms_topn="200" pre_nms_topn="6000"
+      ratio="2.67" scale="4.0,6.0,9.0,16.0,24.0,32.0"/>
+      <input> ... </input>
+      <output> ... </output>
+  </layer>
+
+@endsphinxdirective

docs/ops/detection/Proposal_4.md

@@ -1,5 +1,8 @@
 # Proposal {#openvino_docs_ops_detection_Proposal_4}
 
+@sphinxdirective
+
+
 **Versioned name**: *Proposal-4*
 
 **Category**: *Object detection*
@@ -8,27 +11,31 @@
 
 **Detailed description**
 
-*Proposal* has three inputs: a 4D tensor of shape `[num_batches, 2*K, H, W]` with probabilities whether particular
-bounding box corresponds to background or foreground, a 4D tensor of shape `[num_batches, 4*K, H, W]` with deltas for each
-of the bound box, and a tensor with input image size in the `[image_height, image_width, scale_height_and_width]` or
-`[image_height, image_width, scale_height, scale_width]` format. `K` is number of anchors and `H, W` are height and
+*Proposal* has three inputs: a 4D tensor of shape ``[num_batches, 2*K, H, W]`` with probabilities whether particular
+bounding box corresponds to background or foreground, a 4D tensor of shape ``[num_batches, 4*K, H, W]`` with deltas for each
+of the bound box, and a tensor with input image size in the ``[image_height, image_width, scale_height_and_width]`` or
+``[image_height, image_width, scale_height, scale_width]`` format. ``K`` is number of anchors and ``H, W`` are height and
 width of the feature map. Operation produces two tensors:
-the first mandatory tensor of shape `[batch_size * post_nms_topn, 5]` with proposed boxes and
-the second optional tensor of shape `[batch_size * post_nms_topn]` with probabilities (sometimes referred as scores).
+the first mandatory tensor of shape ``[batch_size * post_nms_topn, 5]`` with proposed boxes and
+the second optional tensor of shape ``[batch_size * post_nms_topn]`` with probabilities (sometimes referred as scores).
 
 *Proposal* layer does the following with the input tensor:
+
 1.  Generates initial anchor boxes. Left top corner of all boxes is at (0, 0). Width and height of boxes are calculated from *base_size* with *scale* and *ratio* attributes.
 2.  For each point in the first input tensor:
-    *   pins anchor boxes to the image according to the second input tensor that contains four deltas for each box: for *x* and *y* of center, for *width* and for *height*
-    *   finds out score in the first input tensor
+
+  * pins anchor boxes to the image according to the second input tensor that contains four deltas for each box: for *x* and *y* of center, for *width* and for *height*
+  * finds out score in the first input tensor
+  
 3.  Filters out boxes with size less than *min_size*
 4.  Sorts all proposals (*box*, *score*) by score from highest to lowest
 5.  Takes top *pre_nms_topn* proposals
-6.  Calculates intersections for boxes and filter out all boxes with \f$intersection/union > nms\_thresh\f$
+6.  Calculates intersections for boxes and filter out all boxes with :math:`intersection/union > nms\_thresh`
 7.  Takes top *post_nms_topn* proposals
 8.  Returns the results:
-    *   Top proposals, if there is not enough proposals to fill the whole output tensor, the valid proposals will be terminated with a single -1.
-    *   Optionally returns probabilities for each proposal, which are not terminated by any special value.
+
+  * Top proposals, if there is not enough proposals to fill the whole output tensor, the valid proposals will be terminated with a single -1.
+  * Optionally returns probabilities for each proposal, which are not terminated by any special value.
 
 **Attributes**:
 
@@ -36,61 +43,63 @@ the second optional tensor of shape `[batch_size * post_nms_topn]` with probabil
 
   * **Description**: *base_size* is the size of the anchor to which *scale* and *ratio* attributes are applied.
   * **Range of values**: a positive integer number
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *pre_nms_topn*
+
   * **Description**: *pre_nms_topn* is the number of bounding boxes before the NMS operation. For example, *pre_nms_topn* equal to 15 means to take top 15 boxes with the highest scores.
   * **Range of values**: a positive integer number
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *post_nms_topn*
+
   * **Description**: *post_nms_topn* is the number of bounding boxes after the NMS operation. For example, *post_nms_topn* equal to 15 means to take after NMS top 15 boxes with the highest scores.
   * **Range of values**: a positive integer number
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *nms_thresh*
 
   * **Description**: *nms_thresh* is the minimum value of the proposal to be taken into consideration. For example, *nms_thresh* equal to 0.5 means that all boxes with prediction probability less than 0.5 are filtered out.
   * **Range of values**: a positive floating-point number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Required**: *yes*
 
 * *feat_stride*
 
   * **Description**: *feat_stride* is the step size to slide over boxes (in pixels). For example, *feat_stride* equal to 16 means that all boxes are analyzed with the slide 16.
   * **Range of values**: a positive integer
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *min_size*
 
   * **Description**: *min_size* is the minimum size of box to be taken into consideration. For example, *min_size* equal 35 means that all boxes with box size less than 35 are filtered out.
   * **Range of values**: a positive integer number
-  * **Type**: `int`
+  * **Type**: ``int``
   * **Required**: *yes*
 
 * *ratio*
 
   * **Description**: *ratio* is the ratios for anchor generation.
   * **Range of values**: a list of floating-point numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Required**: *yes*
 
 * *scale*
 
   * **Description**: *scale* is the scales for anchor generation.
   * **Range of values**: a list of floating-point numbers
-  * **Type**: `float[]`
+  * **Type**: ``float[]``
   * **Required**: *yes*
 
 * *clip_before_nms*
 
   * **Description**: *clip_before_nms* flag that specifies whether to perform clip bounding boxes before non-maximum suppression or not.
   * **Range of values**: true or false
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: true
   * **Required**: *no*
 
@@ -98,7 +107,7 @@ the second optional tensor of shape `[batch_size * post_nms_topn]` with probabil
 
   * **Description**: *clip_after_nms* is a flag that specifies whether to perform clip bounding boxes after non-maximum suppression or not.
   * **Range of values**: true or false
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: false
   * **Required**: *no*
 
@@ -106,7 +115,7 @@ the second optional tensor of shape `[batch_size * post_nms_topn]` with probabil
 
   * **Description**: *normalize* is a flag that specifies whether to perform normalization of output boxes to *[0,1]* interval or not.
   * **Range of values**: true or false
-  * **Type**: `boolean`
+  * **Type**: ``boolean``
   * **Default value**: false
   * **Required**: *no*
 
@@ -114,7 +123,7 @@ the second optional tensor of shape `[batch_size * post_nms_topn]` with probabil
 
   * **Description**: *box_size_scale* specifies the scale factor applied to box sizes before decoding.
   * **Range of values**: a positive floating-point number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Default value**: 1.0
   * **Required**: *no*
 
@@ -122,7 +131,7 @@ the second optional tensor of shape `[batch_size * post_nms_topn]` with probabil
 
   * **Description**: *box_coordinate_scale* specifies the scale factor applied to box coordinates before decoding.
   * **Range of values**: a positive floating-point number
-  * **Type**: `float`
+  * **Type**: ``float``
   * **Default value**: 1.0
   * **Required**: *no*
 
@@ -130,6 +139,7 @@ the second optional tensor of shape `[batch_size * post_nms_topn]` with probabil
 
   * **Description**: *framework* specifies how the box coordinates are calculated.
   * **Range of values**:
+
     * "" (empty string) - calculate box coordinates like in Caffe*
     * *tensorflow* - calculate box coordinates like in the TensorFlow* Object Detection API models
   * **Type**: string
@@ -138,17 +148,17 @@ the second optional tensor of shape `[batch_size * post_nms_topn]` with probabil
 
 **Inputs**:
 
-*   **1**: 4D tensor of type *T* and shape `[batch_size, 2*K, H, W]` with class prediction scores. **Required.**
+*   **1**: 4D tensor of type *T* and shape ``[batch_size, 2*K, H, W]`` with class prediction scores. **Required.**
 
-*   **2**: 4D tensor of type *T* and shape `[batch_size, 4*K, H, W]` with deltas for each bounding box. **Required.**
+*   **2**: 4D tensor of type *T* and shape ``[batch_size, 4*K, H, W]`` with deltas for each bounding box. **Required.**
 
-*   **3**: 1D tensor of type *T* with 3 or 4 elements:  `[image_height, image_width, scale_height_and_width]` or `[image_height, image_width, scale_height, scale_width]`. **Required.**
+*   **3**: 1D tensor of type *T* with 3 or 4 elements:  ``[image_height, image_width, scale_height_and_width]`` or ``[image_height, image_width, scale_height, scale_width]``. **Required.**
 
 **Outputs**
 
-*   **1**: tensor of type *T* and shape `[batch_size * post_nms_topn, 5]`.
+*   **1**: tensor of type *T* and shape ``[batch_size * post_nms_topn, 5]``.
 
-*   **2**: tensor of type *T* and shape `[batch_size * post_nms_topn]` with probabilities.
+*   **2**: tensor of type *T* and shape ``[batch_size * post_nms_topn]`` with probabilities.
 
 **Types**
 
@@ -156,34 +166,40 @@ the second optional tensor of shape `[batch_size * post_nms_topn]` with probabil
 
 **Example**
 
-```xml
-<layer ... type="Proposal" ... >
-    <data base_size="16" feat_stride="8" min_size="16" nms_thresh="1.0" normalize="0" post_nms_topn="1000" pre_nms_topn="1000" ratio="1" scale="1,2"/>
-    <input>
-        <port id="0">
-            <dim>7</dim>
-            <dim>4</dim>
-            <dim>28</dim>
-            <dim>28</dim>
-        </port>
-        <port id="1">
-            <dim>7</dim>
-            <dim>8</dim>
-            <dim>28</dim>
-            <dim>28</dim>
-        </port>
-        <port id="2">
-            <dim>3</dim>
-        </port>
-    </input>
-    <output>
-        <port id="3" precision="FP32">
-            <dim>7000</dim>
-            <dim>5</dim>
-        </port>
-        <port id="4" precision="FP32">
-            <dim>7000</dim>
-        </port>
-    </output>
-</layer>
-```
+
+.. code-block::  cpp 
+
+  <layer ... type="Proposal" ... >
+      <data base_size="16" feat_stride="8" min_size="16" nms_thresh="1.0" normalize="0" post_nms_topn="1000" pre_nms_topn="1000" ratio="1" scale="1,2"/>
+      <input>
+          <port id="0">
+              <dim>7</dim>
+              <dim>4</dim>
+              <dim>28</dim>
+              <dim>28</dim>
+          </port>
+          <port id="1">
+              <dim>7</dim>
+              <dim>8</dim>
+              <dim>28</dim>
+              <dim>28</dim>
+          </port>
+          <port id="2">
+              <dim>3</dim>
+          </port>
+      </input>
+      <output>
+          <port id="3" precision="FP32">
+              <dim>7000</dim>
+              <dim>5</dim>
+          </port>
+          <port id="4" precision="FP32">
+              <dim>7000</dim>
+          </port>
+      </output>
+  </layer>
+
+@endsphinxdirective
+
+
+