TI AM67A SoC: Cortex-A53, R5F and 4 TOPS Edge AI Architecture

The Texas Instruments AM67A is a heterogeneous vision SoC built on TI's Jacinto 7 architecture: four Cortex-A53 application cores, three separate Cortex-R5F cores across different domains, two C7x + MMA deep learning accelerators rated at up to 4 TOPS combined, a hardware ISP and a dedicated depth-and-motion accelerator. This article walks through what each block actually does, and through four things the datasheet says that most summaries of this part leave out. Every figure here comes from TI's published documentation — AM67x datasheet SPRSPA3B (March 2024, revised June 2026), the SPRUJB3D technical reference manual and the SPRZ575A errata. Spikedge has not independently benchmarked this platform for this article; where a number would require measurement, that is stated rather than estimated.

What is the TI AM67A?

The AM67A is TI's vision-oriented member of the AM67x family. TI's own positioning line describes it as an Arm Cortex-A53 4 TOPS vision SoC with an RGB-IR ISP for four cameras, aimed at machine vision, robotics and smart HMI.

Three names need separating before anything else:

• AM67 — the same family without the vision and deep learning accelerators. No C7x, no MMA, no VPAC, no DMPAC.
• AM67A — the part with them. This article's subject.
• J722S — in the datasheet's words, "the base part number for the preproduction superset device". The TRM and errata are published under this name, not under AM67A.

That last point has a practical consequence you will hit within a day of starting: a kernel patch, device tree file or forum answer about this silicon will almost certainly say j722s. That is not a different chip. It is the same silicon under the name TI uses for documentation and software.

Which AM67A?

"AM67A" is not one part. The datasheet's device comparison table lists four production part numbers across the family, and the differences change system design:

Source: TI, SPRSPA3B, Table 4-1.

So AM67A74 is an AM67A without a GPU — a reasonable choice for a headless vision node, and the wrong part if you are planning a Qt-based HMI. Only two AM67A order codes appear in the datasheet's production table, AM67A74AKGHIAMWR and AM67A94AKGHIAMWR, and both carry speed grade K.

The AM67A block diagram: four compute domains

The datasheet's block diagram divides the device into four areas: Application Cores, MCU Channel with FFI, Device Management and Run-time Management.

Cortex-A53

Up to quad Cortex-A53 at up to 1.4 GHz, sharing 512 KB of L2 with SECDED ECC; each core has 32 KB L1 D-cache with SECDED ECC and 32 KB L1 I-cache with parity.

Speed grade matters here. Grade J tops out at 1250 MHz, grade K at 1400 MHz. Both orderable AM67A parts are grade K, so 1.4 GHz is what you get — but the LPDDR4 ceiling moves with it too (3200–3733 MT/s on J, 3466–4000 MT/s on K).

This is where Linux, ROS 2, networking, logging and orchestration live. How to split work between this domain and the R5F cores is a design decision in its own right, covered in running Linux alongside Cortex-R5F on the AM67A.

Three R5F cores — two of which are yours

This is the single most misreported fact about the AM67A.

The datasheet lists three separate single-core Cortex-R5F cores, each up to 800 MHz:

The device description phrases it as "a Cortex-R5F MCU Island core and two Cortex-R5F cores for Device and Run-time Management" — wording that reads, on a fast pass, as though only one core is available to you. In practice two of the three are available to your firmware — the MCU-R5F and the MAIN-R5F; the third runs TI's power, clock and resource management firmware and ships inside the boot image.

Those two are not interchangeable. They sit in different domains, behind different interconnects and different reset and power arrangements, and code that comes up cleanly on one can stall on the other. Treat "which R5F" as an architectural decision, not a build flag.

Two further points that get assumed and are wrong:

• There is no lockstep. The TRM lists lockstep under "unsupported features" for all three R5F subsystems. "FFI" means freedom from interference — an isolation property. It is not two cores executing the same instruction stream and comparing results.
• Which core the SDK exposes is an SDK question, not a datasheet question. The datasheet points you twice to the PROCESSOR-SDK-AM67A Software Build Sheet for that answer.

