It’s not just about hardware anymore

In the hierarchy of systems, the processor has always played a central role. When making architectural decisions on a system, one of the first considerations is which processor to use. Once chosen and configured, a designer can go about implementing the agree-upon structure. The key question is, how do you know when you’re done?

That’s where things have gotten tough. The basic expectations of what it means to have a working chip have changed dramatically with the advent of the system on a chip (SoC). And, to the chagrin of designers, those expectations have gone way up. The verification required to meet this higher standard has evolved to the point where, before silicon is delivered, software must be executed. This burns through so many clock cycles that the only way to prove with any confidence – and in a reasonable timeframe – that software works is through emulation.

Is it done yet?
With the old way of doing things, there was a giant chasm between the hardware world and the software world. Typically, a processor would be a separate chip. That chip could be breadboarded along with other components; once ready, a software engineer could start writing code.

The processor and software design realms were so far apart that the chip designer might work in a semiconductor corporation in one of the world’s usual technology hubs, while any guy with access to an electronics store, a soldering iron, a terminal, and an oscilloscope anywhere in the world could design software for an embedded system.

The processor designer’s mandate was straightforward: the chip was deemed working when it could execute the entire instruction set in the manner prescribed by the spec and at the designated performance. Mostly. If the designer was lucky, a few errors could be documented and tolerated (only to become part of the processor legacy, with future editions having to replicate those errors).

Life isn’t so easy anymore. For the most advanced, challenging embedded systems, the processor no longer has the luxury of its own chip. Now the chip is an entire system: not only does the processor have to work, but several processors may have to work. And they may not all be the same. And the interconnect structure has to deliver, as does the memory subsystem.

How does he or she know when it’s all running properly? When it can run the kinds of fundamental software that will be executed under the targeted operating conditions, at the required performance and power levels. Exactly what that software is might vary dramatically between systems. But typical tests might include:

* Diagnostics
* Firmware
* Booting Linux
* Demonstrating that Linux provides all of the necessary services for the applications that will be written on top of it
* Showing that critical algorithms execute efficiently. This is especially true of “bare metal” systems, which don’t use an operating system at all. The target code must be shown to operate well.