summaryrefslogtreecommitdiff
path: root/docs/sections/timing_adapters.md
diff options
context:
space:
mode:
Diffstat (limited to 'docs/sections/timing_adapters.md')
-rw-r--r--docs/sections/timing_adapters.md25
1 files changed, 15 insertions, 10 deletions
diff --git a/docs/sections/timing_adapters.md b/docs/sections/timing_adapters.md
index ab05490..7ca7076 100644
--- a/docs/sections/timing_adapters.md
+++ b/docs/sections/timing_adapters.md
@@ -1,18 +1,23 @@
# Building timing adapter with custom options
The sources contain the configuration for a timing adapter utility for the *Arm® Ethos™-U* NPU driver. The timing
-adapter allows the platform to simulate user provided memory bandwidth and latency constraints.
+adapter allows the platform to simulate user provided memory bandwidth and latency constraints on platforms that
+support it. The timing adapter driver aims to control the behavior of two AXI buses used by *Ethos-U* NPU. One is for
+SRAM memory region, and the other is for flash or DRAM.
-The timing adapter driver aims to control the behavior of two AXI buses used by *Ethos-U* NPU. One is for SRAM memory
-region, and the other is for flash or DRAM.
+The SRAM is where intermediate buffers are expected to be allocated and therefore, this region can serve frequent read
+and write traffic generated by computation operations while executing a neural network inference. The flash or DDR is
+where we expect to store the model weights and therefore, this bus would only usually be used for RO traffic.
-The SRAM is where intermediate buffers are expected to be allocated and therefore, this region can serve frequent Read
-and Write traffic generated by computation operations while executing a neural network inference.
+It is used for MPS3 FPGA and for Fast Model environment (or [AVH](./arm_virtual_hardware.md)).
-The flash or DDR is where we expect to store the model weights and therefore, this bus would only usually be used for RO
-traffic.
-
-It is used for MPS3 FPGA and for Fast Model environment.
+> **NOTE**: All Arm® Corstone™-300 based platform implementations fully support the use of `timing adapter` to perform
+> bandwidth/latency sweeps for performance estimation of the Arm® Ethos™-U NPUs. However, Arm® Corstone™-310's
+> implementation of timing adapter is, different and, unsuitable for such benchmarking. See
+> [differences between timing adapter implementations](#differences-between-timing-adapter-implementations-in-arm-corstone_300-and-arm-corstone_310) for more details. Therefore, for Arm® Corstone™-310 targets, the
+> CMake configuration is set up to ignore the timing adapters, if any, entirely. If you want to do any NPU performance
+> benchmarking for different bandwidth and latency conditions, we recommend using the Arm® Corstone™-300
+> implementations.
The CMake build framework allows the parameters to control the behavior of each bus with following parameters:
@@ -128,7 +133,7 @@ An example of the build with a custom timing adapter configuration:
```commandline
cmake .. -DTA_CONFIG_FILE=scripts/cmake/timing_adapter/my_ta_config.cmake
```
-## Differences between timing adapter implementations in Arm® Corstone™-300 and Arm® Corstone™-310
+## Differences between timing adapter implementations in Arm Corstone-300 and Arm Corstone-310
Corstone-300 FVP and FPGA implements timing adapters that are tied to AXI masters M0 and M1 on the Ethos-U NPU.