Andes Technology: RISC-V and AI IP for a custom inference chip

Andes Technology supplies the processor and AI building blocks that other companies integrate into their own chips. Its AndesAIRE portfolio connects a configurable inference accelerator with software tools and RISC-V CPU execution. This makes Andes relevant to teams designing edge AI silicon, where memory, supported operators and data movement can matter as much as arithmetic capacity. Evaluating it means tracing a real model through the intended hardware configuration. Buying IP is the beginning of a chip integration program, rather than a shortcut to a finished device.

01 / ProductProcessor IP and inference technology in one portfolio

AndesAIRE combines AnDLA accelerator IP, a neural-network software development kit and compute libraries for Andes processors. The company describes an execution approach in which suitable computation runs on the accelerator while other operations can use CPU software. This is the central product relationship: the accelerator handles a selected workload, while the processor remains involved in control and in operations that do not map to that accelerator.

The AnDLA I370 product page targets edge and endpoint inference and describes configurable compute and local-memory resources. It lists model categories including convolutional networks, recurrent networks, vision transformers and small language models, with framework inputs including PyTorch, ONNX and TensorFlow Lite. Those descriptions establish intended scope. They do not prove that every model within those categories maps fully to a selected I370 configuration or meets a particular device's latency requirement.

The offering is licensed design technology. A customer must integrate the chosen blocks with memory, interfaces, power management and its other chip functions. That separates Andes from a ready-made inference accelerator card or cloud inference service. It also changes the meaning of flexibility: the customer can influence the silicon architecture, but must take responsibility for verifying the resulting product and sustaining its software.

02 / AudienceThe relevant customer is designing the device

Andes is most interesting when a team wants control over a processor-based subsystem and has a reason to specialize local inference. Examples might include a sensor hub, industrial vision device or endpoint that cannot rely on a continuous cloud connection. These are possible applications, not reported customer implementations. Each demands different choices about model precision, available memory, response time and the proportion of work that stays on the CPU.

Teams should compare it with other IP approaches at the level where they are making a decision. SiFive is a contextual comparison for RISC-V processor design and ecosystem choices. Arm represents another established processor-IP route. The useful question is how the chosen core, tools, libraries and integration support fit the customer's existing engineering environment. An instruction-set preference alone does not settle that system-level question.

A team purchasing finished hardware is working at a different layer. It can evaluate a platform such as Axelera AI by deploying a model onto supplied hardware and software. With Andes IP, the same model evaluation also informs the hardware that will be built. That creates opportunities for customization, but it requires a chip program capable of acting on the findings.

03 / WorkflowFollow one model through the accelerator and CPU

Consider an illustrative smart-camera design with a trained detection model and a strict local-memory budget. Begin with a representative model export and evaluation dataset, including cases the product must handle reliably. Keep a reference output from the original software execution. Before any performance discussion, verify whether the transformed model preserves the application's required behavior; a smaller or faster model is not useful if it changes important detections.

The AndesAIRE NN SDK describes model analysis, pruning, quantization and deployment tooling. Its NNPilot tools include hardware-aware optimization, operator fusion, memory scheduling and performance estimation, with runtime generation for the accelerator driver and NN libraries. For the proposed camera, the meaningful deliverable is a report showing the transformed graph, its memory needs and the execution destination of each significant operation. An estimated total should be traceable to those choices.

Then inspect fallback behavior. An unsupported operation may be computable by CPU software, but crossing between accelerator and CPU can involve synchronization and memory movement. Ask which tensor layouts each side expects and whether additional conversions are needed. Test a model variant that stresses the fallback path rather than only the example that maps cleanly. This distinguishes functional support from an architecture that remains efficient under the actual product workload.

Next compare hardware configurations. Increasing compute resources without sufficient local memory or data delivery may simply move the bottleneck. The I370 page describes configurable resources and supported numerical formats; treat those as configuration choices to explore, not a single fixed chip specification. Compare candidate configurations using the same model transformations, external-memory assumptions and software versions. A peak-operation figure alone cannot establish end-to-end camera performance.

Finally connect inference to the rest of the product. Include image acquisition, preprocessing, output handling and recovery from an overloaded frame queue. Measure on representative implementation hardware when available and preserve the assumptions used before then. This workflow is proposed editorial analysis. Sequenced has not licensed the IP, synthesized a customer design or independently benchmarked Andes silicon.

04 / PricingLicensing scope matters more than a nominal entry price

No public numerical license tariff was found on the reviewed product and contact pages as of October 21, 2026. Andes directs product and business inquiries to its contact process. The evaluation should request a quotation for a defined processor, accelerator configuration and software package. An architecture-specific proposal is necessary to understand what the customer may build and which integration support it receives.

One explicit boundary appears on the AX46MPV product page: Andes Custom Extension, or ACE, is separately licensable. Do not assume that processor customization is automatically included with a core license. Ask how optional features, tool updates, model-library support and project reuse are treated. The public pages do not establish the terms for a particular customer's tapeouts, derivative chips or continuing support, so those should remain contractual questions rather than inferred entitlements.

05 / DistinctionsVector compute and custom instructions broaden the design space

The AX46MPV page describes a configurable 64-bit RISC-V vector multicore processor supporting the RISC-V Vector extension and Linux-capable memory management. That creates a separate avenue from assigning every AI operation to a dedicated accelerator. A vector processor can be relevant to functions that need programmable arithmetic or change over time. The right balance depends on the model and surrounding application, not on a universal preference for fixed-function or programmable computation.

ACE provides a mechanism for adding scalar or vector instructions to supported Andes processors. The official material describes a definition flow using instruction descriptions and hardware logic, with tooling to generate associated processor and software-development extensions. This is hardware and toolchain customization. It should not be confused with asking a conversational assistant to optimize source code, and it requires verification of both the instruction behavior and its software use.

A disciplined project would consider a custom instruction after profiling exposes a recurring bottleneck that existing instructions and compiler choices do not resolve adequately. The candidate instruction needs a precise semantic definition, corner-case tests and a realistic utilization estimate. Adding a specialized operation that the application rarely executes can create maintenance cost without meaningful system benefit. Andes' customization capability is valuable when the customer can substantiate the need and own the resulting design decision.

06 / QuestionsQuestions a useful evaluation should answer

Request an operator-coverage report for the exact model and tool release, together with fallback details. Check whether quantization affects the application's important outputs and whether calibration data resembles field inputs. A published list of model families is an introduction to an evaluation, not a substitute for it. For a language or vision-language workload, also examine intermediate-state storage and the growth of memory demand under realistic input sizes.

Clarify the hardware evidence behind any proposed performance target. Is it a software estimate, a synthesis result under stated constraints, an FPGA demonstration or a measurement on silicon? Each can be useful, but they answer different questions. Compare power and latency using consistent boundaries: whether external memory, CPU fallback and preprocessing are included can change the practical interpretation of a result.

Also establish who maintains the deployed software stack. The model may evolve after the chip is fixed, and compiler or runtime updates may alter its mapping. A customer needs a process for validating those changes and keeping a known-good deployment reproducible. The reviewed public pages describe the tools and IP, but they do not establish a guaranteed future compatibility policy or every support obligation for an individual license.

07 / DecisionChoose the level of specialization deliberately