C7x + MMA, and what "4 TOPS" is

Two deep learning accelerators, up to 4 TOPS total. Each pairs a C7x256V — a 256-bit vector DSP rated up to 40 GFLOPS at up to 1.0 GHz — with a Matrix Multiply Accelerator rated up to 2 TOPS at 8-bit precision, and each has 2.25 MB of L2 SRAM.

So the headline number decomposes cleanly: 4 TOPS is 2 × 2 TOPS of INT8 peak matrix throughput at 1.0 GHz. It is a peak capability figure, not a frame rate.

The more consequential detail is what the two accelerators buy you. A second accelerator block does not make one model run twice as fast; whether a single model can be split across both depends on what TI's compiler does with it. The clearest benefit of having two is running two independent inference streams in parallel — two cameras, two models. In a single-stream application the second block may sit idle.

GPU, video and display

• GPU: IMG BXS-4-64, 256 KB cache, single shader core, up to 50 GFLOPS, OpenGL ES 3.2 and Vulkan 1.2. Present on AM67A94, absent on AM67A74. OpenCL is not listed in the datasheet.
• Video: H.265 Main Level 5.1 High-tier and H.264 Baseline/Main/High Level 5.2, up to 4K UHD, up to 500 MP/s encode/decode (4K60).
• Motion JPEG: encode at 416 MPixel/s up to 4K UHD.
• Display: up to three displays over OLDI/LVDS, DSI or DPI; four display pipelines with hardware overlay, maximum two pipelines per display.

The vision subsystem

Two accelerators, doing different jobs.

VPAC carries the ISP and vision assist blocks. The datasheet's reference name for the AM67A instance is VPAC3L — the lite derivative, not the full VPAC3 found on larger Jacinto parts. Published capability: 600 MP/s ISP, 12-bit RGB-IR support, up to 16-bit RAW input, line support up to 4096, plus WDR, LDC, VISS and MSC.

DMPAC contains two engines: Dense Optical Flow and a Stereo Disparity Engine. Across TI's AM6xA line, DMPAC appears on AM67A and AM69A and not on AM62A or AM68A — which makes the AM67A the part that offers hardware depth and dense motion in the quad-Cortex-A53 class.

There is a counter-intuitive consequence worth stating plainly: the AM68A carries twice the TOPS of the AM67A but a lower published ISP throughput (480 MP/s against 600 MP/s) and no DMPAC. For a stereo-depth or optical-flow workload, the part with fewer TOPS can be the better fit. Choosing on the TOPS column alone hides that.

On the input side there are four CSI-2 receivers, each 4-lane D-PHY at up to 2.5 Gb/s per lane, plus one CSI-2 transmitter that shares its physical interface with MIPI DSI — you get camera output or a DSI display, not both.

Three constraints that shape the board

The feature list reads generously. Board design narrows it quickly.

SERDES budget. The datasheet's footnote is explicit: PCIe, USB 3.0 and SGMII share a total of two SERDES ports. You cannot have all three at full capability. On a design that wants NVMe storage, USB 3.0 and SGMII Ethernet, this is the first compromise you will make.

Pin multiplexing. The note above the comparison table states that feature availability is a function of shared IO pins and that SysConfig should be used to check. Up to 147 GPIO, 9 UART, 7 I²C, 5 SPI, 5 McASP, 4 CAN-FD and three MMC/SD interfaces do not all come out at once. Produce a pin budget before schematic capture.

Ethernet is two external ports. The datasheet says "3-port Gigabit Ethernet switch", then clarifies: one internal port and two external ports. TSN, IEEE 1588 (Annex D/E/F with 802.1AS PTP), an ALE-based classifier with 512 classifiers and hardware IP/UDP/TCP checksum offload sit behind those two ports.

On memory: LPDDR4 only — no DDR4, no LPDDR5 — over a 32-bit bus with inline ECC, up to 4000 MT/s and a maximum of 8 GB. The 32-bit width, not the data rate, is the real constraint once multiple cameras and inference run together.

