Hard core: the challenges of programming multicore architecture

4 mins read

It’s been a tough year for semiconductors. Between the millions of unbuilt cars and the delayed iPhones, the everyday consumer is developing an understanding of where the brains in their electronics come from, and how important they are.

The buzz around challenges to the supply chain, however, has camouflaged another significant issue within the chip market. While global powers pour time and money into solving the supply and demand issues, the complexity of programming multicore chip architectures remains very real, threatening to have a similar impact on the supply of software innovation.

Programmability of chips is an important topic right now. As our devices have become smarter and more interconnected, new market opportunities have sprung up, each with its own unique set of requirements. Inflexible architectures with heterogenous programming environments are no longer sufficient to meet with evolving demand for innovation and there is an urgent need to address the balance between time, cost and reward of bringing new products to market.

But with so many multicore architectures available, what are the specific issues of programmability that need to be addressed?

1. Lengthening time to market and spiralling development costs

The first and most obvious challenge in design is the sheer complexity involved in today’s SoCs. Applications based on heterogeneous multicore processors demand complex custom programming, validation and verification — even at the most established and cutting-edge design houses. This, in turn, leads to a slow time to market that puts financial pressure on the manufacturer.

With the myriad niche applications that the chip industry now caters to, there is no ‘one size fits all’ when it comes to programming, meaning that it is impossible to guarantee product designers a consistent reusable and familiar environment to work in.

2. Inflexible architectures requiring you to start from scratch

Perhaps even more frustratingly, once the time-consuming programming process is complete, the end product is not necessarily ‘future-proof’. As devices evolve and become more intelligent, they have more precise and distinct requirements, and the structure of the system needs to change accordingly. Suddenly, the custom development you spent months on doesn’t translate to the new iteration of the SoC architecture.

With so many variables to the physical composition of the product, and the need to maximise the performance of the processor that drives it, even minor updates can demand a re-design from the ground up.

3. The restrictions of processor ‘families’

Despite this, the myth persists that remaining within a specific family of processors will deliver re-use benefits, and conversely that swapping between different processor families is extremely difficult because of different instruction sets. No problem though — Arm processors give you flexibility and scope to change, right?

Wrong. Every SoC is different; there’s no truly homogenous programming model across heterogeneous platforms that is consistently made available to engineers. Given the specific demands of the IoT and of the bespoke processors being designed to drive devices, different toolsets and techniques are deployed for different purposes.

A common frame of reference within which architectures and concepts can be freely interchanged is all too rare — not only is it extremely difficult to attribute a programme to and balance across cores, but even the interface through which you would do so is often complex and inaccessible.

So, in short: complex SoCs based on multi-core processors take years to reach the market, range from difficult to impossible to modify once they arrive, and lack the accessibility and adaptablility to even attempt to make amends. All of this makes it actively more difficult for end users to shape their product into their intended vision.

The creative process

It’s time to step back from these issues and see the bigger picture. We don’t have the time or money to invest colossal sums in long term projects aiming at perpetually moving targets, we need to move to a more agile and accessible development model.

Ultimately, what we’re talking about here is the need for a new design environment that can serve as a genuinely common frame of reference between different products. It needs to be able to configure different types of processing — be that general purpose, digital signal processing (DSP), artificial intelligence (AI) or Input/Output (IO) — using the same tools and the same language and with robust and reliable execution characteristics.

Given the aforementioned complexity and specificity of new markets, a real-time operating system like FreeRTOS ticks a lot of those boxes. Familiarity and flexibility are powerful weapons in an engineer’s arsenal, and operating systems like FreeRTOS are designed to make that flexibility as accessible and easy to understand as possible. A key missing piece of the puzzle is the ability to apply such a system to multicore architecture.

To maximise its versatility and accessibility, that environment then needs to rest upon a more flexible style of hardware platform that allows engineers to use different processing types at their discretion. Multicore chip programming is not as inaccessible a challenge if engineers can build an architecture based on what they need, when they need it, without having to continually learn new languages, architectures or tools — it’s about empowering them to build a solution that can develop, adapt and grow with the market.

The way forward

A combination of a high-level abstraction like the FreeRTOS operating system, with full control over a genuinely adaptable, scalable and predictable compute platform would attack the obstacles inherent in the chip industry as we see it. Hardware that allows engineers to reliably reconfigure without a total architectural rebuild, and a programming environment based on existing programming techniques, will drastically improve the scalability and flexibility of tomorrow’s platforms.

Tackling these obstacles gives electronics engineers the environment and time to focus on the creative application of their craft, purpose-building a market-specific solution without the architectural or programming restrictions. Solutions can grow and adapt alongside the market, rather than being torn down and reassembled in the time-honoured fashion that our industry can no longer rely on.

Whether tackling the challenges of developing markets like the smart home, or building more efficient implementations of more established crafts such as voice processing, a versatile platform accessed through an environment everyone can understand can only benefit the engineer — and by extension their chosen market.

Author details: Mark Lippett is CEO, XMOS