Repository: nrfconnect/sdk-nrf
Pull request #21539: doc: High-Performance Framework
Author: login: mif1-nordic
Labels: name: doc-required
description: PR must not be merged without tech writer approval.
name: CI-disable
description: Disable CI for this PR
name: changelog-entry-required
description: Update changelog before merge. Remove label if entry is not needed or already added.
name: backport v3.0-branch
Created: 2025-04-08T14:10:12Z | Merged: 2025-04-16T10:51:21Z



Diff:
diff --git a/applications/hpf/gpio/README.rst b/applications/hpf/gpio/README.rst
index 84e1814c03fd..3201c38863e2 100644
--- a/applications/hpf/gpio/README.rst
+++ b/applications/hpf/gpio/README.rst
@@ -1,21 +1,28 @@
 .. _sdp_gpio:
-.. _hpf_gpio:
+.. _hpf_gpio_example:
 
 High-Performance Framework GPIO
 ###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create a software peripheral on FLPR in High-Performance Framework (HPF) by implementing a subset of Zephyr's GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a :ref:`High-Performance Framework (HPF) <hpf_index>` application implementing a simple peripheral.
+The application implements a subset of the Zephyr GPIO API.
 
-* mbox (:kconfig:option:`SB_CONFIG_HPF_GPIO_BACKEND_MBOX`)
-* icmsg (:kconfig:option:`SB_CONFIG_HPF_GPIO_BACKEND_ICMSG`)
-* icbmsg (:kconfig:option:`SB_CONFIG_HPF_GPIO_BACKEND_ICBMSG`)
+Application overview
+********************
+
+This application shows the implementation of a subset of the Zephyr GPIO API, intended for use with the :zephyr:code-sample:`blinky` sample from Zephyr.
+It supports the mbox, icmsg, and icbmsg IPC backends.
+Depending on your needs, you can enable them with the relevant sysbuild options.
+
+The GPIO HPF application is structured into the following main components:
+
+* The HPF application - Operates on the FLPR core and handles the GPIO state using VIO.
+* The Hard Real Time (HRT) module - Runs on the FLPR core and implements low-level GPIO features.
+* The GPIO driver - Operates on the application core and uses the Zephyr's scalable real-time operating system (RTOS) GPIO API for data and configuration transmission between the application and FLPR cores.
 
 Requirements
 ************
@@ -24,11 +31,24 @@ The firmware supports the following development kit:
 
 .. table-from-sample-yaml::
 
+Configuration
+*************
+
+You can enable the following IPC backends:
+
+* mbox (``SB_CONFIG_HPF_GPIO_BACKEND_MBOX``)
+* icmsg (``SB_CONFIG_HPF_GPIO_BACKEND_ICMSG``)
+* icbmsg (``SB_CONFIG_HPF_GPIO_BACKEND_ICBMSG``)
+
 Building and running
 ********************
 
-You must include code for both the application core and FLPR core.
-The recommended method is to build the :zephyr:code-sample:`blinky` with the necessary sysbuild configuration.
+.. |application path| replace:: :file:`applications/hpf/gpio`
+
+.. include:: /includes/application_build_and_run.txt
+
+To build and run the application, you must include code for both the application core and FLPR core.
+The process involves building the :zephyr:code-sample:`blinky` sample with the appropriate sysbuild configuration.
 
 For example, to build with icmsg backend, run the following commands:
 
@@ -38,3 +58,38 @@ For example, to build with icmsg backend, run the following commands:
      west flash
 
 Upon successful execution, **LED0** will start flashing.
+
+Dependencies
+************
+
+* :file:`zephyr/doc/services/ipc/ipc_service` - Used for transferring data between application core and the FLPR core (if you are not using the mbox backend).
+* :file:`zephyr/doc/hardware/peripherals/mbox.rst` - Used for transferring data between application core and the FLPR core (if you are not using the ipc backend).
+* `nrf HAL <nrfx API documentation_>`_ - Enables access to the VPR CSR registers for direct hardware control.
+
+API documentation
+*****************
+
+Application uses the following API elements:
+
+Zephyr driver
+=============
+
+* Header file: :file:`drivers/gpio/gpio_hpf.h`
+* Source file: :file:`drivers/gpio/gpio_hpf.c`
+
+The following source files depend on the selected IPC backend:
+
+* Source file: :file:`drivers/gpio/gpio_hpf_icmsg.c`
+* Source file: :file:`drivers/gpio/gpio_hpf_mbox.c`
+
+FLPR application
+================
+
+Source file: :file:`applications/hpf/gpio/src/main.c`
+
+FLPR application HRT
+====================
+
+ * Header file: :file:`applications/hpf/gpio/src/hrt/hrt.h`
+ * Source file: :file:`applications/hpf/gpio/src/hrt/hrt.c`
+ * Assembly: :file:`applications/hpf/gpio/src/hrt/hrt-nrf54l15.s`
diff --git a/applications/hpf/hpf.rst b/applications/hpf/hpf.rst
new file mode 100644
index 000000000000..3ebdcaf1f36b
--- /dev/null
+++ b/applications/hpf/hpf.rst
@@ -0,0 +1,19 @@
+.. _hpf_applications_readme:
+
+High-Performance Framework
+##########################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+High-Performance Framework, is a framework designed to facilitate the creation and integration of :ref:`peripheral emulations using coprocessors <coprocessors_index>`.
+The following applications are created using HPF:
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+   :caption: Subpages:
+
+   gpio/README
+   mspi/README
diff --git a/applications/hpf/mspi/README.rst b/applications/hpf/mspi/README.rst
new file mode 100644
index 000000000000..748cce534590
--- /dev/null
+++ b/applications/hpf/mspi/README.rst
@@ -0,0 +1,388 @@
+.. _hpf_mspi_example:
+
+High-Performance Framework MSPI
+###############################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+This application demonstrates how to write a :ref:`High-Performance Framework (HPF) <hpf_index>` application and communicate with it.
+The application implements a subset of the Zephyr MSPI API.
+
+Application overview
+********************
+
+The MSPI HPF application is structured into the following main components:
+
+* :ref:`The HPF application <hpf_mspi_example_api>` - Operates on the FLPR core and facilitates data transmission between the application core and the connected MSPI device.
+* :ref:`The Hard Real Time (HRT) module <hpf_mspi_example_api>` - Runs on the FLPR core and facilitates data transmission between the FLPR core and the connected MSPI device.
+  The module emulates the MSPI hardware peripheral on the FLPR core, managing real-time data transmission and ensuring precise timing and synchronization of data transfer operations.
+* :ref:`The MSPI Zephyr driver <hpf_mspi_example_api>` - Operates on the application core and uses the Zephyr's scalable real-time operating system (RTOS) MSPI API for data and configuration transmission between the application and FLPR cores.
+
+Scope
+*****
+
+The application must meet the following key requirements:
+
+* Compatibility with the MSPI configuration including clock polarity, phase, and the number of data lines or transmission modes (single, quad).
+* Low latency and high throughput.
+
+Requirements
+************
+
+The application supports the following development kits:
+
+.. table-from-sample-yaml::
+
+Configuration and data transfer management
+******************************************
+
+Data transfer between the MSPI driver and the HPF application is done through the ICMsg.
+Data can be configured to be passed either by copy or by reference.
+By default, data is passed by reference.
+To enable data passing by copy, you must disable the ``SDP_MSPI_IPC_NO_COPY`` Kconfig option.
+
+Initialization phase
+====================
+
+The initialization of the MSPI HPF application is divided into two main phases: driver initialization and device initialization.
+
+1. Driver initialization:
+
+   a. A user application calls the :c:func:`mspi_config` function to initialize the MSPI driver.
+   #. The MSPI driver passes the DTS pin configuration to the HPF application.
+   #. The HPF application calls the :c:func:`config_pins` function to initialize GPIO settings based on the received configuration.
+   #. All pins are assigned to specific VIO lines using a mapping array.
+
+2. Device initialization
+
+   a. A user application calls the :c:func:`mspi_dev_config` function to configure the MSPI device.
+   #. The MSPI driver passes selected parts of the configuration to the HPF application.
+   #. The HPF application adds the device configuration to the device list.
+
+Data transmission phase
+=======================
+
+The data transmission process is structured into two parts: preparation and the transfer.
+
+1. Transfer preparation
+
+   a. A user application calls the :c:func:`mspi_transceive` function to initiate a data transfer.
+   #. The MSPI driver passes transfer parameters to HPF application (``hrt_xfer_t``).
+   #. The HPF application calls the :c:func:`configure_clock` function to set the clock polarity and phase (SPI modes) based on the ``cpp_mode`` parameter.
+      It ensures compatibility with modes 0 and 3.
+   #. For each packet, MSPI driver passes packet data to HPF application, awaiting completion.
+   #. For each packet, HPF application calls the :c:func:`xfer_execute` function to prepare the transfer and adjust the last word.
+
+   .. note::
+
+      Due to hardware constraints, the length of the last word cannot be ``1``.
+      The :c:func:`adjust_tail` function modifies the last two words to meet this requirement.
+
+2. Packet element transfer
+
+   a. Each packet transfer is initiated by the :c:func:`hrt_write` or :c:func:`hrt_read` functions on the FLPR core.
+      Additionally, each packet is divided into four elements: ``command``, ``address``, ``dummy_cycles``, and ``data``.
+   #. The :c:func:`hrt_write` and :c:func:`hrt_read` functions prepare the hardware for data transmission by setting GPIO direction masks and determining active packet elements.
+   #. The chip select (CS) is enabled before the transfer and disabled afterward unless ``ce_hold`` is set to ``true``.
+   #. Each TX packet element is processed using the :c:func:`hrt_tx` function.
+   #. :c:func:`hrt_read` function treats the ``data`` element as RX and passes all other elements to the :c:func:`hrt_write` function.
+   #. For each packet element, the shift controller is configured for the appropriate number of data lines and word size.
+
+Sequence flow
+=============
+
+The following diagram illustrates the interactions between the user application and the FLPR HRT, mapping out each step from initialization to data transfer:
+
+.. uml::
+
+  @startuml
+  skinparam sequence {
+  DividerBackgroundColor #8DBEFF
+  DividerBorderColor #8DBEFF
+  LifeLineBackgroundColor #13B6FF
+  LifeLineBorderColor #13B6FF
+  ParticipantBackgroundColor #13B6FF
+  ParticipantBorderColor #13B6FF
+  BoxBackgroundColor #C1E8FF
+  BoxBorderColor #C1E8FF
+  GroupBackgroundColor #8DBEFF
+  GropuBorderColor #8DBEFF
+  }
+
+  skinparam note {
+  BackgroundColor #ABCFFF
+  BorderColor #2149C2
+  }
+
+  box "Application"
+  participant "User\nApplication" as t
+  participant "Zephyr RTOS\nMSPI API" as a
+  participant "HPF eMSPI driver" as d
+  end box
+  box "FLPR"
+  participant "HPF FLPR APP" as f
+  participant "HRT" as h
+  end box
+
+  == Initialization ==
+
+  activate t
+  t -> a : mspi_config()
+  activate a
+  a -> d : api_config()
+  activate d
+  d -> d : send_config(HPF_MSPI_CONFIG_PINS)
+  note right d: Shared mem and/or IRQ num
+  d -> f : HPF_MSPI_CONFIG_PINS
+  activate f
+  f -> f : config_pins()
+  return
+  deactivate f
+  d --> a
+  deactivate d
+  a --> t
+  deactivate a
+
+  ...
+
+  loop for each device
+  t -> a : mspi_dev_config()
+  activate a
+  a -> d : api_dev_config()
+  activate d
+  d -> d : send_config(HPF_MSPI_CONFIG_DEV)
+  note right d: Shared mem and/or IRQ num
+  d -> f : HPF_MSPI_CONFIG_DEV
+  activate f
+  note right f: Fill structures\nwith data from APP\nand configure CE pins
+  return
+  deactivate f
+  d --> a
+  deactivate d
+  a --> t
+  deactivate a
+  end
+
+  ...
+
+  == TX-RX-TX requests ==
+
+  t -> a : mspi_transceive()
+  activate a
+  a -> d : api_transceive()
+  activate d
+  d -> d : send_config(HPF_MSPI_CONFIG_XFER)
+  note right d: Shared mem and/or IRQ num
+  d -> f : HPF_MSPI_CONFIG_XFER
+  activate f
+  f -> f : configure_clock()
+  return
+  deactivate f
+  loop for each packet
+  d -> d ++ : start_next_packet()
+  d -> d ++ : xfer_packet()
+  note right d: Shared mem and/or IRQ num
+  d -> f : HPF_MSPI_TX or HPF_MSPI_TXRX
+  activate f
+  f -> f ++ : xfer_execute()
+  f -> f ++ : adjust_tail(command)
+  deactivate f
+  f -> f ++ : adjust_tail(address)
+  deactivate f
+  f -> f ++ : adjust_tail(dummy_cycles)
+  deactivate f
+  f -> f ++ : adjust_tail(data)
+  deactivate f
+  deactivate f
+  note right f: IRQ num
+  f -> h : Dispatch
+  activate h
+
+  alt transfer type TX
+  h -> h ++ : hrt_write()
+  h -> h ++ : hrt_tx(command)
+  deactivate h
+  h -> h ++ : hrt_tx(address)
+  deactivate h
+  h -> h ++ : hrt_tx(dummy_cycles)
+  deactivate h
+  h -> h ++ : hrt_tx(data)
+  deactivate h
+  deactivate h
+
+  else trasnfer type TXRX
+  note right h: Temp. set data length to 0
+  h -> h ++ : hrt_write()
+  h -> h ++ : hrt_tx(command)
+  deactivate h
+  h -> h ++ : hrt_tx(address)
+  deactivate h
+  h -> h ++ : hrt_tx(dummy_cycles)
+  deactivate h
+  deactivate h
+  note right h: Temp. set data length to original value
+  note right h: Receive data
+  end
+  return
+  return
+  deactivate d
+  deactivate d
+  d --> a
+  deactivate d
+  a --> t
+  deactivate a
+  deactivate t
+  @enduml
+
+Key functions
+=============
+
+Key functions, such as :c:func:`hrt_write`, :c:func:`hrt_tx`, and :c:func:`hrt_read` are integral to managing the data transfer process, handling tasks from setting GPIO directions to executing low-level data transfers.
+
+.. list-table::
+   :widths: 20 30 50
+   :header-rows: 1
+
+   * - Function
+     - Purpose
+     - Key Steps
+   * - :c:func:`hrt_write`
+     - The primary function for executing a TX transfer. It handles configuration, timing, and data transmission for all frame elements.
+     - 1. Configures GPIO directions for TX using the transfer parameters.
+       2. Determines the active frame element (command, address, dummy bits, or data).
+       3. Transfers the frame elements sequentially via :c:func:`hrt_tx`.
+       4. Manages clock timing and CE pin behavior.
+   * - :c:func:`hrt_tx`
+     - Handles the low-level data transfer for a specific frame element (e.g., ``command``, ``address``, ``dummy_cycles``, or ``data``).
+     - 1. Configures the shift controller (:c:func:`nrf_vpr_csr_vio_shift_ctrl_buffered_set`).
+       2. Writes each word from the data buffer to the output register.
+       3. Starts the hardware counter for generating clock signal.
+   * - :c:func:`hrt_read`
+     - The primary function for executing a RX transfer. It handles configuration, timing, and data transmission for all frame elements.
+     - 1. Call :c:func:`hrt_write` for ``command``, ``address`` and ``dummy_cycles`` elements.
+       2. Configures GPIO directions for RX using the transfer parameters.
+       3. Receives ``data`` element.
+       4. Manages clock timing and CE pin behavior.
+   * - :c:func:`adjust_tail`
+     - Manages the formatting of the last and penultimate words in the transfer buffer to comply with hardware limitations.
+     - - Adjusts word boundaries when the last word requires only 1 clock cycle to be sent.
+       - Handles cases where data needs to be split across multiple words.
+
+Key data structures
+===================
+
+The following section provides an overview of the primary data structures used in managing MSPI transfers.
+These structures are crucial for configuring and executing data transfers efficiently.
+
+* Transfer elements
+
+  * ``hrt_frame_element_t`` - Defines different frame elements (:c:enumerator:`HRT_FE_COMMAND`, :c:enumerator:`HRT_FE_ADDRESS`, :c:enumerator:`HRT_FE_DUMMY_CYCLES`, :c:enumerator:`HRT_FE_DATA`).
+
+* Transfer configuration
+
+  * ``hrt_xfer_t`` - Encapsulates the core configuration for an MSPI transfer.
+  * ``xfer_data`` - An array of the ``hrt_xfer_data_t`` structures for the frame elements (:c:member:`command`, :c:member:`address`, :c:member:`dummy_cycles`, :c:member:`data`).
+  * ``bus_widths`` - Defines the bit-width configuration for the :c:member:`command`, :c:member:`address`, :c:member:`dummy_cycles`, and :c:member:`data` sections of the transfer.
+  * ``counter_value``: Sets the clock divider to achieve frequency specified by a user.
+  * ``ce_vio`` - Index of the VIO pin used as CE.
+  * ``ce_hold`` - Whether CE remains asserted after the transfer.
+  * ``ce_polarity`` - Active polarity of the CE pin.
+  * ``tx_direction_mask`` and ``rx_direction_mask`` - Configure GPIO directions for data transmission.
+  * ``cpp_mode`` - SPI mode 0 or 3
+
+* Transfer data
+
+  * ``hrt_xfer_data_t`` - Represents transfer-specific properties for each frame element.
+  * ``data`` - Points to the data being transmitted or received.
+  * ``word_count`` - Number of 32-bit words in the data buffer.
+  * ``last_word_clocks`` - Number of clock pulses for the final word.
+  * ``penultimate_word_clocks`` - Clock pulses for the second-to-last word.
+  * ``last_word`` - Holds the last word data (for transition or from reception).
+  * ``fun_out`` - Selects which function in TX to use to access buffered output register.
+
+Building and running
+********************
+
+.. |application path| replace:: :file:`applications/hpf/mspi`
+
+.. include:: /includes/application_build_and_run.txt
+
+To build and run the application, you must include code for both the application core and FLPR core.
+The process involves building a test or user application that is using MSPI driver with the appropriate sysbuild configuration.
+
+.. tabs::
+
+   .. tab:: Building with tests
+
+      You can use the tests listed in the :ref:`hpf_mspi_example_testing` section.
+      To build them, execute the following command in their respective directories:
+
+      .. code-block:: console
+
+         west build -p -b nrf54l15dk_nrf54l15_cpuapp
+
+   .. tab:: Building with User Application
+
+      Follow these steps to build with a user application:
+
+      1. Enable the following Kconfig options:
+
+         * ``SB_CONFIG_HPF`` - Enables the High-Performance Framework (HPF).
+         * ``SB_CONFIG_HPF_MSPI`` - Integrates the HPF application image with the user application image.
+
+      #. Disable the following Kconfig options:
+
+         * ``SB_CONFIG_VPR_LAUNCHER`` - Disables the default VPR launcher image for the application core.
+         * ``SB_CONFIG_PARTITION_MANAGER`` - Disables the :ref:`Partition Manager <partition_manager>`.
+
+      #. Implement the business logic using the MSPI API with the HPF application.
+
+      #. Add device tree nodes that describe the chips connected via MSPI (hpf_mspi).
+
+      #. Compile your code.
+
+.. _hpf_mspi_example_testing:
+
+Testing
+*******
+
+The following tests utilize the MSPI driver along with this application:
+
+* ``nrf/tests/zephyr/drivers/mspi/api``
+* ``nrf/tests/zephyr/drivers/flash/common``
+
+These tests report results through serial port (the USB debug port on the nFR54L15 DK).
+
+Dependencies
+************
+
+* :file:`zephyr/doc/services/ipc/ipc_service` - Used for transferring data between application core and the FLPR core.
+* `nrf HAL <nrfx API documentation_>`_ - Enables access to the VPR CSR registers for direct hardware control.
+* :ref:`hpf_assembly_management` - Used to optimize performance-critical sections.
+
+.. _hpf_mspi_example_api:
+
+API documentation
+*****************
+
+Application uses the following API elements:
+
+Zephyr driver
+=============
+
+* Header file: :file:`include/drivers/mspi/hpf_mspi.h`
+* Source file: :file:`drivers/mspi/mspi_hpf.c`
+
+FLPR application
+================
+
+* Source file: :file:`applications/hpf/mspi/src/main.c`
+
+FLPR application HRT
+====================
+
+* Header file: :file:`applications/hpf/mspi/src/hrt/hrt.h`
+* Source file :file:`applications/hpf/mspi/src/hrt/hrt.c`
+* Assembly: :file:`applications/hpf/mspi/src/hrt/hrt-nrf54l15.s`
diff --git a/doc/_utils/redirects.py b/doc/_utils/redirects.py
index f7b73cc8c0ae..65d610e4be7a 100644
--- a/doc/_utils/redirects.py
+++ b/doc/_utils/redirects.py
@@ -419,6 +419,7 @@
     ("ug_zigbee_tools", "protocols/zigbee/index"), # Zigbee tools (removed after v3.0.0)
     ("protocols/zigbee/tools", "protocols/zigbee/index"),
     ("applications/nrf5340_audio/README", "applications/nrf5340_audio/index"), # nRF5340 Audio applications (landing)
+    ("applications/sdp/gpio/README", "applications/hpf/gpio/README"), #High-Performance Framework applications
     ("samples/samples_bl", "samples/bl"), # Bluetooth samples (landing)
     ("samples/bluetooth/connection_event_trigger/README", "samples/bluetooth/event_trigger/README"),
     ("samples/bluetooth/broadcast_config_tool/README", "samples/bluetooth/nrf_auraconfig/README"),
diff --git a/doc/nrf/app_dev.rst b/doc/nrf/app_dev.rst
index 780ec1fe766b..0971c4012013 100644
--- a/doc/nrf/app_dev.rst
+++ b/doc/nrf/app_dev.rst
@@ -37,3 +37,4 @@ For detailed integration instructions of specific technologies and components, c
    app_dev/device_guides/fem/index
    app_dev/device_guides/custom/index
    app_dev/device_guides/wifi_coex