Where the documents disagree with each other

Four cases where TI's own published sources do not line up. Each of them can cost you a design cycle.

1. eMMC HS400. The datasheet lists an 8-bit eMMC interface up to HS400. Errata advisory i2478 states that HS400 mode is not supported on silicon revision 1.0. Budget your boot time on HS200.

2. CSI recovery. Errata i2190 reports that the CSI receive interface can enter an unknown state after an incomplete or CRC-failed frame, requiring a module reset. On a multi-camera system under vibration this is a driver-level recovery path you must design, not an edge case you can ignore.

3. Operating temperature. The part-number nomenclature table and the package option addendum give different operating temperature ranges for the same order codes. For that reason this article publishes no single temperature range for the AM67A. If temperature grade is a design input, confirm it with TI directly rather than from any secondary source.

4. Custom code on the C7x. Footnote 5 of the device comparison table reads: "On the AM67A SoC, the Deep Learning Accelerator C7x + MMA are reserved for executing TI provided code, and are not available for custom code." TI uses the same wording in the AM68A and AM69A datasheets.

But the datasheet for TDA4VEN and TDA4AEN — the automotive siblings on the same silicon — carries no such footnote, and TI's own MCU+ SDK release notes for J722S list the C7x cores among supported cores with real-time OS options. The most plausible reading is that the footnote is a commercial restriction at the AM67A part-number level rather than a silicon-level block, but the enforcement mechanism is documented nowhere.

Practically: running your own trained model through TI's compilation flow onto the C7x is the supported, documented path and is not in question. Writing your own C7x kernel is. If your plan depends on the latter, resolve it with TI before committing — do not carry it as an assumption.

One more date discrepancy worth knowing: the errata revision available is April 2025 while the datasheet is June 2026. The errata is older than the datasheet. Confirm the current revision of both before starting board design.

Functional safety: read the revision history

For anyone evaluating the AM67A in a safety-relevant programme, this is the section that matters.

The revision history of SPRSPA3 Rev. B lists, among the changes from Rev. A, the removal of functional-safety feature statements, of the safety diagnostic block from the functional block diagram, of the "safety targeted" feature row from the device comparison, and of AEC-Q100, ASIL-B and SIL-2 references from the overview. The current comparison table gives "AEC-Q100 Qualified: No" for all four parts.

We are not going to interpret why. What can be said is narrower and more useful: a presentation, blog post or internal evaluation based on Rev. A may contain statements that are no longer in the datasheet. If a safety requirement is on your programme, take that question to TI with the current revision in hand.

Secure boot is an order code, not a software switch

The security block is substantial: hardware-enforced root of trust with backup-key switching, takeover, IP and anti-rollback protection, an Arm TrustZone-based TEE, extensive firewalling, secure watchdog/timer/IPC, RPMB support, a user-programmable HSM core with its own security DMA and IPC, and AES, SHA-2, DRBG and PKA acceleration.

But the comparison table marks "Device Security" as Optional, tied to the Device Type identifier in the part number. That field takes three ranges:

Read the order code AM67A94AKGHIAMWR and the security field is H — secure with production key. So the currently listed production parts do ship as secure variants. The point stands regardless: secure boot is decided at procurement, not in software. A team that prototypes on a base part and plans to "turn on secure boot later" is rescheduling both supply and verification.

Thermal design is a lifetime claim

The Power-On Hours table states the case more clearly than any thermal guidance could:

The 125 °C profile is defined as 5% at −40 °C, 65% at 70 °C, 20% at 110 °C and 10% at 125 °C. The datasheet also warns that one profile should be chosen and applied for the life of the application, and that mixing them is not recommended.

100,000 hours is roughly 11 years of continuous operation. 20,000 hours is about 2.3. That factor of five can be lost to an enclosure airflow decision. On an industrial product that promises a ten-year field life, thermal design is the lifetime claim.

