In recent years, at launch events for all kinds of embedded SoCs, the slick slide decks always feature a big “XXX TOPS” headline. It feels like TOPS draws even more attention than the clock speed in GHz—as if a bigger TOPS number means it can run anything, and a smaller one means it cannot.
PART 01 What Exactly Is the TOPS Number
TOPS, or Trillion Operations Per Second, means one trillion operations per second. As described in this Qualcomm article [1], TOPS represents the “potential peak inference capability” determined by the processor’s architecture and frequency—note that it is potential and peak.
How is this number calculated? Generally it is: the number of MAC units (Multiply-Accumulate units) × frequency × 2. Why do AI chip vendors use it to measure compute power? The heaviest workload in neural networks is matrix multiplication (convolution is essentially also a matrix multiply), and at the lowest level a matrix multiply breaks down into a huge pile of MACs, where each item is exactly one multiplication plus one accumulation—corresponding to a single MAC.
So how many MAC units an NPU packs in and at what frequency it runs basically determines its peak compute power. The reason for the × 2 is that one MAC contains one multiplication and one addition, counting as two operations. Precision is generally counted at INT8; some vendors count at INT4, which doubles the number directly. So when comparing the TOPS of two chips, at the very least you must first confirm they use the same precision and the same algorithm—otherwise the comparison is meaningless.
Also, a real model is not a neat pile of MACs for you to compute on, which makes comparison even harder.
NPUs excel at operators like Conv and MatMul, but a model also contains Resize, Transpose, various odd post-processing operators, and dynamically sized inputs. The NPU may not support these, or supports them with very low efficiency—so in the end they either fall back to running on the CPU or require changing the model structure. Looking through the RKNN-Toolkit2 changelog, Rockchip has spent recent years adding operators, introducing mixed precision, and optimizing Transformers; later it added W4A16 quantization and Flash Attention, which RV1126B only began supporting from version 2.3.2. In other words, for the same chip, a one-version difference in the SDK can change both which models run and how fast they run.
PART 02 Real-World Speed Depends on the Whole Pipeline
For a vision-processing product, the data roughly flows like this:
Camera (MIPI CSI) → ISP (3A, HDR, noise reduction) → Resize / color conversion (RGA) → NPU inference → CPU post-processing (NMS, tracking, business logic) → encoding / display / network
The NPU is only one stage of it. How the overall system performs depends on this entire pipeline.

PART 03 Memory Movement
This is the most easily overlooked part. Do the math: for 4K RGB888 at 30 fps, a single uncompressed video stream already amounts to 3840×2160×3×30 ≈ 746 MB/s. That is just the image itself—not counting the ISP’s intermediate buffers, double buffering, the resized image, tensors, or the encoding buffers, let alone a second or third camera.
So when evaluating a vision board, besides looking at the NPU’s specs, you must also figure out how the data flows after it enters via CSI: whether the buffer coming out of the ISP can be fed directly to the RGA and NPU, whether there is zero-copy, and whether some frames get memcpy’d two or three times along the way. Copying one extra time may seem trivial, but when multiple cameras come online together, the DDR bandwidth is quickly exhausted—and in many cases the bottleneck never even reaches the NPU.
PART 04 CPU
After the detection network finishes running, things are not over.
NMS, object tracking, coordinate conversion, protocol stacks, databases, UI, and business logic—these things still largely have to be handled by the CPU.
For example, the RK3576 has four A72 cores plus four A53 cores, with max frequencies of 2.2 GHz and 2.0 GHz respectively; the RV1126B, on the other hand, has four A53 cores. If post-processing is complex and you also need to run several services at the same time, the big A72 cores certainly have far more headroom.
But on the flip side, if the product is simply a camera with fixed functionality, piling on an overly powerful CPU may only add cost, power consumption, and heat dissipation in the end. So a stronger CPU is not always better—it still comes down to what the whole system actually uses it for.
PART 05 ISP
I think this is becoming more and more important.
Sometimes we think: since the SoC already has an NPU sitting idle anyway, why not just offload noise reduction, HDR, and night-vision enhancement to the NPU too. I would not recommend this. These are fixed per-frame operations; if you hand them to the general-purpose NPU, its compute and bandwidth stay occupied, and the recognition models that really need to run end up queuing.
A highlight of the RV1126B is that it provides an AI-ISP. According to Rockchip, when the AI-ISP is working it does not occupy that 3 TOPS general-purpose NPU, and compared with running noise reduction directly on the NPU, both bandwidth and power consumption are lower. It also features AI Remosaic, 6-DOF digital stabilization, and multi-camera stitching. For camera products that must run 7×24, the idea of handing fixed image processing to dedicated hardware while leaving the NPU for recognition models is especially sound.
(The above content is a quotation excerpted from a shared resource on the internet.
Article shared from the Internet
)
About Rockchip RV1126B chip, our team Thinkcore have developed two boards, they are:
RV1126B 50 IPC Board
(
http://www.think-core.com/product/detail/23/112
)



RV1126B 38 size BTB SOM core board


ONE MORE THING
Thinkcore Team is an embedded board solution provider, developer, and motherboard supplier, specializing in the design, manufacturing, sales, and technical sharing of embedded motherboards. Our chipset portfolio includes Rockchip, Allwinner, and others. We welcome inquiries and collaboration!
mail: developer@thinkcore.cn