Qualcomm Dragonwing Q-2390 vs IQ-2390: A78, NPU, TSN and a RISC-V Core

Most edge AI silicon announcements chase bigger numbers. The Dragonwing Q-2390 and its industrial sibling, the IQ-2390, do the opposite: Qualcomm has put a modest quad-core CPU, a 1.1 TOPS Hexagon NPU, two Gigabit Ethernet ports with Time-Sensitive Networking, and an optional RISC-V real-time core into a small, long-lived part aimed at the large middle of the IoT market, the devices that need a little vision, a little audio intelligence and deterministic I/O, not a data-centre in a box.

That matters now because the industry has spent two years debating whether edge AI means ever larger modules, while the shipping volume sits in point-of-sale terminals, access controllers, HMIs, gateways and compact machine-vision heads. A part that handles those jobs, with a stated longevity commitment to 2036, changes the make-or-buy math for a lot of embedded teams.

By the end you will know exactly what the two parts share, where they differ by part number, what 1.1 TOPS can and cannot do, how to partition work between the Cortex-A cores and the RISC-V core, and how to decide between Q and IQ. We also flag what Qualcomm has not disclosed.

What this covers: the silicon and SKU matrix, the mixed-criticality architecture, TSN and the NPU in practice, trade-offs, a selection checklist, and an FAQ.

Context and Background

Qualcomm announced the Q-2390 and IQ-2390 on 1 September 2026, ahead of IFA 2026 in Berlin. The Q-2390 targets commercial and consumer products: retail point-of-sale, kiosks, access control, smart appliances, smart agriculture, home robots, fitness equipment and enterprise terminals. The IQ-2390 is the first member of a new IQ2 Series for industrial edge AI, positioned beneath the existing IQ6, IQ8, IQ9, IQX and IQ10 series, and aimed at industrial automation, oil and gas, utilities and energy. Sources for these statements are the Qualcomm press release and independent coverage from CNX Software and Robotics 24/7.

The positioning is worth pausing on. The Dragonwing brand is Qualcomm’s rebranded IoT and industrial line, and until now the practical conversation around it centred on high-end parts that compete with NVIDIA Jetson-class modules. We covered that end of the market in Jetson T3000 vs T4000 vs T5000 Thor module selection. The 2390 pair sits at the opposite end: a 1.1 TOPS class device where the competition is not Jetson but NXP i.MX 8M and 9-series parts, TI Sitara and AM6x devices, Renesas RZ, MediaTek Genio and Rockchip, plus the occasional microcontroller with an NPU.

Three details separate this launch from a routine SoC refresh. First, the optional SiFive E61 RISC-V real-time core makes Qualcomm one of the larger vendors to ship a RISC-V core for control tasks beside Arm application cores inside an IoT SoC. Second, TSN is on the Ethernet MACs of a low-cost part, not reserved for premium industrial silicon. Third, the longevity commitment to 2036 is the sort of promise industrial buyers actually underwrite product roadmaps with.

A caution about sources. Everything in this article about the silicon comes from Qualcomm’s announcement and the coverage that reproduces its product brief. The product page details, process node, certifications, pricing and board support package maturity were not available in the material we could verify, and we label those clearly rather than guessing. Evaluation kits are expected in early 2027, so no independent benchmark exists yet, and anything numeric about performance below is either derived arithmetic or marked illustrative.

Why the sub-2-TOPS tier matters

The vision-AI conversation is dominated by tens and hundreds of TOPS, yet most deployed edge devices run models that fit in a few megabytes: person detection, barcode and QR localisation, anomaly classifiers on vibration or current signatures, wake-word and keyword spotting, simple segmentation. These workloads care far more about idle power, boot time, I/O determinism and bill-of-materials cost than about peak throughput. A SoC that adds an NPU to an otherwise conventional application processor lets a team keep one chip, one software stack and one supply chain, instead of pairing a microcontroller with a separate accelerator.

Dragonwing Q-2390 Architecture: What Is Actually in the Silicon

