CEVA licenses the AI processing architecture inside custom chips

CEVA supplies silicon and software intellectual property that other companies integrate into chips. Its NeuPro neural-processing architectures and NeuPro Studio tools address the hardware beneath an AI product. The reader’s decision is therefore whether to license and integrate an inference architecture, not which off-the-shelf accelerator board or cloud subscription to buy.

01 / ProductNano and M address different scales of inference design

NeuPro-Nano is described as a self-contained programmable NPU for embedded machine learning. CEVA says it can execute neural networks, feature extraction, signal processing and control code without requiring a separate host CPU or DSP for that processing role. That describes the IP core’s architecture; a finished product will still need its other interfaces and system functions.

NeuPro-M addresses larger edge and generative-AI workloads with scalable processing configurations and support for mixed numeric precision. The two families should not be collapsed into one performance claim. The intended model, memory traffic and surrounding system determine which architecture is worth evaluating.

NeuPro Studio connects trained models to these NPUs through optimization, graph compilation, simulation and emulation. It offers a route using CEVA-provided models and a bring-your-own-model route. A model that imports successfully still needs to be mapped, profiled and checked for quality on the chosen target configuration.

02 / AudienceFor teams making a silicon architecture decision

A strong reader is a semiconductor team designing an always-listening audio device or an industrial sensor chip. Such a team can influence memory, clocking, interfaces and the NPU configuration. It is choosing a component of a silicon design whose consequences will persist beyond one model release.

This is a poor starting point for a software team that only needs to deploy an application next month on an existing computer. IP licensing introduces integration, verification and manufacturing responsibilities. Those responsibilities can be justified by scale or product requirements, but they are not removed by an easy-to-use model toolkit.

Arm is relevant when considering the wider processor-IP composition of a chip. Synopsys provides another perspective on IP and design tooling. The practical comparison is which architecture and development relationship fit the silicon program, not which vendor has the most impressive isolated AI demonstration.

03 / WorkflowProposed workflow: select an inference block for an audio device

Consider a proposed low-power audio chip that must recognize a bounded set of acoustic events while maintaining its other signal-processing work. Start by listing the required events, the audio front end, the latency target and the expected active duty cycle. The model team and chip architects need the same workload definition before either can make a useful resource estimate.

Create representative reference models and evaluation audio before requesting a hardware configuration. Include background speech, music, silence and overlapping events where they belong to the intended environment. Preserve a quality threshold for each important class. One aggregate accuracy figure can conceal failure on the event that matters most to the product.

Determine whether the task belongs in NeuPro-Nano’s embedded-ML scope or requires a larger architecture. CEVA describes Nano as combining control and signal-processing capability with neural-network execution. Investigate that claim with the actual feature-extraction and postprocessing code, rather than assuming all non-network work disappears automatically into the NPU.

Use the Studio evaluation to import the candidate model and inspect supported operations. Quantization and compression should be treated as transformations to validate. Compare outputs on difficult audio before and after each material change. If a reduced-precision model loses the distinction between similar events, its smaller footprint alone does not make it acceptable.

Build a workload timeline that includes audio input, feature preparation, inference and event handling. A model that finishes quickly in isolation may compete with another task at exactly the wrong time. For an always-listening device, transitions between idle and active work are part of the workload, not an implementation detail to be considered after the architecture is selected.

The Studio product description includes partitioning code across processing elements and profiling in Arch Planner. Use that capability to examine alternative mappings and memory assumptions. Keep separate results for the network, preprocessing and the complete pipeline. A proposed resource saving should be traceable to the part of the workload that changed.

Ask the silicon team to evaluate realistic memory movement. Model weights, intermediate tensors and input buffers have different lifetimes and access patterns. A configuration that appears attractive when everything fits close to the processor may behave differently with external memory traffic. Record those assumptions with every power or throughput estimate.

Carry more than one model into the architecture study. The production model may change after additional field data arrives, and a hardware design has a longer lifetime than a training experiment. Include a plausible larger candidate and a different operator pattern. This is a practical way to investigate headroom without claiming that any architecture is future-proof.

Use simulation and emulation results to guide the decision, then define what must be checked in implemented silicon. Clocking, physical design and the rest of the system affect the final result. Keep pre-silicon estimates clearly labeled and require a later comparison against the actual device rather than presenting them as measured product performance.

Finally establish how the product team will reproduce and update the compiled model. The compiler version, runtime libraries and permitted software distribution need to fit the maintenance plan. A custom-chip program should know which party owns each artifact and who can diagnose a regression after the initial integration work ends.

04 / PricingLicensing is negotiated around a silicon program

The public pages do not establish a complete license price, royalty schedule or a self-service entitlement for every tool. Those items should be requested in a proposal for the intended program. The article does not infer a particular royalty rate or commercial commitment from the fact that CEVA licenses IP.

CEVA’s 6 July 2026 announcement reports a NeuPro-M licensing agreement with an unnamed major U.S. software and AI platform company. It supports current commercial activity but does not identify the customer, disclose the contract value or prove a shipped end product. None of those missing facts should be guessed.

For the audio-chip project, compare total program effort rather than license cost alone. Reusing an architecture can reduce some design work while introducing a dependency on the associated tools and support. The useful proposal explains how the team moves from evaluation to integration and then maintains the result over the product’s lifetime.

05 / DistinctionsThe customer can shape the hardware around the workload

CEVA’s company overview describes a broader portfolio spanning connectivity, sensing and edge AI. That IP portfolio connects multiple functions required by an intelligent device. The company operates below the application layer, where decisions about computation and memory can shape many future devices.

Our assessment is that NeuPro’s value should be evaluated as a hardware-software combination. An NPU feature is useful only when the model tools can map the real workload to it and the silicon implementation preserves the expected benefit. This is why the proposed study carries representative models and surrounding signal code together.

06 / QuestionsKeep vendor specifications separate from implemented results

Which numeric format and sparsity assumptions support a performance figure? CEVA’s product pages contain several efficiency and throughput claims with differing scopes. This blueprint does not combine them into a universal ranking. Request a result for the model, configuration and memory system under consideration.

How much flexibility remains after implementation? A programmable core offers options, but supported operators, available memory and physical resources still constrain future models. Test plausible model changes during architecture selection rather than relying on a general claim about scalability.

What support accompanies the licensed implementation? Establish access to compilers, debugging resources and maintenance fixes for the program’s expected lifetime. The product team needs a practical route to investigate a wrong result, not only a license to include a processing block.

07 / DecisionChoose CEVA when custom silicon is already the right product path

The next useful step is a bounded architecture evaluation with representative models, signal code and memory assumptions. Its outcome should be an explained tradeoff between quality, resources and integration effort. If the product does not justify a silicon program, choose an available device platform first and revisit IP licensing only when the hardware requirement becomes concrete.