Silicon & associated systems at the forefront

Microsoft’s yearly Build developer conference took place last Tuesday-Thursday, March 21-23 (as I write these words on Memorial Day), and was rife with AI-themed announcements spanning mobile-to-enterprise software and services.

Curiously, however, many of these announcements were derived from, and in general the most notable news (IMHO) came from, a media-only event held one day earlier, on Monday, March 20. There, Microsoft and its longstanding Arm-based silicon partner Qualcomm co-announced the long-telegraphed Snapdragon X Elite and Plus SoCs along with Surface Laptop and Pro systems based on them. Notably, too, Microsoft-branded computers weren’t the only ones on the stage this time; Acer, Asus, Dell, HP, Lenovo and Samsung unveiled ‘em, too.

To assess the importance of last week’s news, let’s begin with a few history lessons. First off, a personal one: as longtime readers may recall, I’ve long covered and owned Windows-on-Arm operating systems and computers, beginning with my NVIDIA Tegra 3 SoC-based Surface with Windows RT more than a decade back:

We Deserve Better: GNSS for the 21st Century 


Unlocking the Power of Multi-Level BOMs in Electronics Production 


Neuchips Driving AI Innovations in Inferencing


Three years ago, I acquired (and still regularly use, including upgrading it to Windows 11 Pro) a Surface Pro X powered by the Snapdragon 8cx SC8180X-based, Microsoft-branded SQ1 SoC:

More recently, I bought off eBay a gently used, modestly discounted “Project Volterra” system (officially: Windows Dev Kit 2023) running a Qualcomm Snapdragon 8cx Gen 3 (SQ3) SoC:

And even more recently, as you can read about in more detail from my just-published coverage, I generationally backstepped, snagging off Woot! (at substantial discount) a used example of Microsoft and Qualcomm’s first developer-tailored stab at Windows-on-Arm, the ECS LIVA Mini Box QC710 Desktop, based on a prior-generation Snapdragon 7c SC7180 SoC:

So, you could say that I’ve got no shortage of experience with Windows-on-Arm, complete with no shortage of scars, most caused by software shortcomings. Windows RT, for example, relied exclusively on Arm-compiled applications (further complicated by an exclusive Microsoft Store online distribution scheme); unsurprisingly, the available software suite garnered little adoption beyond Microsoft’s own titles.

With Windows 10 for Arm, as I complained about in detail at the time, while an emulation layer for x86-compiled content did exist, both its performance and inherent breadth and depth of functionality were subpar…so much so that Microsoft ended up pulling the plug on Windows 10 and focusing ongoing development on the Windows 11 for Arm successor, which has proven far more robust.

Here’s another personal narrative related to this post’s primary topic coverage: last fall, I mentioned that I’d acquired two generations’ successors to my long-used Surface Pro 5 hybrid:

A primary-plus-spare Surface Pro 7+:

 notably for backwards-compatibility with my Kensington docking station:

and the long-term transition destination, a pair of Surface Pro 8s:

What I didn’t buy instead, although it was already available at the time, was the Surface Pro 9. That’s because I wanted my successor systems to be cellular data-capable, and the only Surface 9 variants that supported this particular feature (albeit at a 5G cellular capability uptick compared to the LTE support in what I ended up getting instead) were Arm-based, with what I felt was insufficient upgrade differentiation from my existing Surface Pro X.

Flash forward to a bit more than two months ago, and Microsoft introduced the Surface Pro 10, along with the Surface Laptop 6. They’re both based on Intel Meteor Lake CPUs with integrated NPU (neural processing) cores, reflected in the dedicated Copilot key on each model’s keyboard. Copilot (introduced at last year’s Build), for those of you who don’t already know, is the OpenAi GPT-derived chatbot successor to Microsoft’s now-shuttered Cortana. But here’s an interesting thing, at least to me: the Surface Pro 10 and Surface Laptop 6 are both explicitly positioned as “For Business” devices, therefore sold exclusively to businesses and commercial customers, not available to consumers (at least through normal direct retail channels…note that I got my prior-generation SP7+ and SP8 “For Business” units via eBay resellers).

What about next-generation consumer models? The answer to that question chronologically catches us up to last week’s news. Microsoft’s new Surface Pro 11 (complete with a redesigned keyboard that can be used standalone and an optional OLED screen) and Surface Laptop 7, along with the newly unveiled systems from other Microsoft-partner OEMs, are exclusively Qualcomm Snapdragon X-based, which I suspect you’ll agree represents quite a sizeable bet (and gamble). They’re also labeled as being Copilot+ systems (an upgrade to the earlier Copilot nomenclature), reflective of the fact that Snapdragon X SoCs’ NPUs tout 40 TOPS (trillions of, or “tera”, operations per second) performance. Intel’s Meteor Lake SoC, unveiled last September, is “only” capable of 10 TOPs, for example…which may explain why, last Monday, the very same day, Intel “coincidentally” released a sneak peek of its next-generation Lunar Lake architecture, also claimed Copilot+ NPU performance-capable and coming later this year.