The Dragonwing Q-2390 and IQ-2390 share one platform: a quad-core Arm CPU (one Cortex-A78 plus three Cortex-A55), an Adreno 704 GPU, an optional Hexagon NPU of up to 1.1 TOPS, an optional SiFive E61 RISC-V real-time core at up to 600 MHz, dual-channel 16-bit LPDDR4x, and two Gigabit Ethernet ports with TSN. They diverge in package, temperature grade, and cellular and GNSS options.

Figure 1: Block-level view of the Dragonwing Q-2390 and IQ-2390 platform. Optional blocks, present only on AB part numbers, are the NPU, the audio DSP and the RISC-V core.

Figure 1 groups the platform into four domains: application compute, acceleration, the real-time island, and I/O. The long-description version is simple. The application cluster and GPU talk to shared LPDDR4x through the memory controller; the NPU and audio DSP sit beside them as optional accelerators; the RISC-V core runs its own firmware on 768 KB of local memory; and the Ethernet, camera, display, PCIe and storage interfaces hang off the interconnect.

The CPU cluster: one big, three small

Qualcomm lists one Cortex-A78 and three Cortex-A55 cores, with a 512 KB L3 cache, clocked up to 1.5 or 1.9 GHz depending on the SKU. The 1+3 arrangement is a deliberate choice. The A78 is an out-of-order core that handles latency-sensitive foreground work, such as a UI thread, a vision pre-processing step, or a protocol stack burst. The three A55 cores are in-order efficiency cores that carry the background services, a container runtime, a field-bus gateway and logging.

For embedded developers the practical consequence is that the scheduler needs guidance. With a single big core, anything pinned to it competes with everything else you consider high priority. A sensible pattern is to leave the A78 to the main application process, pin interrupt-heavy drivers and network queues to an A55, and use cgroup cpusets or taskset to keep batch work off the big core. Qualcomm’s brief does not state per-core cache sizes or whether the cores are arranged in one or two clusters, so treat those as unverified until the technical reference manual is available.

The Adreno 704 GPU runs up to 1.1 GHz, and the display path uses an Adreno 921 display processing unit with a 4-lane MIPI DSI output up to 1080p at 60 fps. This is a modern but modest graphics stack, appropriate to an HMI, a kiosk or a smart display, which is exactly the target.

The Hexagon NPU: 1.1 TOPS, optional, and only on AB parts

The NPU is a Qualcomm Hexagon block rated at up to 1.1 TOPS, and the same AB parts also carry a Hexagon V66 audio DSP at up to 1.1 GHz. Two points here deserve emphasis because they are easy to miss in a skim of the announcement. The NPU is not present on every part number, and “TOPS” as quoted by vendors is a peak figure for a particular integer precision, typically INT8, under ideal conditions. Qualcomm’s brief does not state the supported data types, so we do not claim them.

What does 1.1 TOPS buy you? As illustrative arithmetic only: a small image classifier of the MobileNet class needs on the order of a billion operations per inference at 224×224 input. At a sustained utilisation of, say, a quarter of peak, which is an assumption and not a measured number, the NPU could in principle sustain on the order of hundreds of such inferences per second. Real throughput is bounded by memory bandwidth, operator support, quantisation quality and the software runtime, so plan to measure on the evaluation kit once it ships.

Memory, storage and I/O

Memory is dual-channel 16-bit LPDDR4x at up to 1.8 GHz. If that figure is the I/O clock, the interface is double data rate and the combined 32-bit bus gives a theoretical peak near 14 GB/s (1.8 GHz x 2 transfers x 4 bytes). That is a derived number, not a Qualcomm claim, and sustained bandwidth will be materially lower once the CPU, GPU, display scan-out and camera ISP contend for it. Display scan-out at 1080p60 and a pair of camera streams already consume a visible share, which is why memory bandwidth, not TOPS, is usually the real limit in this class.

Storage is eMMC 5.1 plus SD 3.0. Expansion is PCIe 2.0 x1 and USB (a USB 3.1 Type-C or Micro USB port and a USB 2.0 Type-C port). The I/O budget is generous for the class: ten QUP serial engines for UART, I2C and SPI, and 155 GPIO. Camera input is up to two 4-lane MIPI CSI ports, supporting a 13 MP dual-camera or a 25 MP single-camera setup with zero-shutter-lag capture at 30 fps. Video decode reaches 1080p30 for H.264, H.265 and VP9, and encode reaches 1080p30 for H.264 and H.265.

