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
Nov 30, 2021
Have you ever wondered why Bill is a common nickname for William and Dick is a common nickname for Richard?...
Nov 30, 2021
Explore the history of the chip design process, from the days of Integrated Device Manufacturers (IDMs) to EDA tools and today's era of democratized design. The post Just What Is Democratized Design Anyway? appeared first on From Silicon To Software....
Nov 30, 2021
The demand for smaller electronics devices can be achieved by high-density layers in multi-layer build-up substrates or multi-layered printed circuit boards (PCB). Vias are essential in the design... [[ Click on the title to access the full blog on the Cadence Community site...
Nov 8, 2021
Intel® FPGA Technology Day (IFTD) is a free four-day event that will be hosted virtually across the globe in North America, China, Japan, EMEA, and Asia Pacific from December 6-9, 2021. The theme of IFTD 2021 is 'Accelerating a Smart and Connected World.' This virtual event ...

featured video

Emulation and Prototyping to Accelerate Your Product Development Process

Sponsored by Cadence Design Systems

Validate your most sophisticated SoC designs before silicon and stay on schedule. Full system verification and early software development is possible with Cadence Palladium and Protium Dynamic Duo for IP/SoC verification, hardware and software regressions, full system verification, and early software development.

Click here for more information about Emulation and Prototyping from Cadence Design Systems

featured paper

Using the MAX66242 Mobile Application, the Basics

Sponsored by Maxim Integrated (now part of Analog Devices)

This application note describes the basics of the near-field communication (NFC)/radio frequency identification (RFID) MAX66242EVKIT board and gives an application utilizing the NFC capabilities of iOS and Android® based mobile devices to exercise board functionality. It then demonstrates how the application enables use of memory and secure features in the MAX66242. It also shows how to use the MAX66242 with an onboard I2C temperature sensor, demonstrating the device's energy harvesting feature.

Click to read more

Featured Chalk Talk

Easy Hardware and Software Scalability across Renesas RA MCUs

Sponsored by Mouser Electronics and Renesas

There are a bewildering number of choices when designing with an MCU. It can be a challenge to find one with exactly what your design requires - form factor, cost, power consumption, performance, features, and ease-of-use. In this episode of Chalk Talk, Amelia Dalton chats with Brad Rex of Renesas about the small-but-powerful Renesas RA family - a flexible and scalable collection of MCUs that may be exactly what your next project needs.

Click here for more information about Renesas Electronics RA Family Arm® Cortex® Microcontrollers