+   app_dev/device_guides/coprocessors/index
diff --git a/doc/nrf/app_dev/device_guides/coprocessors/assembly_management.rst b/doc/nrf/app_dev/device_guides/coprocessors/assembly_management.rst
new file mode 100644
index 000000000000..dda973cf9640
--- /dev/null
+++ b/doc/nrf/app_dev/device_guides/coprocessors/assembly_management.rst
@@ -0,0 +1,106 @@
+.. _hpf_assembly_management:
+
+Assembly management
+###################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+Assembly management is a critical component in the development process, particularly when meeting the modularity and testability requirements defined in the :ref:`hpf_event_handling`.
+
+Overview
+********
+
+Emulating communication protocols requires precise timing.
+To manage this, you must separate the time-sensitive parts of the code, known as Hard Real-Time (HRT) components.
+These components have strict timing requirements and are stored in a pre-compiled assembly format to ensure they remain unchanged.
+
+The assembly management CMake functions are integrated into the build process and are executed with every build.
+These functions check for any modifications that could lead to the generation of different assembly files, such as changes in HRT source files or the compiler used.
+Detecting these changes is essential because they can impact the timing accuracy of software peripherals.
+If any changes are detected that could affect the assembly files, you must verify that these differences are within acceptable limits.
+This ensures that the new code maintains the necessary timing accuracy.
+
+To use this feature, you must include the command ``hpf_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c")`` in your application's :file:`CMakeLists.txt` file, where ``file.c`` value is the C file containing only Hard Real-Time (HRT) functions.
+
+Although the assembly management functions are called every time in build time, some of them can also be run independently by using CMake targets in VPR core's application build directory.
+
+See the following flow of the build-time assembly management process:
+
+.. image:: images/hpf_assembly_build_time_management_process.svg
+  :alt: HPF assembly management process
+
+.. _hpf_assembly_management_cmake:
+
+Implementation
+**************
+
+The assembly management performed at build time uses following :ref:`CMake<cmake_options>` functions:
+
+* :c:func:`hpf_assembly_generate`
+* :c:func:`hpf_assembly_check`
+* :c:func:`hpf_assembly_prepare_install`
+* :c:func:`hpf_assembly_target_sources`
+
+hpf_assembly_generate
+=====================
+
+The :c:func:`hpf_assembly_generate` function creates a build target (asm_gen) that generates a temporary assembly file from HRT source files.
+This files is named :file:`file-soc-temp.s` and is located in the Fast Lightweight Peripheral Processor (FLPR) application's build directory when running ``ninja build``.
+In the filename, *soc* represents the System on Chip (SoC) name used in the current build, such as ``nrf54l15``.
+
+hpf_assembly_check
+==================
+
+The :c:func:`hpf_assembly_check` function sets up a build target (asm_check) that is triggered when executing ``ninja build``, following the :c:func:`sdk_assembly_generate` function.
+The target verifies if the :file:`file-soc-temp.s` file in the build directory matches the :file:`file-soc.s` file in the source directory.
+If discrepancies are found, it triggers a CMake error (in user mode) or warning (in developer mode).
+
+hpf_assembly_prepare_install
+============================
+
+The :c:func:`hpf_assembly_prepare_install` function creates a build target (asm_install) that replaces the :file:`file-soc.s` file in the source directory with :file:`file-soc-temp.s` from the build directory.
+
+hpf_assembly_target_sources
+===========================
+
+The :c:func:`hpf_assembly_target_sources` function includes the :file:`file-soc.s` from source directory (user mode) or the :file:`file-soc-temp.s` from build directory (developer mode) in the target sources.
+
+Configuration
+*************
+
+You can change the mechanism of :c:func:`hpf_assembly_check` and :c:func:`hpf_assembly_target_sources` functions by switching between user and developer build modes:
+
+* User mode - The application uses a pre-generated assembly file to construct the HRT component.
+* Developer mode -  The application employs a newly generated assembly file.
+  This approach not only facilitates the integration of updates but also allows for a thorough review of changes made by developers and modifications introduced by the toolchain.
+  You can enable it by setting the ``SB_CONFIG_HPF_DEVELOPER_MODE`` Kconfig option.
+  If this setting is disabled, files are built in the user mode.
+
+Verifiying assembly files and managing updates
+==============================================
+
+When working in user or developer mode, you must verify the integrity and accuracy of assembly files:
+
+* In user mode, if you receive a CMake error from asm_check, evaluate if the differences between :file:`file-soc-temp.s` and :file:`file-soc.s` are minimal and maintain the required timing accuracy.
+  Depending on the outcome, do the following:
+
+  * If the differences are acceptable, execute the ``ninja asm_install`` command in the FLPR application's build directory to use the new assembly files.
+  * If the differences are significant, investigate and adjust the code, or re-run hardware characterization tests to ensure compliance with the required specifications.
+
+* In developer mode, if you wish to update the source directory with newly generated assembly files, invoke the ``ninja asm_install`` command in the ``build/hpf`` directory.
+
+Running CMake targets
+*********************
+
+There are three CMake targets that can be executed:
+
+* asm_gen - Generates new assembly files out of HRT source files.
+  This target is established by the :c:func:`hpf_assembly_generate` function.
+* asm_check - Checks if newly generated assembly files differ from the existing ones and prints the result to the console.
+  This target is established by the :c:func:`hpf_assembly_check` function.
+* asm_install - Replaces assembly files in the source directory with newly generated ones, assuming the asm_gen was called before.
+
+You must run all assembly management CMake targets in the VPR application's build directory. They can be executed using the command ``ninja target_name``.
+For example, to run the asm_install target, you would use the command ``ninja asm_install``.
diff --git a/doc/nrf/app_dev/device_guides/coprocessors/event_handling.rst b/doc/nrf/app_dev/device_guides/coprocessors/event_handling.rst
new file mode 100644
index 000000000000..9c9d9cb27743
--- /dev/null
+++ b/doc/nrf/app_dev/device_guides/coprocessors/event_handling.rst
@@ -0,0 +1,155 @@
+.. _hpf_event_handling:
+
+Event handling
+##############
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+This page section outlines the critical requirements and implementation strategies for managing events within the system, ensuring that functionalities are both modular and precise in execution.
+
+.. note::
+
+   This page outlines best practices for architecture design.
+   You might need to implement some components, as they are not yet available.
+
+Requirements
+************
+
+The system must support the integration of multiple High-Performance Framework (HPF) peripherals, ensuring the following:
+
+* Modularity, allowing to combine functionalities of multiple HPF peripherals.
+* Timing accuracy, focusing on handling certain parts of the code with very accurate timings.
+* Verification, ensuring it is possible verify timing accuracy without the need to rerun an entire suite of hardware characteristic tests.
+
+Implementation
+**************
+
+To ensure precise timing, specific sections of the code should be identified and managed as Hard-Real Time (HRT) functions.
+These functions must be kept separate from the main application code.
+
+During the build process, HRT functions are compiled into assembly code.
+This code is then compared to a previously verified version to ensure that there are no significant deviations.
+If the differences are minimal or non-existent, the new code will be considered accurate for timing.
+
+HRT functions shall be developed using the Hardware Abstraction Layer (HAL) and avoid any calls to external functions.
+While you can use macros that do not lead to external function calls, you must redefine locally any external macro that influences the assembly code to maintain the required timing accuracy.
+
+Furthermore, HRT functions shall be implemented as interrupt handlers.
+This implementation ensures that these functions are executed in the correct sequence when triggered by multiple sources, maintaining the system's timing accuracy.
+
+Interaction between HRT and non-HRT code
+****************************************
+
+Since HRT functions shall be implemented as Interrupt Service Routines (ISR) they cannot use function arguments for passing values between application and HRT.
+To facilitate this communication, you can use the following methods or their combination:
+
+* VEVIF interrupt ID - You can assign separate HRT functions to certain VEVIF IRQs.
+* Shared memory - You can store data in the pre-defined memory addresses.
+
+The sequence flow must be designed to handle initialization, transaction requests, and error handling efficiently.
+During initialization, the system boots up and prepares for operation by entering a wait state.
+For transaction requests, the system handles transmission and reception requests through IPC mechanisms, utilizing shared memory or IRQ numbers for communication between different parts of the system.
+
+In the event of an error, such as a memory fault, the system triggers an error handler which notifies the Host of the error and then enters an infinite loop to halt further operations:
+
+.. uml::
+
+
+  @startuml
+
+  skinparam sequence {
+  DividerBackgroundColor #8DBEFF
+  DividerBorderColor #8DBEFF
+  LifeLineBackgroundColor #13B6FF
+  LifeLineBorderColor #13B6FF
+  ParticipantBackgroundColor #13B6FF
+  ParticipantBorderColor #13B6FF
+  BoxBackgroundColor #C1E8FF
+  BoxBorderColor #C1E8FF
+  GroupBackgroundColor #8DBEFF
+  GropuBorderColor #8DBEFF
+  }
+
+  skinparam note {
+  BackgroundColor #ABCFFF
+  BorderColor #2149C2
+  }
+
+  participant Thread as t
+  participant "IPC IRQ \n(low priority)" as i
+  participant "HRT IRQ \n(high priority)" as h
+  participant "Error handler \n(top priority)" as e
+
+  == Initialization ==
+
+  [-> t : Start VPR
+  activate t
+  t -> t : Boot
+  t -> t : Initialization
+  t -> t : WFI
+  deactivate t
+  ...
+
+  == TX-RX-TX requests ==
+
+  [-> i : TX request from host
+  activate i
+  i -> i : IPC RX
+  note right i: Shared mem and/or IRQ num
+  i -> h : Dispatch
+  deactivate i
+
+  activate h
+  h -> h : HRT TX execution
+  [-> i : RX request from host
+  h -> h : Mark TX as done
+  return
+
+  activate i
+  i -> i : IPC RX
+  opt
+  i -> i : Notify host:\n"TX queue empty"
+  end
+  i -> h : Dispatch
+  deactivate i
+
+  activate h
+  h -> h : HRT RX execution
+  [-> i : TX request from host
+
+  h -> h: Mark Rx as done
+  return
+  activate i
+
+  i -> i : IPC TX
+  i -> i : IPC RX
+  i -> h : Dispatch
+  deactivate i
+
+  activate h
+  h -> h : HRT TX execution
+  h -> h : Mark TX as done
+  return
+
+  i --> t
+
+  activate t
+  t -> t : WFI
+  deactivate t
+  ...
+
+  == Error handling ==
+  [-> h : ...
+  activate h
+  h -> h : HRT TX execution
+  e <-] : Memory fault
+  deactivate h
+  activate e
+  e -> e : Notify host:\n"HPF error"
+  e -> e : Infinite loop
+
+  @enduml
+
+This sequence ensures that the system maintains robust operation and handles errors effectively to prevent system failures.
diff --git a/doc/nrf/app_dev/device_guides/coprocessors/fault_handling.rst b/doc/nrf/app_dev/device_guides/coprocessors/fault_handling.rst
new file mode 100644
index 000000000000..972a33c6f0ec
--- /dev/null
+++ b/doc/nrf/app_dev/device_guides/coprocessors/fault_handling.rst
@@ -0,0 +1,47 @@
+.. _hpf_fault_handling:
+
+Fault handling
+##############
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following page outlines mechanisms and strategies that shall be employed to manage faults in both the Host and High-Performance Framework (HPF) firmware environments.
+
+.. note::
+   This page outlines best practices for architecture design.
+   You might need to implement some components, as they are not yet available.
+
+Handling Host crash
+*******************
+
+In case of a Host crash followed by a reset, the hardware is designed to ensure that a reset of the application core (Host) simultaneously triggers a reset of the HPF firmware (FLPR core).
+
+This ensures synchronization between the cores.
+
+Handling firmware crash
+***********************
+
+In case a HPF firmware crashes, the issue must be signalled to the Host.
+Since there are no hardware resources dedicated to this task, you must implement the solution in software.
+You can employ the following strategies, individually or combined:
+
+* Use the TIMER peripheral as watchdog in one of the following ways:
+
+  * Set up the TIMER with the Host and ensure it is regularly cleared by the HPF firmware.
+    If the firmware fails to clear the TIMER, an Interrupt Request (IRQ) is sent to the Host indicating an HPF firmware error.
+  * Use the Watchdog Timer (WDT) peripheral with STOP functionality.
+    HPF firmware has to feed the watchdog.
+    If it fails to do so, the Host receives an interrupt and must execute TASK_STOP.
+    This solution assumes that the Host is always able to invoke TASK_STOP within two 32kHz cycles. Otherwise, the WDT triggers a reset, which might be undesired.
+
+* Implement a trap handler that signals the fault condition to the Host, for example, using the VEVIF IRQ and a predefined memory location to store the error code.
+
+   .. note::
+         The drawback of relying only on this solution is its inability to address scenarios where the HPF firmware is caught in an infinite loop.
+         This risk might be mitigated through thorough code inspection and testing.
+
+* Create a flag within shared memory that is periodically updated by the HPF firmware and monitored by the Host.
+
+ By implementing the outlined strategies, you can ensure that both the Host and HPF firmware can manage and recover from faults efficiently, thereby enhancing system stability and performance.
diff --git a/doc/nrf/app_dev/device_guides/coprocessors/hpf.rst b/doc/nrf/app_dev/device_guides/coprocessors/hpf.rst
new file mode 100644
index 000000000000..31796af3679a
--- /dev/null
+++ b/doc/nrf/app_dev/device_guides/coprocessors/hpf.rst
@@ -0,0 +1,39 @@
+.. _hpf_index:
+
+High-Performance Framework (HPF)
+################################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+Subsequent sections explain practical aspects of using the High-Performance Framework (HPF).
+
+The integrated RISC-V coprocessor (FLPR) provides real-time peripherals mapped to the processor's Control and Status Register (CSR) space.
+It facilitates development of custom, software-defined peripherals, enhancing functionality and performance of the main processor.
+
+HPF is designed for optimal size and latency.
+To achieve this, the Zephyr kernel and other unnecessary components are disabled.
+For details see the configuration file :file:`nrf/applications/hpf/mspi/boards/nrf54l15dk_nrf54l15_cpuflpr.conf`.
+With these changes, the application runs in a simple, single-threaded, baremetal environment.
+
+High-Performance Framework, is a framework designed to facilitate the creation and integration of software peripherals using coprocessors.
+It provides the following resources:
+
+* Targeted tools - Hardware Abstraction Layers (HALs) for VPR's :ref:`Real-Time peripherals<hpf_real_time_peripherals>` and :ref:`CMake targets for assembly management<hpf_assembly_management_cmake>`.
+
+* :ref:`Application examples <hpf_applications_readme>` for the supported drivers.
+
+* Descriptions of architectural issues when creating software peripherals: :ref:`event handling<hpf_event_handling>`, :ref:`fault handling<hpf_fault_handling>`, and :ref:`power management<hpf_power_management>`.
+
+These resources are intended to serve as foundational starting points, enabling you to create customized software peripherals tailored to specific application needs.
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Contents
+
+   assembly_management.rst
+   event_handling.rst
+   fault_handling.rst
+   power_management.rst
+   rt_peripherals.rst
diff --git a/doc/nrf/app_dev/device_guides/coprocessors/images/hpf_assembly_build_time_management_process.svg b/doc/nrf/app_dev/device_guides/coprocessors/images/hpf_assembly_build_time_management_process.svg
new file mode 100644
index 000000000000..3ea88abab516
--- /dev/null
+++ b/doc/nrf/app_dev/device_guides/coprocessors/images/hpf_assembly_build_time_management_process.svg
@@ -0,0 +1,144 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<!-- Generated by Microsoft Visio, SVG Export hpf_assembly_management_process.svg Page-1 -->
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ev="http://www.w3.org/2001/xml-events"
+		width="7.61964in" height="6.72221in" viewBox="0 0 548.614 483.999" xml:space="preserve" color-interpolation-filters="sRGB"
+		class="st12">
+	<style type="text/css">
+	<![CDATA[
+		.st1 {fill:#00a2c6;stroke:none;stroke-width:1}
+		.st2 {fill:#ffffff;font-family:Arial;font-size:0.833336em}
+		.st3 {font-size:1em}
+		.st4 {fill:none;stroke:none;stroke-width:1}
+		.st5 {fill:#de823b;stroke:none;stroke-width:1}
+		.st6 {fill:#ffffff;stroke:#000000;stroke-width:1}
+		.st7 {fill:#000000;font-family:Arial;font-size:0.833336em}
+		.st8 {marker-end:url(#mrkr4-50);stroke:#00a2c6;stroke-linecap:butt;stroke-width:1}
+		.st9 {fill:#00a2c6;fill-opacity:1;stroke:#00a2c6;stroke-opacity:1;stroke-width:0.28409090909091}
+		.st10 {marker-start:url(#mrkr4-56);stroke:#00a2c6;stroke-linecap:butt;stroke-width:1}
+		.st11 {marker-end:url(#mrkr4-50);stroke:#00a2c6;stroke-dasharray:8,4;stroke-linecap:butt;stroke-width:1}
+		.st12 {fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
+	]]>
+	</style>
+
+	<defs id="Markers">
+		<g id="lend4">
+			<path d="M 2 1 L 0 0 L 2 -1 L 2 1 " style="stroke:none"/>
+		</g>
+		<marker id="mrkr4-50" class="st9" refX="-7.04" orient="auto" markerUnits="strokeWidth" overflow="visible">
+			<use xlink:href="#lend4" transform="scale(-3.52,-3.52) "/>
+		</marker>
+		<marker id="mrkr4-56" class="st9" refX="6.68" orient="auto" markerUnits="strokeWidth" overflow="visible">
+			<use xlink:href="#lend4" transform="scale(3.52) "/>
+		</marker>
+	</defs>
+	<g>
+		<title>Page-1</title>
+		<g id="shape5-1" transform="translate(25.4961,-333.24)">
+			<title>Nordic Blue</title>
+			<desc>CMakeLists.txt</desc>
+			<rect x="0" y="453.291" width="113.528" height="30.7087" class="st1"/>
+			<text x="23.98" y="471.64" class="st2">CMakeLists.txt</text>		</g>
+		<g id="shape6-4" transform="translate(25.4961,-302.531)">
+			<title>Nordic Blue.6</title>
+			<desc>sdp_assembly(file.c)</desc>
+			<rect x="0" y="453.291" width="113.528" height="30.7087" class="st1"/>
+			<text x="11.19" y="471.64" class="st2">sdp_assembly(file.c)</text>		</g>
+		<g id="shape7-7" transform="translate(1,-270.641)">
+			<title>Nordic Blue.7</title>
+			<desc>sdp_assembly_generate</desc>
+			<rect x="0" y="452.11" width="162.52" height="31.8898" class="st1"/>
+			<text x="26.78" y="471.05" class="st2">sdp_assembly_generate</text>		</g>
+		<g id="shape8-10" transform="translate(1,-236.463)">
+			<title>Nordic Blue.8</title>
+			<desc>sdp_assembly_check</desc>
+			<rect x="0" y="452.11" width="162.52" height="31.8898" class="st1"/>
+			<text x="33.46" y="471.05" class="st2">sdp_assembly_check</text>		</g>
+		<g id="shape9-13" transform="translate(196.921,-270.641)">
+			<title>Nordic Blue.9</title>
+			<desc>file-soc-temp.s created in build dir</desc>
+			<rect x="0" y="452.11" width="162.52" height="31.8898" class="st1"/>
+			<text x="6.51" y="471.05" class="st2">file-soc-temp.s created in build dir</text>		</g>
+		<g id="shape10-16" transform="translate(196.921,-236.463)">
+			<title>Nordic Blue.10</title>
+			<desc>file-soc-temp.s checked against file-soc.s in source</desc>
+			<rect x="0" y="452.11" width="162.52" height="31.8898" class="st1"/>
+			<text x="11.23" y="465.05" class="st2">file-soc-temp.s checked against <tspan x="39.86" dy="1.2em" class="st3">file</tspan>-soc.s in source</text>		</g>
+		<g id="shape22-20" transform="translate(253.685,-91.4091)">
+			<title>Nordic Sky</title>
+			<rect x="0" y="455.653" width="195.921" height="28.3465" class="st4"/>
+		</g>
+		<g id="shape18-22" transform="translate(249.835,-20.543)">
+			<title>Nordic Fall</title>
+			<desc>CMake warning</desc>
+			<rect x="0" y="427.306" width="56.6929" height="56.6929" class="st5"/>
+			<text x="12.51" y="452.65" class="st2">CMake <tspan x="10.84" dy="1.2em" class="st3">warning</tspan></text>		</g>
+		<g id="shape13-26" transform="translate(221.417,-363.063)">
+			<title>Nordic Blue.13</title>
+			<desc>ninja build</desc>
+			<rect x="0" y="427.306" width="113.528" height="56.6929" class="st1"/>
+			<text x="34.25" y="458.65" class="st2">ninja build</text>		</g>
+		<g id="shape14-29" transform="translate(418.732,-363.063)">
+			<title>Nordic Blue.14</title>
+			<desc>ninja asm_install</desc>
+			<rect x="0" y="427.306" width="113.528" height="56.6929" class="st1"/>
+			<text x="19.8" y="458.65" class="st2">ninja asm_install</text>		</g>
+		<g id="shape15-32" transform="translate(403.047,-147.393)">
+			<title>Nordic Blue.15</title>
+			<desc>file-soc.s is replaced with file-soc-temp.s</desc>
+			<rect x="0" y="453.291" width="144.567" height="30.7087" class="st1"/>
+			<text x="7.26" y="465.65" class="st2">file-soc.s is replaced with file-<tspan x="47.83" dy="1.2em" class="st3">soc</tspan>-temp.s</text>		</g>
+		<g id="shape16-36" transform="translate(1,-197.561)">
+			<title>Nordic Blue.16</title>
+			<desc>sdp_assembly_prepare_install</desc>
+			<rect x="0" y="447.385" width="162.52" height="36.6142" class="st1"/>
+			<text x="13.72" y="468.69" class="st2">sdp_assembly_prepare_install</text>		</g>
+		<g id="shape17-39" transform="translate(403.047,-442.197)">
+			<title>Nordic Blue.17</title>
+			<desc>manual verification of changes</desc>
+			<rect x="0" y="462.739" width="144.567" height="21.2598" class="st6"/>
+			<text x="4.74" y="476.37" class="st7">manual verification of changes</text>		</g>
+		<g id="shape25-42" transform="translate(205.898,-112.669)">
+			<title>Nordic Blue.25</title>
+			<desc>if file-soc-temp.s != file-soc.s</desc>
+			<rect x="0" y="462.739" width="144.567" height="21.2598" class="st6"/>
+			<text x="9.07" y="476.37" class="st7">if file-soc-temp.s != file-soc.s</text>		</g>
+		<g id="shape29-45" transform="translate(271.094,-112.669)">
+			<title>Dynamic connector</title>
+			<path d="M7.09 484 L7.09 512.39" class="st8"/>
+		</g>
+		<g id="shape1000-51" transform="translate(196.921,-293.673)">
+			<title>Dynamic connector.1000</title>
+			<path d="M-6.68 491.09 L-7.04 491.09 L-33.4 491.09" class="st10"/>
+		</g>
+		<g id="shape1001-57" transform="translate(403.047,-162.748)">
+			<title>Dynamic connector.1001</title>
+			<path d="M-6.68 484 L-7.04 484 L-17.48 484 A2.3622 2.3622 -180 0 0 -22.2 484 L-122.5 484 A2.3622 2.3622 -180 1 0 -127.23
+						 484 L-320.79 484 L-320.79 449.19" class="st10"/>
+		</g>
+		<g id="shape1002-62" transform="translate(163.52,-245.322)">
+			<title>Dynamic connector.1002</title>
+			<path d="M0 476.91 L26.36 476.91" class="st8"/>
+		</g>
+		<g id="shape1003-67" transform="translate(271.094,-363.063)">
+			<title>Dynamic connector.1003</title>
+			<path d="M7.09 484 L7.09 537.49" class="st8"/>
+		</g>
+		<g id="shape1004-72" transform="translate(482.5,-363.063)">
+			<title>Dynamic connector.1004</title>
+			<path d="M-7 484 L-7.16 661.92" class="st8"/>
+		</g>
+		<g id="shape1005-77" transform="translate(271.094,-236.463)">
+			<title>Dynamic connector.1005</title>
+			<path d="M7.09 484 L7.09 579.49" class="st11"/>
+		</g>
+		<g id="shape1006-82" transform="translate(278.181,-20.543)">
+			<title>Dynamic connector.1006</title>
+			<path d="M0 484 L0 496.67 L105.02 496.67 L105.02 28.41 L197.15 28.41 L197.15 34.05" class="st11"/>
+		</g>
+		<g id="shape1007-87" transform="translate(468.327,-442.197)">
+			<title>Dynamic connector.1007</title>
+			<path d="M7 484 L7.12 499.4" class="st11"/>
+		</g>
+	</g>
+</svg>
diff --git a/doc/nrf/app_dev/device_guides/coprocessors/index.rst b/doc/nrf/app_dev/device_guides/coprocessors/index.rst
new file mode 100644
index 000000000000..a6745b82c0e7
--- /dev/null
+++ b/doc/nrf/app_dev/device_guides/coprocessors/index.rst
@@ -0,0 +1,23 @@
+.. _coprocessors_index:
+
+Developing with coprocessors
+############################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following pages provide a detailed guide on utilizing coprocessor effectively within the nRF54L15 platform.
+
+The VPR coprocessor (Fast Lightweight Peripheral Processor - FLPR) can be utilized in two distinct ways:
+
+* As an additional core in a multicore system using Zephyr in multithreaded mode.
+  See :ref:`vpr_flpr_nrf54l` for more details.
+* As a peripheral emulator using the High-Performance Framework (HPF).
+  For more information, refer to the following documentation.
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Contents
+
+   hpf.rst
diff --git a/doc/nrf/app_dev/device_guides/coprocessors/power_management.rst b/doc/nrf/app_dev/device_guides/coprocessors/power_management.rst
new file mode 100644
index 000000000000..1138fe3f8397
--- /dev/null
+++ b/doc/nrf/app_dev/device_guides/coprocessors/power_management.rst
@@ -0,0 +1,235 @@
+.. _hpf_power_management:
+
+Power management
+################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following page outlines the approaches and mechanisms employed to ensure efficient power management in High-Performance Framework (HPF) systems, focusing on resource allocation, system states, and interactions between different components.
+
+.. note::
+   This page outlines best practices for architecture design.
+   You might need to implement some components, as they are not yet available.
+
+Power management strategies
+***************************
+
+Power Management in HPF should be considered from two perspectives: the Host controller and the HPF firmware.
+
+Host controller
+===============
+
+The Host is responsible for managing power state of the following resources:
+
+* FLPR core with HPF firmware running on it
+* RAM
+
+To achieve optimal power state, you must use the `Device Runtime Power Management`_ and `System Power Off`_.
+
+See an example flow of the Host power management:
+
+.. uml::
+
+  @startuml
+  skinparam sequence {
+  DividerBackgroundColor #8DBEFF
+  DividerBorderColor #8DBEFF
+  LifeLineBackgroundColor #13B6FF
+  LifeLineBorderColor #13B6FF
+  ParticipantBackgroundColor #13B6FF
+  ParticipantBorderColor #13B6FF
+  BoxBackgroundColor #C1E8FF
+  BoxBorderColor #C1E8FF
+  GroupBackgroundColor #8DBEFF
+  GropuBorderColor #8DBEFF
+  }
+
+  skinparam note {
+  BackgroundColor #ABCFFF
+  BorderColor #2149C2
+  }
+
+  participant Zephyr
+  participant Application
+  participant "HPF driver"
+  participant "VPR driver"
+  participant FLPR
+
+  activate Zephyr
+  Zephyr -> Zephyr : post kernel initialization
+  activate Zephyr
+  Zephyr -> "VPR driver" : Initialize drivers
+  activate "VPR driver"
+  rnote over "VPR driver"
+  Power on FLPR RAM
+  endrnote
+  rnote over "VPR driver"
+  If non-XIP:
+  Copy code to RAM
+  endrnote
+  rnote over "VPR driver"
+  Start FLPR
+  endrnote
+
+  "VPR driver" -> "VPR driver" : Initialize IPC
+  activate "VPR driver"
+  "VPR driver" -> FLPR
+  activate FLPR
+  rnote over FLPR
+  Boot
+  endrnote
+  rnote over FLPR
+  Initialize IPC
+  endrnote
+  return
+  deactivate "VPR driver"
+
+  "VPR driver" -> "VPR driver" : Initialize FLPR
+  activate "VPR driver"
+  "VPR driver" -> FLPR : FLPR_INIT
+  activate FLPR
+  rnote over FLPR
+  Initialize HW, peripherals, etc
+  endrnote
+  return FLPR_INITD
+  deactivate "VPR driver"
+  return
+  deactivate "VPR driver"
+
+
+  deactivate Zephyr
+  Zephyr -> Application : Start application
+  activate Application
+  Application -> "HPF driver" : hpf_driver_config(...)
+  activate "HPF driver"
+  "HPF driver" -> "HPF driver" : HPF driver initialization
+  activate "HPF driver"
+  "HPF driver" -> "VPR driver" : pm_device_runtime_get(&flpr)
+  activate "VPR driver"
+  "VPR driver" -> FLPR : FLPR_RESUME
+  activate FLPR
+  rnote over FLPR
+  Enter RESUME state
+  endrnote
+  return FLPR_RESUMED
+  return
+
+  "HPF driver" -> FLPR : HPF_APP_CONFIGURE
+  activate FLPR
+  rnote over FLPR
+  Configure HPF application
+  endrnote
+  return HPF_APP_CONFIGURED
+  deactivate "HPF driver"
+  return
+  ...
+
+
+  Application -> "HPF driver" : hpf_driver_transcieve(...)
+  activate "HPF driver"
+  "HPF driver" -> FLPR : HPF_APP_XFER
+  activate FLPR
+  rnote over FLPR
+  Execute transfer
+  endrnote
+  return HPF_APP_XFERD
+  return
+  ...
+
+
+  Application -> "HPF driver" : hpf_driver_config(...)
+  activate "HPF driver"
+  "HPF driver" -> "HPF driver" : HPF driver deinitialization
+  activate "HPF driver"
+  "HPF driver" -> FLPR : HPF_APP_DECONFIGURE
+  activate FLPR
+  rnote over FLPR
+  Deconfigure HPF application
+  endrnote
+  return HPF_APP_DECONFIGURED
+
+  "HPF driver" -> "VPR driver" : pm_device_runtime_put(&flpr)
+  activate "VPR driver"
+  "VPR driver" -> FLPR : FLPR_SUSPEND
+  activate FLPR
+  rnote over FLPR
+  Enter SUSPENDED state
+  endrnote
+  return FLPR_SUSPENDED
+  return
+  deactivate "HPF driver"
+  return
+  return
+
+
+  Zephyr -> Zephyr : power off procedure
+  activate Zephyr
+  "Zephyr" -> "VPR driver" : power off
+  activate "VPR driver"
+  "VPR driver" -> "VPR driver" : FLPR shutdown
+  activate "VPR driver"
+  "VPR driver" -> FLPR : FLPR_SHUTDOWN_PREPARE
+  activate FLPR
+  rnote over FLPR
+  Deinitialize HW peripherals, etc
+  endrnote
+  return FLPR_SHUTDOWN_PREPARED
+  deactivate "VPR driver"
+  rnote over "VPR driver"
+  Power off FLPR
+  endrnote
+  rnote over "VPR driver"
+  Power off FLPR RAM
+  endrnote
+  return
+  deactivate Zephyr
+  @enduml
+
+.. note::
+	VPR driver is not yet implemented, it should be implemented when writing HPF software.
+	It shall run on application core.
+	Its purpose is to control basic FLPR functionalities like initialization of inter processor communication and power mode management.
+
+HPF firmware
+============
+
+HPF firmware is responsible for managing power states of the following resources:
+
+* FLPR CPU power state
+* Hardware peripherals used by the HPF firmware
+
+FLPR CPU power state management
+-------------------------------
+
+Your HPF firmware should not use the Zephyr libraries for `System Power Management`_, as the libraries rely on multithreading.
+Instead, you must implement a distinct approach.
+
+Your HPF firmware should configure a sleep mode that is activated using both the ``SLEEPSTATE`` and ``STACKONSLEEP`` fields in the ``NORDIC.VPRNORDICSLEEPCTRL`` register.
+For details, see the *Sleep mode operation* section in the VPR peripheral description.
+
+This configuration must occur in the following cases:
+
+* When the FLPR starts (the sleep mode setting is derived from a Kconfig option).
+* When the Host receives the ``SUSPEND`` or ``RESUME`` signal.
+
+In the main loop, the HPF firmware should call ``k_cpu_idle`` to enter sleep mode.
+Ensure that ``k_cpu_idle()`` is only called within the main loop to prevent the FLPR from entering an incorrect power state.
+
+Sleep modes should be application-specific.
+Consider the following:
+
+* Latency requirements of the emulated protocol
+* Minimum time in sleep mode that brings power savings
+* Hardware limitations (for example, constraints on waking up from hibernation)
+
+Hardware peripherals
+--------------------
+
+You might have to use specific hardware peripherals with the HPF firmware.
+
+When FLPR starts, it must initialize the required peripherals.
+When the Host sends a request for shutdown, these peripherals should be deinitialized and powered down before signaling that preparations for shutdown are complete.
+
+To ensure the optimal power state of hardware peripherals, the HPF firmware should employ nrfx drivers, which are designed to manage the power states of hardware peripherals effectively.
diff --git a/doc/nrf/app_dev/device_guides/coprocessors/rt_peripherals.rst b/doc/nrf/app_dev/device_guides/coprocessors/rt_peripherals.rst
new file mode 100644
index 000000000000..0473d5770046
--- /dev/null
+++ b/doc/nrf/app_dev/device_guides/coprocessors/rt_peripherals.rst
@@ -0,0 +1,323 @@
+.. _hpf_real_time_peripherals:
+
+Real-time peripherals
+#####################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+.. contents::
+   :local:
+   :depth: 2
+
+This document provides technical details and guidance on how to use the real-time (RT) peripherals integrated into the VPR CPU.
+They are designed to enhance real-time performance and allow precise control over GPIO pads and other low-level hardware interactions.
+
+Overview
+********
+
+The real-time peripherals consist of the following main components that interact to deliver cycle-accurate control and synchronization of GPIO pads and events:
+
+* VPR TIMER (VTIM) - Provides precise timing control and synchronization.
+* VPR IO (VIO) - A GPIO controller that can handle up to 16 pins.
+* VPR Event Interface (VEVIF) - Enables the sourcing of interrupt requests (IRQs) from the VPR and interaction with the Distributed Programmable Peripheral Interconnect (DPPI).
+
+The peripherals operate in real-time and are mapped to the processor's Control and Status Register (CSR) space.
+They remain active even in wait, sleep, and deep sleep modes, making them ideal for energy-efficient designs.
+
+Prerequisites
+*************
+
+Before you start using the RT peripherals, enable them by calling the :c:func:`nrf_vpr_csr_rtperiph_enable_set` function.
+
+VPR TIMER (VTIM)
+****************
+
+The VPR TIMER (VTIM) offers the following features:
+
+* Two 16-bit timers (counter 0 and counter 1) that can operate independently or combine to form a 32-bit timer.
+* Precise synchronization with the VIO and VEVIF modules for generating event pulses upon timer completion.
+* Operation at the same clock frequency as the CPU without a prescaler.
+
+.. note::
+   You can find the full API in the `nrfx API documentation`_.
+
+TIMER modes
+===========
+
+Each timer can operate in several modes to control its counting behavior, which can be set using the :c:func:`nrf_vpr_csr_vtim_count_mode_set` function:
+
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` - Halts the timer when it reaches zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_WRAP` - Restarts the timer from its maximum value (``0xFFFF``) after reaching zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_RELOAD` - Reloads the timer with a pre-configured value when it reaches zero.
+  The value is set using the :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set` or :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set` function.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_TRIGGER_COMBINED` - Trigger (counter 0) or combined (counter 1) mode.
+
+  * Trigger mode is set to counter 0.
+    The counter stops at zero and will not immediately restart the countdown if there is a change in value in counter 0, or in the combined counter when counter 1 is set to combined mode.
+    Instead, it restarts only after a VIO event pulse occurs or VEVIF task 0 is triggered.
+  * Combined mode is set to counter 1.
+    Counter 1 and counter 0 act as one, combined counter, with counter 1 covering the 16 most significant bits and counter 0 covering the 16 least significant bits.
+    The mode for the combined counter is set in counter 0.
+    In this mode, the system omits any counter event pulses that occur when counter 1 reaches zero.
+
+Use the ``nrf_vpr_csr_vtim_simple_*`` API to set the counters in standalone mode.
+You must specify the counter index:
+
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_wait_set`
+
+Use the following functions (``nrf_vpr_csr_vtim_combined_*`` ) to adjust the combined counter:
+
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_wait_trigger`
+
+Operational guidelines
+======================
+
+Familiarize yourself with the following guidelines for managing counters within the system:
+
+* Writing any non-zero value to a counter starts the counter.
+  You can do this using ``nrf_vpr_csr_vtim_{combined,simple}_counter_set``, which sets the counter to a given value, or ``nrf_vpr_csr_vtim_{combined,simple}_counter_add_set``, which adds a value to the counter's current value.
+* Timers generate an event pulse when they reach zero, which may trigger actions in other RT peripherals.
+* Timers stop when they reach zero or if you set the counter value to zero in the :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` mode.
+
+Interrupt
+=========
+
+Counter 0 can generate an interrupt request if it is enabled using the :c:func:`nrf_vpr_csr_cnt_irq_enable_set` function.
+The interrupt line triggered varies depending on the System on Chip (SoC):
+
+.. list-table:: IRQ line triggered by counter 0
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - IRQ line
+
+   * - nRF54L15 FLPR
+     - 31
+
+CPU stalling
+============
+
+CPU can be stalled until corresponding counter's event pulse is generated, using the :c:func:`nrf_vpr_csr_vtim_simple_wait_set` or :c:func:`nrf_vpr_csr_vtim_combined_wait_trigger` function.
+
+VPR IO (VIO)
+************
+
+The VPR IO (VIO) offers the following features:
+
+* 16 GPIO pins - Supports up to 16 pins, configurable as input or output.
+* Buffered outputs - Allows high-speed parallel GPIO updates.
+* Pin direction control - Allows each pin to be individually configured for input or output.
+
+Mapping pins
+============
+
+VIO pin numbering differs from general pin numbering.
+See the following table for pin mapping between GPIO and VIO for specific targets:
+
+.. list-table:: Pin mapping between GPIO and VIO
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - VIO pins available
+     - Corresponding GPIO pins
+
+   * - nrf54L15 FLPR
+     - 4,0,1,3,2,5..10
+     - P2: 0..10
+
+.. note::
+   Routing the signal between VPR and physical pins may require SoC-specific configuration.
+   For instance, on the nRF54L15 SoC, you must change the ownership of GPIO pin with ``nrf_gpio_pin_control_select(pin, NRF_GPIO_PIN_SEL_VPR);``.
+
+Direction
+=========
+
+You can set the pin direction using the :c:func:`nrf_vpr_csr_vio_dir_set` function and toggle it with the :c:func:`nrf_vpr_csr_vio_dir_toggle_set` function.
+
+Output
+======
+
+You can set the pin output values using the :c:func:`nrf_vpr_csr_vio_out_set` function and toggle it with the :c:func:`nrf_vpr_csr_vio_out_toggle_set` function.
+
+Input
+=====
+
+You can access input pin values with the :c:func:`nrf_vpr_csr_vio_in_get` function.
+To modify how frequently these values are updated, use :c:func:`nrf_vpr_csr_vio_mode_in_set`, which allows configuration in one of the following modes:
+
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_CONTINUOUS` - The value is continuously updated with the current state of VIO pins, provided that the CPU is not in a sleep state.
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_EVENT` - The value is updated only on a counter 1 event pulse, regardless of the CPU state.
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_SHIFT` - Similarly to event mode, the value is updated on a counter 1 event pulse.
+  Additionally, input is shifted.
+  For more information, see the :ref:`hpf_real_time_input_shifting` documentation section.
+
+When in continuous mode, VIO pin 0 generates an event pulse on any value change.
+This pulse can request the VPR clock to start, even if the CPU is in sleep mode or the clock is turned off.
+
+Buffering
+=========
+
+VIO supports queuing updates that are applied on the next timer event pulse, allowing synchronized GPIO updates.
+You can access buffered analogues using the ``nrf_vpr_csr_vio_*_buffered_*`` functions.
+Writing to buffers will set dirty bits, which you can check with ``nrf_vpr_csr_vio_*_buffered_dirty_check``.
+A dirty buffer is transferred to its direct analogue on a counter 0 event pulse, clearing the corresponding dirty bit.
+Writing to a dirty buffer will stall the CPU to prevent overruns.
+Additionally, writing to a direct analogue will also write to the buffer, clearing the dirty bit (if set).
+Do not use the :c:func:`nrf_vpr_csr_vio_in_buffered_get` function in continuous or event modes, as it will stall the CPU until the next counter 1 event pulse.
+
+Shifting
+========
+
+VIO supports serialized input and output operations.
+
+Output shifting
+---------------
+
+VIO supports serialized output operations, useful for reducing CPU load during high-frequency GPIO updates.
+The shifting mode is configured using :c:struct:`nrf_vpr_csr_vio_mode_out_t`, where :c:member:`frame_width` defines frame width in bits.
+You can use the following shifting modes:
+
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_NONE` - Shifting is disabled.
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB` - Shifting uses output and buffered output.
+  This mode is optimized for wide parallel output streams, where output data needs to be loaded very frequently.
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB_TOGGLE` - VIO 0 is reserved for the clock output pin.
+  Shifting uses output and buffered output.
+  This mode is optimized for serial protocol master operations, such as SPI, where timing synchronization is critical.
+
+You can set the advanced configuration for output shifting with the :c:func:`nrf_vpr_csr_vio_config_set` function.
+
+.. note::
+  For more information on output shifting, see the *Shifting modes and usage* section in the VPR peripheral description.
+
+.. _hpf_real_time_input_shifting:
+
+Input shifting
+--------------
+
+VIO supports serialized input operations through shifting, activated by setting :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_SHIFT`.
+Shifting process aligns with the serial clock and sampling point based on counter 1 event pulses.
+This mode is intended to be used in conjunction with :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB_TOGGLE` output mode.
+
+.. note::
+  For more information on input shifting, see the *Input Shifting* section in the VPR peripheral description.
+
+Combined access
+===============
+
+Since VIO is using 16 pins, some functionalities have been combined into a single register.
+By using ``nrf_vpr_csr_vio_*_combined_*``, you can decrease the number of times registers are accessed, and consequently improve timings.
+
+VPR Events Interface (VEVIF)
+****************************
+
+VEVIF is an event interface for VPR, allowing connection to the domain's DPPI system.
+VEVIF can also generate IRQs to other CPUs.
+Note that VEVIF is the only RT peripheral module with registers accessible through Advanced Peripheral Bus (APB).
+
+Tasks
+=====
+
+VEVIF tasks are responsible for generating interrupts handled by the VPR interrupt controller.
+You can trigger tasks in the following ways:
+
+* By calling the :c:func:`nrf_vpr_task_trigger` function, usually from other core to trigger an IRQ on VPR.
+* By calling the :c:func:`nrf_vpr_csr_tasks_set` function, which is done only locally from VPR to generate local IRQ.
+* Through the DPPI system, configured with the :c:func:`nrf_vpr_csr_vevif_subscribe_set` function.
+
+The interrupt service routine must clear the task bit using the :c:func:`nrf_vpr_csr_vevif_tasks_clear`.
+
+Events
+======
+
+VEVIF events can generate pulses that trigger an IRQ line or DPPI channels.
+You can trigger events through calling the :c:func:`nrf_vpr_csr_vevif_events_set` function (locally from VPR).
+To source DPPI using VEVIF events, you must configure it with the :c:func:`nrf_vpr_csr_vevif_publish_set` function.
+To source IRQ out of VPR using VEVIF events, you need to enable them using the :c:func:`nrf_vpr_int_enable` function (from remote side) or the :c:func:`nrf_vpr_csr_vevif_int_enable` function (from VPR).
+
+Buffering
+---------
+
+Similarly to VIO, you can buffer VEVIF events using the :c:func:`nrf_vpr_csr_vevif_events_buffered_set` function.
+Buffer overflows are avoided by stalling the CPU when writing to a dirty buffer.
+
+Tasks and events availability
+=============================
+
+The availability of VEVIF tasks and events varies depending on the SoC:
+
+.. list-table:: VEVIF availability on SoCs
+   :widths: auto
+   :header-rows: 1
+
+   * - Resource
+     - Availability
+   * - VEVIF tasks
+     - 16..22
+   * - VEVIF tasks DPPI connections
+     - 16..19 connected to DPPIC_00 channels 0..3
+   * - VEVIF events
+     - 16..22
+   * - VEVIF events DPPI connections
+     - 16..19 connected to DPPIC_00 channels 0..3
+
+Use cases
+*********
+
+The following sections show how to use RT peripherals in selected scenarios.
+
+Interaction between VTIM and VIO
+================================
+
+You can use VTIM to trigger GPIO updates:
+
+* Timers generate event pulses upon reaching zero.
+* VIO outputs are synchronized with these pulses, ensuring precise GPIO control.
+
+Toggle VIO pin on VTIM event
+----------------------------
+
+In this example, VTIM (in reload combined mode) is set to generate an event every 64 million CPU cycles.
+Whenever this event occurs, VIO is configured to toggle pin 9 (mapping to P2.09 - **LED0** on the nRF54L15 DK) using buffered output:
+
+.. code-block:: c
+
+   // Configure ownership of P2.09 pin (VIO pin 9) - nRF54L15 specific
+   nrf_gpio_pin_control_select(NRF_GPIO_PIN_MAP(2, 9), NRF_GPIO_PIN_SEL_VPR);
+
+   // Enable real-time peripherals
+   nrf_vpr_csr_rtperiph_enable_set(true);
+
+   // Configure counters to reload and combined mode
+   nrf_vpr_csr_vtim_count_mode_set(0, NRF_VPR_CSR_VTIM_COUNT_RELOAD);
+   nrf_vpr_csr_vtim_count_mode_set(1, NRF_VPR_CSR_VTIM_COUNT_TRIGGER_COMBINED);
+
+   // Configure VIO pin 9 as output
+   nrf_vpr_csr_vio_dir_set(1 << 9);
+
+   // Configure reload value
+   nrf_vpr_csr_vtim_combined_counter_top_set(64000000);
+
+   // Start the timer
+   nrf_vpr_csr_vtim_combined_counter_set(64000000);
+
+   while (true)
+   {
+      // Configure buffer output to toggle pin 9
+      nrf_vpr_csr_vio_out_toggle_buffered_set(1 << 9);
+
+      // CPU is stalled until output buffer is clean.
+   }
diff --git a/doc/nrf/applications.rst b/doc/nrf/applications.rst
index 474ef84513d8..0af07260743a 100644
--- a/doc/nrf/applications.rst
+++ b/doc/nrf/applications.rst
@@ -18,11 +18,11 @@ If you want to list applications available for one or more specific boards, `use
    :caption: Subpages:
 
    ../../applications/connectivity_bridge/README
-   ../../applications/hpf/gpio/README
    ../../applications/ipc_radio/README
    ../../applications/matter_bridge/README
    ../../applications/nrf5340_audio/index
    ../../applications/nrf_desktop/README
    ../../applications/machine_learning/README
+   ../../applications/hpf/hpf
    ../../applications/serial_lte_modem/README
    ../../applications/matter_weather_station/README
diff --git a/doc/nrf/conf.py b/doc/nrf/conf.py
index 7a5a2fcbe5dd..6e9f5b7a56e6 100644
--- a/doc/nrf/conf.py
+++ b/doc/nrf/conf.py
@@ -56,6 +56,7 @@
     "notfound.extension",
     "ncs_tool_versions",
     "page_filter",
+    "sphinxcontrib.plantuml",
 ]
 
 linkcheck_ignore = [
diff --git a/doc/nrf/links.txt b/doc/nrf/links.txt
index adeabde980fc..16b5da78c59e 100644
--- a/doc/nrf/links.txt
+++ b/doc/nrf/links.txt
@@ -102,6 +102,7 @@
 .. _`Golioth Firmware SDK NCS doc`: https://github.com/golioth/golioth-firmware-sdk/tree/v0.13.1/examples/zephyr#using-with-nordics-nrf-connect-sdk
 
 .. _`nrfx`: https://github.com/NordicSemiconductor/nrfx/
+.. _`nrfx API documentation`: https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/index.html
 .. _`Changelog for nrfx 2.2.0`: https://github.com/NordicSemiconductor/nrfx/blob/master/CHANGELOG.md#user-content-220---2020-04-28
 .. _`Changelog for nrfx 2.3.0`: https://github.com/NordicSemiconductor/nrfx/blob/master/CHANGELOG.md#user-content-230---2020-08-19
 .. _`Changelog for nrfx 2.4.0`: https://github.com/NordicSemiconductor/nrfx/blob/master/CHANGELOG.md#user-content-240---2020-11-13
@@ -630,6 +631,9 @@
 .. _`Zephyr Logging`: https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/logging/index.html
 .. _`Dictionary-based Logging`: https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/logging/index.html#dictionary-based_logging
 .. _`Run-time Filtering`: https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/logging/index.html#runtime_filtering
+.. _`Device Runtime Power Management`: https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/pm/device_runtime.html
+.. _`System Power Off`: https://docs.nordicsemi.com/bundle/zephyr-apis-latest/page/group_sys_poweroff.html
+.. _`System Power Management`: https://docs.nordicsemi.com/bundle/ncs-latest/page/zephyr/services/pm/system.html
 
 .. _`nRF9160: GPS with SUPL client library`: https://docs.nordicsemi.com/bundle/ncs-1.2.0/page/nrf/samples/nrf9160/gps/README.html
 


Reviews:
user: login: greg-fer
state: DISMISSED
author_association: CONTRIBUTOR
submitted_at: 2025-04-08T15:48:45Z
user: login: magp-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T09:22:10Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-10T11:17:13Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-11T07:47:10Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-11T08:07:31Z
user: login: masz-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-11T14:45:14Z
user: login: magp-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-11T15:10:32Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-12T14:05:28Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-12T18:07:16Z
user: login: masz-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-14T09:41:35Z
user: login: magp-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T10:17:25Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T12:02:39Z
user: login: masz-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T12:21:49Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T12:29:14Z
user: login: masz-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T12:46:51Z
user: login: magp-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T13:09:09Z
user: login: masz-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T13:18:59Z
user: login: masz-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T13:19:56Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T13:31:37Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T13:31:53Z
user: login: annwoj
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T13:32:02Z
user: login: mif1-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-15T13:42:34Z
user: login: annwoj
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T07:54:06Z
user: login: magp-nordic
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T08:03:52Z
user: login: masz-nordic
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T08:09:14Z
user: login: umapraseeda
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T08:21:22Z
user: login: umapraseeda
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T09:06:27Z
user: login: masz-nordic
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T09:10:36Z
user: login: b-gent
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T09:19:21Z
user: login: rlubos
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T10:51:14Z

Review comments:
diff_hunk: @@ -0,0 +1,11 @@
+<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=5,IE=9" ><![endif]-->
+<!DOCTYPE html>
path: doc/nrf/app_dev/device_guides/hpf/hpf_pm.drawio.html
user: login: greg-fer
body: Rework in Visio: https://nordicsemi.atlassian.net/wiki/spaces/TECHDOC/pages/120293046/Figure+guide
created_at: 2025-04-08T15:44:24Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,11 @@
+<!--[if IE]><meta http-equiv="X-UA-Compatible" content="IE=5,IE=9" ><![endif]-->
+<!DOCTYPE html>
path: doc/nrf/app_dev/device_guides/hpf/hpf_asm.drawio.html
user: login: greg-fer
body: Rework in Visio: https://nordicsemi.atlassian.net/wiki/spaces/TECHDOC/pages/120293046/Figure+guide
created_at: 2025-04-08T15:45:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,23 @@
+================================
+High Performance Framework (HPF)
+================================
path: doc/nrf/app_dev/device_guides/hpf/index.rst
user: login: greg-fer
body: Please provide the link to a page on Confluence or a JIRA issue that describes the idea behind adding these docs, so that maintainers and requirements can be checked and tech writers can see if they meet [guidelines for doc sections](https://nordicsemi.atlassian.net/wiki/spaces/TECHDOC/pages/649694362/Guidelines+for+doc+sections+in+the+NCS)
created_at: 2025-04-08T15:46:41Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,67 @@
+#######################
+HPF Assembly Management
+#######################
+
+Assembly Management is required to achieve following requirements defined in event handling:
+
+- Modularity
+- Testability
+
+
+Rationale
+=========
+
+During a build, Hard Real-Time (HRT) functions will be compiled to assembly code.
+This code will be checked against previous version of the assembly code that was verified with HW characteristic tests.
+If the difference is none, or deemed small enough, new code is considered timing accurate as well.
+Application will use pre-generated assembly file to build HRT part.
+By storing assembly files, it is possible to review changes introduced both by developer and toolchain.
+
+Implementation
+==============
+
+Assembly management is implemented in build-time CMake scripts.
+In order to use it, application's CMakeLists.txt has to include ``sdp_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c)``.
+Where ``file.c`` is C file containing only HRT functions.
+
+This allows following CMake functions to be used:
+
+- ``sdp_assembly_generate``
+- ``sdp_assembly_check``
+- ``sdp_assembly_prepare_install``
+- ``sdp_assembly_target_sources``
+
+sdp_assembly_generate
+---------------------
+
+This function adds a build target that generates a temporary ``file-soc-temp.s`` file in the FLPR application's build directory when ``ninja build`` is invoked.
+``soc`` is the SoC name for current build, such as ``nrf54l15``.
+
+sdp_assembly_check
+------------------
+
+This function adds a build target that is called when ``ninja build`` is invoked, after one from ``sdk_assembly_generate``.
+It checks whether ``file-soc-temp.s`` file in build directory is identical to ``file-soc.s`` file in source directory (where ``file.c`` is located).
+If there is a difference between those files, a CMake warning is generated.
path: doc/nrf/app_dev/device_guides/hpf/assembly_management.rst
user: login: magp-nordic
body: This line should be changed to something like this:
```suggestion
If there is a difference between those files, a CMake error (user mode) or warning (developer mode) is generated.
```
created_at: 2025-04-09T09:07:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,67 @@
+#######################
+HPF Assembly Management
+#######################
+
+Assembly Management is required to achieve following requirements defined in event handling:
+
+- Modularity
+- Testability
+
+
+Rationale
+=========
+
+During a build, Hard Real-Time (HRT) functions will be compiled to assembly code.
+This code will be checked against previous version of the assembly code that was verified with HW characteristic tests.
+If the difference is none, or deemed small enough, new code is considered timing accurate as well.
+Application will use pre-generated assembly file to build HRT part.
+By storing assembly files, it is possible to review changes introduced both by developer and toolchain.
+
+Implementation
+==============
+
+Assembly management is implemented in build-time CMake scripts.
+In order to use it, application's CMakeLists.txt has to include ``sdp_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c)``.
+Where ``file.c`` is C file containing only HRT functions.
+
+This allows following CMake functions to be used:
+
+- ``sdp_assembly_generate``
+- ``sdp_assembly_check``
+- ``sdp_assembly_prepare_install``
+- ``sdp_assembly_target_sources``
+
+sdp_assembly_generate
+---------------------
+
+This function adds a build target that generates a temporary ``file-soc-temp.s`` file in the FLPR application's build directory when ``ninja build`` is invoked.
+``soc`` is the SoC name for current build, such as ``nrf54l15``.
+
+sdp_assembly_check
+------------------
+
+This function adds a build target that is called when ``ninja build`` is invoked, after one from ``sdk_assembly_generate``.
+It checks whether ``file-soc-temp.s`` file in build directory is identical to ``file-soc.s`` file in source directory (where ``file.c`` is located).
+If there is a difference between those files, a CMake warning is generated.
+Developer should verify if changes between ``file-soc-temp.s`` and ``file-soc.s`` can be deemed small enough to be considered timing accurate.
+If yes, ``ninja asm_install`` should be called in the FLPR application's build directory.
path: doc/nrf/app_dev/device_guides/hpf/assembly_management.rst
user: login: magp-nordic
body: This is still true, but for user mode, so it probably should be changed to something like this:
```suggestion
In user mode, developer should verify if changes between ``file-soc-temp.s`` and ``file-soc.s`` can be deemed small enough to be considered timing accurate.
If yes, ``ninja asm_install`` should be called in the FLPR application's build directory.
```
created_at: 2025-04-09T09:09:10Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,67 @@
+#######################
+HPF Assembly Management
+#######################
+
+Assembly Management is required to achieve following requirements defined in event handling:
+
+- Modularity
+- Testability
+
+
+Rationale
+=========
+
+During a build, Hard Real-Time (HRT) functions will be compiled to assembly code.
+This code will be checked against previous version of the assembly code that was verified with HW characteristic tests.
+If the difference is none, or deemed small enough, new code is considered timing accurate as well.
+Application will use pre-generated assembly file to build HRT part.
+By storing assembly files, it is possible to review changes introduced both by developer and toolchain.
+
+Implementation
+==============
+
+Assembly management is implemented in build-time CMake scripts.
+In order to use it, application's CMakeLists.txt has to include ``sdp_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c)``.
+Where ``file.c`` is C file containing only HRT functions.
+
+This allows following CMake functions to be used:
+
+- ``sdp_assembly_generate``
+- ``sdp_assembly_check``
+- ``sdp_assembly_prepare_install``
+- ``sdp_assembly_target_sources``
+
+sdp_assembly_generate
+---------------------
+
+This function adds a build target that generates a temporary ``file-soc-temp.s`` file in the FLPR application's build directory when ``ninja build`` is invoked.
+``soc`` is the SoC name for current build, such as ``nrf54l15``.
+
+sdp_assembly_check
+------------------
+
+This function adds a build target that is called when ``ninja build`` is invoked, after one from ``sdk_assembly_generate``.
+It checks whether ``file-soc-temp.s`` file in build directory is identical to ``file-soc.s`` file in source directory (where ``file.c`` is located).
+If there is a difference between those files, a CMake warning is generated.
+Developer should verify if changes between ``file-soc-temp.s`` and ``file-soc.s`` can be deemed small enough to be considered timing accurate.
+If yes, ``ninja asm_install`` should be called in the FLPR application's build directory.
+Otherwise, code needs to be adjusted or HW characterisation tests need to be rerun.
path: doc/nrf/app_dev/device_guides/hpf/assembly_management.rst
user: login: magp-nordic
body: There should be a small description below this line of what happens in developer mode:
```suggestion
Otherwise, code needs to be adjusted or HW characterisation tests need to be rerun.
In developer mode, ``file-soc-temps.s`` is included in the build. However, the file is not replaced in the source directory, to do that ``ninja asm_install`` should be called in the FLPR application's build directory.
```
created_at: 2025-04-09T09:14:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,67 @@
+#######################
+HPF Assembly Management
+#######################
+
+Assembly Management is required to achieve following requirements defined in event handling:
+
+- Modularity
+- Testability
+
+
+Rationale
+=========
+
+During a build, Hard Real-Time (HRT) functions will be compiled to assembly code.
+This code will be checked against previous version of the assembly code that was verified with HW characteristic tests.
+If the difference is none, or deemed small enough, new code is considered timing accurate as well.
+Application will use pre-generated assembly file to build HRT part.
path: doc/nrf/app_dev/device_guides/hpf/assembly_management.rst
user: login: magp-nordic
body: This should be changed:
```suggestion
Application can be build in two modes: user or developer mode. In user mode, application will use pre-generated assembly file to build HRT part. In developer mode application will use newly-generated assembly file.
```
created_at: 2025-04-09T09:20:01Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,127 @@
+.. _hpf_event_handling:
+
+Event handling
+##############
+
+This page section outlines the critical requirements and implementation strategies for managing events within the system, ensuring that functionalities are both modular and precise in execution.
+
+Requirements
+************
+
+The system must support the integration of multiple High-Performance Framework (HPF) peripherals, ensuring the following:
+
+* Modularity, allowing to combine functionalities of multiple HPF peripherals.
+* Timing accuracy, focusing on handling certain parts of the code with very accurate timings.
+* Verification, ensuring it is possible verify timing accuracy without the need to rerun an entire suite of hardware characteristic tests.
+
+Implementation
+**************
+
+To ensure precise timing, specific sections of the code are identified and managed as Hard-Real Time (HRT) functions.
+These functions are kept separate from the main application code.
+
+During the build process, HRT functions are compiled into assembly code.
+This code is then compared to a previously verified version to ensure that there are no significant deviations.
+If the differences are minimal or non-existent, the new code will be deemed accurate in terms of timing.
+
+HRT functions are developed using the Hardware Abstraction Layer (HAL) and avoid any calls to external functions.
+While you can use macros that do not lead to external function calls, you must redefine locally any external macro that influences the assembly code to maintain the required timing accuracy.
+
+Furthermore, HRT functions are implemented as interrupt handlers.
+This implementation ensures that these functions are executed in the correct sequence when triggered by multiple sources, maintaining the system's timing accuracy.
+
+Interaction between HRT and non-HRT code
+****************************************
+
+Communication between HRT and non-HRT code is critical, especially since HRT functions operate within an Interrupt Service Routine (ISR) and cannot use function arguments for passing values.
+To facilitate this communication, you can use the following methods: specific VEVIF IRQs can be assigned to different HRT functions, and data can be stored in predefined memory addresses.
+
+* VEVIF interrupt ID - You can assign separate HRT functions to certain VEVIF IRQs.
+* Shared memory - You can store data in the pre-defined memory addresses.
+
+The sequence flow is designed to handle initialization, transaction requests, and error handling efficiently.
+During initialization, the system boots up and prepares for operation by entering a wait state.
+For transaction requests, the system handles transmission and reception requests through IPC mechanisms, utilizing shared memory or IRQ numbers for communication between different parts of the system.
+
+In the event of an error, such as a memory fault, the system triggers an error handler which notifies the host of the error and then enters an infinite loop to halt further operations.
+This sequence ensures that the system maintains robust operation and handles errors effectively to prevent system failures:
path: doc/nrf/app_dev/device_guides/hpf/event_handling.rst
user: login: annwoj
body: added - plz verify
created_at: 2025-04-10T11:17:13Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,320 @@
+.. _hpf_real_time_peripherals:
+
+Real-time Peripherals
+#####################
+
+.. contents::
+   :local:
+   :depth: 2
+
+This document provides technical details and guidance on how to use the real-time (RT) peripherals integrated into the VPR CPU.
+They are designed to enhance real-time performance and allow precise control over GPIO pads and other low-level hardware interactions.
+
+Overview
+********
+
+The real-time peripherals consist of the following main components that interact to deliver cycle-accurate control and synchronization of GPIO pads and events:
+
+* VPR TIMER (VTIM) - Provides precise timing control and synchronization.
+* VPR IO (VIO) - A GPIO controller that can handle up to 16 pins.
+* VPR Event Interface (VEVIF) - Enables the sourcing of interrupt requests (IRQs) from the VPR and interaction with the Distributed Programmable Peripheral Interconnect (DPPI).
+
+The peripherals operate in real-time and are mapped to the processor's Control and Status Register (CSR) space.
+They remain active even in wait, sleep, and deep sleep modes, making them ideal for energy-efficient designs.
+
+Prerequisites
+*************
+
+Before you start using the RT peripherals, enable them by calling the :c:func:`nrf_vpr_csr_rtperiph_enable_set` function.
+
+VPR TIMER (VTIM)
+****************
+
+The VPR TIMER (VTIM) offers the following features:
+
+* Two 16-bit timers (counter 0 and counter 1) that can operate independently or combine to form a 32-bit timer.
+* Precise synchronization with the VIO and VEVIF modules for generating event pulses upon timer completion.
+* Operation at the same clock frequency as the CPU without a prescaler.
+
+.. note::
+   You can find the full API in the `nrfx documentation. <https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/group_nrf_vpr_csr_vtim_hal.html>`_
+
+TIMER modes
+===========
+
+Each timer can operate in several modes to control its counting behavior, which can be set using the :c:func:`nrf_vpr_csr_vtim_count_mode_set` function:
+
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` - Halts the timer when it reaches zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_WRAP` - Restarts the timer from its maximum value (``0xFFFF``) after reaching zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_RELOAD` - Reloads the timer with a pre-configured value when it reaches zero.
+  The value is set using the :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set` or :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set` function.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_TRIGGER_COMBINED` - Trigger (counter 0) or combined (counter 1) mode.
+
+  * Trigger mode is set to counter 0.
+    The counter stops at zero and will not immediately restart the countdown if there is a change in value in counter 0, or in the combined counter when counter 1 is set to combined mode.
+    Instead, it restarts only after a VIO event pulse occurs or VEVIF task 0 is triggered.
+  * Combined mode is set to counter 1.
+    Counter 1 and counter 0 act as one, combined counter, with counter 1 covering the 16 most significant bits and counter 0 covering the 16 least significant bits.
+    The mode for the combined counter is set in counter 0.
+    In this mode, the system omits any counter event pulses that occur when counter 1 reaches zero.
+
+Use the ``nrf_vpr_csr_vtim_simple_*`` API to set the counters in standalone mode.
+You must specify the counter index:
+
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_wait_set`
+
+Use the following functions (``nrf_vpr_csr_vtim_combined_*`` ) to adjust the combined counter:
+
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_wait_trigger`
+
+Operational guidelines
+======================
+
+Familiarize yourself with the following guidelines for managing counters within the system:
+
+* Writing any non-zero value to a counter starts the counter.
+  You can do this using ``nrf_vpr_csr_vtim_{combined,simple}_counter_set``, which sets the counter to a given value, or ``nrf_vpr_csr_vtim_{combined,simple}_counter_add_set``, which adds a value to the counter's current value.
+* Timers generate an event pulse when they reach zero, which may trigger actions in other RT peripherals.
+* Timers stop when they reach zero or if you set the counter value to zero in the :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` mode.
+
+Interrupt
+=========
+
+Counter 0 can generate an interrupt request if it is enabled using the :c:func:`nrf_vpr_csr_cnt_irq_enable_set` function.
+The interrupt line triggered varies depending on the System on Chip (SoC):
+
+.. list-table:: IRQ line triggered by counter 0
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - IRQ line
+
+   * - nRF54L15 FLPR
+     - 32 (TODO VERIFY - 31 in HAC)
+
+CPU stalling
+============
+
+CPU can be stalled until corresponding counter's event pulse is generated, using the :c:func:`nrf_vpr_csr_vtim_simple_wait_set` or :c:func:`nrf_vpr_csr_vtim_combined_wait_trigger` function.
+
+VPR IO (VIO)
+************
+
+The VPR IO (VIO) offers the following features:
+
+* 16 GPIO pins - Supports up to 16 pins, configurable as input or output.
+* Buffered outputs - Allows high-speed parallel GPIO updates.
+* Pin direction control - Allows each pin to be individually configured for input or output.
+
+Mapping pins
+============
+
+VIO pin numbering differs from general pin numbering.
+See the following table for pin mapping between GPIO and VIO for specific targets:
+
+.. list-table:: Pin mapping between GPIO and VIO
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - VIO pins available
+     - Corresponding GPIO pins
+
+   * - nrf54L15 FLPR
+     - 4,0,1,3,2,5..10
+     - P2: 0..10
+
+.. note::
+   Routing the signal between VPR and physical pins may require SoC-specific configuration.
+   For instance, on the nRF54L15 SoC, you must change the ownership of GPIO pin with ``nrf_gpio_pin_control_select(pin, NRF_GPIO_PIN_SEL_VPR);``.
+
+Direction
+=========
+
+You can set the pin direction using the :c:func:`nrf_vpr_csr_vio_dir_set` function and toggle it with the :c:func:`nrf_vpr_csr_vio_dir_toggle_set` function.
+
+Output
+======
+
+You can set the pin output values using the :c:func:`nrf_vpr_csr_vio_out_set` function and toggle it with the :c:func:`nrf_vpr_csr_vio_out_toggle_set` function.
+
+Input
+=====
+
+You can access input pin values with the :c:func:`nrf_vpr_csr_vio_in_get` function.
+To modify how frequently these values are updated, use :c:func:`nrf_vpr_csr_vio_mode_in_set`, which allows configuration in one of the following modes:
+
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_CONTINUOUS` - The value is continuously updated with the current state of VIO pins, provided that the CPU is not in a sleep state.
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_EVENT` - The value is updated only on a counter 1 event pulse, regardless of the CPU state.
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_SHIFT` - Similarly to event mode, the value is updated on a counter 1 event pulse.
+  Additionally, input is shifted.
+  For more information, see the :ref:`hpf_real_time_input_shifting` documentation section.
+
+When in continuous mode, VIO pin 0 generates an event pulse on any value change.
+This pulse can request the VPR clock to start, even if the CPU is in sleep mode or the clock is turned off.
+
+Buffering
+=========
+
+VIO supports queuing updates that are applied on the next timer event pulse, allowing synchronized GPIO updates.
+You can access buffered analogues using the ``nrf_vpr_csr_vio_*_buffered_*`` functions.
+Writing to buffers will set dirty bits, which you can check with ``nrf_vpr_csr_vio_*_buffered_dirty_check``.
+A dirty buffer is transferred to its direct analogue on a counter 0 event pulse, clearing the corresponding dirty bit.
+Writing to a dirty buffer will stall the CPU to prevent overruns.
+Additionally, writing to a direct analogue will also write to the buffer, clearing the dirty bit (if set).
+Do not use the :c:func:`nrf_vpr_csr_vio_in_buffered_get` function in continuous or event modes, as it will stall the CPU until the next counter 1 event pulse.
+
+Shifting
+========
+
+VIO supports serialized input and output operations.
+
+Output shifting
+---------------
+
+VIO supports serialized output operations, useful for reducing CPU load during high-frequency GPIO updates.
+The shifting mode is configured using :c:struct:`nrf_vpr_csr_vio_mode_out_t`, where :c:member:`frame_width` defines frame width in bits.
+You can use the following shifting modes:
+
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_NONE` - Shifting is disabled.
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB` - Shifting uses output and buffered output.
+  This mode is optimized for wide parallel output streams, where output data needs to be loaded very frequently.
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB_TOGGLE` - VIO 0 is reserved for the clock output pin.
+  Shifting uses output and buffered output.
+  This mode is optimized for serial protocol master operations, such as SPI, where timing synchronization is critical.
+
+You can set the advanced configuration for output shifting with the :c:func:`nrf_vpr_csr_vio_config_set` function.
+
+.. note::
+  For more information on output shifting, see the *Shifting modes and usage* section in the VPR peripheral description.
+
+.. _hpf_real_time_input_shifting:
+
+Input shifting
+--------------
+
+VIO supports serialized input operations through shifting, activated by setting :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_SHIFT`.
+Shifting process aligns with the serial clock and sampling point based on counter 1 event pulses.
+This mode is intended to be used in conjunction with :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB_TOGGLE` output mode.
+
+.. note::
+  For more information on input shifting, see the *Input Shifting* section in the VPR peripheral description.
+
+Combined access
+===============
+
+Since VIO is using 16 pins, some functionalities have been combined into a single register.
+By using ``nrf_vpr_csr_vio_*_combined_*``, you can decrease the number of times registers are accessed, and consequently improve timings.
+
+VPR Events Interface (VEVIF)
+****************************
+
+VEVIF is an event interface for VPR, allowing connection to the domain's DPPI system.
+VEVIF can also generate IRQs to other CPUs.
+Note that VEVIF is the only RT peripheral module with registers accessible through Advanced Peripheral Bus (APB).
+
+Tasks
+=====
+
+VEVIF tasks are responsible for generating interrupts handled by the VPR interrupt controller.
+You can trigger tasks in the following ways:
+
+* By calling the :c:func:`nrf_vpr_task_trigger` function, usually from other core to trigger an IRQ on VPR.
+* By calling the :c:func:`nrf_vpr_csr_tasks_set` function, which is done only locally from VPR to generate local IRQ.
+* Through the DPPI system, configured with the :c:func:`nrf_vpr_csr_vevif_subscribe_set` function.
+
+The interrupt service routine must clear the task bit using the :c:func:`nrf_vpr_csr_vevif_tasks_clear`.
+
+Events
+======
+
+VEVIF events can generate pulses that trigger an IRQ line or DPPI channels.
+You can trigger events through calling the :c:func:`nrf_vpr_csr_vevif_events_set` function (locally from VPR).
+To source DPPI using VEVIF events, you must configure it with the :c:func:`nrf_vpr_csr_vevif_publish_set` function.
+To source IRQ out of VPR using VEVIF events, you need to enable them using the :c:func:`nrf_vpr_int_enable` function (from remote side) or the :c:func:`nrf_vpr_csr_vevif_int_enable` function (from VPR).
+
+Buffering
+---------
+
+Similarly to VIO, you can buffer VEVIF events using the :c:func:`nrf_vpr_csr_vevif_events_buffered_set` function.
+Buffer overflows are avoided by stalling the CPU when writing to a dirty buffer.
+
+Tasks and events availability
+=============================
+
+The availability of VEVIF tasks and events varies depending on the SoC:
+
+.. list-table:: VEVIF availability on SoCs
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - VEVIF tasks available
+     - VEVIF tasks DPPI connections
+     - VEVIF events available
+     - VEVIF events DPPI connections
+
+   * - nRF54L15 FLPR
path: doc/nrf/app_dev/device_guides/hpf/rt_peripherals.rst
user: login: annwoj
body: tbc - Is it only nRF54L15? what about nRF54H20?
created_at: 2025-04-11T07:47:09Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,320 @@
+.. _hpf_real_time_peripherals:
+
+Real-time Peripherals
+#####################
+
+.. contents::
+   :local:
+   :depth: 2
+
+This document provides technical details and guidance on how to use the real-time (RT) peripherals integrated into the VPR CPU.
+They are designed to enhance real-time performance and allow precise control over GPIO pads and other low-level hardware interactions.
+
+Overview
+********
+
+The real-time peripherals consist of the following main components that interact to deliver cycle-accurate control and synchronization of GPIO pads and events:
+
+* VPR TIMER (VTIM) - Provides precise timing control and synchronization.
+* VPR IO (VIO) - A GPIO controller that can handle up to 16 pins.
+* VPR Event Interface (VEVIF) - Enables the sourcing of interrupt requests (IRQs) from the VPR and interaction with the Distributed Programmable Peripheral Interconnect (DPPI).
+
+The peripherals operate in real-time and are mapped to the processor's Control and Status Register (CSR) space.
+They remain active even in wait, sleep, and deep sleep modes, making them ideal for energy-efficient designs.
+
+Prerequisites
+*************
+
+Before you start using the RT peripherals, enable them by calling the :c:func:`nrf_vpr_csr_rtperiph_enable_set` function.
+
+VPR TIMER (VTIM)
+****************
+
+The VPR TIMER (VTIM) offers the following features:
+
+* Two 16-bit timers (counter 0 and counter 1) that can operate independently or combine to form a 32-bit timer.
+* Precise synchronization with the VIO and VEVIF modules for generating event pulses upon timer completion.
+* Operation at the same clock frequency as the CPU without a prescaler.
+
+.. note::
+   You can find the full API in the `nrfx documentation. <https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/group_nrf_vpr_csr_vtim_hal.html>`_
path: doc/nrf/app_dev/device_guides/hpf/rt_peripherals.rst
user: login: annwoj
body: ```suggestion
   You can find the full API in the `nrfx API documentation`_.
```
Got this one confirmed - we can only refer to the docset.
+we need to add the following to links.txt instead (after line 101):

``` .. `nrfx API documentation`: https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/index.html ```
created_at: 2025-04-11T08:04:28Z
author_association: CONTRIBUTOR
diff_hunk: @@ -37,3 +37,4 @@ For detailed integration instructions of specific technologies and components, c
    app_dev/device_guides/fem/index
    app_dev/device_guides/custom/index
    app_dev/device_guides/wifi_coex
+   app_dev/device_guides/hpf/index
path: doc/nrf/app_dev.rst
user: login: masz-nordic
body: ```suggestion
   app_dev/device_guides/coprocessors/index
```
created_at: 2025-04-11T14:26:45Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,15 @@
+.. _coprocessors_index:
+
+Developing with coprocesors
+###########################
+
+Thie following pages provide a detailed guide for developers aiming to utilize coprocessors effectively within the nRF54L and nRF54H platforms.
+The RISC-V coprocessor integrated into these platforms facilitates the development of custom, software-defined peripherals, enhancing the functionality and performance of the main processor.
path: doc/nrf/app_dev/device_guides/hpf/index.rst
user: login: masz-nordic
body: This section should not focus on HPF, but explain that you can use VPR with both:
- multithreaded zephyr (and that page should be taken from https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf54l/vpr_flpr.html)
- HPF (and the whole structure added here should then be under that)
created_at: 2025-04-11T14:29:28Z
author_association: CONTRIBUTOR
path: doc/nrf/app_dev/device_guides/hpf/hpf_gpio_example.rst
user: login: masz-nordic
body: To be deleted
created_at: 2025-04-11T14:31:48Z
author_association: CONTRIBUTOR
path: doc/nrf/app_dev/device_guides/hpf/hpf_mspi_example.rst
user: login: masz-nordic
body: This should be in `applications/hpf/mspi`
created_at: 2025-04-11T14:32:06Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,24 @@
+.. _hpf_index:
+
+High-Performance Framework (HPF)
+################################
+
+.. note::
+
+   The HPF support in the |NCS| is currently experimental.
+
+High-Performance Framework, is a framework designed to facilitate the creation and integration of software peripherals using coprocessors.
+It includes targeted tools and code examples.
path: doc/nrf/app_dev/device_guides/hpf/hpf.rst
user: login: masz-nordic
body: It should be expanded on general overview of what HPF provides and why VPR is fit for making software peripherals.
created_at: 2025-04-11T14:33:08Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,65 @@
+.. _hpf_assembly_management:
+
+Assembly management
+###################
+
+Assembly Management is a critical component in the development process, particularly when meeting the modularity and testability requirements defined in the event handling.
+
+Overview
+********
+
+During the compilation process, Hard Real-Time (HRT) functions are compiled into assembly code.
+This assembly code is then compared to a previously verified version that has undergone hardware characteristic tests.
+If the differences between the current and previous versions are within acceptable limits, the new code is considered to maintain timing accuracy.
+
+The application can be built in two modes: user mode and developer mode.
+In user mode, the application uses a pre-generated assembly file to construct the HRT component, while in developer mode, the application employs a newly generated assembly file.
+This approach not only facilitates the integration of updates but also allows for a thorough review of changes made by developers and modifications introduced by the toolchain.
path: doc/nrf/app_dev/device_guides/hpf/assembly_management.rst
user: login: masz-nordic
body: How to enable/disable dev mode?
created_at: 2025-04-11T14:35:17Z
author_association: CONTRIBUTOR
path: doc/nrf/app_dev/device_guides/hpf/assembly_management.rst
user: login: masz-nordic
body: @magp-nordic please verify if up to date
created_at: 2025-04-11T14:39:54Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,48 @@
+.. _hpf_fault_handling:
+
+Fault handling
+##############
+
+The following page outlines mechanisms and strategies employed to manage faults in both the Host and High-Performance Framework (HPF) firmware environments.
+
+Host fault
+**********
+
+In case of a Host crash followed by a reset, the management of the VPR state depends on the system architecture:
+
+* On the :ref:`nRF54L platform<ug_nrf54l>`, the hardware is designed to ensure that a reset of the application core (Host) simultaneously triggers a reset of the HPF firmware (:ref:`FLPR core<vpr_flpr_nrf54l>`).
+* On the :ref:`nRF54H platform<ug_nrf54h>`, the :ref:`Secure Domain Firmware<ug_nrf54h20_secure_domain>` is responsible for resetting all resources allocated to the owner of the HPF FW (FLPR), which is the Host.
+
+This architecture ensures synchronization between the cores.
+
+Firmware fault
+**************
+
+In case a HPF firmware crashes, it must be signalled to the Host.
+Since there are no hardware resources dedicated to this task, you must implement the solution in software.
+You can employ the following strategies individually or combined:
+
+.. tabs::
path: doc/nrf/app_dev/device_guides/hpf/fault_handling.rst
user: login: masz-nordic
body: This should not be tabs, but a list.
created_at: 2025-04-11T14:40:57Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,209 @@
+.. _hpf_power_management:
+
+Power management
+################
+
+The following page outlines the approaches and mechanisms employed to ensure efficient power management in High-Performance Framework (HPF) systems, focusing on resource allocation, system states, and interaction between different components.
+
+Power Management in HPF should be considered from the Host side and the HPF firmware side.
+
+Host side
+*********
+
+The Host is responsible for managing power state of the following resources:
+
+* VPR core with HPF firmware running on it
+* RAM
+
+To achieve optimal power state, you must use the `Device Runtime Power Management`_ and `System Power Off`_.
+
+See an example flow of the Host power management:
+
+  .. uml::
path: doc/nrf/app_dev/device_guides/hpf/power_management.rst
user: login: masz-nordic
body: Are we implementing it like this in mSPI?
If not, then better to use other name of driver.
created_at: 2025-04-11T14:42:09Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,209 @@
+.. _hpf_power_management:
+
+Power management
+################
+
+The following page outlines the approaches and mechanisms employed to ensure efficient power management in High-Performance Framework (HPF) systems, focusing on resource allocation, system states, and interaction between different components.
+
+Power Management in HPF should be considered from the Host side and the HPF firmware side.
+
+Host side
+*********
+
+The Host is responsible for managing power state of the following resources:
+
+* VPR core with HPF firmware running on it
+* RAM
+
+To achieve optimal power state, you must use the `Device Runtime Power Management`_ and `System Power Off`_.
+
+See an example flow of the Host power management:
+
+  .. uml::
+
+    @startuml
+    participant Zephyr
+    participant Application
+    participant "mSPI driver"
+    participant "VPR drivers"
+    participant FLPR
+
+    activate Zephyr
+    Zephyr -> Zephyr : post kernel initialization
+    activate Zephyr
+    Zephyr -> "VPR drivers" : Initialize drivers
+    activate "VPR drivers"
+    rnote over "VPR drivers"
+    Power on FLPR RAM
+    endrnote
+    rnote over "VPR drivers"
+    If non-XIP:
+    Copy code to RAM
+    endrnote
+    rnote over "VPR drivers"
+    Start VPR
+    endrnote
+
+    "VPR drivers" -> "VPR drivers" : Initialize IPC
+    activate "VPR drivers"
+    "VPR drivers" -> FLPR
+    activate FLPR
+    rnote over FLPR
+    Boot
+    endrnote
+    rnote over FLPR
+    Initialize IPC
+    endrnote
+    return
+    deactivate "VPR drivers"
+
+    "VPR drivers" -> "VPR drivers" : Initialize FLPR
+    activate "VPR drivers"
+    "VPR drivers" -> FLPR : FLPR_INIT
+    activate FLPR
+    rnote over FLPR
+    Initialize HW, peripherals, etc
+    endrnote
+    return FLPR_INITD
+    deactivate "VPR drivers"
+    return
+    deactivate "VPR drivers"
+
+
+    deactivate Zephyr
+    Zephyr -> Application : Start application
+    activate Application
+    Application -> "mSPI driver" : mspi_config(...)
+    activate "mSPI driver"
+    "mSPI driver" -> "mSPI driver" : mSPI initialization
+    activate "mSPI driver"
+    "mSPI driver" -> "VPR drivers" : pm_device_runtime_get(&flpr)
+    activate "VPR drivers"
+    "VPR drivers" -> FLPR : FLPR_RESUME
+    activate FLPR
+    rnote over FLPR
+    Enter RESUME state
+    endrnote
+    return FLPR_RESUMED
+    return
+
+    "mSPI driver" -> FLPR : FLPR_MSPI_CONFIGURE
+    activate FLPR
+    rnote over FLPR
+    Configure emulated MSPI
+    endrnote
+    return FLPR_MSPI_CONFIGURED
+    deactivate "mSPI driver"
+    return
+    ...
+
+
+    Application -> "mSPI driver" : mspi_transcieve(...)
+    activate "mSPI driver"
+    "mSPI driver" -> FLPR : FLPR_MSPI_XFER
+    activate FLPR
+    rnote over FLPR
+    Execute MSPI transfer
+    endrnote
+    return FLPR_MSPI_XFERD
+    return
+    ...
+
+
+    Application -> "mSPI driver" : mspi_config(...)
+    activate "mSPI driver"
+    "mSPI driver" -> "mSPI driver" : mSPI initialization
+    activate "mSPI driver"
+    "mSPI driver" -> FLPR : FLPR_MSPI_DECONFIGURE
+    activate FLPR
+    rnote over FLPR
+    Deconfigure emulated MSPI
+    endrnote
+    return FLPR_MSPI_DECONFIGURED
+
+    "mSPI driver" -> "VPR drivers" : pm_device_runtime_put(&flpr)
+    activate "VPR drivers"
+    "VPR drivers" -> FLPR : FLPR_SUSPEND
+    activate FLPR
+    rnote over FLPR
+    Enter SUSPENDED state
+    endrnote
+    return FLPR_SUSPENDED
+    return
+    deactivate "mSPI driver"
+    return
+    return
+
+
+    Zephyr -> Zephyr : power off procedure
+    activate Zephyr
+    "Zephyr" -> "VPR drivers" : power off
+    activate "VPR drivers"
+    "VPR drivers" -> "VPR drivers" : FLPR shutdown
+    activate "VPR drivers"
+    "VPR drivers" -> FLPR : FLPR_SHUTDOWN_PREPARE
+    activate FLPR
+    rnote over FLPR
+    Deinitialize HW peripherals, etc
+    endrnote
+    return FLPR_SHUTDOWN_PREPARED
+    deactivate "VPR drivers"
+    rnote over "VPR drivers"
+    Power off VPR
+    endrnote
+    rnote over "VPR drivers"
+    Power off FLPR RAM
+    endrnote
+    return
+    deactivate Zephyr
+    @enduml
+
+Device runtime power management
+===============================
+
+Each HPF device driver instance should call ``pm_device_runtime_get(hpf_dev)`` during its initialization
+and ``pm_device_runtime_put(hpf_dev)`` upon deinitialization.
+This ensure efficient handling of cases where multiple HPF peripherals are running on a single VPR core.
+
+VPR coprocessor driver is responsible for managing transitions to ``PM_DEVICE_ACTION_SUSPEND`` and ``PM_DEVICE_ACTION_RESUME`` by signaling these state changes to the VPR.
+The HPF firmware on the other side handles the corresponding actions.
path: doc/nrf/app_dev/device_guides/hpf/power_management.rst
user: login: masz-nordic
body: This does not exist yet.
created_at: 2025-04-11T14:42:38Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,320 @@
+.. _hpf_real_time_peripherals:
+
+Real-time Peripherals
+#####################
+
+.. contents::
+   :local:
+   :depth: 2
+
+This document provides technical details and guidance on how to use the real-time (RT) peripherals integrated into the VPR CPU.
+They are designed to enhance real-time performance and allow precise control over GPIO pads and other low-level hardware interactions.
+
+Overview
+********
+
+The real-time peripherals consist of the following main components that interact to deliver cycle-accurate control and synchronization of GPIO pads and events:
+
+* VPR TIMER (VTIM) - Provides precise timing control and synchronization.
+* VPR IO (VIO) - A GPIO controller that can handle up to 16 pins.
+* VPR Event Interface (VEVIF) - Enables the sourcing of interrupt requests (IRQs) from the VPR and interaction with the Distributed Programmable Peripheral Interconnect (DPPI).
+
+The peripherals operate in real-time and are mapped to the processor's Control and Status Register (CSR) space.
+They remain active even in wait, sleep, and deep sleep modes, making them ideal for energy-efficient designs.
+
+Prerequisites
+*************
+
+Before you start using the RT peripherals, enable them by calling the :c:func:`nrf_vpr_csr_rtperiph_enable_set` function.
+
+VPR TIMER (VTIM)
+****************
+
+The VPR TIMER (VTIM) offers the following features:
+
+* Two 16-bit timers (counter 0 and counter 1) that can operate independently or combine to form a 32-bit timer.
+* Precise synchronization with the VIO and VEVIF modules for generating event pulses upon timer completion.
+* Operation at the same clock frequency as the CPU without a prescaler.
+
+.. note::
+   You can find the full API in the `nrfx documentation. <https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/group_nrf_vpr_csr_vtim_hal.html>`_
+
+TIMER modes
+===========
+
+Each timer can operate in several modes to control its counting behavior, which can be set using the :c:func:`nrf_vpr_csr_vtim_count_mode_set` function:
+
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` - Halts the timer when it reaches zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_WRAP` - Restarts the timer from its maximum value (``0xFFFF``) after reaching zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_RELOAD` - Reloads the timer with a pre-configured value when it reaches zero.
+  The value is set using the :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set` or :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set` function.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_TRIGGER_COMBINED` - Trigger (counter 0) or combined (counter 1) mode.
+
+  * Trigger mode is set to counter 0.
+    The counter stops at zero and will not immediately restart the countdown if there is a change in value in counter 0, or in the combined counter when counter 1 is set to combined mode.
+    Instead, it restarts only after a VIO event pulse occurs or VEVIF task 0 is triggered.
+  * Combined mode is set to counter 1.
+    Counter 1 and counter 0 act as one, combined counter, with counter 1 covering the 16 most significant bits and counter 0 covering the 16 least significant bits.
+    The mode for the combined counter is set in counter 0.
+    In this mode, the system omits any counter event pulses that occur when counter 1 reaches zero.
+
+Use the ``nrf_vpr_csr_vtim_simple_*`` API to set the counters in standalone mode.
+You must specify the counter index:
+
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_wait_set`
+
+Use the following functions (``nrf_vpr_csr_vtim_combined_*`` ) to adjust the combined counter:
+
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_wait_trigger`
+
+Operational guidelines
+======================
+
+Familiarize yourself with the following guidelines for managing counters within the system:
+
+* Writing any non-zero value to a counter starts the counter.
+  You can do this using ``nrf_vpr_csr_vtim_{combined,simple}_counter_set``, which sets the counter to a given value, or ``nrf_vpr_csr_vtim_{combined,simple}_counter_add_set``, which adds a value to the counter's current value.
+* Timers generate an event pulse when they reach zero, which may trigger actions in other RT peripherals.
+* Timers stop when they reach zero or if you set the counter value to zero in the :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` mode.
+
+Interrupt
+=========
+
+Counter 0 can generate an interrupt request if it is enabled using the :c:func:`nrf_vpr_csr_cnt_irq_enable_set` function.
+The interrupt line triggered varies depending on the System on Chip (SoC):
+
+.. list-table:: IRQ line triggered by counter 0
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - IRQ line
+
+   * - nRF54L15 FLPR
+     - 32 (TODO VERIFY - 31 in HAC)
path: doc/nrf/app_dev/device_guides/hpf/rt_peripherals.rst
user: login: masz-nordic
body: Needs to be verified
created_at: 2025-04-11T14:43:24Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,24 @@
+.. _hpf_index:
+
+High-Performance Framework (HPF)
+################################
+
+.. note::
+
+   The HPF support in the |NCS| is currently experimental.
path: doc/nrf/app_dev/device_guides/hpf/hpf.rst
user: login: masz-nordic
body: It should be noted that HPF is supported only on L15.
created_at: 2025-04-11T14:44:42Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,320 @@
+.. _hpf_real_time_peripherals:
+
+Real-time Peripherals
+#####################
+
+.. contents::
+   :local:
+   :depth: 2
+
+This document provides technical details and guidance on how to use the real-time (RT) peripherals integrated into the VPR CPU.
+They are designed to enhance real-time performance and allow precise control over GPIO pads and other low-level hardware interactions.
+
+Overview
+********
+
+The real-time peripherals consist of the following main components that interact to deliver cycle-accurate control and synchronization of GPIO pads and events:
+
+* VPR TIMER (VTIM) - Provides precise timing control and synchronization.
+* VPR IO (VIO) - A GPIO controller that can handle up to 16 pins.
+* VPR Event Interface (VEVIF) - Enables the sourcing of interrupt requests (IRQs) from the VPR and interaction with the Distributed Programmable Peripheral Interconnect (DPPI).
+
+The peripherals operate in real-time and are mapped to the processor's Control and Status Register (CSR) space.
+They remain active even in wait, sleep, and deep sleep modes, making them ideal for energy-efficient designs.
+
+Prerequisites
+*************
+
+Before you start using the RT peripherals, enable them by calling the :c:func:`nrf_vpr_csr_rtperiph_enable_set` function.
+
+VPR TIMER (VTIM)
+****************
+
+The VPR TIMER (VTIM) offers the following features:
+
+* Two 16-bit timers (counter 0 and counter 1) that can operate independently or combine to form a 32-bit timer.
+* Precise synchronization with the VIO and VEVIF modules for generating event pulses upon timer completion.
+* Operation at the same clock frequency as the CPU without a prescaler.
+
+.. note::
+   You can find the full API in the `nrfx documentation. <https://docs.nordicsemi.com/bundle/nrfx-apis-latest/page/group_nrf_vpr_csr_vtim_hal.html>`_
+
+TIMER modes
+===========
+
+Each timer can operate in several modes to control its counting behavior, which can be set using the :c:func:`nrf_vpr_csr_vtim_count_mode_set` function:
+
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` - Halts the timer when it reaches zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_WRAP` - Restarts the timer from its maximum value (``0xFFFF``) after reaching zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_RELOAD` - Reloads the timer with a pre-configured value when it reaches zero.
+  The value is set using the :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set` or :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set` function.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_TRIGGER_COMBINED` - Trigger (counter 0) or combined (counter 1) mode.
+
+  * Trigger mode is set to counter 0.
+    The counter stops at zero and will not immediately restart the countdown if there is a change in value in counter 0, or in the combined counter when counter 1 is set to combined mode.
+    Instead, it restarts only after a VIO event pulse occurs or VEVIF task 0 is triggered.
+  * Combined mode is set to counter 1.
+    Counter 1 and counter 0 act as one, combined counter, with counter 1 covering the 16 most significant bits and counter 0 covering the 16 least significant bits.
+    The mode for the combined counter is set in counter 0.
+    In this mode, the system omits any counter event pulses that occur when counter 1 reaches zero.
+
+Use the ``nrf_vpr_csr_vtim_simple_*`` API to set the counters in standalone mode.
+You must specify the counter index:
+
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_wait_set`
+
+Use the following functions (``nrf_vpr_csr_vtim_combined_*`` ) to adjust the combined counter:
+
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_wait_trigger`
+
+Operational guidelines
+======================
+
+Familiarize yourself with the following guidelines for managing counters within the system:
+
+* Writing any non-zero value to a counter starts the counter.
+  You can do this using ``nrf_vpr_csr_vtim_{combined,simple}_counter_set``, which sets the counter to a given value, or ``nrf_vpr_csr_vtim_{combined,simple}_counter_add_set``, which adds a value to the counter's current value.
+* Timers generate an event pulse when they reach zero, which may trigger actions in other RT peripherals.
+* Timers stop when they reach zero or if you set the counter value to zero in the :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` mode.
+
+Interrupt
+=========
+
+Counter 0 can generate an interrupt request if it is enabled using the :c:func:`nrf_vpr_csr_cnt_irq_enable_set` function.
+The interrupt line triggered varies depending on the System on Chip (SoC):
+
+.. list-table:: IRQ line triggered by counter 0
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - IRQ line
+
+   * - nRF54L15 FLPR
+     - 32 (TODO VERIFY - 31 in HAC)
+
+CPU stalling
+============
+
+CPU can be stalled until corresponding counter's event pulse is generated, using the :c:func:`nrf_vpr_csr_vtim_simple_wait_set` or :c:func:`nrf_vpr_csr_vtim_combined_wait_trigger` function.
+
+VPR IO (VIO)
+************
+
+The VPR IO (VIO) offers the following features:
+
+* 16 GPIO pins - Supports up to 16 pins, configurable as input or output.
+* Buffered outputs - Allows high-speed parallel GPIO updates.
+* Pin direction control - Allows each pin to be individually configured for input or output.
+
+Mapping pins
+============
+
+VIO pin numbering differs from general pin numbering.
+See the following table for pin mapping between GPIO and VIO for specific targets:
+
+.. list-table:: Pin mapping between GPIO and VIO
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - VIO pins available
+     - Corresponding GPIO pins
+
+   * - nrf54L15 FLPR
+     - 4,0,1,3,2,5..10
+     - P2: 0..10
+
+.. note::
+   Routing the signal between VPR and physical pins may require SoC-specific configuration.
+   For instance, on the nRF54L15 SoC, you must change the ownership of GPIO pin with ``nrf_gpio_pin_control_select(pin, NRF_GPIO_PIN_SEL_VPR);``.
+
+Direction
+=========
+
+You can set the pin direction using the :c:func:`nrf_vpr_csr_vio_dir_set` function and toggle it with the :c:func:`nrf_vpr_csr_vio_dir_toggle_set` function.
+
+Output
+======
+
+You can set the pin output values using the :c:func:`nrf_vpr_csr_vio_out_set` function and toggle it with the :c:func:`nrf_vpr_csr_vio_out_toggle_set` function.
+
+Input
+=====
+
+You can access input pin values with the :c:func:`nrf_vpr_csr_vio_in_get` function.
+To modify how frequently these values are updated, use :c:func:`nrf_vpr_csr_vio_mode_in_set`, which allows configuration in one of the following modes:
+
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_CONTINUOUS` - The value is continuously updated with the current state of VIO pins, provided that the CPU is not in a sleep state.
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_EVENT` - The value is updated only on a counter 1 event pulse, regardless of the CPU state.
+* :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_SHIFT` - Similarly to event mode, the value is updated on a counter 1 event pulse.
+  Additionally, input is shifted.
+  For more information, see the :ref:`hpf_real_time_input_shifting` documentation section.
+
+When in continuous mode, VIO pin 0 generates an event pulse on any value change.
+This pulse can request the VPR clock to start, even if the CPU is in sleep mode or the clock is turned off.
+
+Buffering
+=========
+
+VIO supports queuing updates that are applied on the next timer event pulse, allowing synchronized GPIO updates.
+You can access buffered analogues using the ``nrf_vpr_csr_vio_*_buffered_*`` functions.
+Writing to buffers will set dirty bits, which you can check with ``nrf_vpr_csr_vio_*_buffered_dirty_check``.
+A dirty buffer is transferred to its direct analogue on a counter 0 event pulse, clearing the corresponding dirty bit.
+Writing to a dirty buffer will stall the CPU to prevent overruns.
+Additionally, writing to a direct analogue will also write to the buffer, clearing the dirty bit (if set).
+Do not use the :c:func:`nrf_vpr_csr_vio_in_buffered_get` function in continuous or event modes, as it will stall the CPU until the next counter 1 event pulse.
+
+Shifting
+========
+
+VIO supports serialized input and output operations.
+
+Output shifting
+---------------
+
+VIO supports serialized output operations, useful for reducing CPU load during high-frequency GPIO updates.
+The shifting mode is configured using :c:struct:`nrf_vpr_csr_vio_mode_out_t`, where :c:member:`frame_width` defines frame width in bits.
+You can use the following shifting modes:
+
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_NONE` - Shifting is disabled.
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB` - Shifting uses output and buffered output.
+  This mode is optimized for wide parallel output streams, where output data needs to be loaded very frequently.
+* :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB_TOGGLE` - VIO 0 is reserved for the clock output pin.
+  Shifting uses output and buffered output.
+  This mode is optimized for serial protocol master operations, such as SPI, where timing synchronization is critical.
+
+You can set the advanced configuration for output shifting with the :c:func:`nrf_vpr_csr_vio_config_set` function.
+
+.. note::
+  For more information on output shifting, see the *Shifting modes and usage* section in the VPR peripheral description.
+
+.. _hpf_real_time_input_shifting:
+
+Input shifting
+--------------
+
+VIO supports serialized input operations through shifting, activated by setting :c:enumerator:`NRF_VPR_CSR_VIO_MODE_IN_SHIFT`.
+Shifting process aligns with the serial clock and sampling point based on counter 1 event pulses.
+This mode is intended to be used in conjunction with :c:enumerator:`NRF_VPR_CSR_VIO_SHIFT_OUTB_TOGGLE` output mode.
+
+.. note::
+  For more information on input shifting, see the *Input Shifting* section in the VPR peripheral description.
+
+Combined access
+===============
+
+Since VIO is using 16 pins, some functionalities have been combined into a single register.
+By using ``nrf_vpr_csr_vio_*_combined_*``, you can decrease the number of times registers are accessed, and consequently improve timings.
+
+VPR Events Interface (VEVIF)
+****************************
+
+VEVIF is an event interface for VPR, allowing connection to the domain's DPPI system.
+VEVIF can also generate IRQs to other CPUs.
+Note that VEVIF is the only RT peripheral module with registers accessible through Advanced Peripheral Bus (APB).
+
+Tasks
+=====
+
+VEVIF tasks are responsible for generating interrupts handled by the VPR interrupt controller.
+You can trigger tasks in the following ways:
+
+* By calling the :c:func:`nrf_vpr_task_trigger` function, usually from other core to trigger an IRQ on VPR.
+* By calling the :c:func:`nrf_vpr_csr_tasks_set` function, which is done only locally from VPR to generate local IRQ.
+* Through the DPPI system, configured with the :c:func:`nrf_vpr_csr_vevif_subscribe_set` function.
+
+The interrupt service routine must clear the task bit using the :c:func:`nrf_vpr_csr_vevif_tasks_clear`.
+
+Events
+======
+
+VEVIF events can generate pulses that trigger an IRQ line or DPPI channels.
+You can trigger events through calling the :c:func:`nrf_vpr_csr_vevif_events_set` function (locally from VPR).
+To source DPPI using VEVIF events, you must configure it with the :c:func:`nrf_vpr_csr_vevif_publish_set` function.
+To source IRQ out of VPR using VEVIF events, you need to enable them using the :c:func:`nrf_vpr_int_enable` function (from remote side) or the :c:func:`nrf_vpr_csr_vevif_int_enable` function (from VPR).
+
+Buffering
+---------
+
+Similarly to VIO, you can buffer VEVIF events using the :c:func:`nrf_vpr_csr_vevif_events_buffered_set` function.
+Buffer overflows are avoided by stalling the CPU when writing to a dirty buffer.
+
+Tasks and events availability
+=============================
+
+The availability of VEVIF tasks and events varies depending on the SoC:
+
+.. list-table:: VEVIF availability on SoCs
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - VEVIF tasks available
+     - VEVIF tasks DPPI connections
+     - VEVIF events available
+     - VEVIF events DPPI connections
+
+   * - nRF54L15 FLPR
path: doc/nrf/app_dev/device_guides/hpf/rt_peripherals.rst
user: login: masz-nordic
body: HPF only targets L15.
created_at: 2025-04-11T14:45:04Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,65 @@
+.. _hpf_assembly_management:
+
+Assembly management
+###################
+
+Assembly Management is a critical component in the development process, particularly when meeting the modularity and testability requirements defined in the event handling.
+
+Overview
+********
+
+During the compilation process, Hard Real-Time (HRT) functions are compiled into assembly code.
+This assembly code is then compared to a previously verified version that has undergone hardware characteristic tests.
+If the differences between the current and previous versions are within acceptable limits, the new code is considered to maintain timing accuracy.
+
+The application can be built in two modes: user mode and developer mode.
+In user mode, the application uses a pre-generated assembly file to construct the HRT component, while in developer mode, the application employs a newly generated assembly file.
+This approach not only facilitates the integration of updates but also allows for a thorough review of changes made by developers and modifications introduced by the toolchain.
+
+See following flow of the build-time assembly management process:
+
+.. IMG TBA
+
+Implementation
+**************
+
+Assembly management is integrated into the build process through CMake scripts.
+To use this feature, you must include the command ``sdp_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c")`` in your application's :file:`CMakeLists.txt` file, where ``file.c`` value is the C file containing only Hard Real-Time (HRT) functions.
+
+You can manage assembly files with the following functions:
+
+* ``sdp_assembly_generate``
+* ``sdp_assembly_check``
+* ``sdp_assembly_prepare_install``
+* ``sdp_assembly_target_sources``
+
+sdp_assembly_generate
+=====================
+
+The :c:func:`sdp_assembly_generate` function creates a build target that generates a temporary assembly file.
+Tis file is named :file:`file-soc-temp.s` and is located in the Fast Lightweight Peripheral Processor (FLPR) application's build directory when ``ninja build`` is invoked.
+``soc`` represents the System on Chip (SoC) name for the current build, such as ``nrf54l15``.
+
+sdp_assembly_check
+==================
+
+The :c:func:`sdp_assembly_check` function establishes a build target that is triggered when executing ``ninja build``, following the :c:func:`sdk_assembly_generate` function.
+It verifies whether the :file:`file-soc-temp.s` file in the build directory matches the :file:`file-soc.s` file in the source directory.
+If discrepancies are found, a CMake error (in user mode) or warning (in developer mode) is generated.
+In user mode, you should assess whether the differences between :file:`file-soc-temp.s` and :file:`file-soc.s` are minimal enough to be considered timing accurate.
+If they are, you must execute the ``ninja asm_install`` command in the FLPR application's build directory.
+If not, you need to adjust the code or re-run hardware characterization tests.
+
+In developer mode, :file:`file-soc-temp.s` is included in the build, but it is not automatically replaced in the source directory.
+To update the source directory, invoke the ``ninja asm_install`` command.
+
+sdp_assembly_prepare_install
+============================
+
+The :c:func:`sdp_assembly_prepare_install` function creates a build target that replaces the :file:`file-soc.s` file in the source directory with :file:`file-soc-temp.s` from the build directory.
+It is activated when executing the ``ninja asm_install`` command in the FLPR application's build directory.
+
+sdp_assembly_target_sources
+===========================
+
+The :c:func:`sdp_assembly_target_sources` function includes the :file:`file-soc.s` from source directory in the target sources.
path: doc/nrf/app_dev/device_guides/hpf/assembly_management.rst
user: login: magp-nordic
body: This should probably be updated with information that in developer mode `file-soc-temp.s` files are included instead of `file-soc.s`. Sorry for not pointing it out before, I've just noticed this.
created_at: 2025-04-11T15:10:11Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,24 @@
+.. _hpf_index:
+
+High-Performance Framework (HPF)
+################################
+
+.. note::
+
+   The HPF support in the |NCS| is currently experimental.
path: doc/nrf/app_dev/device_guides/hpf/hpf.rst
user: login: annwoj
body: Why in the fault_hadling.rst file we are mentioning nRF54H20 then (line 14)? Shouldn't this be removed? 
created_at: 2025-04-12T14:05:28Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,20 +1,16 @@
-.. _sdp_gpio:
+.. _hpf_gpio_example:
 
-SDP GPIO
-########
+High-Performance Framework GPIO
path: applications/sdp/gpio/README.rst
user: login: annwoj
body: @mif1-nordic  @masz-nordic  Both application readme files do not follow the general template. Please add the missing content, if possible, we should include the required sections.
We're missing the following items:

- user interface sections
- Table from sample-yaml (for mspi)
- No information on building and running (mspi)
- No information on testing
- Missing dependencies section for both files
- Other references to existing articles that could provide more context
created_at: 2025-04-12T17:41:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,296 @@
+.. _hpf_mspi_example:
+
+High-Performance Framework MSPI
+###############################
+
+The application demonstrates the integration and operation of a Multi-bit SPI Bus (MSPI) using a High-Performance Framework (HPF) across different core modules within a ZephyrRTOS environment.
+
+Application overview
+********************
+
+The MSPI HPF application is structured into the following main components:
+
+* The MSPI driver - Operates on the application core and uses the Zephyr's scalable real-time operating system (RTOS) MSPI API for data and configuration transmission between the application and FLPR cores.
+* The HPF application - Operates on the FLPR core and facilitates data transmission between the FLPR core and the connected MSPI device.
+* The Hard Real Time (HRT) module - Runs on the FLPR core and facilitates data transmission between the FLPR core and the connected MSPI device.
+  The module emulates the MSPI hardware peripheral on the FLPR core, managing real-time data transmission and ensuring precise timing and synchronization of data transfer operations.
+
+Additionally, for efficient operation, the application must have the following:
+
+* Compatibility with the MSPI configuration including clock polarity, phase, and the number of data lines or transmission modes (single, quad).
+* Low latency and high troughput.
+
+Requirements
+************
+
+The application supports the following development kits:
+
+.. table from sample-yaml to be added
+
+Configuration
+*************
+
+Data transfer between the MSPI driver and the HPF application is done through the interprocessor communication (IPC).
+Depending on the platform, data can be passed either by copy (:ref:`nRF54H20 platform<ug_nrf54h>`) or by reference (:ref:`nRF54L15 platform<ug_nrf54l>`).
path: applications/sdp/mspi/README.rst
user: login: annwoj
body: Why are we even mentioning nrf54h20, isn't only nrf54l15 supported?
created_at: 2025-04-12T17:43:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,24 @@
+.. _hpf_index:
+
+High-Performance Framework (HPF)
+################################
+
+.. note::
+
+   The HPF support in the |NCS| is currently experimental.
path: doc/nrf/app_dev/device_guides/hpf/hpf.rst
user: login: masz-nordic
body: Should be removed
created_at: 2025-04-14T09:41:35Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,105 @@
+.. _hpf_assembly_management:
+
+Assembly management
+###################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+Assembly management is a critical component in the development process, particularly when meeting the modularity and testability requirements defined in the :ref:`hpf_event_handling`.
+
+Overview
+********
+
+Emulating communication protocols requires precise timing.
+To manage this, you must separate the time-sensitive parts of the code, known as Hard Real-Time (HRT) components.
+These components have strict timing requirements and are stored in a pre-compiled assembly format to ensure they remain unchanged.
+
+The assembly management CMake functions are integrated into the build process and are executed with every build.
+These functions check for any modifications that could lead to the generation of different assembly files, such as changes in HRT source files or the compiler used.
+Detecting these changes is essential because they can impact the timing accuracy of software peripherals.
+If any changes are detected that could affect the assembly files, you must verify that these differences are within acceptable limits.
+This ensures that the new code maintains the necessary timing accuracy.
+
+To use this feature, you must include the command ``hpf_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c")`` in your application's :file:`CMakeLists.txt` file, where ``file.c`` value is the C file containing only Hard Real-Time (HRT) functions.
+
+Although the assembly management functions are called every time in build time, some of them can also be run independently by using CMake targets in VPR core's application build directory.
+
+See following flow of the build-time assembly management process:
+
+.. IMG TBA
+
+.. _hpf_assembly_management_cmake:
+
+Implementation
+**************
+
+The assembly management performed at build time uses following :ref:`CMake<cmake_options>` functions:
+
+* :c:func:`hpf_assembly_generate`
+* :c:func:`hpf_assembly_check`
+* :c:func:`hpf_assembly_prepare_install`
+* :c:func:`hpf_assembly_target_sources`
+
+hpf_assembly_generate
+=====================
+
+The :c:func:`hpf_assembly_generate` function creates a build target (asm_gen) that generates a temporary assembly file from HRT source files.
+This files is named :file:`file-soc-temp.s` and is located in the Fast Lightweight Peripheral Processor (FLPR) application's build directory when running ``ninja build``.
+In the filename, *soc* represents the System on Chip (SoC) name used in the current build, such as ``nrf54l15``.
+
+hpf_assembly_check
+==================
+
+The :c:func:`hpf_assembly_check` function sets up a build target (asm_check) that is triggered when executing ``ninja build``, following the :c:func:`sdk_assembly_generate` function.
+The target verifies if the :file:`file-soc-temp.s` file in the build directory matches the :file:`file-soc.s` file in the source directory.
+If discrepancies are found, it triggers a CMake error (in user mode) or warning (in developer mode).
+
+hpf_assembly_prepare_install
+============================
+
+The :c:func:`hpf_assembly_prepare_install` function creates a build target (asm_install) that replaces the :file:`file-soc.s` file in the source directory with :file:`file-soc-temp.s` from the build directory.
+
+hpf_assembly_target_sources
+===========================
+
+The :c:func:`hpf_assembly_target_sources` function includes the :file:`file-soc.s` from source directory in the target sources.
path: doc/nrf/app_dev/device_guides/hpf/assembly_management.rst
user: login: magp-nordic
body: @annwoj this sentence needs to be changed to something like:
```suggestion
The :c:func:`hpf_assembly_target_sources` function includes the :file:`file-soc.s` from source directory (user mode) or the :file:`file-soc-temp.s` from build directory in the target sources.
```
Just to make sure that there is an indication of which assembly files are included in build depending on user/developer build mode. I forgot to add it myself.
created_at: 2025-04-15T10:17:21Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,20 +1,28 @@
 .. _sdp_gpio:
path: applications/sdp/gpio/README.rst
user: login: annwoj
body: Note to self -> update redirects file
created_at: 2025-04-15T12:02:39Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,208 @@
+.. _hpf_power_management:
+
+Power management
+################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following page outlines the approaches and mechanisms employed to ensure efficient power management in High-Performance Framework (HPF) systems, focusing on resource allocation, system states, and interactions between different components.
+
+Power management strategies
+***************************
+
+Power Management in HPF should be considered from two perspectves: the Host controller and the HPF firmware.
+
+Host controller
+===============
+
+The Host is responsible for managing power state of the following resources:
+
+* FLPR core with HPF firmware running on it
+* RAM
+
+To achieve optimal power state, you must use the `Device Runtime Power Management`_ and `System Power Off`_.
path: doc/nrf/app_dev/device_guides/coprocessors/power_management.rst
user: login: masz-nordic
body: It should be shown that the power management is an architecture design and SW components are not there yet.
@mif1-nordic is working on adding that to this page.
created_at: 2025-04-15T12:11:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,208 @@
+.. _hpf_power_management:
+
+Power management
+################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following page outlines the approaches and mechanisms employed to ensure efficient power management in High-Performance Framework (HPF) systems, focusing on resource allocation, system states, and interactions between different components.
+
+Power management strategies
+***************************
+
+Power Management in HPF should be considered from two perspectves: the Host controller and the HPF firmware.
+
+Host controller
+===============
+
+The Host is responsible for managing power state of the following resources:
+
+* FLPR core with HPF firmware running on it
+* RAM
+
+To achieve optimal power state, you must use the `Device Runtime Power Management`_ and `System Power Off`_.
+
+See an example flow of the Host power management:
+
+.. uml::
+
+  @startuml
+  participant Zephyr
+  participant Application
+  participant "mSPI driver"
+  participant "FLPR drivers"
+  participant FLPR
+
+  activate Zephyr
+  Zephyr -> Zephyr : post kernel initialization
+  activate Zephyr
+  Zephyr -> "FLPR drivers" : Initialize drivers
+  activate "FLPR drivers"
+  rnote over "FLPR drivers"
+  Power on FLPR RAM
+  endrnote
+  rnote over "FLPR drivers"
+  If non-XIP:
+  Copy code to RAM
+  endrnote
+  rnote over "FLPR drivers"
+  Start FLPR
+  endrnote
+
+  "FLPR drivers" -> "FLPR drivers" : Initialize IPC
+  activate "FLPR drivers"
+  "FLPR drivers" -> FLPR
+  activate FLPR
+  rnote over FLPR
+  Boot
+  endrnote
+  rnote over FLPR
+  Initialize IPC
+  endrnote
+  return
+  deactivate "FLPR drivers"
+
+  "FLPR drivers" -> "FLPR drivers" : Initialize FLPR
+  activate "FLPR drivers"
+  "FLPR drivers" -> FLPR : FLPR_INIT
+  activate FLPR
+  rnote over FLPR
+  Initialize HW, peripherals, etc
+  endrnote
+  return FLPR_INITD
+  deactivate "FLPR drivers"
+  return
+  deactivate "FLPR drivers"
+
+
+  deactivate Zephyr
+  Zephyr -> Application : Start application
+  activate Application
+  Application -> "mSPI driver" : mspi_config(...)
+  activate "mSPI driver"
+  "mSPI driver" -> "mSPI driver" : mSPI initialization
+  activate "mSPI driver"
+  "mSPI driver" -> "FLPR drivers" : pm_device_runtime_get(&flpr)
+  activate "FLPR drivers"
+  "FLPR drivers" -> FLPR : FLPR_RESUME
+  activate FLPR
+  rnote over FLPR
+  Enter RESUME state
+  endrnote
+  return FLPR_RESUMED
+  return
+
+  "mSPI driver" -> FLPR : FLPR_MSPI_CONFIGURE
+  activate FLPR
+  rnote over FLPR
+  Configure emulated MSPI
+  endrnote
+  return FLPR_MSPI_CONFIGURED
+  deactivate "mSPI driver"
+  return
+  ...
+
+
+  Application -> "mSPI driver" : mspi_transcieve(...)
+  activate "mSPI driver"
+  "mSPI driver" -> FLPR : FLPR_MSPI_XFER
+  activate FLPR
+  rnote over FLPR
+  Execute MSPI transfer
+  endrnote
+  return FLPR_MSPI_XFERD
+  return
+  ...
+
+
+  Application -> "mSPI driver" : mspi_config(...)
+  activate "mSPI driver"
+  "mSPI driver" -> "mSPI driver" : mSPI initialization
+  activate "mSPI driver"
+  "mSPI driver" -> FLPR : FLPR_MSPI_DECONFIGURE
+  activate FLPR
+  rnote over FLPR
+  Deconfigure emulated MSPI
+  endrnote
+  return FLPR_MSPI_DECONFIGURED
+
+  "mSPI driver" -> "FLPR drivers" : pm_device_runtime_put(&flpr)
+  activate "FLPR drivers"
+  "FLPR drivers" -> FLPR : FLPR_SUSPEND
+  activate FLPR
+  rnote over FLPR
+  Enter SUSPENDED state
+  endrnote
+  return FLPR_SUSPENDED
+  return
+  deactivate "mSPI driver"
+  return
+  return
+
+
+  Zephyr -> Zephyr : power off procedure
+  activate Zephyr
+  "Zephyr" -> "FLPR drivers" : power off
+  activate "FLPR drivers"
+  "FLPR drivers" -> "FLPR drivers" : FLPR shutdown
+  activate "FLPR drivers"
+  "FLPR drivers" -> FLPR : FLPR_SHUTDOWN_PREPARE
+  activate FLPR
+  rnote over FLPR
+  Deinitialize HW peripherals, etc
+  endrnote
+  return FLPR_SHUTDOWN_PREPARED
+  deactivate "FLPR drivers"
+  rnote over "FLPR drivers"
+  Power off FLPR
+  endrnote
+  rnote over "FLPR drivers"
+  Power off FLPR RAM
+  endrnote
+  return
+  deactivate Zephyr
+  @enduml
+
+HPF firmware
+============
+
+HPF firmware is responsible for managing power states of the following resources:
+
+* FLPR CPU power state
+* Hardware peripherals used by the HPF firmware
+
+FLPR CPU power state management
+-------------------------------
+
+Your HPF firmware should not use the Zephyr libraries for `System Power Management`_, as the libraries rely on multithreading.
+Instead, you must implement a distinct approach.
+
+Your HPF firmware should configure a sleep mode that is activated using both the ``SLEEPSTATE`` and ``STACKONSLEEP`` fields in the ``NORDIC.VPRNORDICSLEEPCTRL`` register.
+For details, see the *Sleep mode operation* section in the FLPR peripheral description.
path: doc/nrf/app_dev/device_guides/coprocessors/power_management.rst
user: login: masz-nordic
body: ```suggestion
For details, see the *Sleep mode operation* section in the VPR peripheral description.
```
created_at: 2025-04-15T12:12:13Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,20 +1,28 @@
 .. _sdp_gpio:
+.. _hpf_gpio_example:
 
-SDP GPIO
-########
+High-Performance Framework GPIO
+###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create SDP on FLPR in Zephyr threadless mode by implementing a subset of Zephyr GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
+The application implements subset of Zephyr GPIO API.
 
-* mbox (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_MBOX`)
-* icmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICMSG`)
-* icbmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICBMSG`)
+Application overview
+********************
+
+This application shows the implementation of a subset of the Zephyr GPIO API, intended for use with the :zephyr:code-sample:`blinky` sample from Zephyr.
+It supports multiple IPC backends, including mbox, icmsg, and icbmsg.
path: applications/sdp/gpio/README.rst
user: login: magp-nordic
body: @annwoj Including is probably not the best word here, because those are exactly three backends that we support.
created_at: 2025-04-15T12:16:04Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,324 @@
+.. _hpf_real_time_peripherals:
+
+Real-time peripherals
+#####################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+.. contents::
+   :local:
+   :depth: 2
+
+This document provides technical details and guidance on how to use the real-time (RT) peripherals integrated into the VPR CPU.
+They are designed to enhance real-time performance and allow precise control over GPIO pads and other low-level hardware interactions.
+
+Overview
+********
+
+The real-time peripherals consist of the following main components that interact to deliver cycle-accurate control and synchronization of GPIO pads and events:
+
+* VPR TIMER (VTIM) - Provides precise timing control and synchronization.
+* VPR IO (VIO) - A GPIO controller that can handle up to 16 pins.
+* VPR Event Interface (VEVIF) - Enables the sourcing of interrupt requests (IRQs) from the VPR and interaction with the Distributed Programmable Peripheral Interconnect (DPPI).
+
+The peripherals operate in real-time and are mapped to the processor's Control and Status Register (CSR) space.
+They remain active even in wait, sleep, and deep sleep modes, making them ideal for energy-efficient designs.
+
+Prerequisites
+*************
+
+Before you start using the RT peripherals, enable them by calling the :c:func:`nrf_vpr_csr_rtperiph_enable_set` function.
+
+VPR TIMER (VTIM)
+****************
+
+The VPR TIMER (VTIM) offers the following features:
+
+* Two 16-bit timers (counter 0 and counter 1) that can operate independently or combine to form a 32-bit timer.
+* Precise synchronization with the VIO and VEVIF modules for generating event pulses upon timer completion.
+* Operation at the same clock frequency as the CPU without a prescaler.
+
+.. note::
+   You can find the full API in the `nrfx API documentation`_.
+
+TIMER modes
+===========
+
+Each timer can operate in several modes to control its counting behavior, which can be set using the :c:func:`nrf_vpr_csr_vtim_count_mode_set` function:
+
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` - Halts the timer when it reaches zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_WRAP` - Restarts the timer from its maximum value (``0xFFFF``) after reaching zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_RELOAD` - Reloads the timer with a pre-configured value when it reaches zero.
+  The value is set using the :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set` or :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set` function.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_TRIGGER_COMBINED` - Trigger (counter 0) or combined (counter 1) mode.
+
+  * Trigger mode is set to counter 0.
+    The counter stops at zero and will not immediately restart the countdown if there is a change in value in counter 0, or in the combined counter when counter 1 is set to combined mode.
+    Instead, it restarts only after a VIO event pulse occurs or VEVIF task 0 is triggered.
+  * Combined mode is set to counter 1.
+    Counter 1 and counter 0 act as one, combined counter, with counter 1 covering the 16 most significant bits and counter 0 covering the 16 least significant bits.
+    The mode for the combined counter is set in counter 0.
+    In this mode, the system omits any counter event pulses that occur when counter 1 reaches zero.
+
+Use the ``nrf_vpr_csr_vtim_simple_*`` API to set the counters in standalone mode.
+You must specify the counter index:
+
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_wait_set`
+
+Use the following functions (``nrf_vpr_csr_vtim_combined_*`` ) to adjust the combined counter:
+
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_wait_trigger`
+
+Operational guidelines
+======================
+
+Familiarize yourself with the following guidelines for managing counters within the system:
+
+* Writing any non-zero value to a counter starts the counter.
+  You can do this using ``nrf_vpr_csr_vtim_{combined,simple}_counter_set``, which sets the counter to a given value, or ``nrf_vpr_csr_vtim_{combined,simple}_counter_add_set``, which adds a value to the counter's current value.
+* Timers generate an event pulse when they reach zero, which may trigger actions in other RT peripherals.
+* Timers stop when they reach zero or if you set the counter value to zero in the :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` mode.
+
+Interrupt
+=========
+
+Counter 0 can generate an interrupt request if it is enabled using the :c:func:`nrf_vpr_csr_cnt_irq_enable_set` function.
+The interrupt line triggered varies depending on the System on Chip (SoC):
+
+.. list-table:: IRQ line triggered by counter 0
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - IRQ line
+
+   * - nRF54L15 FLPR
+     - 32 (TODO VERIFY - 31 in HAC)
path: doc/nrf/app_dev/device_guides/coprocessors/rt_peripherals.rst
user: login: masz-nordic
body: Needs to be verified.
created_at: 2025-04-15T12:17:41Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,20 +1,28 @@
 .. _sdp_gpio:
+.. _hpf_gpio_example:
 
-SDP GPIO
-########
+High-Performance Framework GPIO
+###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create SDP on FLPR in Zephyr threadless mode by implementing a subset of Zephyr GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
+The application implements subset of Zephyr GPIO API.
 
-* mbox (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_MBOX`)
-* icmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICMSG`)
-* icbmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICBMSG`)
+Application overview
+********************
+
+This application shows the implementation of a subset of the Zephyr GPIO API, intended for use with the :zephyr:code-sample:`blinky` sample from Zephyr.
+It supports multiple IPC backends, including mbox, icmsg, and icbmsg.
+Depending on your needs, you can enable them with the relevant sysbuild options.
+
+The GPIO HPF application is structured into the following main components:
+
+* The HPF application - Operates on the FLPR core and facilitates data transmission between the FLPR core and the GPIOs.
path: applications/sdp/gpio/README.rst
user: login: magp-nordic
body: @annwoj (see similar comment in MSPI README)
```suggestion
* The HPF application - Operates on the FLPR core and handles data transmission between the FLPR core and the GPIOs.
```
created_at: 2025-04-15T12:19:03Z
author_association: CONTRIBUTOR
diff_hunk: @@ -24,17 +31,64 @@ The firmware supports the following development kit:
 
 .. table-from-sample-yaml::
 
+Configuration
+*************
+
+You can enable the following IPC backends:
+
+* mbox (``SB_CONFIG_HPF_GPIO_BACKEND_MBOX``)
+* icmsg (``SB_CONFIG_HPF_GPIO_BACKEND_ICMSG``)
+* icbmsg (``SB_CONFIG_HPF_GPIO_BACKEND_ICBMSG``)
+
 Building and running
 ********************
 
-You must include code for both the application core and FLPR core.
-The recommended method is to build the :zephyr:code-sample:`blinky` with the necessary sysbuild configuration.
+.. |application path| replace:: :file:`applications/sdp/gpio`
+
+.. include:: /includes/application_build_and_run.txt
+
+To build and run the application, you must include code for both the application core and FLPR core.
+The process involves building the :zephyr:code-sample:`blinky` sample with the appropriate sysbuild configuration.
 
 For example, to build with icmsg backend, run the following commands:
 
   .. code-block:: console
 
-     west build -b nrf54l15dk/nrf54l15/cpuapp -- -DSB_CONFIG_PARTITION_MANAGER=n -DSB_CONFIG_HPF=y -DSB_CONFIG_HPF_GPIO=y -DSB_CONFIG_HPF_GPIO_BACKEND_ICMSG=y -DEXTRA_DTC_OVERLAY_FILE="./boards/nrf54l15dk_nrf54l15_cpuapp_hpf_gpio.overlay"
+     west build -b nrf54l15dk/nrf54l15/cpuapp -- -DSB_CONFIG_PARTITION_MANAGER=n -DSB_CONFIG_HPF=y -DSB_CONFIG_HPF_GPIO=y -DSB_CONFIG_HPF_GPIO_BACKEND_ICMSG=y -DEXTRA_DTC_OVERLAY_FILE="./boards/nrf54l15dk_nrf54l15_cpuapp_egpio.overlay"
      west flash
 
 Upon successful execution, **LED0** will start flashing.
+
+Dependencies
+************
+
+* :ref:`ipc_service_sample` - Used for transfering data between application core and the FLPR core.
path: applications/hpf/gpio/README.rst
user: login: magp-nordic
body: @annwoj not sure this is the right ref, we do not use the sample. We use ipc service drivers that are located in zephyr/subsys/ipc/ipc_service. I think their documentation is at zephyr/doc/services/ipc/ipc_service (_ipc_service_api label)
created_at: 2025-04-15T12:29:05Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+.. _hpf_assembly_management:
+
+Assembly management
+###################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+Assembly management is a critical component in the development process, particularly when meeting the modularity and testability requirements defined in the :ref:`hpf_event_handling`.
+
+Overview
+********
+
+Emulating communication protocols requires precise timing.
+To manage this, you must separate the time-sensitive parts of the code, known as Hard Real-Time (HRT) components.
+These components have strict timing requirements and are stored in a pre-compiled assembly format to ensure they remain unchanged.
+
+The assembly management CMake functions are integrated into the build process and are executed with every build.
+These functions check for any modifications that could lead to the generation of different assembly files, such as changes in HRT source files or the compiler used.
+Detecting these changes is essential because they can impact the timing accuracy of software peripherals.
+If any changes are detected that could affect the assembly files, you must verify that these differences are within acceptable limits.
+This ensures that the new code maintains the necessary timing accuracy.
+
+To use this feature, you must include the command ``hpf_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c")`` in your application's :file:`CMakeLists.txt` file, where ``file.c`` value is the C file containing only Hard Real-Time (HRT) functions.
+
+Although the assembly management functions are called every time in build time, some of them can also be run independently by using CMake targets in VPR core's application build directory.
+
+See following flow of the build-time assembly management process:
+
+.. image:: images/hpf_assembly_management_process.svg
path: doc/nrf/app_dev/device_guides/coprocessors/assembly_management.rst
user: login: annwoj
body: note to self: fix the trailing whitespaces
created_at: 2025-04-15T12:29:14Z
author_association: CONTRIBUTOR
diff_hunk: @@ -24,17 +31,64 @@ The firmware supports the following development kit:
 
 .. table-from-sample-yaml::
 
+Configuration
+*************
+
+You can enable the following IPC backends:
+
+* mbox (``SB_CONFIG_HPF_GPIO_BACKEND_MBOX``)
+* icmsg (``SB_CONFIG_HPF_GPIO_BACKEND_ICMSG``)
+* icbmsg (``SB_CONFIG_HPF_GPIO_BACKEND_ICBMSG``)
+
 Building and running
 ********************
 
-You must include code for both the application core and FLPR core.
-The recommended method is to build the :zephyr:code-sample:`blinky` with the necessary sysbuild configuration.
+.. |application path| replace:: :file:`applications/sdp/gpio`
+
+.. include:: /includes/application_build_and_run.txt
+
+To build and run the application, you must include code for both the application core and FLPR core.
+The process involves building the :zephyr:code-sample:`blinky` sample with the appropriate sysbuild configuration.
 
 For example, to build with icmsg backend, run the following commands:
 
   .. code-block:: console
 
-     west build -b nrf54l15dk/nrf54l15/cpuapp -- -DSB_CONFIG_PARTITION_MANAGER=n -DSB_CONFIG_HPF=y -DSB_CONFIG_HPF_GPIO=y -DSB_CONFIG_HPF_GPIO_BACKEND_ICMSG=y -DEXTRA_DTC_OVERLAY_FILE="./boards/nrf54l15dk_nrf54l15_cpuapp_hpf_gpio.overlay"
+     west build -b nrf54l15dk/nrf54l15/cpuapp -- -DSB_CONFIG_PARTITION_MANAGER=n -DSB_CONFIG_HPF=y -DSB_CONFIG_HPF_GPIO=y -DSB_CONFIG_HPF_GPIO_BACKEND_ICMSG=y -DEXTRA_DTC_OVERLAY_FILE="./boards/nrf54l15dk_nrf54l15_cpuapp_egpio.overlay"
      west flash
 
 Upon successful execution, **LED0** will start flashing.
+
+Dependencies
+************
+
+* :ref:`ipc_service_sample` - Used for transfering data between application core and the FLPR core.
+* `nrf HAL <nrfx API documentation_>`_ - Enables access to the VPR CSR registers for direct hardware control.
+
+API documentation
+*****************
+
+Application uses the following API elements:
+
+Zephyr driver
+=============
+
+* Header file: :file:`drivers/gpio/nrfe_gpio.h`
+
+The source file depends on the selected IPC backend:
+
+* Source file: :file:`drivers/gpio/gpio_nrfe.c`
path: applications/hpf/gpio/README.rst
user: login: magp-nordic
body: @annwoj this is included regardless of IPC backend, it is a common file.
created_at: 2025-04-15T12:32:23Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,21 +1,28 @@
 .. _sdp_gpio:
-.. _hpf_gpio:
+.. _hpf_gpio_example:
 
 High-Performance Framework GPIO
 ###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create a software peripheral on FLPR in High-Performance Framework (HPF) by implementing a subset of Zephyr's GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
path: applications/hpf/gpio/README.rst
user: login: magp-nordic
body: @masz-nordic shouldn't it be: "how to write a software peripheral application"?
created_at: 2025-04-15T12:33:46Z
author_association: CONTRIBUTOR
diff_hunk: @@ -24,17 +31,64 @@ The firmware supports the following development kit:
 
 .. table-from-sample-yaml::
 
+Configuration
+*************
+
+You can enable the following IPC backends:
+
+* mbox (``SB_CONFIG_HPF_GPIO_BACKEND_MBOX``)
+* icmsg (``SB_CONFIG_HPF_GPIO_BACKEND_ICMSG``)
+* icbmsg (``SB_CONFIG_HPF_GPIO_BACKEND_ICBMSG``)
+
 Building and running
 ********************
 
-You must include code for both the application core and FLPR core.
-The recommended method is to build the :zephyr:code-sample:`blinky` with the necessary sysbuild configuration.
+.. |application path| replace:: :file:`applications/sdp/gpio`
+
+.. include:: /includes/application_build_and_run.txt
+
+To build and run the application, you must include code for both the application core and FLPR core.
+The process involves building the :zephyr:code-sample:`blinky` sample with the appropriate sysbuild configuration.
 
 For example, to build with icmsg backend, run the following commands:
 
   .. code-block:: console
 
-     west build -b nrf54l15dk/nrf54l15/cpuapp -- -DSB_CONFIG_PARTITION_MANAGER=n -DSB_CONFIG_HPF=y -DSB_CONFIG_HPF_GPIO=y -DSB_CONFIG_HPF_GPIO_BACKEND_ICMSG=y -DEXTRA_DTC_OVERLAY_FILE="./boards/nrf54l15dk_nrf54l15_cpuapp_hpf_gpio.overlay"
+     west build -b nrf54l15dk/nrf54l15/cpuapp -- -DSB_CONFIG_PARTITION_MANAGER=n -DSB_CONFIG_HPF=y -DSB_CONFIG_HPF_GPIO=y -DSB_CONFIG_HPF_GPIO_BACKEND_ICMSG=y -DEXTRA_DTC_OVERLAY_FILE="./boards/nrf54l15dk_nrf54l15_cpuapp_egpio.overlay"
path: applications/hpf/gpio/README.rst
user: login: magp-nordic
body: @mif1-nordic this should not be changed. Also there are more name changes, that should be fixed (for example, nrfe should be changed to hpf)
created_at: 2025-04-15T12:35:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,363 @@
+.. _hpf_mspi_example:
+
+High-Performance Framework MSPI
+###############################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
+The application implements subset of Zephyr MSPI API.
+
+Application overview
+********************
+
+The MSPI HPF application is structured into the following main components:
+
+* The HPF application - Operates on the FLPR core and facilitates data transmission between the FLPR core and the connected MSPI device.
+* The Hard Real Time (HRT) module - Runs on the FLPR core and facilitates data transmission between the FLPR core and the connected MSPI device.
+  The module emulates the MSPI hardware peripheral on the FLPR core, managing real-time data transmission and ensuring precise timing and synchronization of data transfer operations.
+* The MSPI driver - Operates on the application core and uses the Zephyr's scalable real-time operating system (RTOS) MSPI API for data and configuration transmission between the application and FLPR cores.
+
+Scope
+*****
+
+The application must meet the following key requirements:
+
+* Compatibility with the MSPI configuration including clock polarity, phase, and the number of data lines or transmission modes (single, quad).
+* Low latency and high troughput.
+
+Requirements
+************
+
+The application supports the following development kits:
+
+.. table-from-sample-yaml::
+
+Configuration and data transfer management
+******************************************
+
+Data transfer between the MSPI driver and the HPF application is done through the interprocessor communication (IPC).
path: applications/hpf/mspi/README.rst
user: login: magp-nordic
body: ```suggestion
Data transfer between the MSPI driver and the HPF application is done through the ICMsg.
```
ICMsg is one of IPCs, so I think it should be specified. Otherwise, someone might think that other IPCs are also supported in this application (like ICBMsg), which are not.
created_at: 2025-04-15T12:42:02Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,363 @@
+.. _hpf_mspi_example:
+
+High-Performance Framework MSPI
+###############################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
+The application implements subset of Zephyr MSPI API.
+
+Application overview
+********************
+
+The MSPI HPF application is structured into the following main components:
+
+* The HPF application - Operates on the FLPR core and facilitates data transmission between the FLPR core and the connected MSPI device.
path: applications/hpf/mspi/README.rst
user: login: magp-nordic
body: @annwoj 
```suggestion
* The HPF application - Operates on the FLPR core and facilitates data transmission between the APP core and the connected MSPI device.
```
Or:
```suggestion
* The HPF application - Operates on the FLPR core and handles data transmission between the APP core and the HRT.
```
To be more clear, the HPF application is between APP driver and HRT - it is located on FLPR core and it receives requests from APP, if they require communicating with MSPI device, then it is forwarded to HRT part.
created_at: 2025-04-15T12:45:09Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,19 @@
+.. _hpf_applications_readme:
+
+High-Performance Framework
+##########################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+High-Performance Framework, is a framework designed to facilitate the creation and integration of :ref:`software peripherals using coprocessors <coprocessors_index>`.
+You can utilize HPF with the following available applications:
path: applications/hpf/hpf.rst
user: login: mif1-nordic
body: ```suggestion
Following applicaions were made with High-Performance Framework:
```
created_at: 2025-04-15T12:45:28Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,324 @@
+.. _hpf_real_time_peripherals:
+
+Real-time peripherals
+#####################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+.. contents::
+   :local:
+   :depth: 2
+
+This document provides technical details and guidance on how to use the real-time (RT) peripherals integrated into the VPR CPU.
+They are designed to enhance real-time performance and allow precise control over GPIO pads and other low-level hardware interactions.
+
+Overview
+********
+
+The real-time peripherals consist of the following main components that interact to deliver cycle-accurate control and synchronization of GPIO pads and events:
+
+* VPR TIMER (VTIM) - Provides precise timing control and synchronization.
+* VPR IO (VIO) - A GPIO controller that can handle up to 16 pins.
+* VPR Event Interface (VEVIF) - Enables the sourcing of interrupt requests (IRQs) from the VPR and interaction with the Distributed Programmable Peripheral Interconnect (DPPI).
+
+The peripherals operate in real-time and are mapped to the processor's Control and Status Register (CSR) space.
+They remain active even in wait, sleep, and deep sleep modes, making them ideal for energy-efficient designs.
+
+Prerequisites
+*************
+
+Before you start using the RT peripherals, enable them by calling the :c:func:`nrf_vpr_csr_rtperiph_enable_set` function.
+
+VPR TIMER (VTIM)
+****************
+
+The VPR TIMER (VTIM) offers the following features:
+
+* Two 16-bit timers (counter 0 and counter 1) that can operate independently or combine to form a 32-bit timer.
+* Precise synchronization with the VIO and VEVIF modules for generating event pulses upon timer completion.
+* Operation at the same clock frequency as the CPU without a prescaler.
+
+.. note::
+   You can find the full API in the `nrfx API documentation`_.
+
+TIMER modes
+===========
+
+Each timer can operate in several modes to control its counting behavior, which can be set using the :c:func:`nrf_vpr_csr_vtim_count_mode_set` function:
+
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` - Halts the timer when it reaches zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_WRAP` - Restarts the timer from its maximum value (``0xFFFF``) after reaching zero.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_RELOAD` - Reloads the timer with a pre-configured value when it reaches zero.
+  The value is set using the :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set` or :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set` function.
+* :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_TRIGGER_COMBINED` - Trigger (counter 0) or combined (counter 1) mode.
+
+  * Trigger mode is set to counter 0.
+    The counter stops at zero and will not immediately restart the countdown if there is a change in value in counter 0, or in the combined counter when counter 1 is set to combined mode.
+    Instead, it restarts only after a VIO event pulse occurs or VEVIF task 0 is triggered.
+  * Combined mode is set to counter 1.
+    Counter 1 and counter 0 act as one, combined counter, with counter 1 covering the 16 most significant bits and counter 0 covering the 16 least significant bits.
+    The mode for the combined counter is set in counter 0.
+    In this mode, the system omits any counter event pulses that occur when counter 1 reaches zero.
+
+Use the ``nrf_vpr_csr_vtim_simple_*`` API to set the counters in standalone mode.
+You must specify the counter index:
+
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_simple_counter_wait_set`
+
+Use the following functions (``nrf_vpr_csr_vtim_combined_*`` ) to adjust the combined counter:
+
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_get`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_top_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_add_set`
+* :c:func:`nrf_vpr_cst_vtim_combined_counter_wait_trigger`
+
+Operational guidelines
+======================
+
+Familiarize yourself with the following guidelines for managing counters within the system:
+
+* Writing any non-zero value to a counter starts the counter.
+  You can do this using ``nrf_vpr_csr_vtim_{combined,simple}_counter_set``, which sets the counter to a given value, or ``nrf_vpr_csr_vtim_{combined,simple}_counter_add_set``, which adds a value to the counter's current value.
+* Timers generate an event pulse when they reach zero, which may trigger actions in other RT peripherals.
+* Timers stop when they reach zero or if you set the counter value to zero in the :c:enumerator:`NRF_VPR_CSR_VTIM_COUNT_STOP` mode.
+
+Interrupt
+=========
+
+Counter 0 can generate an interrupt request if it is enabled using the :c:func:`nrf_vpr_csr_cnt_irq_enable_set` function.
+The interrupt line triggered varies depending on the System on Chip (SoC):
+
+.. list-table:: IRQ line triggered by counter 0
+   :widths: auto
+   :header-rows: 1
+
+   * - Target
+     - IRQ line
+
+   * - nRF54L15 FLPR
+     - 32 (TODO VERIFY - 31 in HAC)
path: doc/nrf/app_dev/device_guides/coprocessors/rt_peripherals.rst
user: login: masz-nordic
body: It's 31
```suggestion
     - 31
```
created_at: 2025-04-15T12:46:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,131 @@
+.. _hpf_event_handling:
+
+Event handling
+##############
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+This page section outlines the critical requirements and implementation strategies for managing events within the system, ensuring that functionalities are both modular and precise in execution.
+
+Requirements
+************
+
+The system must support the integration of multiple High-Performance Framework (HPF) peripherals, ensuring the following:
+
+* Modularity, allowing to combine functionalities of multiple HPF peripherals.
+* Timing accuracy, focusing on handling certain parts of the code with very accurate timings.
+* Verification, ensuring it is possible verify timing accuracy without the need to rerun an entire suite of hardware characteristic tests.
+
+Implementation
+**************
+
+To ensure precise timing, specific sections of the code are identified and managed as Hard-Real Time (HRT) functions.
+These functions are kept separate from the main application code.
path: doc/nrf/app_dev/device_guides/coprocessors/event_handling.rst
user: login: mif1-nordic
body: ```suggestion
To ensure precise timing, specific sections of the code shall be identified and managed as Hard-Real Time (HRT) functions.
These functions shall be kept separate from the main application code.
```
created_at: 2025-04-15T12:54:39Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+.. _hpf_assembly_management:
+
+Assembly management
+###################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+Assembly management is a critical component in the development process, particularly when meeting the modularity and testability requirements defined in the :ref:`hpf_event_handling`.
+
+Overview
+********
+
+Emulating communication protocols requires precise timing.
+To manage this, you must separate the time-sensitive parts of the code, known as Hard Real-Time (HRT) components.
+These components have strict timing requirements and are stored in a pre-compiled assembly format to ensure they remain unchanged.
+
+The assembly management CMake functions are integrated into the build process and are executed with every build.
+These functions check for any modifications that could lead to the generation of different assembly files, such as changes in HRT source files or the compiler used.
+Detecting these changes is essential because they can impact the timing accuracy of software peripherals.
+If any changes are detected that could affect the assembly files, you must verify that these differences are within acceptable limits.
+This ensures that the new code maintains the necessary timing accuracy.
+
+To use this feature, you must include the command ``hpf_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c")`` in your application's :file:`CMakeLists.txt` file, where ``file.c`` value is the C file containing only Hard Real-Time (HRT) functions.
+
+Although the assembly management functions are called every time in build time, some of them can also be run independently by using CMake targets in VPR core's application build directory.
+
+See following flow of the build-time assembly management process:
+
+.. image:: images/hpf_assembly_management_process.svg
+  :alt: HPF assembly management process
+
+.. _hpf_assembly_management_cmake:
+
+Implementation
+**************
+
+The assembly management performed at build time uses following :ref:`CMake<cmake_options>` functions:
+
+* :c:func:`hpf_assembly_generate`
+* :c:func:`hpf_assembly_check`
+* :c:func:`hpf_assembly_prepare_install`
+* :c:func:`hpf_assembly_target_sources`
+
+hpf_assembly_generate
+=====================
+
+The :c:func:`hpf_assembly_generate` function creates a build target (asm_gen) that generates a temporary assembly file from HRT source files.
+This files is named :file:`file-soc-temp.s` and is located in the Fast Lightweight Peripheral Processor (FLPR) application's build directory when running ``ninja build``.
+In the filename, *soc* represents the System on Chip (SoC) name used in the current build, such as ``nrf54l15``.
+
+hpf_assembly_check
+==================
+
+The :c:func:`hpf_assembly_check` function sets up a build target (asm_check) that is triggered when executing ``ninja build``, following the :c:func:`sdk_assembly_generate` function.
+The target verifies if the :file:`file-soc-temp.s` file in the build directory matches the :file:`file-soc.s` file in the source directory.
+If discrepancies are found, it triggers a CMake error (in user mode) or warning (in developer mode).
+
+hpf_assembly_prepare_install
+============================
+
+The :c:func:`hpf_assembly_prepare_install` function creates a build target (asm_install) that replaces the :file:`file-soc.s` file in the source directory with :file:`file-soc-temp.s` from the build directory.
+
+hpf_assembly_target_sources
+===========================
+
+The :c:func:`hpf_assembly_target_sources` function includes the :file:`file-soc.s` from source directory (user mode) or the :file:`file-soc-temp.s` from build directory in the target sources.
path: doc/nrf/app_dev/device_guides/coprocessors/assembly_management.rst
user: login: magp-nordic
body: @annwoj 
```suggestion
The :c:func:`hpf_assembly_target_sources` function includes the :file:`file-soc.s` from source directory (user mode) or the :file:`file-soc-temp.s` from build directory (developer mode) in the target sources.
```
I guess it is my mistake, sorry.
created_at: 2025-04-15T13:02:45Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,20 +1,28 @@
 .. _sdp_gpio:
+.. _hpf_gpio_example:
 
-SDP GPIO
-########
+High-Performance Framework GPIO
+###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create SDP on FLPR in Zephyr threadless mode by implementing a subset of Zephyr GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
+The application implements subset of Zephyr GPIO API.
 
-* mbox (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_MBOX`)
-* icmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICMSG`)
-* icbmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICBMSG`)
+Application overview
+********************
+
+This application shows the implementation of a subset of the Zephyr GPIO API, intended for use with the :zephyr:code-sample:`blinky` sample from Zephyr.
+It supports multiple IPC backends, including mbox, icmsg, and icbmsg.
+Depending on your needs, you can enable them with the relevant sysbuild options.
+
+The GPIO HPF application is structured into the following main components:
+
+* The HPF application - Operates on the FLPR core and facilitates data transmission between the FLPR core and the GPIOs.
path: applications/sdp/gpio/README.rst
user: login: masz-nordic
body: There is no 'data transmission' between FLPR and VIO. It could be:
`... and handles GPIO state using VIO.`
created_at: 2025-04-15T13:18:59Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,21 +1,28 @@
 .. _sdp_gpio:
-.. _hpf_gpio:
+.. _hpf_gpio_example:
 
 High-Performance Framework GPIO
 ###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create a software peripheral on FLPR in High-Performance Framework (HPF) by implementing a subset of Zephyr's GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
path: applications/hpf/gpio/README.rst
user: login: masz-nordic
body: How about
```suggestion
This application demonstrates how to write a High-Performance Framework (HPF) application implementing a simple peripheral.
```
created_at: 2025-04-15T13:19:56Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,21 +1,28 @@
 .. _sdp_gpio:
-.. _hpf_gpio:
+.. _hpf_gpio_example:
 
 High-Performance Framework GPIO
 ###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create a software peripheral on FLPR in High-Performance Framework (HPF) by implementing a subset of Zephyr's GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
path: applications/hpf/gpio/README.rst
user: login: annwoj
body: applied
created_at: 2025-04-15T13:31:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,20 +1,28 @@
 .. _sdp_gpio:
+.. _hpf_gpio_example:
 
-SDP GPIO
-########
+High-Performance Framework GPIO
+###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create SDP on FLPR in Zephyr threadless mode by implementing a subset of Zephyr GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
+The application implements subset of Zephyr GPIO API.
 
-* mbox (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_MBOX`)
-* icmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICMSG`)
-* icbmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICBMSG`)
+Application overview
+********************
+
+This application shows the implementation of a subset of the Zephyr GPIO API, intended for use with the :zephyr:code-sample:`blinky` sample from Zephyr.
+It supports multiple IPC backends, including mbox, icmsg, and icbmsg.
+Depending on your needs, you can enable them with the relevant sysbuild options.
+
+The GPIO HPF application is structured into the following main components:
+
+* The HPF application - Operates on the FLPR core and facilitates data transmission between the FLPR core and the GPIOs.
path: applications/sdp/gpio/README.rst
user: login: annwoj
body: fixed
created_at: 2025-04-15T13:31:53Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,20 +1,28 @@
 .. _sdp_gpio:
+.. _hpf_gpio_example:
 
-SDP GPIO
-########
+High-Performance Framework GPIO
+###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create SDP on FLPR in Zephyr threadless mode by implementing a subset of Zephyr GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a High-Performance Framework (HPF) application and communicate with it.
+The application implements subset of Zephyr GPIO API.
 
-* mbox (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_MBOX`)
-* icmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICMSG`)
-* icbmsg (:kconfig:option:`SB_CONFIG_SDP_GPIO_BACKEND_ICBMSG`)
+Application overview
+********************
+
+This application shows the implementation of a subset of the Zephyr GPIO API, intended for use with the :zephyr:code-sample:`blinky` sample from Zephyr.
+It supports multiple IPC backends, including mbox, icmsg, and icbmsg.
path: applications/sdp/gpio/README.rst
user: login: annwoj
body: reworded
created_at: 2025-04-15T13:32:02Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,43 @@
+.. _hpf_fault_handling:
+
+Fault handling
+##############
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following page outlines mechanisms and strategies that shall be employed to manage faults in both the Host and High-Performance Framework (HPF) firmware environments.
+
+Handling Host crash
+*******************
+
+In case of a Host crash followed by a reset, the hardware is designed to ensure that a reset of the application core (Host) simultaneously triggers a reset of the HPF firmware (FLPR core).
+
+This ensures synchronization between the cores.
+
+Handling firmware crash
+***********************
+
+In case a HPF firmware crashes, the issue must be signalled to the Host.
+Since there are no hardware resources dedicated to this task, you must implement the solution in software.
+You can employ the following strategies, individually or combined:
+
+* Using the TIMER peripheral as watchdog in one of the following ways:
path: doc/nrf/app_dev/device_guides/coprocessors/fault_handling.rst
user: login: mif1-nordic
body: ```suggestion
* Use the TIMER peripheral as watchdog in one of the following ways:
```
created_at: 2025-04-15T13:37:18Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,43 @@
+.. _hpf_fault_handling:
+
+Fault handling
+##############
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following page outlines mechanisms and strategies that shall be employed to manage faults in both the Host and High-Performance Framework (HPF) firmware environments.
+
+Handling Host crash
+*******************
+
+In case of a Host crash followed by a reset, the hardware is designed to ensure that a reset of the application core (Host) simultaneously triggers a reset of the HPF firmware (FLPR core).
+
+This ensures synchronization between the cores.
+
+Handling firmware crash
+***********************
+
+In case a HPF firmware crashes, the issue must be signalled to the Host.
+Since there are no hardware resources dedicated to this task, you must implement the solution in software.
+You can employ the following strategies, individually or combined:
+
+* Using the TIMER peripheral as watchdog in one of the following ways:
+
+  * Set up the TIMER with the Host and ensure it is regularly cleared by the HPF firmware.
+    If the firmware fails to clear the TIMER, an Interrupt Request (IRQ) is sent to the Host indicating an HPF firmware error.
+  * Use the Watchdog Timer (WDT) peripheral with STOP functionality.
+    HPF firmware has to feed the watchdog.
+    If it fails to do so, the Host receives an interrupt and must execute TASK_STOP.
+    This solution assumes that the Host is always able to invoke TASK_STOP within two 32kHz cycles. Otherwise, the WDT triggers a reset, which might be undesired.
+
+* Implementing a trap handler that signals the fault condition to the Host, for example, using the VEVIF IRQ and a predefined memory location to store the error code.
path: doc/nrf/app_dev/device_guides/coprocessors/fault_handling.rst
user: login: mif1-nordic
body: ```suggestion
* Implement a trap handler that signals the fault condition to the Host, for example, using the VEVIF IRQ and a predefined memory location to store the error code.
```
created_at: 2025-04-15T13:37:45Z
author_association: CONTRIBUTOR
diff_hunk: @@ -1,21 +1,28 @@
 .. _sdp_gpio:
-.. _hpf_gpio:
+.. _hpf_gpio_example:
 
 High-Performance Framework GPIO
 ###############################
 
-.. contents::
-   :local:
-   :depth: 2
+.. caution::
 
-This application demonstrates how to create a software peripheral on FLPR in High-Performance Framework (HPF) by implementing a subset of Zephyr's GPIO API.
-It is intended for use with Zephyr's :zephyr:code-sample:`blinky` sample.
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
 
-You can use the following IPC backends:
+This application demonstrates how to write a :ref:`High-Performance Framework (HPF) <hpf_index>` application implementing a simple peripheral.
+The application implements subset of Zephyr GPIO API.
path: applications/hpf/gpio/README.rst
user: login: masz-nordic
body: ```suggestion
The application implements a subset of the Zephyr GPIO API.
```
created_at: 2025-04-16T07:57:45Z
author_association: CONTRIBUTOR
diff_hunk: @@ -38,3 +58,37 @@ For example, to build with icmsg backend, run the following commands:
      west flash
 
 Upon successful execution, **LED0** will start flashing.
+
+Dependencies
+************
+
+* :file:`zephyr/doc/services/ipc/ipc_service` - Used for transferring data between application core and the FLPR core.
path: applications/hpf/gpio/README.rst
user: login: masz-nordic
body: ```suggestion
* :file:`zephyr/doc/services/ipc/ipc_service` - Used for transferring data between application core and the FLPR core (if you are not using the mbox backend).
```
created_at: 2025-04-16T07:59:08Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,381 @@
+.. _hpf_mspi_example:
+
+High-Performance Framework MSPI
+###############################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+This application demonstrates how to write a :ref:`High-Performance Framework (HPF) <hpf_index>` application and communicate with it.
+The application implements subset of Zephyr MSPI API.
path: applications/hpf/mspi/README.rst
user: login: masz-nordic
body: ```suggestion
The application implements a subset of the Zephyr MSPI API.
```
created_at: 2025-04-16T08:00:25Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,381 @@
+.. _hpf_mspi_example:
+
+High-Performance Framework MSPI
+###############################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+This application demonstrates how to write a :ref:`High-Performance Framework (HPF) <hpf_index>` application and communicate with it.
+The application implements subset of Zephyr MSPI API.
+
+Application overview
+********************
+
+The MSPI HPF application is structured into the following main components:
+
+* The HPF application - Operates on the FLPR core and facilitates data transmission between the application core and the connected MSPI device.
+* The Hard Real Time (HRT) module - Runs on the FLPR core and facilitates data transmission between the FLPR core and the connected MSPI device.
+  The module emulates the MSPI hardware peripheral on the FLPR core, managing real-time data transmission and ensuring precise timing and synchronization of data transfer operations.
+* The MSPI driver - Operates on the application core and uses the Zephyr's scalable real-time operating system (RTOS) MSPI API for data and configuration transmission between the application and FLPR cores.
path: applications/hpf/mspi/README.rst
user: login: masz-nordic
body: ref to this file could be added here:
https://github.com/nrfconnect/sdk-nrf/blob/main/drivers/mspi/mspi_hpf.c
created_at: 2025-04-16T08:01:32Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,381 @@
+.. _hpf_mspi_example:
+
+High-Performance Framework MSPI
+###############################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+This application demonstrates how to write a :ref:`High-Performance Framework (HPF) <hpf_index>` application and communicate with it.
+The application implements subset of Zephyr MSPI API.
+
+Application overview
+********************
+
+The MSPI HPF application is structured into the following main components:
+
+* The HPF application - Operates on the FLPR core and facilitates data transmission between the application core and the connected MSPI device.
+* The Hard Real Time (HRT) module - Runs on the FLPR core and facilitates data transmission between the FLPR core and the connected MSPI device.
+  The module emulates the MSPI hardware peripheral on the FLPR core, managing real-time data transmission and ensuring precise timing and synchronization of data transfer operations.
+* The MSPI driver - Operates on the application core and uses the Zephyr's scalable real-time operating system (RTOS) MSPI API for data and configuration transmission between the application and FLPR cores.
+
+Scope
+*****
+
+The application must meet the following key requirements:
+
+* Compatibility with the MSPI configuration including clock polarity, phase, and the number of data lines or transmission modes (single, quad).
+* Low latency and high throughput.
+
+Requirements
+************
+
+The application supports the following development kits:
+
+.. table-from-sample-yaml::
+
+Configuration and data transfer management
+******************************************
+
+Data transfer between the MSPI driver and the HPF application is done through the ICMsg.
+Data can be configured to be passed either by copy or by reference.
+By default, data is passed by reference.
+To enable data passing by copy, you must disable the ``SDP_MSPI_IPC_NO_COPY`` Kconfig option.
+
+Initialization phase
+====================
+
+The initialization of the MSPI HPF application is divided into two main phases: driver initialization and device initialization.
+
+1. Driver initialization:
+
+   a. A user application calls the :c:func:`mspi_config` function to initialize the MSPI driver.
+   #. The MSPI driver passes the DTS pin configuration to the HPF application.
+   #. The HPF application calls the :c:func:`config_pins` function to initialize GPIO settings based on the received configuration.
+   #. All pins are assigned to specific VIO lines using a mapping array.
+
+2. Device initialization
+
+   a. A user application calls the :c:func:`mspi_dev_config` function to configure the MSPI device.
+   #. The MSPI driver passes selected parts of the configuration to the HPF application.
+   #. The HPF application adds the device configuration to the device list.
+
+Data transmission phase
+=======================
+
+The data transmission process is structured into two parts: preparation and the transfer.
+
+1. Transfer preparation
+
+   a. A user application calls the :c:func:`mspi_transceive` function to initiate a data transfer.
+   #. The MSPI driver passes transfer parameters to HPF application (``hrt_xfer_t``).
+   #. The HPF application calls the :c:func:`configure_clock` function to set the clock polarity and phase (SPI modes) based on the ``cpp_mode`` parameter.
+      It ensures compatibility with modes 0 and 3.
+   #. For each packet, MSPI driver passes packet data to HPF application, awaiting completion.
+   #. For each packet, HPF application calls the :c:func:`xfer_execute` function to prepare the transfer and adjust the last word.
+
+   .. note::
+
+      Due to hardware constraints, the length of the last word cannot be ``1``.
+      The :c:func:`adjust_tail` function modifies the last two words to meet this requirement.
+
+2. Packet element transfer
+
+   a. Each packet transfer is initiated by the :c:func:`hrt_write` or :c:func:`hrt_read` functions on the FLPR core.
+      Additionally, each packet is divided into four elements: ``command``, ``address``, ``dummy_cycles``, and ``data``.
+   #. The :c:func:`hrt_write` and :c:func:`hrt_read` functions prepare the hardware for data transmission by setting GPIO direction masks and determining active packet elements.
+   #. The chip select (CS) is enabled before the transfer and disabled afterward unless ``ce_hold`` is set to ``true``.
+   #. Each TX packet element is processed using the :c:func:`hrt_tx` function.
+   #. :c:func:`hrt_read` function treats the ``data`` element as RX and passes all other elements to the :c:func:`hrt_write` function.
+   #. For each packet element, the shift controller is configured for the appropriate number of data lines and word size.
+
+Sequence flow
+=============
+
+The following diagram illustrates the interactions between the user application and the FLPR HRT, mapping out each step from initialization to data transfer:
+
+.. uml::
+
+  @startuml
+  skinparam sequence {
+  DividerBackgroundColor #8DBEFF
+  DividerBorderColor #8DBEFF
+  LifeLineBackgroundColor #13B6FF
+  LifeLineBorderColor #13B6FF
+  ParticipantBackgroundColor #13B6FF
+  ParticipantBorderColor #13B6FF
+  BoxBackgroundColor #C1E8FF
+  BoxBorderColor #C1E8FF
+  GroupBackgroundColor #8DBEFF
+  GropuBorderColor #8DBEFF
+  }
+
+  skinparam note {
+  BackgroundColor #ABCFFF
+  BorderColor #2149C2
+  }
+
+  box "Application"
+  participant "User\nApplication" as t
+  participant "Zephyr RTOS\nMSPI API" as a
+  participant "HPF eMSPI driver" as d
+  end box
+  box "FLPR"
+  participant "HPF FLPR APP" as f
+  participant "HRT" as h
+  end box
+
+  == Initialization ==
+
+  activate t
+  t -> a : mspi_config()
+  activate a
+  a -> d : api_config()
+  activate d
+  d -> d : send_config(HPF_MSPI_CONFIG_PINS)
+  note right d: Shared mem and/or IRQ num
+  d -> f : HPF_MSPI_CONFIG_PINS
+  activate f
+  f -> f : config_pins()
+  return
+  deactivate f
+  d --> a
+  deactivate d
+  a --> t
+  deactivate a
+
+  ...
+
+  loop for each device
+  t -> a : mspi_dev_config()
+  activate a
+  a -> d : api_dev_config()
+  activate d
+  d -> d : send_config(HPF_MSPI_CONFIG_DEV)
+  note right d: Shared mem and/or IRQ num
+  d -> f : HPF_MSPI_CONFIG_DEV
+  activate f
+  note right f: Fill structures\nwith data from APP\nand configure CE pins
+  return
+  deactivate f
+  d --> a
+  deactivate d
+  a --> t
+  deactivate a
+  end
+
+  ...
+
+  == TX-RX-TX requests ==
+
+  t -> a : mspi_transceive()
+  activate a
+  a -> d : api_transceive()
+  activate d
+  d -> d : send_config(HPF_MSPI_CONFIG_XFER)
+  note right d: Shared mem and/or IRQ num
+  d -> f : HPF_MSPI_CONFIG_XFER
+  activate f
+  f -> f : configure_clock()
+  return
+  deactivate f
+  loop for each packet
+  d -> d ++ : start_next_packet()
+  d -> d ++ : xfer_packet()
+  note right d: Shared mem and/or IRQ num
+  d -> f : HPF_MSPI_TX or HPF_MSPI_TXRX
+  activate f
+  f -> f ++ : xfer_execute()
+  f -> f ++ : adjust_tail(command)
+  deactivate f
+  f -> f ++ : adjust_tail(address)
+  deactivate f
+  f -> f ++ : adjust_tail(dummy_cycles)
+  deactivate f
+  f -> f ++ : adjust_tail(data)
+  deactivate f
+  deactivate f
+  note right f: IRQ num
+  f -> h : Dispatch
+  activate h
+
+  alt transfer type TX
+  h -> h ++ : hrt_write()
+  h -> h ++ : hrt_tx(command)
+  deactivate h
+  h -> h ++ : hrt_tx(address)
+  deactivate h
+  h -> h ++ : hrt_tx(dummy_cycles)
+  deactivate h
+  h -> h ++ : hrt_tx(data)
+  deactivate h
+  deactivate h
+
+  else trasnfer type TXRX
+  note right h: Temp. set data length to 0
+  h -> h ++ : hrt_write()
+  h -> h ++ : hrt_tx(command)
+  deactivate h
+  h -> h ++ : hrt_tx(address)
+  deactivate h
+  h -> h ++ : hrt_tx(dummy_cycles)
+  deactivate h
+  deactivate h
+  note right h: Temp. set data length to original value
+  note right h: Receive data
+  end
+  return
+  return
+  deactivate d
+  deactivate d
+  d --> a
+  deactivate d
+  a --> t
+  deactivate a
+  deactivate t
+  @enduml
+
+Key functions
+=============
+
+Key functions, such as :c:func:`hrt_write`, :c:func:`hrt_tx`, and :c:func:`hrt_read` are integral to managing the data transfer process, handling tasks from setting GPIO directions to executing low-level data transfers.
+
+.. list-table::
+   :widths: 20 30 50
+   :header-rows: 1
+
+   * - Function
+     - Purpose
+     - Key Steps
+   * - :c:func:`hrt_write`
+     - The primary function for executing a TX transfer. It handles configuration, timing, and data transmission for all frame elements.
+     - 1. Configures GPIO directions for TX using the transfer parameters.
+       2. Determines the active frame element (command, address, dummy bits, or data).
+       3. Transfers the frame elements sequentially via :c:func:`hrt_tx`.
+       4. Manages clock timing and CE pin behavior.
+   * - :c:func:`hrt_tx`
+     - Handles the low-level data transfer for a specific frame element (e.g., ``command``, ``address``, ``dummy_cycles``, or ``data``).
+     - 1. Configures the shift controller (:c:func:`nrf_vpr_csr_vio_shift_ctrl_buffered_set`).
+       2. Writes each word from the data buffer to the output register.
+       3. Starts the hardware counter for generating clock signal.
+   * - :c:func:`hrt_read`
+     - The primary function for executing a RX transfer. It handles configuration, timing, and data transmission for all frame elements.
+     - 1. Call :c:func:`hrt_write` for ``command``, ``address`` and ``dummy_cycles`` elements.
+       2. Configures GPIO directions for RX using the transfer parameters.
+       3. Receives ``data`` element.
+       4. Manages clock timing and CE pin behavior.
+   * - :c:func:`adjust_tail`
+     - Manages the formatting of the last and penultimate words in the transfer buffer to comply with hardware limitations.
+     - - Adjusts word boundaries when the last word requires only 1 clock cycle to be sent.
+       - Handles cases where data needs to be split across multiple words.
+
+Key data structures
+===================
+
+The following section provides an overview of the primary data structures used in managing MSPI transfers.
+These structures are crucial for configuring and executing data transfers efficiently.
+
+* Transfer elements
+
+  * ``hrt_frame_element_t`` - Defines different frame elements (:c:enumerator:`HRT_FE_COMMAND`, :c:enumerator:`HRT_FE_ADDRESS`, :c:enumerator:`HRT_FE_DUMMY_CYCLES`, :c:enumerator:`HRT_FE_DATA`).
+
+* Transfer configuration
+
+  * ``hrt_xfer_t`` - Encapsulates the core configuration for an MSPI transfer.
+  * ``xfer_data`` - An array of the ``hrt_xfer_data_t`` structures for the frame elements (:c:member:`command`, :c:member:`address`, :c:member:`dummy_cycles`, :c:member:`data`).
+  * ``bus_widths`` - Defines the bit-width configuration for the :c:member:`command`, :c:member:`address`, :c:member:`dummy_cycles`, and :c:member:`data` sections of the transfer.
+  * ``counter_value``: Sets the clock divider to achieve frequency specified by a user.
+  * ``ce_vio`` - Index of the VIO pin used as CE.
+  * ``ce_hold`` - Whether CE remains asserted after the transfer.
+  * ``ce_polarity`` - Active polarity of the CE pin.
+  * ``tx_direction_mask`` and ``rx_direction_mask`` - Configure GPIO directions for data transmission.
+  * ``cpp_mode`` - SPI mode 0 or 3
+
+* Transfer data
+
+  * ``hrt_xfer_data_t`` - Represents transfer-specific properties for each frame element.
+  * ``data`` - Points to the data being transmitted or received.
+  * ``word_count`` - Number of 32-bit words in the data buffer.
+  * ``last_word_clocks`` - Number of clock pulses for the final word.
+  * ``penultimate_word_clocks`` - Clock pulses for the second-to-last word.
+  * ``last_word`` - Holds the last word data (for transition or from reception).
+  * ``fun_out`` - Selects which function in TX to use to access buffered output register.
+
+Building and running
+********************
+
+.. |application path| replace:: :file:`applications/hpf/mspi`
+
+.. include:: /includes/application_build_and_run.txt
+
+To build and run the application, you must include code for both the application core and FLPR core.
+The process involves building a test or user application that is using MSPI driver with the appropriate sysbuild configuration.
+
+.. tabs::
+
+   .. tab:: Building with tests
+
+      You can use the tests listed in the :ref:`hpf_mspi_example_testing` section.
+      To build them, execute the following command in their respective directories:
+
+      .. code-block:: console
+
+         west build -p -b nrf54l15dk_nrf54l15_cpuapp
+
+   .. tab:: Building with User Application
+
+      Follow these steps to build with a user application:
+
+      1. Enable the following Kconfig options:
+
+         * ``SB_CONFIG_HPF`` - Enables the High-Performance Framework (HPF).
+         * ``SB_CONFIG_HPF_MSPI`` - Integrates the HPF application image with the user application image.
+
path: applications/hpf/mspi/README.rst
user: login: masz-nordic
body: ```suggestion

      #. Disable the following Kconfig options:
      
         * ``SB_CONFIG_VPR_LAUNCHER`` - Disables the default VPR launcher image for the application core.
         * ``SB_CONFIG_PARTITION_MANAGER`` - Disables the :ref:`Partition Manager <partition_manager>`.
         
```
created_at: 2025-04-16T08:06:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,19 @@
+.. _hpf_applications_readme:
+
+High-Performance Framework
+##########################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+High-Performance Framework, is a framework designed to facilitate the creation and integration of :ref:`software peripherals using coprocessors <coprocessors_index>`.
path: applications/hpf/hpf.rst
user: login: masz-nordic
body: ```suggestion
High-Performance Framework, is a framework designed to facilitate the creation and integration of :ref:`peripheral emulations using coprocessors <coprocessors_index>`.
```
created_at: 2025-04-16T08:08:47Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+.. _hpf_assembly_management:
+
+Assembly management
+###################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+Assembly management is a critical component in the development process, particularly when meeting the modularity and testability requirements defined in the :ref:`hpf_event_handling`.
+
+Overview
+********
+
+Emulating communication protocols requires precise timing.
+To manage this, you must separate the time-sensitive parts of the code, known as Hard Real-Time (HRT) components.
+These components have strict timing requirements and are stored in a pre-compiled assembly format to ensure they remain unchanged.
+
+The assembly management CMake functions are integrated into the build process and are executed with every build.
+These functions check for any modifications that could lead to the generation of different assembly files, such as changes in HRT source files or the compiler used.
+Detecting these changes is essential because they can impact the timing accuracy of software peripherals.
+If any changes are detected that could affect the assembly files, you must verify that these differences are within acceptable limits.
+This ensures that the new code maintains the necessary timing accuracy.
+
+To use this feature, you must include the command ``hpf_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c")`` in your application's :file:`CMakeLists.txt` file, where ``file.c`` value is the C file containing only Hard Real-Time (HRT) functions.
+
+Although the assembly management functions are called every time in build time, some of them can also be run independently by using CMake targets in VPR core's application build directory.
+
+See following flow of the build-time assembly management process:
+
+.. image:: images/hpf_assembly_build_time_management_process.svg
+  :alt: HPF assembly management process
+
+.. _hpf_assembly_management_cmake:
+
+Implementation
+**************
+
+The assembly management performed at build time uses following :ref:`CMake<cmake_options>` functions:
+
+* :c:func:`hpf_assembly_generate`
+* :c:func:`hpf_assembly_check`
+* :c:func:`hpf_assembly_prepare_install`
+* :c:func:`hpf_assembly_target_sources`
+
+hpf_assembly_generate
+=====================
+
+The :c:func:`hpf_assembly_generate` function creates a build target (asm_gen) that generates a temporary assembly file from HRT source files.
+This files is named :file:`file-soc-temp.s` and is located in the Fast Lightweight Peripheral Processor (FLPR) application's build directory when running ``ninja build``.
+In the filename, *soc* represents the System on Chip (SoC) name used in the current build, such as ``nrf54l15``.
+
+hpf_assembly_check
+==================
+
+The :c:func:`hpf_assembly_check` function sets up a build target (asm_check) that is triggered when executing ``ninja build``, following the :c:func:`sdk_assembly_generate` function.
+The target verifies if the :file:`file-soc-temp.s` file in the build directory matches the :file:`file-soc.s` file in the source directory.
+If discrepancies are found, it triggers a CMake error (in user mode) or warning (in developer mode).
+
+hpf_assembly_prepare_install
+============================
+
+The :c:func:`hpf_assembly_prepare_install` function creates a build target (asm_install) that replaces the :file:`file-soc.s` file in the source directory with :file:`file-soc-temp.s` from the build directory.
+
+hpf_assembly_target_sources
+===========================
+
+The :c:func:`hpf_assembly_target_sources` function includes the :file:`file-soc.s` from source directory (user mode) or the :file:`file-soc-temp.s` from build directory (developer mode) in the target sources.
+
+Configuration
+*************
+
+You can change the mechanism of :c:func:`hpf_assembly_check` and :c:func:`hpf_assembly_target_sources` functions by switching between user and developer build modes:
+
+* User mode - The application uses a pre-generated assembly file to construct the HRT component.
+* Developer mode -  The application employs a newly generated assembly file.
+  This approach not only facilitates the integration of updates but also allows for a thorough review of changes made by developers and modifications introduced by the toolchain.
+  You can enable it by setting the ``SB_CONFIG_HPF_DEVELOPER_MODE`` Kconfig option.
+  If this setting is disabled, files are build in the user mode.
path: doc/nrf/app_dev/device_guides/coprocessors/assembly_management.rst
user: login: umapraseeda
body: ```suggestion
  If this setting is disabled, files are built in the user mode.
```
created_at: 2025-04-16T08:17:03Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,106 @@
+.. _hpf_assembly_management:
+
+Assembly management
+###################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+Assembly management is a critical component in the development process, particularly when meeting the modularity and testability requirements defined in the :ref:`hpf_event_handling`.
+
+Overview
+********
+
+Emulating communication protocols requires precise timing.
+To manage this, you must separate the time-sensitive parts of the code, known as Hard Real-Time (HRT) components.
+These components have strict timing requirements and are stored in a pre-compiled assembly format to ensure they remain unchanged.
+
+The assembly management CMake functions are integrated into the build process and are executed with every build.
+These functions check for any modifications that could lead to the generation of different assembly files, such as changes in HRT source files or the compiler used.
+Detecting these changes is essential because they can impact the timing accuracy of software peripherals.
+If any changes are detected that could affect the assembly files, you must verify that these differences are within acceptable limits.
+This ensures that the new code maintains the necessary timing accuracy.
+
+To use this feature, you must include the command ``hpf_assembly_install(app "${CMAKE_SOURCE_DIR}/file.c")`` in your application's :file:`CMakeLists.txt` file, where ``file.c`` value is the C file containing only Hard Real-Time (HRT) functions.
+
+Although the assembly management functions are called every time in build time, some of them can also be run independently by using CMake targets in VPR core's application build directory.
+
+See following flow of the build-time assembly management process:
path: doc/nrf/app_dev/device_guides/coprocessors/assembly_management.rst
user: login: umapraseeda
body: ```suggestion
See the following flow of the build-time assembly management process:
```
created_at: 2025-04-16T08:18:18Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,235 @@
+.. _hpf_power_management:
+
+Power management
+################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following page outlines the approaches and mechanisms employed to ensure efficient power management in High-Performance Framework (HPF) systems, focusing on resource allocation, system states, and interactions between different components.
+
+.. note::
+   This page outlines best practices for architecture design.
+   You might need to implement some components, as they are not yet available.
+
+Power management strategies
+***************************
+
+Power Management in HPF should be considered from two perspectves: the Host controller and the HPF firmware.
path: doc/nrf/app_dev/device_guides/coprocessors/power_management.rst
user: login: umapraseeda
body: ```suggestion
Power Management in HPF should be considered from two perspectives: the Host controller and the HPF firmware.
```
created_at: 2025-04-16T08:19:13Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,235 @@
+.. _hpf_power_management:
+
+Power management
+################
+
+.. caution::
+
+   The High-Performance Framework (HPF) support in the |NCS| is :ref:`experimental <software_maturity>` and is limited to the nRF54L15 device.
+
+The following page outlines the approaches and mechanisms employed to ensure efficient power management in High-Performance Framework (HPF) systems, focusing on resource allocation, system states, and interactions between different components.
+
+.. note::
+   This page outlines best practices for architecture design.
+   You might need to implement some components, as they are not yet available.
+
+Power management strategies
+***************************
+
+Power Management in HPF should be considered from two perspectves: the Host controller and the HPF firmware.
+
+Host controller
+===============
+
+The Host is responsible for managing power state of the following resources:
+
+* FLPR core with HPF firmware running on it
+* RAM
+
+To achieve optimal power state, you must use the `Device Runtime Power Management`_ and `System Power Off`_.
+
+See an example flow of the Host power management:
+
+.. uml::
+
+  @startuml
+  skinparam sequence {
+  DividerBackgroundColor #8DBEFF
+  DividerBorderColor #8DBEFF
+  LifeLineBackgroundColor #13B6FF
+  LifeLineBorderColor #13B6FF
+  ParticipantBackgroundColor #13B6FF
+  ParticipantBorderColor #13B6FF
+  BoxBackgroundColor #C1E8FF
+  BoxBorderColor #C1E8FF
+  GroupBackgroundColor #8DBEFF
+  GropuBorderColor #8DBEFF
+  }
+
+  skinparam note {
+  BackgroundColor #ABCFFF
+  BorderColor #2149C2
+  }
+
+  participant Zephyr
+  participant Application
+  participant "HPF driver"
+  participant "VPR driver"
+  participant FLPR
+
+  activate Zephyr
+  Zephyr -> Zephyr : post kernel initialization
+  activate Zephyr
+  Zephyr -> "VPR driver" : Initialize drivers
+  activate "VPR driver"
+  rnote over "VPR driver"
+  Power on FLPR RAM
+  endrnote
+  rnote over "VPR driver"
+  If non-XIP:
+  Copy code to RAM
+  endrnote
+  rnote over "VPR driver"
+  Start FLPR
+  endrnote
+
+  "VPR driver" -> "VPR driver" : Initialize IPC
+  activate "VPR driver"
+  "VPR driver" -> FLPR
+  activate FLPR
+  rnote over FLPR
+  Boot
+  endrnote
+  rnote over FLPR
+  Initialize IPC
+  endrnote
+  return
+  deactivate "VPR driver"
+
+  "VPR driver" -> "VPR driver" : Initialize FLPR
+  activate "VPR driver"
+  "VPR driver" -> FLPR : FLPR_INIT
+  activate FLPR
+  rnote over FLPR
+  Initialize HW, peripherals, etc
+  endrnote
+  return FLPR_INITD
+  deactivate "VPR driver"
+  return
+  deactivate "VPR driver"
+
+
+  deactivate Zephyr
+  Zephyr -> Application : Start application
+  activate Application
+  Application -> "HPF driver" : hpf_driver_config(...)
+  activate "HPF driver"
+  "HPF driver" -> "HPF driver" : HPF driver initialization
+  activate "HPF driver"
+  "HPF driver" -> "VPR driver" : pm_device_runtime_get(&flpr)
+  activate "VPR driver"
+  "VPR driver" -> FLPR : FLPR_RESUME
+  activate FLPR
+  rnote over FLPR
+  Enter RESUME state
+  endrnote
+  return FLPR_RESUMED
+  return
+
+  "HPF driver" -> FLPR : HPF_APP_CONFIGURE
+  activate FLPR
+  rnote over FLPR
+  Configure HPF application
+  endrnote
+  return HPF_APP_CONFIGURED
+  deactivate "HPF driver"
+  return
+  ...
+
+
+  Application -> "HPF driver" : hpf_driver_transcieve(...)
+  activate "HPF driver"
+  "HPF driver" -> FLPR : HPF_APP_XFER
+  activate FLPR
+  rnote over FLPR
+  Execute transfer
+  endrnote
+  return HPF_APP_XFERD
+  return
+  ...
+
+
+  Application -> "HPF driver" : hpf_driver_config(...)
+  activate "HPF driver"
+  "HPF driver" -> "HPF driver" : HPF driver deinitialization
+  activate "HPF driver"
+  "HPF driver" -> FLPR : HPF_APP_DECONFIGURE
+  activate FLPR
+  rnote over FLPR
+  Deconfigure HPF application
+  endrnote
+  return HPF_APP_DECONFIGURED
+
+  "HPF driver" -> "VPR driver" : pm_device_runtime_put(&flpr)
+  activate "VPR driver"
+  "VPR driver" -> FLPR : FLPR_SUSPEND
+  activate FLPR
+  rnote over FLPR
+  Enter SUSPENDED state
+  endrnote
+  return FLPR_SUSPENDED
+  return
+  deactivate "HPF driver"
+  return
+  return
+
+
+  Zephyr -> Zephyr : power off procedure
+  activate Zephyr
+  "Zephyr" -> "VPR driver" : power off
+  activate "VPR driver"
+  "VPR driver" -> "VPR driver" : FLPR shutdown
+  activate "VPR driver"
+  "VPR driver" -> FLPR : FLPR_SHUTDOWN_PREPARE
+  activate FLPR
+  rnote over FLPR
+  Deinitialize HW peripherals, etc
+  endrnote
+  return FLPR_SHUTDOWN_PREPARED
+  deactivate "VPR driver"
+  rnote over "VPR driver"
+  Power off FLPR
+  endrnote
+  rnote over "VPR driver"
+  Power off FLPR RAM
+  endrnote
+  return
+  deactivate Zephyr
+  @enduml
+
+.. note::
+	VPR driver is not yet implemented, it should be implemented when writing HPF software.
+	It shall run on application core.
+	Its purpouse is to control basic FLPR functionalities like initialization of inter processor communication and power mode management.
path: doc/nrf/app_dev/device_guides/coprocessors/power_management.rst
user: login: umapraseeda
body: ```suggestion
	Its purpose is to control basic FLPR functionalities like initialization of inter processor communication and power mode management.
```
created_at: 2025-04-16T08:19:27Z
author_association: CONTRIBUTOR

PR comments:
user: login: NordicBuilder
created_at: 2025-04-08T14:14:07Z
body: ## CI Information

<sup>_To view the history of this post, clich the 'edited' button above_</sup>
Build number: 45
### Inputs:
#### Sources:
<details><summary> more details</summary>
</details>

#### Github labels
| Enabled | Name | Description |
| -- | -- | -- |
|| ci-disabled | _Disable the ci execution_ | 
|| ci-all-test | _Run all of ci, no test spec filtering will be done_ | 
|| ci-force-downstream | _Force execution of downstream even if twister fails_ | 
|| ci-run-twister | _Force run twister_ | 
|| ci-run-zephyr-twister | _Force run zephyr twister_ | 

<details><summary> List of changed files detected by CI (0)</summary>

```
```
</details>

### Outputs:

#### Toolchain
Version: 
Build docker image: 

#### Test Spec & Results: :white_check_mark: Success; :x: Failure; :orange_circle: Queued; :yellow_circle: Progress; :white_medium_square: Skipped; :warning: Quarantine
- :white_medium_square: Toolchain
- :white_medium_square: Build twister
- :white_medium_square: Integration tests



*Note: This message is automatically posted and updated by the CI*
author_association: CONTRIBUTOR
user: login: github-actions[bot]
created_at: 2025-04-08T14:32:45Z
body: You can find the documentation preview for this PR [here](https://ncsdoc.z6.web.core.windows.net/PR-21539/).

Preview links for modified nRF Connect SDK documents:

https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/app_dev.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/app_dev/device_guides/coprocessors/assembly_management.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/app_dev/device_guides/coprocessors/event_handling.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/app_dev/device_guides/coprocessors/fault_handling.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/app_dev/device_guides/coprocessors/hpf.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/app_dev/device_guides/coprocessors/index.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/app_dev/device_guides/coprocessors/power_management.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/app_dev/device_guides/coprocessors/rt_peripherals.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/applications.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/applications/hpf/gpio/README.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/applications/hpf/hpf.html
https://ncsdoc.z6.web.core.windows.net/PR-21539/nrf/applications/hpf/mspi/README.html
author_association: NONE