Note the ceilings. 1080p30 means this is not a part for 4K video analytics or multi-stream NVR work. It is a part for one or two cameras, which is exactly how most compact vision heads and kiosks are built.

Connectivity: the Q-2390 gets radios, the IQ-2390 does not

Both parts have two Gigabit Ethernet ports with TSN. Wi-Fi 5 and Bluetooth 5.0 or 5.1 come through companion WCN3950 and WCN398x chips. Optional LTE Cat 4 and GNSS (Gen 9 VT v4-Lite, GPS L1) exist only on the Q-2390 M-suffix parts. The IQ-2390 has neither modem nor GNSS, which fits an industrial design philosophy where cellular is typically a separately certified module.

Q-2390 vs IQ-2390: The SKU and Part Number Matrix

The cleanest way to understand the family is by part number, because the marketing names hide the real decisions. The Q-2390 comes in four orderable variants, CQ2390S-0-AA, CQ2390S-0-AB, CQ2390M-0-AA and CQ2390M-0-AB. The IQ-2390 is a single part, IQ2390-AB. Two suffixes drive everything: AA versus AB, and S versus M.

Part number	Family	NPU	RISC-V core	Audio DSP	LTE Cat 4 and GNSS	Temp range	Package
CQ2390S-0-AA	Q-2390	No	No	No	No	-30 to +95 C	12 x 12 mm
CQ2390S-0-AB	Q-2390	Yes	Yes	Yes	No	-30 to +115 C	12 x 12 mm
CQ2390M-0-AA	Q-2390	No	No	No	Yes	-30 to +95 C	12 x 12 mm
CQ2390M-0-AB	Q-2390	Yes	Yes	Yes	Yes	-30 to +115 C	12 x 12 mm
IQ2390-AB	IQ-2390	Yes	Yes	Yes	No	-30 to +115 C	21.3 x 18.4 mm

Source: CNX Software’s reproduction of the Qualcomm product brief. The AA/AB split is stated as: AB adds the NPU, the RISC-V core and the Hexagon V66 audio DSP. The S/M split is stated as: M adds LTE and GNSS. Verify against the official product brief before ordering.

What the matrix tells you

First, the AB suffix is the real “AI and real-time” tier. If you want the NPU or the RISC-V real-time core, you must buy an AB part, and on the Q-2390 that also lifts the temperature ceiling from +95 C to +115 C. That makes the AA parts the cost-optimised, thermally less capable variants, suited to indoor consumer products.

Second, the packages are radically different. The Q-2390 is a 12 x 12 x 0.92 mm part on a 0.4 mm ball pitch, which implies fine-pitch PCB technology, microvias and typically a six-or-more-layer board. The IQ-2390 is a 21.3 x 18.4 x 1.82 mm part on a 0.8 mm pitch, which is far easier to route and assemble, and is more tolerant of the vibration and thermal cycling that industrial products face. Qualcomm’s description of a ruggedised package with vibration and shock tolerance for the IQ-2390 is consistent with that larger, coarser-pitch design. The practical effect is that a team can often move from a four-layer to a simpler stack-up with the IQ-2390 and avoid high-density-interconnect fabrication, at the cost of board area.

Third, the IQ-2390 is only offered in the AB configuration. There is no “industrial without NPU” part, so buyers get the full feature set, including the RISC-V core and TSN, whether or not they use the NPU.

Fourth, and a point that is easy to get wrong, TSN is described in the brief as part of the shared platform with two GbE ports; Qualcomm’s commercial messaging emphasises it more for the IQ-2390. Whether every Q-2390 part number exposes the full TSN feature set to software is not stated, so confirm per part number.

Decision matrix: which part for which product

Figure 2: A selection flow for the Dragonwing Q-2390 and IQ-2390 family. The first questions are cellular, then NPU or real-time core, then thermal grade and package.

