Architecting a visual tracking accelerator for a multi-camera XR SoC

The challenge

Head tracking on a wearable has to run continuously at very low power. The client needed a fixed-function engine that would take pixels from a multi-camera cluster and deliver, every frame, the feature data the host needed for a headpose update. The algorithms existed as reference software. The hardware did not.

What we owned

The specification. SiliconScapes was hardware architect of record. We authored and maintained the Hardware Architecture Specification, the block-level Micro-Architecture Specifications, an inter-stage interface specification, and the register map. Every change landed as a change note against a decision registry, so reviewers could see what moved and why.

The architecture. A streaming pipeline that took the client’s reference algorithms from software to a fixed-function engine, with the memory, dispatch and host-interface decisions that determine whether a design like this meets its power budget. The specifics belong to the client; the method is ours.

The golden model. A bit-exact hardware model, held golden against the RTL on real image sequences and against the client’s own software reference, so every RTL release was judged on data rather than opinion.

The RTL and the delivery method. SiliconScapes wrote the RTL across fifteen IP repositories and ran the workflow around it: tagged releases, pinned dependencies, staged design reviews, and integration benches at the seams between blocks.

The prototype path. Our co-simulation platform stood in for a subsystem that was still in RTL, implementing the real register map, so firmware development ran against the architecture months before that RTL landed. Memory PPA inventories were produced against the target foundry’s macro catalogue.

Outcome

A controlled specification set and an RTL reference implementation built from it, verified against a bit-exact golden model and ready for silicon or FPGA.