TI publishes no power consumption figure in the datasheet; section 6.6 points to the Power Estimation Tool instead. That is the correct approach for this class of device — power is a function of which blocks run and at which operating point, not a single number.

Where the AM67A fits

TI's listed target applications: human-machine interface, patient monitoring, industrial PC, building security, off-highway vehicles, test and measurement, energy storage, video surveillance, machine vision, industrial mobile robots (AGV/AMR) and front camera systems.

Spikedge works on this class of system across Edge AI pipelines and TI platforms. Architecturally, the AM67A is a strong candidate when several of these are true at once:

• Multiple independent camera inputs. Four 4-lane CSI-2 receivers with a hardware ISP is not common in this power class.
• Vision and control in the same box. Moving a tight control loop into a separate domain without adding an external MCU cuts board cost and synchronisation complexity.
• Classical vision alongside deep learning. Stereo depth or dense optical flow in dedicated hardware rather than on the A53s or GPU.
• Industrial networking. Two external ports with TSN and IEEE 1588, plus four CAN-FD channels — two in the main domain and two in the MCU domain, which lets you separate control traffic from application traffic.
• Long service life with security requirements. Hardware root of trust, TrustZone, a programmable HSM and a 100,000-hour POH profile are coherent together — see secure boot and OTA lifecycle.

When the AM67A is the wrong choice

• You need to write your own accelerator kernels. See the unresolved contradiction above. If custom C7x code is load-bearing for your design, this is a question to settle before selection, not after.
• Your model falls outside TI's compilation flow. Large transformers, generative models or unusual operators will leave layers on the Cortex-A53. When that happens the 4 TOPS label stops describing your system. Verify that the target model compiles before choosing the platform.
• Your team is built on CUDA. The migration cost from a TensorRT-based workflow can exceed whatever the TOPS comparison suggests. The toolchains are not shared.
• You need materially more inference throughput. Eight cameras running several heavy models per frame is a different class of device. AM68A and AM69A target that band.
• You need PRU-ICSS. There is no PRU-ICSS on the AM67x. If your plan is to offload EtherCAT or PROFINET onto a programmable real-time unit, TI's AM64x and AM243x families are built for that; this one is not. We cover that split under industrial protocols.
• AEC-Q100 or a functional safety target is a requirement. The current comparison table says "No" for AEC-Q100 and Rev. B removed the safety statements.
• You need a GPU and ordered AM67A74. That variant does not have one.

Getting hands on

The most accessible way to work with an AM67A today is a development board. TI's own is the J722S EVM; BeagleY-AI and the T3 Gemstone O1 are community and third-party options built on the same silicon. We looked at how much of the SoC one of them actually exposes in our technical analysis of the T3 Gemstone O1.

The general rule applies to all of them: a development board's feature list is not the SoC's feature list. The SoC has four CSI-2 receivers; a board may route two. The SoC has four CAN-FD modules; a board may fit one transceiver. Make feasibility decisions from the datasheet and prototype plans from the board documentation.

What still has to be measured

This article contains no performance figures, because none have been measured here. The published TOPS, MP/s and MHz values are vendor specifications; they do not tell you what an application will do in the field. On an AM67A design heading for production, the minimum measurement set is:

1. Cold boot to application-ready time.
2. R5F interrupt latency and its worst-case distribution, reported as p50/p95/p99 rather than an average.
3. Linux-to-R5F IPC round-trip, idle and under load.
4. Which layers of the target model land on the accelerator and which fall back to the A53.
5. Camera-to-decision latency end to end — not inference time.
6. Sustained frame rate, and where it settles after the first thirty seconds.
7. Junction temperature at thermal steady state, against the chosen POH profile.
8. A53 utilisation when only the ISP and DMPAC are active.
9. Memory bandwidth pressure with inference and storage traffic running together.
10. Recovery behaviour after power loss.

When those numbers exist, they should be published with their conditions attached. A figure without its setup is not a figure — which setup, which method, measured by whom. That discipline is the basis of our hard real-time and RTOS work.

Frequently asked technical questions

