feature article
Subscribe Now

Horses for Courses

HSA Foundation Works to Treat All Processors Equally

Can’t we all just get along? The DSP programmers don’t talk to the CPU programmers; the GPU programmers won’t sit at the lunch table with the device-driver programmers. Hey, gang. We’re all nerds. Let’s work together.

That’s the altruistic but daunting task of the Heterogeneous Systems Architecture (HSA) Foundation, a nonprofit group formed to define hardware and software standards that allow all types of processors, regardless of race, creed, religion, orientation, or country of origin, to play well with others.

As Bryon Moyer so ably described in May, the HSA specification is complex, convoluted, and complicated. It’s also a work in progress, as these things don’t throw themselves together quickly. The HSA Foundation has released version 1.0 of the specification, so it’s real. You can download it and design hardware around it. But your new system won’t have much company for a while.

To recap, the purpose of HSA is to spread a layer of commonality across all types of processors – CPU, GPU, DSP, you name it – so that they’re all treated more or less as equals. By way of contrast, today’s PCs treat the main processor (likely a multicore x86 chip) very differently from the graphics processor (likely a massively multicore chip in its own right). That’s a persistent remnant of the old-school way of designing computers with a single main CPU and one or more peripheral controllers, accelerators, or satellite processors. The operating system and the main applications run on the main CPU; the additional processors get tossed specialty tasks consistent with their architecture.

That’s all well and good, but these days we tend to mix our processors a bit more closely. Even a basic cellphone has at least two processors (CPU and GPU), and special-purpose embedded systems have had mixed processor types for years. Wouldn’t it be nice if we could program these things as if they were true multiprocessor systems, rather than the conventional arm’s-length-and-a-bus relationship between different processors?

HSA isn’t trying to make all processors generic and interchangeable, by any means. They just want to hammer out some rules, guidelines, specifications, and best practices for mixing processors in a system. Want to do it in your own proprietary way? Fine; no HSA police will enforce their vision of system architecture on you. But if you’d like to leverage the work of a group of smart people who’ve given this some real thought, HSA 1.0 might be worth reading and following.

Like many consortia, HSA’s members are made up of people with real jobs, mostly in the processor or IP business. Founding members include AMD, ARM, and Imagination Technologies. What do those three companies have in common? Go ahead, I’ll wait… That’s right: they all make both CPUs and GPUs, and thus have experience with, and a vested interest in, making dissimilar processors work together. Ever since AMD acquired ATI, it has worked mightily to combine the two into a kind of super-processor (what AMD calls an APU, or advanced processing unit) that offers a one-two punch in a single package. ARM, of course, licenses its Cortex processors and Mali graphics engines, while cross-town rival Imagination makes both the MIPS CPU and the PowerVR GPU. Most smartphones and tablets today combine ARM’s CPU with Imagination’s GPU (or vice versa, in a few cases), so mixing competitive offerings is nothing new.

This week the group gave a public status report and a kind of group high-five. The specification is published, the first few HSA-compliant systems are out in the wild, and some member companies are working on more to come.

Most of the partner presentations were of the “coming soon” variety. Lead presenter AMD talked about a nearly real chip, its sixth-generation A-series microprocessor code-named Carrizo. That 12-core beast has four x86 processors and eight GPUs, plus all the usual internal plumbing (now with HSA compliance!) to keep it all flowing smoothly. 

ARM provided some platitudes regarding HSA in general, without missing the opportunity to point out that it already supports heterogeneous processing with its Cortex CPUs and Mali GPUs.

Next up, ARM licensee MediaTek showed a series of Kindergarten-quality block diagrams showing how it would combine “big CPUs” with “little CPUs,” a not-so-subtle reference to its IP provider’s preferred big.Little dual-core architecture.

Imagination Technologies made much the same pitch as ARM, albeit with different brand names, reminding everyone that its MIPS processors already work quite happily alongside its PowerVR GPUs. It finished with a “coming soon” slide that promised a “staged roll-out from 2016 onwards,” so HSA-compliant IP from imagination is now in the pipeline. 

