Big Changes In Embedded Software

Every good hardware or software design starts with a structured approach throughout the design cycle, but as chip architectures and applications begin focusing on specific domains and include some version of AI, that structure is becoming more difficult to define. Embedded software, which in the past was written for very narrow functions with a minimal footprint, is increasingly getting blended into the overall system design and re-used wherever possible.

Embedded software typically has included real-time operating systems, drivers, and firmware, most of which was custom developed, loaded into a design once, and rarely touched again. But as more chips are used for longer periods of time, and for safety- and mission-critical applications, embedded software may need to be updated. So rather than a single architecture for embedded software, it is becoming increasingly flexible and adaptable, and in some cases less energy-efficient and slower. The challenge now is to figure out what needs to be optimized and how best to achieve that.

“The question becomes, ‘What is the system doing?’ And if it turns out that you need to develop the software, but maybe it is hidden, the hardware plus the software together realize the function that is required,” said Pierre-Xavier Thomas, group director of technical and strategic marketing for Tensilica IP at Cadence. “In many embedded systems today, when there is a microcontroller in the system, as there often is today, the embedded software must be optimized. The software is there to coordinate the inputs, the output, and maybe some of the processing for the system to do what it is supposed to do, which is typically to gather information from the environment, do something, then provide some new information to activate something. This isn’t the case in industrial or even in the smart home where you sense, you do something, you look at the sensing data, then activate something. The challenge is to be optimized, low-cost, and perform the function very well. Here, the software becomes very specific, and very specific to the interfaces, and to some extent to the architecture itself. When you control your inputs or outputs, there are registers to control, to communicate, etc., so the software could be very specific, and the software people and firmware developers are working very close to the hardware.”

But as designs become more customized, and as chipmakers try to add some flexibility into designs so everything is not an expensive one-off design, it becomes more difficult to architect both hardware and flexible software.

“Looking at the embedded software space 20 years ago, embedded devices tended to be not connected, not managed, in purpose-built devices,” said Scot Morrison, general manager at Siemens Embedded Solutions. “Engineering teams were trying to optimize for a specific function. There could be some concepts of reusability, such that maybe they’d be able to code for a similar device down the line by the same company. Open source was not really an option at that time. This meant embedded software development started from being very handcrafted, even sculpted, performance-focused and optimized-footprint-focused software.”

Fig. 1: Embedded software is becoming more reusable, but the challenge is optimization. Image source: Siemens Embedded Solutions

Those types of applications still exist. Medical devices such as pacemakers have a single job to do, and they achieve that using as small a footprint and as little energy as possible because the batteries are difficult to replace. But many other devices now utilize embedded software, as well, and that software needs to work in the context of whatever system it is being used in.

So what exactly is embedded software today? “Perhaps the best definition of the embedded software industry is that developers co-design hardware and software for an optimized solution with appreciation for the balance of resources on each side,” said Simon Davidmann, CEO of Imperas Software. “Hardware abstraction layers are a useful approach to allow each side of the fence to have some insight to the overall operation without getting too overwhelmed with unnecessary details. Hardware is based on the physical properties of semiconductor materials and transistors, but for most digital designs a gate-level view is most useful with the RTL abstraction. Software is based on the processor’s instruction set architecture (ISA), with assembly-level microarchitecture to implement the necessary functions, but software is developed with hardware abstraction layers, and the abstractions of high-level languages (such as C) and the operational infrastructure managed by an RTOS or OS.”

Put simply, the link between embedded software and hardware has become more complicated and nuanced. “Traditionally, when we think about software development, it was always hardware first,” said Johannes Stahl, senior director of product marketing at Synopsys. “There was an instruction set, there was a CPU built on an instruction set, there was an architecture of the hardware, and then essentially it would be conceived first and the instruction set created. Software had to be ported and developed, and that’s actually a painful thing, but it happened for a very few ecosystems of instruction sets.”

Over time, software in general has grown to drive more decisions about the hardware, and embedded software has become an integral part of the overall system software architecture. But it also has become murkier with AI/ML now being added into just about everything. In this world, the instruction set is not defined, but the software and the algorithm are. “There, system architects say, ‘I have some software, now build me the best architecture to execute it,” said Stahl. “And by the way, make it with the lowest power.’ That is now really software first, and is an interesting change as engineering teams think about the software stack they need to execute, what customers care about for this software stack, as well as the architecture that will be the best for it.”

Mileage may vary
In markets like automotive, where there are a lot of very complex ECUs, embedded software gets even more difficult to separate out.

“Somebody I hired just came off of a program during which they came up with an idea to add a feature,” said Siemens’ Morrison. “This engineer had to present it to the German automotive company as the number of bytes that were going to be added to the code. It was less than 10 bytes that he wanted to add, but it started a huge argument with the person writing the program. In automotive, they’re now using a lot of 32-bit processors, memory is much cheaper than it used to be, and the focus is much more on how quickly they can design the vehicle because the more the code is optimized and customized, the longer it’s going to take. If you can add something that is functional and robust, but you don’t have to optimize it, maybe you’re re-using it from a past program so it’s bringing along some extra code, and not that highly optimized. But it gets the job done, even if it costs you a little bit more memory or performance. The focus has shifted a lot more towards reusability, lowering costs, lowering time-to-market.”

