heliaPROFILER Cycle-Accurate Profiling for Edge AI

Profiling AI workloads on embedded hardware has typically meant fragmented tools and manual analysis, which slows optimization work down. heliaPROFILER™ consolidates that process into a single automated workflow so developers can identify bottlenecks and compare optimization strategies without piecing together their own tooling. 

Teams building edge AI often can’t tell whether a performance issue lives in the model, the runtime, the compiler, or the hardware without significant manual instrumentation. heliaPROFILER™ answers that question directly by profiling standard TFLM alongside heliaRT™ and heliaAOT™ through the same workflow, so developers can see precisely where Ambiq’s optimizations gain ground and spend their time optimizing instead of building profiling infrastructure. 

It means heliaPROFILER™ measures what actually happens on the chip during execution, not an estimate. Using PMU counters on Apollo510 and DWT cycle counts on earlier Apollo hardware, it reports the real number of cycles, instructions, and cache events a model consumes, layer by layer. 

heliaRT™ and heliaAOT™ are two ways to run AI inference on Ambiq hardware, one as a runtime interpreter and one as an ahead-of-time compiler. heliaPROFILER™ doesn’t run inference itself, it measures how a model performs under standard TFLM, heliaRT, or heliaAOT, so developers can compare all three and choose the right path for their application.

Yes. heliaPROFILER™ includes built-in platform definitions for Apollo 3, 4, and 5, with full Armv8-M PMU access on Apollo510 and DWT-based cycle counts on Apollo 3 and 4. 

Yes. heliaPROFILER™ supports GCC, Arm Compiler for Embedded (ACfE), and Arm Toolchain for Embedded (ATfE), so developers can profile the same model across different toolchain configurations through a consistent workflow rather than rebuilding their setup for each comparison. 

With optional Joulescope integration, heliaPROFILER™ measures power and energy consumption on a per-inference basis rather than just raw current and voltage. That gives developers a direct, model-level view of energy cost, making it easier to evaluate battery-life tradeoffs during development instead of discovering them after deployment.