What does HSA compete with? You, mostly. Makers of heterogeneous systems have had to cobble together their own multi-headed architectures based on shared memory, message passing, or whatever seemed expedient at the time. It’s obviously worked; we have existence proof of that. So proprietary and home-grown solutions are HSA’s biggest opposition.

The other bugaboo is the belief that standardization layers like HSA’s are terrible performance sinks. How can you abstract away differences in processor architecture and memory maps without incurring huge software overhead or reducing differentiation? Won’t HSA turn my system into a lumbering, top-heavy house of cards that treats every processing element as the lowest common denominator?

Nope. Not unless you design it that way. HSA’s guidelines and standards don’t remove any details or differentiation from your system. They merely provide alternatives if you want them. Still want to program down to the bare metal on your GPU? Great; HSA does nothing to stop you. Still want to bit-twiddle your DSP or hard-code your CPU? Fantastic. But if you’d rather treat your disparate processing elements as more-or-less equal partners sharing a memory map and a power supply, HSA has some good ideas about how you might abstract away some of the gory details.

It’s a lot like DirectX, Microsoft’s ever-evolving graphics-driver architecture. At first, high-performance game programmers decried DirectX as a fat, slow layer of buggy bloatware that got between them and their artisanal GPU code. Later, DirectX evolved into a useful abstraction layer that nevertheless allowed hard-core coders to touch the metal if they really wanted to. Today, DirectX is almost universally used to bring sanity to a very complex world of incompatible GPU architectures and daily driver updates.

As Marty Johnson, HSA representative from AMD says, “If you want write-once, run-anywhere code, HSA can get you there. But if you prefer coding to bare metal, HSA supports that, too. It doesn’t turn everything to vanilla. HSA gives you more options, not fewer.”

I like vanilla as much as the next guy. But choices are good, too. And HSA provides a choice for simplicity and sanity. That’s going to be more important as processors, and multiprocessor systems, get more complicated. 

Leave a Reply

featured blogs
Jan 15, 2021
It's Martin Luther King Day on Monday. Cadence is off. Breakfast Bytes will not appear. And, as is traditional, I go completely off-topic the day before a break. In the past, a lot of novelty in... [[ Click on the title to access the full blog on the Cadence Community s...
Jan 14, 2021
Learn how electronic design automation (EDA) tools & silicon-proven IP enable today's most influential smart tech, including ADAS, 5G, IoT, and Cloud services. The post 5 Key Innovations that Are Making Everything Smarter appeared first on From Silicon To Software....
Jan 13, 2021
Here are some genius solutions to everyday problems you probably didn'€™t even know existed, but after you'€™ve seen them you'€™ll say '€œWow!'€...
Jan 13, 2021
Testing is the final step of any manufacturing process, and arguably the most important, and yet it can often be overlooked.  Releasing a poorly tested product onto the market has destroyed more than one reputation for quality, and this is even more important in an age when ...

featured paper

Overcoming Signal Integrity Challenges of 112G Connections on PCB

Sponsored by Cadence Design Systems

One big challenge with 112G SerDes is handling signal integrity (SI) issues. By the time the signal winds its way from the transmitter on one chip to packages, across traces on PCBs, through connectors or cables, and arrives at the receiver, the signal is very distorted, making it a challenge to recover the clock and data-bits of the information being transferred. Learn how to handle SI issues and ensure that data is faithfully transmitted with a very low bit error rate (BER).

Click here to download the whitepaper

Featured Chalk Talk

Digi Remote Manager

Sponsored by Mouser Electronics and Digi

With the complexity of today’s networks, the proliferation of IoT, and the increase in remote access requirements, remote management is going from “nice to have” to “critical” in network design and deployment. In this episode of Chalk Talk, Amelia Dalton chats with Stefan Budricks of Digi International about how Digi Remote Manager can address your remote management and security needs.

Click here for more information about DIGI XBee® Tools