7.11. NPU

H7 i RT1062 wykonują wnioskowanie na procesorze Cortex-M poprzez TFLM i CMSIS-NN. AE3 i N6 dodają dedykowane NPU na tej samej płytce krzemowej – potok tensorowy w stałym krzemie, który wykonuje ciężkie operatory bez zajmowania procesora. Dwa NPU w ofercie OpenMV pochodzą od różnych dostawców i ich łańcuchy narzędzi są odmienne, ale kamera udostępnia oba przez to samo API ml.Model. Różni się plik na dysku oraz środowisko wykonawcze, które go przechodzi.

7.11.1. AE3 – Arm Ethos-U55

AE3 niesie NPU Ethos-U55 firmy Arm na tej samej płytce krzemowej co rdzeń aplikacyjny Cortex-M55. Vela to kompilator offline, który przygotowuje dla niego model: Vela bierze na wejściu standardowy plik .tflite i emituje na wyjściu plik .tflite, którego podgrafy kwalifikujące się do NPU zostały zwinięte w niestandardowy operator Ethos-U niosący komendy bajtowe, które wykonuje NPU. W czasie wnioskowania TFLM przechodzi plik normalnie; operator Ethos-U kieruje swoje komendy bajtowe przez sterownik Ethos-U, a każdy operator, którego Vela nie zwinęła, wraca do CMSIS-NN na M55.

7.11.2. N6 – ST Neural-ART

N6 niesie NPU Neural-ART firmy ST i uruchamia STAI – środowisko wykonawcze ST dla niego – w miejsce TFLM. STEdgeAI to kompilator offline: bierze na wejściu model i emituje relokowalny blob sieci ułożony pod sprzęt Neural-ART. STAI ładuje blob z ROMFS i przechodzi go bezpośrednio na NPU. Zakres obsługiwanych operatorów to to, co STEdgeAI wspiera dla danej części.

7.11.3. Ten sam skrypt, inna kamera

Oba NPU udostępniają te same tensory wejściowe i wyjściowe z tymi samymi parametrami kwantyzacji co model uruchamiany na procesorze. Skrypt napisany dla jednej kamery działa na innej po załadowaniu pliku modelu przygotowanego dla NPU tej kamery. Progi wykrywania, obsługa ROI i podłączenie post-procesora – decyzje na poziomie skryptu – nie zmieniają się.