Figure 2 turns the matrix into questions. The flow asks about cellular first because it is the only branch that cannot be changed later without a respin: only Q-2390 M parts carry LTE Cat 4 and GNSS. If the answer is yes, you are in Q-2390 M territory and the remaining question is AA or AB. If the answer is no, you ask whether you need the NPU or the real-time core, then the thermal environment, and finally whether board density or ruggedness drives you towards the 12 mm or the 21 mm package.

Product type	Likely part	Reasoning
Indoor smart appliance, no AI	CQ2390S-0-AA	Lowest-cost variant, +95 C is enough
Retail kiosk with camera analytics	CQ2390S-0-AB	NPU for vision, Wi-Fi for connectivity
Asset tracker or outdoor terminal with cellular	CQ2390M-0-AB	LTE and GNSS, higher temperature grade
Industrial gateway or HMI with TSN	IQ2390-AB	Coarse-pitch package, +115 C, no modem needed
Compact machine-vision head	IQ2390-AB	NPU plus deterministic Ethernet and a real-time core

These are our recommendations from the published specifications, not Qualcomm guidance. The right answer in a given project depends on certifications and supply terms we cannot see.

Mixed Criticality: Partitioning Work Between Cortex-A and the RISC-V Real-Time Core

The most architecturally interesting feature of the AB parts is the SiFive E61 RISC-V core, running at up to 600 MHz with 768 KB of memory, which Qualcomm supports with Zephyr RTOS while the Cortex-A cores run Android, Yocto-based Linux or Ubuntu. This is the classic asymmetric multiprocessing (AMP) pattern: a rich operating system on one side for networking, UI, containers and AI runtimes, and a small deterministic firmware on the other for tasks where a missed deadline is a defect.

The direct-answer version: use the RISC-V core for anything that must respond in microseconds and must keep responding when Linux hangs, updates or reboots; use the Cortex-A cores for everything else, and connect the two with a narrow, well-defined message channel.

Figure 3: A mixed-criticality exchange on a Dragonwing AB part. Linux publishes setpoints, the RISC-V core closes the fast loop and reports status, and a watchdog path survives a Linux crash.

Figure 3 shows the pattern. Linux sends a setpoint or configuration over a shared-memory mailbox. The RISC-V firmware samples inputs, runs the control loop at a fixed period, drives outputs, and posts status back. If Linux stops responding, the real-time core detects the missed heartbeat and moves outputs to a safe state on its own. That last step is the entire point of the partition.

What 768 KB buys you

768 KB is generous for a Zephyr image with a control loop and a handful of drivers, but it is not an application processor. A realistic budget is a few hundred kilobytes for the kernel, drivers and stack, and the remainder for control code, buffers and a small message queue. It is not a place for a TCP/IP stack with TLS, a JSON parser with large documents, or any model inference.

Qualcomm’s brief does not state which peripherals the RISC-V core can reach directly, how interrupts are routed to it, whether it can access the TSN MAC’s timestamp unit, or what the inter-processor communication mechanism is. Those answers decide whether the core is a true real-time I/O engine or merely a housekeeping microcontroller. Treat them as the first questions to put to your Qualcomm field engineer.

Zephyr, Linux and the shared-memory contract

Using Zephyr on the real-time core is a sensible choice. Zephyr has a mature scheduler, a device-tree driven hardware description, a large driver ecosystem and an open governance model. From the Linux side, the usual pattern for AMP is the remoteproc and RPMsg framework, where Linux loads the firmware, starts the remote processor and exchanges messages through virtio rings in shared memory. Whether Qualcomm’s BSP supports remoteproc for the E61 is not stated in the sources we can verify, so we label it unverified.

Regardless of the transport, design the contract carefully:

Keep messages small, versioned and fixed-size, so the real-time side never allocates.
Use a sequence number and a heartbeat, so each side can detect a dead peer.
Define safe states explicitly, and make the real-time core responsible for entering them.
Never let the real-time loop block on anything Linux controls, including shared locks.
Persist nothing on the real-time side that needs Linux to flush, and plan how firmware is updated and authenticated.

Where the boundary goes wrong