Accompanying the new systems’ latest-generation Arm-based silicon foundations is a further evolution of their x86 code-on-Arm virtualization subsystem, which Microsoft has now branded Prism and is analogous to Apple’s Rosetta technology (the latter first used to run PowerPC binaries on Intel microprocessors, now for x86 binaries on Apple Silicon SoCs), along with other Arm-friendly Windows 11 replumbing. Stating the likely already obvious, Microsoft’s ramped-up Windows-on-Arm push is a seeming reaction to Apple’s systems’ notably improved power consumption/performance/form factor/etc. results subsequent to that company’s own earlier Arm-based embrace. To wit, Microsoft did an interesting half-step a bit more than a year ago when it officially sanctioned running Windows-for-Arm virtualized on Apple Silicon Macs.

Speaking of virtualization, I have no doubt, based both on track record and personal experience, that Prism is capable technology that will continue to improve going forward, since Microsoft has lengthy experience with numerous emulation and virtualization schemes such as:

  • Virtual PC, which enabled running x86-based Windows on PowerPC Macs, and
  • Windows Virtual PC (aka Windows XP Mode), for running Windows XP as a virtualized guest on a Windows 7 Host
  • The more recent, conceptually similar Windows Subsystem for Linux
  • And several generations’ worth of virtualization for prior-generation Xbox titles on newer-generation Xbox consoles, both based on instruction set-compatible and -incompatible CPUs.

To wit, I wonder how Prism is going to play out. Clearly, no matter how robust the emulation and virtualization support, its implementation will be inefficient in comparison to “native” applications. So, I’m assuming that Microsoft will encourage its developers to in-parallel code for both the x86 and Arm versions of Windows, perhaps via an Apple-reminiscent dual-mode “Universal” scheme (in combination with “destination-tailored” downloads from online stores). But, supplier embarrassment and sensationalist press hypothesizing aside, I seriously doubt that Microsoft intends to turn its back on x86 in any big (or even little) way any time soon (in contrast to Apple’s abrupt change in course, in no small part thereby explaining its success in motivating its developer community to rapidly embrace Apple Silicon). Developing for multiple CPU architectures and O/S version foundations requires incremental time, effort, and expense; if you’re an x86 Windows coder and Prism works passably, why expend the extra “lift”?

Further evidence of Apple being in Microsoft’s gunsights comes from the direct call-outs that company officials made last week , particularly against Apple’s MacBook Air. Such comparative assessments are a bit dubious, for at least a couple of reasons. First off, Microsoft neglected to openly reveal that both its and OEM partners’ systems contained fans, whereas the MacBook Air is fan-less; a comparison to the fan-inclusive and otherwise more thermally robust MacBook Pro would be more fair. Plus, although initial comparative benchmarks are seemingly impressive, even against the latest-generation Apple M4 SoC, there’s also anecdotal evidence that Snapdragon X system firmware may sense that a benchmark is being run and allow the CPU to briefly exceed normal thermal spec limits. Any reality behind the comparative hype, both in an absolute and relative sense, will come out once systems are in users’ hands, of course.

So why is Microsoft requiring a standalone NPU core, and specifically such a robust one, in processors that it allows to be branded as Copilot+? While CPUs and GPUs already in systems are alternatively capable of handling various deep learning inference operations, they’re less efficient in doing so in comparison to a focused-function NPU alternative, translating to both lower effective performance and higher energy consumption. Plus, running inference on a CPU or GPU steals away cycles from other applications and operations that could alternatively use them, particularly those for which a NPU isn’t a relevant alternative. One visibly touted example is “Recall”, a newly added Windows 11 feature which, quoting from Microsoft’s website:

…uses Copilot+ PC advanced processing capabilities to take images of your active screen every few seconds. The snapshots are encrypted and saved on your PC’s hard drive. You can use Recall to locate the content you have viewed on your PC using search or on a timeline bar that allows you to scroll through your snapshots. Once you find the snapshot that you were looking for in Recall, it will be analyzed and offer you options to interact with the content.

Recall will also enable you to open the snapshot in the original application in which it was created, and, as Recall is refined over time, it will open the actual source document, website, or email in a screenshot. This functionality will be improved during Recall’s preview phase.

Copilot+ PC storage size determines the number of snapshots that Recall can take and store. The minimum hard drive space needed to run Recall is 256 GB, and 50 GB of space must be available. The default allocation for Recall on a device with 256 GB will be 25 GB, which can store approximately 3 months of snapshots. You can increase the storage allocation for Recall in your PC Settings. Old snapshots will be deleted once you use your allocated storage, allowing new ones to be stored.

Creepy? Seemingly, yes. But at least it runs completely (according to Microsoft, at least) on the edge computing device, with no “cloud” storage or other involvement, thus addressing privacy.

