IT managers are under increasing pressure to boost network capacity and performance to cope with the data deluge. Networking systems
are under a similar form of stress with their performance degrading as
new capabilities are added in software. The solution to both needs is
next-generation System-on-Chip (SoC) communications processors that
combine multiple cores with multiple hardware acceleration engines.
The data deluge, with its massive growth in both mobile and enterprise network traffic, is driving substantial changes in the architectures of base stations, routers, gateways, and other networking systems. To maintainhigh performanceas traffic volume and velocity continue to grow, next-generation communications processors combinemulticoreprocessors with specialized hardware acceleration engines inSoCICs.
The following discussion examines the role of the SoC in today’s network infrastructures, as well as how the SoC will evolve in coming years. Before doing so, it is instructive to consider some of the trends driving this need.
Given the increased complexity of processors and applications, the current generation of Operating Systems (OSs) focuses mostly on software integrity while partially neglecting the need to extract maximum performance out of the existing hardware.
Processors perform as well as OSs allow them to. A computing platform,embeddedor otherwise, consists of not only physical resources – memory, CPU cores, peripherals, and buses – managed with some success by resource partitioning (virtualization), but alsoperformanceresources such as CPU cycles, clock speed, memory and I/O bandwidth, and main/cache memory space. These resources are managed by ancient methods like priority or time slices or not managed at all. As a result, processors are underutilized and consume too much energy, robbing them of their true performance potential.
Virtualization means different things to users with different types of applications. Most forms of virtualization employed in IT server environments aren't of interest to embedded system developers because they don't ensure that processing of time-critical tasks is deterministic. Instead, the way for single and multiprocessor platforms to support multiple operating environments while maintaining real-time responsiveness is to functionally partition processor resources so that they are controlled by specific operating environments, which run directly on the processor silicon rather than on virtual machine implementations.
The origin of embeddedvirtualizationtechnology came about with the idea of creating an environment where aReal-Time Operating System(RTOS) could work alongside a General-PurposeOperating System(GPOS) such as Microsoft Windows. Embedded virtualization creates a partitioned environment in which the two OSs and the applications on them run on a single platform as if they were running on two separate platforms. The advantages of doing this are clear: system cost and complexity can be reduced if fewer processing platforms are required to serve the application’s computing needs. Product reliability can be enhanced as well if systems can be built with fewer hardware elements.
Back in the early ’80s, machine builders saw the opportunity to leverage the PC platform to build control systems for their machines. The first such applications were relatively simple, and the focus was mainly to leverage available hardware that was substantially lower in cost than specialized control hardware.
As the PC evolved with the addition of Windows, numerous applicationsoftwarepackages were introduced, driving a new standard of Human Machine Interface (HMI) with supporting graphic engines and software tools. Machine builders saw the opportunity to use Windows to create advanced HMIs that could simplify their machines’ setup, operation, and maintenance. However, Windows-based PCs could not be used for portions of an application involving time-critical control because Windows, by itself, isn’t an RTOS and is not capable of performing control functions with determinism. Hence, embedded system designers would typically add a real-time computer subsystem to the machine in addition to the PC to deliver a full suite of product functionality.
RTOS suppliers, on the other hand, have not had the resources to build the kind of graphic software tools and support that are available for Windows. A few saw the opportunity to couple their OSs to Windows in order to add RTOS functionality to Windows-based systems on a single computing platform.
The benefits of combining an RTOS with Windows on one machine were obvious for embedded systems OEMs, but the technical issues associated with doing that were very complex. Running two OSs on one computer wasn’t a new concept; it had been done 10 years before on mainframes with virtualization technology. That technology virtualized the whole computer platform, essentially creating an interface layer between the OSs and the hardware much like modern server virtualization technology does today.
The fundamental problem with this is that isolating the OS and application software from direct access to the hardware causes nondeterministic time delays when the application software needs to interact with its I/O. Real-time applications, however, must have direct access (sometimes called bare-metal access) to the devices that the applications need to control, so that the software can write or read data to and from the I/O devices in a timely, deterministic manner.
Embedded virtualization solves themulti-OSdeterminism problem
A method must be devised topartitionthe platform resources so that the RTOS can gain direct access to I/O and interrupts that are necessary for it to run an application deterministically. GPOSs like Windows do not allow a co-resident RTOS to control its I/O devices.
Instead, GPOSs typically take control of all available I/O on the platform during installation. Barring the option of modifying Windows, which would bring a whole new dimension of problems, a means of reserving I/O from Windows had to be devised. And since this was initially done back in the days of single-core processors (Figure 1), techniques had to be developed for the processor to switch context from the RTOS to the GPOS with minimum overhead. These are the principles of embedded virtualization, principles that have been validated in thousands of successful embedded system products.
Figure 1:A GPOS and RTOS share a single-core processor with communication across environments.
Interprocess communication enables task coordination
Multiple OSs running applications in shared but separate environments create the need for applications to pass data to each other. This could easily be performed with a simple block of reserved memory, but would require some level of housekeeping by the applications and would be cumbersome to manage in real-time systems, where messages need to be delivered and read at particular times.
The communication process needs to be structured in such a way that message delivery occurs when expected to maintain determinism. Communication has to take into consideration the priority of the message with respect to the priority of other real-time tasks that are running at the time, so that the message will be delivered at the right time or in the right sequence. This is particularly important when the communication is between an application running in a non-real-time GPOS environment and an application running on an RTOS in a real-time environment. An unprioritized event must not be allowed to interrupt a prioritized task.
Multicoreprocessors aid functional partitioning
The introduction of multicore processors caused some of the rules to change. In principle, processors no longer need to be shared. Each OS can have its own processor core (or multiple cores can be dedicated to a single OS); however, in practice, OSs such as Windows assume that all processor cores belong to them at installation.
Setting up a multicore system so that the GPOS is in control of some cores and not in control of others requires a way to tell the GPOS which cores are not available to it. With the proper means of resolving this, a four-core processor could support several configurations of GPOS:RTOS, including 3:1; 2:2, and 1:3 (see Figure 2). This flexibility allows the user to optimize the platform’scomputing resourcesdepending on the application’s requirement. Whereas an application with a complex Windows portion and light real-time requirements could be configured with three cores running the GPOS application and one core running the RTOS, an application with multiple real-time control functions running simultaneously and communicating with a simple HMI might have one core dedicated to Windows and three to multiple instances of the RTOS.
Figure 2:Embedded virtualization supports different functional partitioning strategies on multicore processors.
With the possibility of running several RTOSs at the same time on a multicore processor, the communication system that was initially developed to communicate between the GPOS and the RTOS on a single shared processor can be extended to enable communication between multiple instances of the RTOS and GPOS. In theory the system architecture could be expanded to create a network of OSs talking to one another, each running application elements that are particularly suited to its own environment. As with the I/O needs of the system, the communications structure needs to maintain and support the real-time determinism requirements of the real-time subsystems.
Virtualization enables deterministic communication across platforms
One embedded virtualization environment that has proven itself in mission-critical applications is the INtime RTOS family from TenAsys Corporation. INtime’s embedded virtualization technology encapsulates the principle of partitioning the PC platform to enable Windows and the RTOS to run side by side. INtime facilitates deterministic communications between instances of the RTOS and Windows with a global object networking system called GOBSnet. This consists of a built-in communication network that allows multiple applications on separate OSs to communicate at the process level in a deterministic way.
Using Ethernet with an addressing scheme akin to that of a URL, GOBSnet was extended to enable separate system functional blocks, called nodes, to communicate deterministically with each other on the same multicore processor or across platforms that are physically distinct. In this manner, large and complex applications can be distributed across several nodes (see Figure 3), simplifying their creation, debugging, and optimization while leveraging the parallel processing capability of multicore processors. This allows OEMs to produce a range of products at different cost points or functionality levels by scaling the number of processors or processor cores that are employed.
Figure 3:Global object networking facilitates communications between cores and across computing platforms in a complex embedded application such as anautomotivetestsystem.
Embedded virtualization techniques have been developed over more than a decade of use in real-time applications, but the full potential of these methods to revolutionize embeddedsystem designis just now becoming clear with the advent of processors that include increasing numbers of CPU cores. Along with global object networking support, embedded virtualization is primed to become the standard way of building large multi-OS systems.