The commonest failure in AMP designs is boundary creep. A team starts with a clean split, then moves a protocol decoder onto the small core for latency, then a small state machine, then logging, until the “real-time” firmware is a second operating system with its own bugs. Resist this. The rule we use is that the real-time core owns anything whose worst-case latency must be bounded by hardware and a short, auditable code path, and nothing else.

A second failure is assuming that two cores means freedom from interference. Both cores share the memory controller. A burst of GPU, camera and display traffic can add latency to real-time core accesses to DDR, which is why real-time code should live in its local 768 KB wherever possible. Qualcomm gives no memory quality-of-service details in the public material, so measure worst-case latency under full load before you trust any deadline.

TSN on a Cost-Optimised SoC: What It Gives You and What to Verify

Both parts expose two Gigabit Ethernet ports with Time-Sensitive Networking. TSN is a family of IEEE 802.1 standards that adds deterministic, bounded-latency delivery to standard Ethernet. For an edge SoC, the two ports matter as much as the TSN label: two ports let the device sit in a line or ring topology as a bridge-less end station, or serve as a small two-port switch endpoint with software bridging, without an external switch chip.

The standards that matter most in industrial deployments are IEEE 802.1AS for time synchronisation, IEEE 802.1Qbv for time-aware scheduled traffic, IEEE 802.1Qci for per-stream filtering and policing, IEEE 802.1CB for frame replication and elimination for redundancy, and IEEE 802.1Qbu with 802.3br for frame pre-emption. Which of these the Dragonwing MACs implement in hardware has not been published in the material we could verify. That is not a minor detail: a part that advertises TSN but only offers 802.1AS timestamping and software-driven shaping is a very different tool from one with a full hardware gate control list.

For the scheduling model in depth, read our guide to TSN time-aware shaper, 802.1Qbv gate control list scheduling. The short version is that Qbv divides time into a repeating cycle and opens or closes queue gates by schedule, so that a scheduled critical stream never waits behind bulk traffic.

A worked budget for a small control loop

Consider a cyclic exchange at a 1 ms period, which is typical for motion and I/O. A minimum-size Ethernet frame with preamble and inter-frame gap occupies 84 bytes on the wire, or 672 bits, which takes 672 ns at 1 Gbit/s. A full 1,500-byte frame occupies 1,538 bytes, or roughly 12.3 microseconds. Without pre-emption or scheduling, a critical frame that arrives just after a bulk frame starts must wait up to about 12.3 microseconds per hop, which is manageable for a 1 ms cycle but dominates a 31.25 microsecond cycle. This is straightforward arithmetic from the Ethernet frame format, not a measured Dragonwing figure.

The point of the budget is to see where the NPU and camera fit. A camera stream is bulk traffic that must be kept out of the control window. With Qbv, you assign the control stream to a high-priority queue with an exclusive window in each cycle, and let video use the remaining time. Without hardware support, you shape in software, accept larger jitter, and keep the control loop on a separate port. Because the part has two ports, one clean design is to dedicate one to deterministic fieldbus traffic and the other to IT and video.

Time synchronisation and the real-time core

If the TSN MAC provides a hardware timestamp clock, there is an elegant design in which the PTP clock disciplines both the Linux system time and a timer that the RISC-V core can read, so that control firmware and Linux agree on time to sub-microsecond accuracy. Whether the E61 can read the Ethernet clock directly is unpublished. If it cannot, the fallback is to mediate time through Linux, which is functional but reintroduces Linux in the timing path.

Verification checklist for TSN

Ask for the list of supported IEEE 802.1 and 802.3 standards per MAC, in hardware versus software.
Confirm the number of hardware transmit queues and whether gate control list entries are offloaded.
Check the Linux driver status for the taprio and etf queueing disciplines, and for ptp4l and phc2sys hardware timestamping.
Test with a calibrated traffic generator and a hardware analyser, and measure cycle-time jitter under load, not on an idle link.

Putting 1.1 TOPS to Work: What the NPU Can and Cannot Do