How many TOPS is the AM67A? Up to 4 TOPS total, as two deep learning accelerators of up to 2 TOPS each at 8-bit precision and 1.0 GHz. That is peak matrix throughput, not a frame rate.

What is the difference between AM67A and AM67? AM67A has the C7x + MMA deep learning accelerators, the VPAC3L vision accelerator and the DMPAC depth-and-motion accelerator. AM67 has none of them. Note that ti.com's AM67 page can display "4 TOPS" because both parts share one datasheet feature block — the comparison table is authoritative.

Is J722S the same chip as AM67A? The datasheet describes J722S as the base part number for the preproduction superset device. The TRM and errata are published under that name. Production orders use AM67 or AM67A part numbers, and TI notes that software should constrain the features it uses to match the intended production device.

Does the AM67A run Linux? Yes. TI publishes a Processor SDK Linux for it, and mainline Linux carries device tree support for this silicon under the j722s name. The application cores are Armv8-A Cortex-A53.

How many Cortex-R5F cores can I actually use? Two of the three — the MCU-R5F and the MAIN-R5F. The wakeup-domain core runs TI's device management firmware. Confirm against the Software Build Sheet for the SDK version you use, and do not assume the two application cores behave identically.

Can I write my own code for the C7x DSP? The datasheet's footnote says the C7x + MMA are reserved for TI-provided code. TI's MCU+ SDK documentation for the same silicon and the datasheet for its automotive siblings suggest otherwise. Running your own trained model through TI's compilation flow is supported and documented; writing custom C7x kernels is unresolved and should be confirmed with TI.

Does the AM67A support TIDL? Yes — TI Deep Learning is the documented path to the C7x + MMA accelerators. Models are compiled on an x86 host into artifacts that the target then executes.

Does the AM67A have PRU-ICSS? No. The term does not appear in the AM67x datasheet, there is no corresponding node in the mainline device tree, and it is absent from the errata's module table. For PRU-based industrial protocol offload, look at AM64x or AM243x.

How many cameras does the AM67A support? At SoC level, four CSI-2 receivers of four lanes each, plus one CSI-2 transmitter that shares its interface with MIPI DSI. How many a given board exposes is a board decision entirely.

Summary

What makes the AM67A interesting is not its TOPS figure but the combination: four A53s, R5F cores in separate domains, a hardware ISP with RGB-IR, a dedicated depth and motion engine, a TSN-capable switch and four CAN-FD channels. For industrial systems where vision, inference and control meet in one enclosure, that is a coherent set.

The constraints are equally real: the accelerator sits behind a software gate whose boundary TI's own documents describe inconsistently, security is a procurement decision, the SERDES and pin budgets force early architectural choices, and the thermal profile is written directly into the rated lifetime. None of these are defects. They are the facts that belong in the architecture plan rather than in the surprise column.

If you are evaluating an AM67A-based system, the fastest route is to settle the workload partitioning and the measurement plan together. Our embedded architecture review is built around exactly those two questions.

Sources

1. Texas Instruments — AM67x Processors datasheet, SPRSPA3B, March 2024, revised June 2026 — https://www.ti.com/lit/ds/symlink/am67a.pdf
2. Texas Instruments — AM67A product page — https://www.ti.com/product/AM67A
3. Texas Instruments — J722S/TDA4VEN/TDA4AEN/AM67 Processor Silicon Revision 1.0 Technical Reference Manual, SPRUJB3D, August 2026 — https://www.ti.com/lit/zip/sprujb3
4. Texas Instruments — J722S/TDA4VEN/TDA4AEN/AM67 Processor Silicon Revision 1.0 Errata, SPRZ575 Rev. A, April 2025 — https://www.ti.com/lit/pdf/sprz575
5. Texas Instruments — PROCESSOR-SDK-AM67A — https://www.ti.com/tool/PROCESSOR-SDK-AM67A
6. Texas Instruments — AM68A product page (family comparison) — https://www.ti.com/product/AM68A

Documents accessed 5 September 2026. TI documentation is revised; verify the current revision directly before making a design commitment.