Introduction to Embedded Computing Systems part II Davide Bertozzi - PowerPoint PPT Presentation

Introduction to Embedded Computing Systems – part II Davide Bertozzi davide.bertozzi@unife.it

Embedded System  An embedded system is a special-purpose system in which the computer is completely encapsulated by the “object” it controls.  Customers want to buy the “object”, not its internal computer!  Unlike a general-purpose computer, such as a personal computer, an embedded system generally performs pre-defined tasks, usually with very specific requirements.  Since the system is dedicated to a specific task, design engineers can optimize it, reducing the size and cost of the product.  This is the category of computing devices with the most stringent power budgets and energy efficiency requirements (MOPS/mW). Performance is only modest with respect to other computing segments, however emerging embedded devices are more and more demanding performance-wise.  The power-performance trade-off is exacerbated in battery- operated devices 2

Embedded System Applications 3

Embedded System Applications  Networking  Robotic science  Medical  Router  Ground Vehicles  Dialysis Machine  Hubs  Drones  Infusion Pumps  Gateways  Underwater Vehicles  Cardiac Monitor  modems  Industrial Robots  Prosthetic Device  Military  Home devices  Automotive  Missiles  TVs  Engine Control  Digital Alarm  Energy  Ignition System  Air Conditioner  Brake System  Smart grids  DVD Video Player  Fuel Injection  Space  Cameras  Lighting System  Space Stations  Appliances  Door Locks  Shuttles  Game consoles  Air Bags ……  Many others… 4

Embedded Systems Characteristics Designed for one/ few specific task(s) or for one/few application domain(s).  Generally, they are mass-produced.  I can spend a bit more to make the product super-efficient!  In contrast, cost savings are multiplied by the whole sales volume.  It must be connected with sensors/actuators to perform its mission.  The user is not expected to load a program onto it (only firmware upgrade)  They are often diskless and use Flash memory as secondary storage.  Require real time performance  embedded system must respond to a certain event within a “deadline”!  E.g., anti-lock breaking system (ABS), counter-attack against missile detection   Developed around a real-time operating system (RTOS) It supports deterministic time-bounded performance and feasible scheduling.  They should have high availability, reliability and (increasingly) security.  Reliability: also known as robustness , it is the ability to deliver the intended  function even in abnormal or dangerous situations. One metric: MTBF. Availability: fraction of time a system is operational.  Security: The condition of being protected against attacks, that either take control  of the system or jeopardize its mission (quite nasty in the IoT era!). 5

An Holistic Approach to Design The field of embedded system research is rich with potential because it combines two factors: First, the system designer usually has control over both the hardware design  and the software design, unlike general-purpose computing  Do you remember the “cross-stack” design notion?  developers of embedded software often must understand the working principles and mechanisms of the hardware and hardware layers during the development stage Second, embedded systems are built upon a wide range of disciplines,  including computer architecture, memory system design, compiler, scheduler/operating system, sensors, energy harvesting and storage, connectivity. Combining these two factors means that barriers between these fields can  be broken down, enabling synergy between multiple fields and resulting in optimizations which are greater than the sum of their parts. 6

Real-Time Operation In real-time embedded systems tasks must be executed in a predictable amount of time, within maximum execution time limits. Real time is divided into soft real time and hard real time .  Soft real time has less-stringent requirements; even if the time limit cannot be  met in some cases, it won’t have a fatal impact on the system. For example, a media player system is soft real time. The system is supposed to play 24 frames in one second, but it is also acceptable when the system fails in some overloaded conditions. Hard real time has strict requirements. The execution of tasks must be absolutely  ensured in all situations; otherwise the consequences will be catastrophic. For example, aircraft autopilot and navigation system are hard real-time systems. They must accomplish a specific task within the certain time limit; otherwise a major accident, collision, or crash could occur. Many embedded systems (mobile phones, game consoles, and so on) do not  need real-time guarantees. But real time is the key for some embedded systems (e.g., industrial control, telemedicine, avionics, automotive, etc.) In real time systems, enforcing time bounds for operations is more  important than performing such operations in short times! 7

An Ideal World: Performance Predictability AND Efficiency One fundamental challenge with embedded systems is delivering predictably  good performance.  Many embedded systems (e.g. anti-lock brakes in a car) have real-time requirements; if computations are not completed before a tight deadline, the system will fail, possibly injuring the user. Unfortunately, many of the performance enhancing features which make  general-purpose computers so fast also make it difficult to predict their performance accurately.  Such features include pipelined and out-of-order instruction execution in the processor, and caches in the memory system. Hence real-time system designers typically operate between two opposite  extremes:  .. designing fast systems with easily predictable technologies (if at all feasible),  ..or more accurately measuring existing complex but fast systems (if at all possible). 8

Are Embedded Systems Really Application-Specific?  Their task specific nature make embedded systems rather different from general-purpose computing (laptops, desktop PCs, HPC, datacenter servers)  However, some embedded systems have grown into something similar to a general-purpose computer…  I hardly find the phone icon in a smartphone!!!!!!!!!  Nonetheless, few people would buy a cellphone just for its gaming capability …. This is secondary (yet important!): you still buy a cellphone to call somebody.  With respect to desktop PCs and servers, they do connect to sensors/actuators.  Similarly, I can watch movies and connect to the internet on my game console. But not as easily on all of them! Also, the degree of «general-purposeness» is  limited (file mgt, Office suite support, etc.) 9

General Purpose Computing: Different Trade-Offs  Designers of embedded devices face more constraints than designers of general-purpose devices.  Power, energy efficiency (MOPS/mW), cost, and physical dimensions usually have a much bigger role in embedded systems  This is not to say that embedded devices are more difficult to build than general purpose devices: the latter tend to have higher overall performance goals (most aggressive: 1 exaFLOP per second) and huge compatibility requirements (backward compatibility with existing software is a must).  But the overall priorities and the balance among them are rather different for embedded devices. 10

Integrated Hardware and Software  General-purpose computers install software dynamically. The software can be installed and uninstalled according to the users’ demands, or by the user itself.  But for embedded systems, software and hardware are often integrated and sold as a package.  This trend is shifting for devices that are always connected via the Internet, such as smartphones, Internet of Things (wearables, for example) or game consoles. In these cases, original device manufacturers (ODMs) can do regular software updates, and/or the user itself can download applications. 11

Integrated Hardware and Software  Embedded software is usually built into the hardware ROM or Flash memory, and runs automatically when the system is started.  Under normal circumstances, the user cannot easily modify or delete the software without the aid of special tools to ensure the integrity of the embedded system.  Due to the tight integration of hardware and software (i.e., software is written FOR a specific hardware), software piracy on embedded systems is less of an issue than in general- purpose computing.  This also makes “system software upgrade” more intricate and less frequent.  However, the vendor might want to protect the IP “encoded” in a piece of software. 12

Generic Hardware Architecture 1) Where is the chip boundary? 2) How does the processor look like? 13