A 1.1 TOPS Hexagon NPU is small by 2026 standards, and that is the honest framing. It is a part for models you would have recognised in 2020: lightweight convolutional detectors, classifiers, small speech and audio networks, and perhaps compact transformer encoders at low resolution. It is not a part for running a billion-parameter language model, and any vendor material that suggests otherwise should be read with suspicion.

Figure 4: A compact machine-vision pipeline on an IQ-2390. The camera feeds the ISP, the NPU runs a small detector, and results travel over a TSN port while the real-time core handles triggers and I/O.

Sizing a workload, with illustrative numbers

Take a hypothetical inspection task: one camera, 640×480 input, a quantised small object detector needing about two billion operations per frame, running at 15 frames per second. That is 30 billion operations per second, or about 3 percent of the NPU’s 1.1 TOPS peak. Even if real utilisation is only 10 percent of peak, which is a deliberately pessimistic assumption, the NPU has room for several such streams. These figures are illustrative; the model size, frame rate and utilisation are assumptions and not measurements.

The binding constraints are typically elsewhere. Pre-processing (colour conversion, resize, normalisation) runs on the CPU or GPU unless the ISP or a hardware scaler performs it. Post-processing such as non-maximum suppression runs on the CPU. Memory traffic for moving frames into and out of the NPU competes with display and camera. A well-optimised pipeline uses zero-copy buffers, so that frames do not cross the CPU cache more than necessary.

Software stack questions

Qualcomm’s brief does not describe the AI software stack for these parts. For Dragonwing generally, Qualcomm’s toolchain is the AI Engine Direct SDK (formerly QNN) and Qualcomm AI Hub for model conversion, but whether the 2390 is supported by those, and with what operator coverage and quantisation formats, is unverified. Ask for the supported operator list and a conversion path from ONNX or TFLite, because operator gaps cause silent CPU fallbacks that destroy the performance advantage.

A practical evaluation protocol when the kit ships:

Convert three representative models from your product, quantise them, and record accuracy against the float baseline.
Measure latency and throughput on the NPU, and on the A78 alone, to see the real speed-up.
Re-measure under full system load, with camera, display and network active.
Record power at the board input, not at the SoC, so the number matches what your battery or power supply sees.

Audio and the V66 DSP

The Hexagon V66 audio DSP, at up to 1.1 GHz on AB parts, is easy to overlook and often valuable. Wake-word detection, noise suppression, beamforming and acoustic anomaly detection are natural fits, and running them on a DSP leaves the A-cores in deep idle. For industrial uses, an audio-based condition-monitoring sensor, listening for bearing noise or leaks, is a strong match for a part with a DSP and a small NPU that can run for years from a modest power budget.

Software, BSP and Lifecycle: What Is and Is Not Known

Qualcomm lists Android, Yocto Linux and Ubuntu on the Cortex-A cores, and Zephyr on the RISC-V core. The Q-2390 and IQ-2390 are said to be available until 2036, a ten-year window from announcement. SECO has said its IQ-2390 products work with its Clea software framework, and early access partners include SECO, Fibocom, Engicam and Eight Development.

What is not known matters more than what is. We could not verify the BSP status, kernel version, whether the vendor kernel is upstream-friendly, the Yocto layer maturity (a meta-qcom style layer is the likely route, but we have not verified it), or whether Ubuntu support is community, canonical or Qualcomm-maintained. These are the questions that decide real schedules. For a general view of how to evaluate Yocto-based images against vendor Ubuntu images in production, see our comparison of Yocto OE4T versus Ubuntu L4T for Jetson production images; the same trade-offs, reproducibility, security patching cadence and image size, apply here even though the silicon differs.

A ten-year lifecycle is a software problem too

Silicon availability to 2036 does not guarantee software support to 2036. A product with a ten-year life needs kernel security patches for the same period, which means either an LTS kernel that the vendor actively maintains, or a mainline-friendly driver set that your team can forward-port. Ask Qualcomm for the support period of the BSP, not only the part. Also ask how firmware for the RISC-V core, secure boot keys and trusted-execution components are updated.

