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
Jun 30, 2022
The Team RF "μWaveRiders" blog series is a showcase for Cadence AWR RF products. Monthly topics will vary between Cadence AWR Design Environment release highlights, feature videos, Cadence... ...
Jun 29, 2022
The 2022 YWCA Golden Gate Silicon Valley Tribute to Women Awards honored five women from the Synopsys team; learn about the award and this year's honorees. The post YWCA Tribute to Women Honors Synopsys Women of Achievement appeared first on From Silicon To Software....
Jun 28, 2022
Watching this video caused me to wander off into the weeds looking at a weird and wonderful collection of wheeled implementations....

featured video

Synopsys 112G Ethernet IP Interoperating with Optical Components & Equalizing E-O-E Link

Sponsored by Synopsys

This OFC 2022 demo features the Synopsys 112G Ethernet IP directly equalizing electrical-optical-electrical (E-O-E) channel and supporting retimer-free CEI-112G linear drive for low-power applications.

Learn More

featured paper

3 key considerations for your next-generation HMI design

Sponsored by Texas Instruments

Human-Machine Interface (HMI) designs are evolving. Learn about three key design considerations for next-generation HMI and find out how low-cost edge AI, power-efficient processing and advanced display capabilities are paving the way for new human-machine interfaces that are smart, easily deployable, and interactive.

Click to read more

featured chalk talk

Power Profiler II

Sponsored by Mouser Electronics and Nordic Semiconductor

If you are working on a low-power IoT design, you are going to face power issues that can get quite complicated. Addressing these issues earlier in your design process can save you a lot of time, effort, and frustration. In this episode of Chalk Talk, Amelia Dalton chats with Kristian Sæther from Nordic Semiconductor about the details of the new Nordic Power Profiler Kit II - including how it can measure actual current, help you configure the right design settings, and show you a visualized power profile for your next design.

Click here for more information about the Nordic Semiconductor Power Profiler Kit II (PPK2)