For tomorrow's communications networks...

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.


refer:http://embedded-computing.com/articles/next-generation-architectures-tomorrows-communications-networks/

New dimension in operating systems

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, embedded or otherwise, consists of not only physical resources – memory, CPU cores, peripherals, and buses – managed with some success by resource partitioning (virtualization), but also performance resources 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.

Most existing management schemes are fragmented. CPU cycles are managed by priorities and temporal isolation, meaning applications that need to finish in a preset amount of time are reserved that time, whether they actually need it or not. Because execution time is not safely predictable due to cache misses, miss speculation, and I/O blocking, the reserved time is typically longer than it needs to be. To ensure that the modem stack in a smartphone receives enough CPU cycles to carry on a call, other applications might be restricted to not run concurrently. This explains why some users of an unnamed brand handset complain that when the phone rings, GPS drops.

Separate from this, power management has recently received a great deal of interest. Notice the “separate” characterization. Most deployed solutions are good at detecting idle times, use modes with slow system response, or particular applications where the CPU can run at lower clock speeds and thus save energy. For example, Intel came up with Hurry Up and Get Idle (HUGI). To understand HUGI, consider this analogy: Someone can use an Indy car at full speed to reach a destination and then park it, but perhaps using a Prius to get there just in time would be more practical. Which do you think uses less gas? Power management based on use modes has too coarse a granularity to effectively mine all energy reduction opportunities all the time.

refer:

http://embedded-computing.com/articles/performance-management-new-dimension-operating-systems/

About embedded virtualization

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 embedded virtualization technology came about with the idea of creating an environment where a Real-Time Operating System (RTOS) could work alongside a General-Purpose Operating 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 application software packages 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.

refer:

http://embedded-computing.com/articles/the-multiprocessor-multi-os-systems/#utm_source=Multicore%2Bmenu&utm_medium=text%2Blink&utm_campaign=articles