Security is listed as an integrated capability of the Q-2390, but the brief names no specifics. For a connected industrial device under regimes such as IEC 62443 and the EU Cyber Resilience Act, you will need to know about secure boot, hardware root of trust, key storage, debug lock and a trusted execution environment before you can claim anything. None of this is verified for these parts.

Alternatives at the Architecture Level

A fair comparison between competing SoC families is possible only at the architecture level, because no independent benchmark exists for the 2390 and we will not invent one. The table compares design philosophy, not measured performance.

Family	CPU style	Accelerator	Real-time island	Notes
Dragonwing Q-2390 / IQ-2390	1x A78 + 3x A55	Hexagon NPU up to 1.1 TOPS (AB)	RISC-V E61 up to 600 MHz (AB)	Dual GbE TSN, 2036 longevity
NXP i.MX 8M Plus class	4x A53	NPU of a few TOPS	Cortex-M7	Mature Yocto and long NXP longevity programme
NXP i.MX 93 class	2x A55	Small Ethos NPU	Cortex-M33	Lower power, lower compute
TI AM62A / AM6x class	A53 cluster	Deep-learning accelerator	Cortex-R5F / M4F	Strong industrial and TSN heritage
MediaTek Genio class	A-class cluster	APU	Often a Cortex-M	Consumer and industrial mix
Renesas RZ class	A55 or A-class	DRP-AI on some	Cortex-M	Strong in industrial vision

The comparison is qualitative and from vendor family positioning, not from head-to-head tests; check current datasheets before using any row. What stands out about the Dragonwing pair is the combination: a single high-performance A78 for peak responsiveness, a RISC-V real-time core, TSN ports on both families, and the Qualcomm modem option on the same silicon. The incumbents differ in maturity of their software and in how long engineers have been shipping with them, which is a real advantage that a new family has to overcome.

Trade-offs, Gotchas, and What Goes Wrong

The suffix trap. The most expensive mistake available is ordering an AA part and discovering you needed the NPU or real-time core. The Q-2390 names look identical in marketing; only the part number tells you. Bake the exact orderable part into your hardware specification, and keep it in your bill of materials review checklist.

Single big core. One Cortex-A78 is a thin foundation for a rich Android UI with a heavy browser engine plus a vision pipeline. Three A55 cores will carry background work, but anything on the critical path to the user lives on one core. Profile early. If the product needs several demanding foreground threads, this is the wrong part.

1080p30 ceilings. Decode and encode top out at 1080p30, and display at 1080p60. Products that want 4K, high-frame-rate capture or multi-camera stitching will not fit. Check the numbers against your camera and panel plans before committing, not after.

Memory bandwidth. Dual 16-bit LPDDR4x gives a 32-bit total data bus. For a design that combines a display, two cameras, an NPU and a Linux workload, bandwidth is the first thing to run out. Reserve budget in the architecture, use compressed framebuffers if supported, and avoid unnecessary format conversions.

Immature ecosystem. The part was announced in September 2026 and evaluation kits arrive in early 2027. That means early-access documentation, early BSP drops and a small pool of community knowledge. If your schedule requires production in mid 2027, you are betting on Qualcomm’s and your SoM vendor’s execution, not on a proven platform. Plan a second source or a pin-compatible fallback for risk-sensitive programmes.

Unverified claims. Process node, safety certifications (functional safety such as IEC 61508 or ISO 13849 capability, or automotive qualification), security architecture details and pricing were not disclosed in what we could verify. Do not assume a part is safety-certified because it targets industrial markets. A RISC-V core on a die is not the same thing as a certified safety island.

Boundary creep and interference. As described earlier, AMP designs drift, and shared memory contention can break latency assumptions. The antidote is discipline and measurement.

Thermal reality. A +115 C rating is a junction or ambient figure depending on how the vendor defines it, and the brief does not say. A fanless industrial enclosure at 70 C ambient with a quad-core part under full load can still throttle. Do thermal modelling with the real power numbers once available.

Practical Recommendations

Treat the Dragonwing Q-2390 and IQ-2390 as a credible cost-and-longevity play for small edge AI, not a performance play. If your product needs one or two camera streams at 1080p, a small detector or classifier, deterministic Ethernet, and a ten-year supply, the family deserves a place on the shortlist. If it needs heavy generative AI, multi-camera 4K or a rich multi-threaded UI, look at larger parts.