Part of this is driven by the fact that more systems are lasting longer, and they are being developed in smaller batches. So unlike a mobile phone, where a chip may sell in volumes of hundreds of millions, the focus on domain-specific applications has sharply reduced those volumes. Chipmakers have adjusted by adding flexibility into their designs, but also by expanding what they are selling to their customers — something that is being made possible by selling solutions directly to OEMs rather than to a Tier 1 or Tier 2 company.

“We are spending a lot more time on winning combinations and system solutions,” said Sailesh Chittipeddi, executive vice president at Renesas. “That can be as simple as a schematic layout for a particular system, combining a microcontroller/microprocessor timing device on a board for a specific application. A great example of that would be a humidifier for room, where a simple layout takes it the whole way. The other side of this would be a system solution where, for example, you would define a complete robot arm with all devices put together, deliver the software package, and how it would connect to something else. That’s something that we never did before. In the past, we would sell a WiFi chip that was needed for some application. Now, we go in with everything we’ve got.”

Embedded software plays a critical role in these kinds of devices. “In general, software architecture is a very important topic, but especially in embedded software because it has one main role and is very dependent on the hardware,” said Haris Turkmanovic, embedded software lead at Vtool, who is also a teaching assistant in the Department of Electronics, School of Electrical Engineering at Belgrade University. “At the same time, good embedded software is not dependent on the hardware. Why? Because if you create a very good software architecture, then that software will not be dependent on the hardware.”

To Turkmanovic, a good software architecture must be composed of multiple layers, including a driver layer, a middleware layer, a service layer, and an applications layer. “Generally, all software must have some layers. In embedded software, it is even more important because it usually happens that the hardware is changed. If you architect the software to be well written, then changes are minor. But if you don’t have a plan and a good design of the software, you have big problems. The other side is if it is one big project. Here, it is critical to design the software well because many people will work on it. A version control system also makes it much easier to manage the software development, and the number of conflicts when merging key branches will be much lower.”

A third aspect, he said, is when software divisions are created. “Let’s say the divisions are vertical and horizontal. Horizontals are the layers mentioned above, with the vertical divisions set up as services, which are a compound of several layers. If you create software like this, it’s much easier in the final development steps to maintain and test that software because it’s organized and documented. Whatever we choose as the base for our software must be designed in multiple layers. But the complexity of the layers depends on the main program flow. Is it bare metal or is it RTOS base software?”

Difficult tradeoffs
Rupert Baines, chief marketing officer at Codasip, does not believe a lot of hardware engineers appreciate just how critical software is. “In a purchasing decision for an SoC you’re designing, the vice president of software probably has the final say as to which IP core or vendor you use. And if she says, ‘No, we’re not using that because the tools aren’t available, you’re not using that core.’ The hardware engineers can say, ‘But it’s a really lovely core. It’s cute.’ It doesn’t matter. That vice president of software has far more engineers and far more pain, and needs the IARs and the Lauterbachs and Seggers and the LLVMs and the Clangs to really be mature. Software eats hardware, and even as a company that make most of our money by licensing hardware, at the end of the day, it is all software, and it’s software that matters.”

That makes tradeoffs especially tricky. Software can be written in a way that is very specific to the hardware in order to optimize it for a particular application. But it can also be written so that it’s applicable in more areas.

“Like everything in engineering, it’s a tradeoff,” Baines said. “The whole point of engineering is what you are trying to optimize for. You’re trading off development efficiency against performance. For an awful lot of applications, and an awful lot of programs these days, what you’re trying to do is pretty well understood, pretty well standardized, and you’re looking to leverage what already exists using standard libraries, and standard software languages. Fifty years ago, you might have written your own language. Nowadays, you’ll write in C or C++ or Python or Java or a standard language. It would be almost inconceivable these days you would write in raw assembly, because the compilers and the tool chain are now so good. So why would you bother? You’re going to be using libraries and drivers that exist. That might be enough for a lot of applications, and that’s going to do your job perfectly well.”

That doesn’t mean the hardware is any less important, however. “It needs to be robust, low cost, energy efficient, and so forth,” said Cadence’s Thomas. “But now, for various reasons, when you do something specific, you may have less ability to sell it, so there’s a desire to make some systems that are a bit more flexible, capable of doing more things. For this, you need to know who you are targeting in order to sell more. It could be that your system goes into a bigger systems, and the differentiations in software are important. That — combined with all that AI and machine learning entails as far as the ability to detect with smart sensors and doing things at the edge because of security and privacy and things like that — requires increasingly more flexibility in an embedded system. Going into that type of system, you need to start by understanding how you can program it and how you can differentiate.”

