Is AMP the same as heterogeneous computing?

No. Heterogeneous computing emphasizes different kinds of processing resources. AMP emphasizes asymmetric roles or management. They often occur together, but neither term fully specifies the other.

Can AMP and SMP coexist?

Yes. A group of cores can run one SMP operating system while separate processors run other environments in an AMP arrangement.

Does AMP require a permanent central controller?

Not as a universal rule. Some designs use a host to start and manage other processors, while the precise authority and communication structure are design choices.

AI Glossary / Data engineering and architecture / Intermediate

Asymmetric multiprocessing

Definition

Asymmetric multiprocessing, or AMP, is an arrangement in which processors or cores have different assigned roles or operate under separate management rather than being treated as one interchangeable scheduling pool. It is often used to combine application processing with specialized or real-time work.

What it means

A device may need to run a user interface, communicate over a network and respond to sensors on a tight schedule.

In a common embedded arrangement, one processor runs a general-purpose operating system while another runs a real-time operating system or dedicated firmware. The processors communicate through a defined interface. Other asymmetric arrangements are possible, including different roles on similar processors.

Contrast this with symmetric multiprocessing, where one operating-system instance commonly schedules tasks across a set of cores as a shared processing pool. A larger system can combine the two: an SMP group can run an application environment while separate processors perform AMP roles.

How it works

Engineers partition the workload and decide which processor owns each responsibility. They define startup, shutdown, memory access, peripheral ownership and communication between the execution environments.

A host may load firmware onto another processor and manage its lifecycle. A message interface can carry commands, measurements and completion notifications. Shared-memory buffers can carry larger data, but both sides need rules for ownership, visibility and reuse.

Separate operating environments do not automatically isolate every shared resource. Processors may contend for memory bandwidth, buses or peripherals. Cache management and memory-ordering requirements depend on the hardware and software arrangement.

The partition can improve predictability for selected tasks, but it can also leave one processor overloaded while another is idle. Moving work between them may require a design change rather than a routine scheduling decision. Fault handling must specify what happens if one environment restarts while another continues using shared state.

Three practical examples

A camera device assigns image-control firmware to a dedicated processor while a general-purpose environment runs the user interface and network services.
A speech device offloads signal-processing work to a DSP and exchanges audio buffers with the main application processor.
An industrial gateway separates regular sensor sampling from analytics and remote-management tasks, then validates the communication boundary.

Think of it this way

Think of a small team with assigned specialists: one handles incoming calls while another operates a machine. Their responsibilities are clear, and they pass requests through an agreed procedure.

That division does not mean they never share tools or wait for one another. Likewise, separate processors can still contend for memory or depend on messages. The analogy explains fixed roles, not a guarantee that every specialist is always busy or that one failure cannot affect another.

Worked example

Checking the communication budget

Imagine an invented device with a sensor processor and an application processor. The sensor side produces 1,000 messages per second, each containing 32 bytes of payload. The offered payload rate is 32,000 bytes per second.

Suppose the application side can sustainably process only 800 messages per second. The backlog grows by 200 messages per second, or 6,400 payload bytes per second. An initially empty buffer with room for 100 messages fills after 100/200 = 0.5 seconds under these steady assumptions.

Giving the sensor task its own processor did not resolve the slower receiving stage. A larger buffer would delay overflow, not remove the sustained rate mismatch.

Possible design responses include reducing the reporting rate, combining measurements where acceptable or increasing the receiver's processing capacity. Each changes a requirement or resource allocation and must be evaluated. The calculation excludes headers and bursts; real capacity planning must include them. It illustrates an AMP interface constraint, not measured performance of a particular processor.

Illustrative case study

A fictional manufacturer separates a machine's sampling loop from its dashboard application. The sampling processor continues collecting data during a dashboard restart, which initially appears to demonstrate complete independence.

A longer test reveals that the shared queue fills while the dashboard is unavailable. The team defines which measurements may be dropped, adds sequence numbers and specifies a recovery handshake before the restarted application consumes old buffers.

It also tests contention for shared memory under peak load. The fictional case shows why separate execution environments still require coordination.

Common misconceptions and mistakes

AMP does not necessarily mean that every processor uses a different instruction set.
Having processors with different performance characteristics does not, by itself, specify the software management model.
Separate operating systems do not automatically provide complete memory or fault isolation.
Dedicated processing does not guarantee a real-time deadline without timing analysis.
Spare capacity on one processor may not be directly available to work assigned to another.

Business use

AMP can be useful when a product combines workloads with different timing, software or hardware requirements. The decision should account for integration and lifecycle costs, not only processor speed.

Review communication contracts, firmware compatibility, update procedures and ownership of shared devices. For an edge-AI system, determine which processor performs acquisition, preprocessing, inference and control, and what happens when an inference result arrives late. Measure the complete chain under load. A responsive model alone is not enough if its input queue overflows or a downstream control task waits for an unavailable application service.

Check your understanding

A producer generates 500 messages per second while its consumer handles 500 on average. Does that alone prove a small buffer cannot overflow?

Answer: No. Bursts, scheduling pauses and variable processing times can temporarily create a backlog. Capacity and timing must be checked beyond the average rates.

Related terms

Symmetric multiprocessing
Shared memory
heterogeneous computing
real-time operating system
DSP
interprocessor communication
embedded system

Learn next

Draw an embedded application's processor assignments and every crossing between them. For each crossing, specify message rate, buffer capacity, ownership and restart behavior, then test the slowest and busiest plausible cases.

Sources

Sources: Linux kernel, Remote Processor Framework: https://www.kernel.org/doc/html/latest/staging/remoteproc.html . Linux kernel, Remote Processor Messaging Framework: https://docs.kernel.org/staging/rpmsg.html . The AMP configuration, lifecycle and messaging discussions were reviewed. The producer-consumer calculation and manufacturer case are original teaching examples, not a timing guarantee for a particular platform.

Previous: Asymmetric cointegration Next: Asymmetric numeral systems