Here’s another example, admittedly a bit more “niche” but more compelling (IMHO) in exemplifying my earlier conceptual explanation. As I most recently discussed in my CES 2024 coverage, upscaling can decrease the “horsepower” of a system’s GPU required in order to render a given-resolution scene to the screen. Such an approach only works credibly, however, only if it comes with no frame rate reduction, image artifacts, or other quality degradations. AI-based upscalers are particularly robust in this regard. And, as discussed and demonstrated at Build, Microsoft’s Automatic Super Resolution (ASR) algorithm runs on the Snapdragon X Elite NPU, leaving the (integrated!) GPU free to focus on its primary polygon and pixel rendering tasks.

That all said, at least one looming storm cloud threatens to rain on this Windows-on-Arm parade. A quick history lesson: NUVIA was a small startup founded in 2019 by ex-Apple and Google employees, in the former case coming from the team that developed the A-series SoCs used in Apple’s smartphones and other devices (and with a direct lineage to the M-series SoCs subsequently included in Apple Silicon-based Macs). Apple predictably sued NUVIA that same year for breach of contract and claimed poaching of employees, only to withdraw the lawsuit in early 2023…but that’s an aside, and anyway, I’m getting chronologically ahead of myself.

NUVIA used part of its investment funding to acquire an architecture license from Arm. A quote from a decade-plus-back writeup at SemiAccurate (along with additional reporting from AnandTech), that as far as I can tell remains accurate, explains (with fixed typos by yours truly):

On top of the pyramid is both the highest cost and lowest licensee count option…This one is called an architectural license, and you don’t actually get a core; instead, you get a set of specs for a core and a compatibility test suite. With all of the license tiers below it, you get you a complete core or other product that you can plug-in to your design with varying degrees of effort, but you cannot change the design itself. If you license a Cortex-A15 you get exactly the same Cortex-A15 that the other licensees get. It may be built with very different surroundings and built on a different process, but the logic is the same. Architectural licensees conversely receive a set of specs and a testing suite that they have to pass; the rest is up to them. If they want to make a processor that is faster, slower, more efficient, smaller, or anything else than the one Arm supplies, this is the license they need to get.

Said more concisely, architecture licensed cores need to fully support a given Arm instruction set generation, but how they implement that instruction set support is completely up to the developer. Cores like those now found in Snapdragon X were already under development under NUVIA’s architecture license when Qualcomm acquired the company for $1.4B in early 2021. And ironically, at the time of the NUVIA acquisition, Qualcomm already had its own Arm architecture license, which it was using to develop its own Kryo-branded cores.

Nevertheless, Arm filed a lawsuit against Qualcomm in late summer 2022. Per coverage at the time from The Register (here’s a more recent follow-up writeup from the same source):

Arm has accused Qualcomm of being in breach of its licenses, and wants the American giant to fulfill its obligations under those agreements, such as destroying its Nuvia CPU designs, plus cough up compensation…

According to Arm…the licenses it granted Nuvia could not be transferred to and used by its new parent Qualcomm without Arm’s permission. Arm says Qualcomm did not, even after months of negotiations, obtain this consent, and that Qualcomm appeared to be focused on putting Nuvia’s custom CPU designs into its own line of chips without permission.

That led to Arm terminating its licenses with Nuvia in early 2022, requiring Qualcomm to destroy and stop using Nuvia’s designs derived from those agreements. It’s claimed that Qualcomm’s top lawyer wrote to Arm confirming it would abide by the termination.

However, says Arm, it appeared from subsequent press reports that Qualcomm may not have destroyed the core designs and still intended to use the blueprints and technology it acquired with Nuvia for its personal device and server chips, allegedly in a breach of contract with Arm…

Arm says individual licenses are specific to individual licensees and their use cases and situations, and can’t be automatically transferred without Arm’s consent.

According to people familiar with the matter, Nuvia was on a higher royalty rate to Arm than Qualcomm, and that Qualcomm hoped to use Nuvia’s technology on its lower rate rather than pay the higher rate. It’s said that Arm wasn’t happy about that, and wanted Qualcomm to pay more to use those blueprints it helped Nuvia develop.

Qualcomm should have negotiated a royalty rate with Arm for the Nuvia tech, and obtained permission to use Nuvia’s CPU core designs in its range of chips, and failed to do so, it is alleged, and is now being sued.

As I write these words, the lawsuit is still active. When will it be resolved, and how? Who knows? All I can say with some degree of certainty, likely stating the obvious in the process, is:

  • Qualcomm is highly motivated for Snapdragon X to succeed, for a variety of reasons
  • Arm is equally motivated for not only Snapdragon X but also other rumored under-development Windows-on-Arm SoCs to succeed (NVIDIA, for example, is one obvious rumored candidate, given both its past history in this particular space and its existing Arm-based SoCs for servers, as is its public partner MediaTek)
  • And their common partner Microsoft is also equally motivated for Arm-based Copilot+ systems (with Qualcomm the lead example) to succeed.

In closing, a couple of other silicon-related comments:

And with that, and closing in on 3,000 words, I’m going to wrap up for today. Let me know your thoughts in the comments!

Brian Dipert is the Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.

Related Content

Source link