Consider a smart home, for example, with multiple sensing devices — smart speakers, cameras and other security and safety sensors. Those can be used for sensing something specific and then making decisions.

“This could be implemented in a device that can be retargeted for different products, but the chip itself might be the same,” Thomas said. “In that case, you would be required to open up your software for somebody that wants to develop an application for a smart device to do something different from, say, a smart doorbell. Then you start having an embedded system that is a bit more flexible in the way it’s designed so that it can be targeted to different products. There, you want the software to start being easier to receive higher-end applications, and to have applications that could be programmed and re-used, in order to target higher end software developers. That could be another layer on top of the lower layer that is addressing all the hardware.”

Not so simple
One issue with embedded software development today, Vtool’s Turkmanovic said, is there is no unified approach. “This is very problematic. Generally, people try to follow some methodology but there isn’t a standard way to do these things. Especially if it is not some time-critical or safety-critical software, project teams don’t have any rules. That can be very problematic for maintaining, for upgrading, for improving. When you get a bunch of the code, and you cannot visualize it, it’s very hard to understand how it works. This is important for engineers who develop software, which is not too safety-critical or in the Linux area. If it’s somewhere in the middle, there are no rules, so it comes down to satisfying functionality. And that is the problem.”

He said it’s far better to have a systematic approach to embedded software. “From the beginning to the end of the project, you must spend a lot of time organizing it. You first need to think about problematic critical paths. Is something real-time or not real-time? How many interrupt routines do you have? How will you organize them? How will you prioritize them? There are so many questions we need to think about in the beginning phase. A lot of the questions are conditioned by the requirements for the projects. Most of them are conditioned by the platform that we use, because we cannot use an RTOS on each platform, only for some specific platforms. If some requirements are very strict time-wise, then you don’t have too much choice. You must follow one direction. If you have limited resources, you also need to better organize your code. What is needed is a unified framework for embedded software.”

In automotive, this is termed ‘service-oriented architecture,’ Siemens’ Morrison said. “In the automotive space, there is a lot more adoption of certain architectures that have emerged in all-software over the years, but what emerged in embedded over the last 10 to 20 years is the concept of the layered architecture. More recently in automotive, this has evolved into a service-oriented architecture. The whole concept of layering when it’s properly applied in a mature software development program is that you still get some software, which is going to be very hardware-dependent, but that should have a very cleanly defined API, maybe even an industry standard API. For instance, with AUTOSAR, you get the MCAL (microcontroller abstraction layer), which typically comes with the chip or the SoC from the semiconductor company. This is because the AUTOSAR standards body has done an excellent job of defining that, such that you could drop different AUTOSAR implementations on there and they generally just work. This means you basically tie all that non-reusable or chip-specific software at the lowest levels, and just build on top of it. You put AUTOSAR on top, and it just runs most of the time. Of course, you have to validate it. Then, on top of AUTOSAR, there are very cleanly defined APIs. This means you can take applications and re-use them from past programs, or move them onto different ECUs. You can reconfigure the software in the vehicle, and with AUTOSAR Adaptive, it takes it to the next level as more of a service-oriented architecture, where it can basically find the information that it needs. That leads to more updateability.”

Conclusion
As the lines blur between embedded software and traditional software, the development responsibility is also changing.

“Traditionally, embedded development was the provenance of the OEM or the hardware developer, i.e., the producer of the hardware,” said Mohamed Awad, vice president of IoT and Embedded at Arm. “Historically, there would have been a software team and a hardware team very tightly coupled, probably reporting to the same manager at the end of the day, working together to build a product. That line is starting to blur now, and we are seeing a lot of cloud service providers, or software service providers — whether it be for ML or other use cases — wanting to access all that compute that’s down on the endpoint, and bring a lot of value in terms of delivering software to a disparate number of hardware devices, which they don’t necessarily have control over.”

In order for those software vendors to be able to deliver that value and innovate on top of all that hardware, there has to be a level of consistency so they can achieve scale, and justify those investments, Awad said. “It doesn’t make sense for them to develop bespoke hardware for devices, which may only ship 1,000 or 10,000 devices, even if they got well into the millions or even billions. A streamlined process is critical here. It would be the same situation as if every mobile phone manufacturer had to develop every app for their mobile phone themselves, and they couldn’t tap into the app ecosystem that exists. And on top of that, those mobile phone vendors only shipped a fraction of the number of devices that they ship. You could imagine how small those ecosystems would be, and they wouldn’t be nearly as rich.”

This explains why many players in the semiconductor ecosystem are rallying around a common framework so that software developers can easily port from one device to another, move software from one device to another, and enable easy testability of devices to ultimately create economies of scale for the software ecosystem.

Related
Embedded Software: Sometimes Easier, Often More Complex
Dependencies and partitioning can turn a simple piece of code into a complex system challenge.
Hidden Impacts Of Software Updates
Over-the-air code changes can stress systems in unexpected ways.
Software-Defined Cars
This approach will streamline development and simplify upgrades, but it also increases design complexity.