Edge AI promises programmability, but for many engineers, it feels more like a locked box. This article explores the real engineering challenges behind so-called “programmable” AI platforms and highlights the key design choices that enable true flexibility. Topics include dynamic LPO design, programmable pre-processing, modular analog AI cores, and the importance of a full-stack development pipeline.

When “Programmable” Doesn’t Mean What You Think It Does

As engineers, we often get excited when we see the word “programmable” on a new AI edge chip. It suggests flexibility, control, and the ability to tailor a platform around our use case. But more often than not, that promise falls short.

You dive into the SDK and find that everything is fixed. You’re expected to follow one inference pipeline. You can’t adjust your logic on the fly. Need to add a second sensor? You’ll probably need a workaround for power conflicts. And if your model architecture isn’t supported out of the box, you're in trouble.

In many cases, "programmable" really just means "parameterizable." You're given a few knobs to turn, but the core behavior is baked in.

We wanted to do better. So we asked ourselves: What would it actually take to build a processor that behaves the way embedded engineers expect? One that gives you real, end-to-end control?

Modular AI Cores with Analog MACs

Most edge AI platforms lock you into specific neural network topologies. You get a compact CNN or maybe a basic RNN. If your model doesn’t fit their expected structure, you’re either forced to compromise or rework your entire approach.

We tackled this limitation by designing modular analog MAC blocks that aren’t hardwired to any specific AI model. Instead, they allow engineers to define their own custom logic, from neural networks to handcrafted algorithms.

This flexibility means your model can be entirely unique to your application, and the implementation becomes your IP. For industries that rely on proprietary algorithms, this control is essential.

By executing these operations in analog directly within memory, we also avoid expensive digital fetch cycles, significantly reducing energy consumption.

Runtime Frequency Scaling with Zero Interruptions

Traditional embedded systems often use fixed-frequency low-power oscillators. Some allow multiple clocks, but switching between them usually requires halting logic or resetting parts of the system.

In contrast, we developed a custom low-power oscillator that supports runtime frequency changes without interrupting downstream logic. This allows a system to remain in an ultra-low-power listening mode and then dynamically shift to higher-frequency compute modes based on real-time sensor input.

This is critical in edge deployments. Imagine a device that samples environmental data every few seconds but wakes up instantly for anomalous patterns. With static clocks, you waste power. With dynamic ones that interrupt, you risk data loss. A seamless oscillator solves both problems.

On-Chip Pre-Processing that Adapts

In most architectures, pre-processing happens on an external MCU. This not only increases latency and board complexity but also burns additional energy through data movement. 

To address this, we included programmable filter banks directly on the chip. These enable early-stage processing like noise reduction, FFT, envelope detection, and frequency band selection before the data ever hits the inference engine.

These filters are runtime configurable. If your input signal characteristics change over time, your preprocessing pipeline can adapt. That’s a significant advantage in edge applications, where environmental conditions are rarely static.

A Compiler That Understands Analog and Event-Driven Logic

A programmable chip is only as good as the software that supports it. That’s why we built our entire toolchain to match the hardware, starting with a custom compiler.

The compiler understands:

• Analog-aware operator placement
• Event-driven scheduling for sensor interrupts
• Memory mapping for co-located compute blocks
• Support for multiple AI pipelines with conditional triggers

You can specify how your model behaves when idle, when it detects specific patterns, or when it switches between modes. This is not just model deployment. It’s behavior definition.

A Unified Software Stack from Sensor to Deployment

We believe real programmability spans the entire development lifecycle. Our toolchain reflects that. Engineers can:

• Collect sensor data using our interface libraries
• Preprocess and label data using visual tools
• Train models externally and import them for mapping
• Use our compiler to optimize deployment for DigAn® architecture
• Update models in the field without flashing firmware

You don’t need to switch environments, stitch together vendor tools, or write custom code for every pipeline change. The experience is seamless, and every stage understands what the hardware can do.

Real Deployments That Prove the Point

Here’s what real engineers have built using these capabilities:

• A vibration analysis tool that uses multiple pre-processing filters to isolate faults before passing signals to a custom AI logic
• A wearable that switches inference thresholds based on detected user activity levels
• A fully offline voice assistant that consumes less than 100 microwatts while waiting for a wake phrase

These systems weren’t built by tweaking firmware or writing custom drivers. They were built by programming at the level that engineers expect.

So, What Makes a Processor Truly Programmable?

It’s not just about running a model. It’s about giving you control over:

• When and how your chip wakes up
• How your data is filtered and cleaned
• What kind of intelligence is applied
• How logic responds to changing inputs

This is the foundation we built into GPX10, our ultra-low-power processor based on the DigAn® architecture. It's not a one-size-fits-all solution. It's a platform that adapts to you.

If you’ve ever wished your edge hardware felt more like an engineering tool and less like a locked-down appliance, you’re not alone. We felt it too. That’s why we built something different.