Choose Q-2390 when the product is a consumer or commercial device, when you need LTE and GNSS integrated, or when board area is tight and your PCB process handles a 0.4 mm pitch. Choose IQ-2390 when the product is industrial, when you value a coarser-pitch package that tolerates vibration, or when cellular is handled by a certified external module. Pick AB parts if there is any chance you will want the NPU or real-time core; the incremental cost is likely lower than the cost of a respin, though pricing is not published.

For a pilot, a pragmatic path looks like this:

Request early-access kits or a SoM from SECO, Fibocom, Engicam or another partner, rather than waiting for the reference kit.
Write a one-page set of acceptance tests: model accuracy and latency, TSN jitter under load, boot time, idle power, and thermal at maximum ambient.
Ask Qualcomm in writing for the BSP support window, the kernel LTS plan, the TSN feature list, the inter-processor communication method and the security architecture.
Prototype the RISC-V and Linux contract early, with a heartbeat and safe-state test, before application code grows around it.
Keep your model and I/O abstractions portable, so a different SoC remains feasible.

Checklist before you commit:

Exact orderable part number chosen and recorded.
Memory bandwidth budget written and reviewed.
TSN capabilities confirmed in hardware, not assumed.
NPU operator coverage tested on your real models.
Software support period obtained in writing.
Safety and security certification needs mapped to what Qualcomm actually provides.

Frequently Asked Questions

What is the Qualcomm Dragonwing Q-2390?

The Dragonwing Q-2390 is a Qualcomm IoT processor for commercial and consumer devices, announced in September 2026. It combines one Cortex-A78 and three Cortex-A55 cores, an Adreno 704 GPU, up to 1.1 TOPS of Hexagon NPU on AB variants, and two Gigabit Ethernet ports with TSN. M variants add LTE Cat 4 and GNSS. Qualcomm says it will remain available until 2036.

What is the difference between Q-2390 and IQ-2390?

Both share the same core platform. The Q-2390 targets commercial and consumer products, is a small 12 x 12 mm package, and has M variants with LTE Cat 4 and GNSS. The IQ-2390 targets industrial use, is a larger 21.3 x 18.4 mm coarser-pitch package, is offered only in the AB configuration with NPU and RISC-V core, and has no cellular modem or GNSS. Both AB parts support -30 to +115 C.

How powerful is the 1.1 TOPS NPU?

It is a small NPU, suited to lightweight vision and audio models such as classifiers, small detectors and keyword spotting. Peak TOPS figures are rarely achieved in practice, as memory bandwidth, operator support and quantisation limit real throughput. Large language models and heavy multi-stream 4K analytics are out of scope. Qualcomm has not published supported data types or independent benchmarks, so measure with your own models.

Does the Dragonwing Q-2390 support real-time workloads?

Yes, on AB variants. An optional SiFive E61 RISC-V core runs at up to 600 MHz with 768 KB of memory and is supported with Zephyr RTOS, while the Cortex-A cores run Android, Yocto Linux or Ubuntu. This lets time-critical control loops run independently of Linux. Details of the inter-processor mechanism and peripheral access are not published, so confirm them before architecting around it.

Do the Q-2390 and IQ-2390 support TSN?

Both are described as having two Gigabit Ethernet ports with Time-Sensitive Networking. Which IEEE 802.1 standards are implemented in hardware, such as 802.1AS time synchronisation and 802.1Qbv scheduled traffic, has not been published in the sources we could verify. Industrial buyers should request the exact feature list and check Linux driver support for taprio and hardware timestamping before relying on TSN.

When can I buy Dragonwing Q-2390 hardware?

Qualcomm showed SoMs based on the processors at IFA 2026, and an early access programme includes SECO, Fibocom, Engicam and Eight Development. Evaluation kits for both platforms are expected in early 2027, which one report puts at Q1 2027. Pricing was not disclosed. Production timing depends on SoM vendors, so engage them early if you have a 2027 launch.