Is Pergrammable A Word?

The price tag to invest in bespoke silicon for devices such as mobile phones, automobiles, laptops, or edge agentic token servers is enormous. Leading-edge SoCs can cost more than $200M to design, verify, and validate over a two-to-three-year development period. Semiconductor and systems companies making that level of investment want those new chips to have long production lifespans to deliver a solid return on investment (ROI).

But ensuring a solid ROI requires the design team to not only build competitive silicon for today’s known requirements, but also anticipate future needs as markets shift. That anticipation problem was always hard; in the age of AI, it has become nearly impossible.

In virtually all of the end markets that drive high-volume SoC design — automotive, mobile, PC, industrial, robotics, networking — running AI models on device is increasingly mandatory. Yet predicting which AI models will be the hot flavor of the month when the new silicon is finally ready to ship is an impossible task. The state of the art in AI changes monthly, sometimes weekly. A two-year silicon design cycle might see the state of the art in the target market segment change five, ten, or more times before the chip ever reaches a customer’s board.

What the architect is actually asking for

The SoC architect laying out requirements for a new chip’s AI subsystem has, by necessity, learned to demand two things simultaneously: performance and programmability.

Performance — or, in the vernacular of the semiconductor world, being performant — means the AI subsystem can crunch through inference workloads efficiently: high throughput, low power, low latency. For a fixed bill of materials and power budget, efficiency is everything.

Programmability means the chip can be updated in the field to run AI models that haven’t been invented yet, models trained on architectures and operators that didn’t exist when the SoC was taped out. Models that will only emerge years from now, on some future Tuesday when a research team publishes something that immediately rewrites the rules.

Both of these requirements are real and both are non-negotiable, and yet the universe of AI processor licensors has, for the past several years, never offered a solution that didn’t compromise one or the other.

The standard NPU architecture and its fatal flaw

Walk the floor of any semiconductor IP trade show and you will hear the same pitch, repeated by a dozen different exhibitors with a dozen different logos: “Our solution pairs a high-performance matrix accelerator with a programmable core, giving your SoC both efficiency and flexibility.”

The accelerator handles the heavy lifting, the big, regular matrix operations that dominate the popular benchmark models. The programmable core (a CPU, DSP, or GPU, depending on the vendor’s legacy product line) handles everything else.

It sounds reasonable. And for a brief window in time — roughly 2019 to 2022, when the dominant inference benchmarks were ResNet variants and MobileNet derivatives — it worked well enough. The accelerator handled 90-plus percent of the compute, and the programmable core handled the thin tail of operators the accelerator couldn’t touch. It was a manageable partitioning problem.

Then came transformers, then large language models and their edge-targeted descendants, then vision-language-action models. Each wave brought new operator types, new graph topologies, new memory access patterns, many of which the fixed-function accelerator was never designed to handle. Suddenly the “manageable partitioning problem” became a performance cliff. Workloads that should have run on the accelerator landed instead on the programmable core, which promptly ran them at a fraction of the speed. Running them was academic; technically they ran, but so slowly as to be functionally useless.

That is the fatal flaw baked into every paired architecture: the algorithm runs on either the performant engine or the programmable engine — never both, and never simultaneously. You get one or the other. The more of the workload you push to the accelerator, the less flexible your silicon becomes. But the more you rely on the programmable core to handle new operators, the more performance you sacrifice.

A tell the industry has been ignoring

There is an obvious question that nobody in the industry has asked loudly enough:

If the programmable cores that these vendors pair with their accelerators were truly useful for running AI workloads, why would they pair them with accelerators at all? Why not simply sell the programmable core alone and let designers use it to run their AI models directly?

The answer, of course, is that no vendor makes that pitch because it would immediately reveal the performance gap. The programmable cores they bundle into their “hybrid” solutions are legacy architectures built for signal processing, control code, or general-purpose computation. They’re not designed for matrix-heavy AI inference and they never were. The accelerator is not a complement to the programmable core, it’s a confession that the programmable core cannot do the job.

What this market is selling as a unified solution is actually two products duct-taped together, each compensating for the other’s weakness, and neither doing the job the SoC architect actually needs done.

Introducing a word that should exist

The English language has a long tradition of coining new words when existing vocabulary fails to describe something real. We borrow, blend, compress, and invent. And so, with apologies to Merriam-Webster:

pergrammable

/ pər-ˈgra-mə-bəl /   adj.

Of a processor architecture: simultaneously and inseparably exhibiting both high computational efficiency and full software programmability, such that neither quality is sacrificed for the other.

Pergrammable is not performant OR programmable. It’s not an accelerator bolted to a legacy core. It’s a single processing architecture that delivers both properties simultaneously, from the same silicon, executing the same instruction stream.

That’s the thing the SoC architect has been asking for, it just didn’t have a name.

The only pergrammable NPU on the market

Quadric’s Chimera GPNPU is pergrammable. It’s not a marketing claim layered on top of a conventional paired architecture. The pergrammability of Chimera is a direct consequence of how the processor was designed from the first principles up.

Chimera’s instruction set architecture is purpose-built and matrix-native, conceived from day one to execute AI inference workloads at high efficiency while remaining fully programmable by software developers writing in C++ or Python. The matrix compute and the programmable control aren’t separate engines connected by a bus and coordinated by a partitioning compiler; they’re unified into a single execution pipeline, running a single instruction stream.

The practical consequences of this are significant:

• Any model runs. A new AI model — including operators that didn’t exist at tape-out — can be ported to Chimera as a software update. No hardware revision, no NRE, no silicon respin.
• No performance cliff. Because there is no partition between a performant engine and a programmable engine, operators run at full matrix throughput regardless of their novelty. The performance doesn’t degrade for new workloads.
• Silicon that compounds. The chip designed today does not depreciate as AI models evolve, it compounds. The same silicon can run models published years after tape-out at performance levels that match or exceed what a fixed-function accelerator achieves today.

This is why Quadric describes Chimera as a living platform. The stack is software. New AI capabilities ship as software updates to existing silicon and the chip doesn’t age the way a fixed-function accelerator ages.

Chimera scales from 1 TOPS to more than 6,400 TOPS in multi-chiplet configurations. It supports convolutional networks, transformers, state-space models, VLA world models, and whatever architecture the AI research community invents next year. All on the same silicon, using the same toolchain, and programmable by the SoC customer’s own software team without requiring Quadric’s involvement or a new licensing arrangement.

The competing solutions in this market will continue to iterate their accelerators, releasing second-generation and third-generation hardwired engines that are each optimized for the models that were popular at the time the accelerator was designed. Each iteration will be a short-term fix for a structural problem that cannot be solved by adding another layer of fixed function to an architecture built on the wrong foundation.

The SoC architect doesn’t have to wait for those vendors to find a better answer. A pergrammable solution already exists. It’s called Chimera.

The post Is Pergrammable A Word? appeared first on Semiconductor Engineering.