Advanced Embedded Systems

1. Advanced Embedded Systems Lecture2 Design Goals and Methodologies. Specifications

2. Advanced Embedded Systems 1. Design goals • If we want to design an ES for a certain application area, we must: • Determine specific goals for the project and • Estimate their feasibility; • The requirements are: • Functional: determined by the application; • Nonfunctional: determined by the application and other factors (e.g. marketing); • An ES design project may have many goals, some of them being measurable; • Key metrics for a digital system design: performance, energy/ power consumption, manufacturing cost, design cost, lifetime cost; • Performance can be speed, image quality, packet loss etc. and can be measured in different ways: • Average performance versus worst – case or best – case; • Throughput versus latency; • Peak versus sustained;

3. Advanced Embedded Systems • Energy/ power consumptions are frequently critical metrics: • Energy consumption is important for battery life; • Power consumption determines heat generation; • Manufacturing cost; is determined by the cost of the components and of the manufacturing process; • Design cost is determined by the design work and the specific equipment used (for example servers and CAD tools required to design a large chip increases the cost with several million dollars); • Lifetime cost is determined by hardware and software maintenance and upgrades; • Design time: must be short; • Different values for reliability: a car must have high reliability, a toy will not be designed for a long lifetime; • Quality: may be difficult to define and measure; it may be related to reliability or with other parameters (e.g. a user interface).

4. Advanced Embedded Systems 2. Design methodologies • Methodology codify design practices; • Less important in computer architecture but important in VLSI and ES design; time is important because of diversity, repeatability and design requirements; • It is necessary to understand and document design practices; as a consequence, this: • Saves time in long run; • Makes system design more repeatable; • Design costs (in time and resources) can be predicted; • A design methodology is not an abstraction, it must be defined in terms of available tools and resources; tools are needed especially for multiprocessor heterogeneous architectures for a quick and reliable design, for integrating different types of processors and for connecting memories and processors in multiprocessor systems;

5. Advanced Embedded Systems • Challenges for designers of ESs: • The design space is large and irregular; there are not synthesis tools for many steps from the design process; as a consequence, designers must rely on analysis and simulation for many design phases; • It is not possible (or, at least, it is very expensive and takes much time) to simulate everything in extreme detail; • It is necessary to develop simulators quickly; simulators must reflect the structure of application – specific designs; tools are needed for constructing simulators; however, simulators cannot replace entirely the application, especially in the input/ output area; • Software developers need to be able to write and evaluate software before the hardware is completed; they need to be able to evaluate not just functionality but performance (speed, power consumption) as well; • Next figure shows a prediction for the design complexity (given by Moore’s law which have predicted a 58% annual increase in the number of transistors/ chip) and the designer productivity (a grow of 21%/ year);

6. Advanced Embedded Systems • The result is a continuously increasing gap between the chips which can be manufactured and the chips which can be designed; • A solution for reducing the gap, and for increasing the designers productivity, is ESs in which some of the design tasks are moved to software; for that, methodologies are needed;

7. Advanced Embedded Systems • Basic design methodologies • The waterfall model: for software development: • Is divided in 5 stages: requirements, specification, architecture, coding and maintenance; • Information flows from the top down, meaning from more abstract stages to more concrete stages, but also some information flow back, for improving the design; • The name of the model is given by the flow of information from top to down; • The model is good for codifying the basic steps of software development but unrealistic in software design practices; in practice, designers can go back, rethink earlier decisions and redo some operations;

8. Advanced Embedded Systems • The spiral model: is a refinement of the waterfall model: • It envisions software design as an iterative process in which versions of the system are created from one to the next; • At each phase, designers go through requirements/ architecture/ coding cycle; the results of one cycle are used in the next round of development; experience from one stage is used in the next stage for both a better and a faster design; • Diversity in hardware asks more synthesis and simulation tools to be used;

9. Advanced Embedded Systems • Design methodologies for ESs: • ESs combine hardware and software components; • Concurrent design (hardware/ software codesign) ensures that hardware and software components are designed separately; • Figure shows a generic codesign methodology: starting from an executable specification, an initial system analysis is performed for detecting parallelism and breaking specifications in processes; after that, hardware/ software partitioning is done, they are separately developed and implemented and finally they are integrated, tested for performance and power consumption and debugged for creating the final system;

10. Advanced Embedded Systems • Platform based design is commonly used for ESs; • Platforms are useful when some basic features must be supported but others can be customized in different products; • Platform based design is a 2 stage process; • First, the platform must be designed in accordance with the standard system requirements and how it should be customizable; • After that, the platform can be used to design a product; • Platform design requires several design phases: • System requirements and software models are turned in more specific requirements on the platform hardware architecture; • Hardware alternatives are evaluated by design space exploration; • The details of the architecture are evaluated and optimized by architectural simulation; • Operating system ports, communication protocols, application libraries and debugging must be developed for the platform;

11. Advanced Embedded Systems • ESs design methodologies are affected by standards too; • Standards create large markets, allow devices to interoperate, guarantee the required functions and justify any system design project; • They are very important in system – on – chip design: for covering the costs of design and manufacturing, many chips must be sold and such large markets are created by standards; • On the other hand, standards define complex behavior that must be adhered to by the designer; • The designer will have less flexibility because some features of the architecture will be imposed by the standard; • Most standards offer improvement possibilities too: they define certain operations which must be done but do not specify how to do them (for ex. video compression standards define basic parameters of motion estimation but not which motion estimation algorithm should be performed); the implemented solution can optimize a certain parameter, such as performance, power, cost, quality; the implementation details are beyond the standard;

12. Advanced Embedded Systems • Standards typically provide a reference implementation; it is an executable program written in a HLL (C, Java or others); • The reference implementation is first used to aid standard developers; • After that, it is distributed to implementers of the specification; the reference implementation may be free of charge but usually it is not enough for building a system in accordance with the standard; a license fee must be paid for additional information; • The reference implementation saves designers time but has some liabilities: • To learn someone else’s code is time consuming; • Generally, the code can not be used as – is; reference implementations are typically written for large workstations with infinite memory and are not forecast to operate in real time; for that, they must be restructured: eliminate unnecessary features, replace heap locations with custom memory management, improve or eliminate cache utilization etc.

13. Advanced Embedded Systems • The implementer of a standard must perform several design tasks; • The unspecified parts of the implementation must be designed; • Parts of the system not specified by the standard (user interface, for example) must be designed; • An initial round of platform – independent optimization must be used to improve the chosen reference implementation; • The reference implementation and other code must be profiled and analyzed; • The hardware platform must be designed based on initial characterization; • The system software must be further optimized to better match the platform; • The platform itself must be further optimized based on additional profiling; • The platform and software must be verified for conformance to the standard as well as nonfunctional parameters such as performance and energy consumption;

14. Advanced Embedded Systems • The design must be tested, verified and validated; it is a critical part of any design; activities: • Testing: exercises an implementation by providing stimuli and evaluating the outputs; • Validation: refers to comparing the implementation to the initial requirements or specification; • Verification: may be performed at any stage of the design and compares the design at one level of abstraction to another; • Designs can be verified by a number of techniques: • Simulation: receives stimulus and generates the expected outputs; simulation may directly interpret a design model or the simulator may be compiled from the model; • Formal methods: perform some sort of proof; they require some sort of description of the property to be tested but not particular input stimuli; • Manual methods are error prone; design walkthroughs can identify them; • Designs must be verified and validated at each level of abstraction; design errors are easier to fix if they are detected when they arise;

15. Advanced Embedded Systems • Complex methodologies must be used for designing high – performance embedded systems; they contain: • Software performance analysis: executable specifications must be analyzed to determine how much computing power is needed and which type of operations must be performed; • Architectural optimization: single or multiple processor architectures must be optimized; • Hardware/ software codesign: decreases the time and helps create efficient heterogeneous architectures; codesign algorithms and methodologies exist; • Software verification: software must be evaluated for functional correctness; • Software tool generation: the software and hardware architectures must generate tools for programming the system; • Network design: networks must provide the necessary bandwidth at reasonable energy levels; this is necessary in distributed ESs or in systems – on – chips;

16. Advanced Embedded Systems • Algorithmic design is connected to ESs design; • ESs designers need to understand which type of features are needed for algorithms in different application areas to ensure that the system they design are optimized for the proper characteristics; • ESs architectures may be designed along with the algorithms they will execute; this is true also in standard based systems since standards allow for algorithmic enhancements; • Algorithm designers need estimates and models to help them tailor the algorithm to the architecture; even if the architecture is not complete, the hardware architects should be able to offer estimates of performance and power consumption; these should be useful for simulators that take models of the architecture; • Algorithm designers need to be able to develop software; this needs functional simulators that run as fast as possible; they provide adequate levels of performance for many applications even if they present some differences against the hardware; if hardware were available, algorithm designers could run code at full speed.

17. Advanced Embedded Systems 3. Specifications of ESs • Specifications can be done in a natural language but the solution is inappropriate since it lacks key requirements for specification techniques; • Specifications must be checked for completeness, absence of contradictions and must offer support for implementation in a systematic way; • Specifications should be captured in machine readable, formal language; • Specifications have as inputs: application knowledge, hardware and software components and are support for implementation, meaning hardware/ software codesign, task concurrency management, high – level transformations, design space exploration, hardware/ software partitioning, compilation and scheduling; • There are several requirements and approaches for specifying ESs;

18. Advanced Embedded Systems 3.1. Requirements for specifying embedded systems • Hierarchy: • Humans are generally not capable of understanding systems containing many objects that can be states, components, having complex relations between them; • The description of ESs, generally real – life systems, may need more objects than humans can understand; • The solution is hierarchy; thus, humans need to handle only a small number of objects at any time; • 2 types of hierarchies: behavioral and structural; • Behavioral hierarchies: contain objects necessary to describe the system behavior; they show a functional flow; examples: states, events, output signals; • Structural hierarchies: describe how systems are composed of physical components; examples: an ES is made of processors, memories, sensors, actuators; a processor is made of registers, buses, decoders, adders etc.

19. Advanced Embedded Systems • Timing behavior: specifications must include timing requirements because timing is a critical feature of ESs; • State – oriented behavior: • State – oriented behavior, implemented by automata, are used for modeling ESs and have the advantage of being easy to be described; • However, classical automata models are insufficient since they cannot model timing and do not support hierarchy; • Event – handling: • Mechanisms for describing events must exist since ESs are reactive; • Events can be: external (generated by the environment) or internal (generated by components of the system); • Support for the design of dependable systems: • Specifications should provide support for designing dependable systems • Specification languages should have unambiguous semantics, facilitate formal verification and be capable of describing security and safety requirements;

20. Advanced Embedded Systems • No obstacles to the generation of efficient implementations: specifications should not contain any obstacles against the efficiency of the ESs; • Exception – oriented behavior: • Exceptions occur in many ESs; actions to handle exceptions must be described; • It is not economical to indicate exceptions for each and every state; • For example, in figure, input k may correspond to an exception; specifying this exception at each state makes the diagram very complex and it can be worse for larger state diagrams with many transitions; • All the transitions can be replaced by a single one;

21. Advanced Embedded Systems • Concurrency: many applications require distributed, concurrent ESs; it is necessary to specify concurrency conveniently; • Synchronization and communication: concurrent actions have to be able to communicate and the agreement for the use of common resources must be specified; for example it is necessary to express mutual exclusion; • Presence of programming elements: • Programming language elements should be present in the specifications since programming languages are a convenient mean to express computations; • Classical state diagrams do not have this requirement; • Executability: • The execution of the specifications is a method to check how close are them to the original ideas; • Specifications including programming languages have an advantage in this context;

22. Advanced Embedded Systems • Support for the design of large systems: mechanisms for designing large systems (for example, object – orientation in software technology) should be available in the specification methodology; • Readability: • Specifications have to be readable by humans; • Specifications should also be readable, as a desire, by machines in order to automatically process them; • Domain – specific support: • The ideal situation is when the same specification technique is applied to all the different types of ESs, since this would minimize the effort for developing specification techniques and tool support; • Due to the diversity of the applications it would be difficult to find the unique language appropriate for all the specifications; • For example control – dominated, data – dominated, centralized and distributed applications domains have specific features which must be included in the specifications; they may need different languages for the specifications;

23. Advanced Embedded Systems • Portability and flexibility: • Specifications should be independent of hardware platforms for being easily used for many target platforms; • Specifications should be flexible meaning that small changes of system’s features should require only small changes of the specifications; • Termination: processes that terminate from the specification must be identified; • Support for nonstandard I/ O devices: ESs use different I/ O devices than classical PCs; those specific I/ O devices must be described by the specifications; • Non – functional properties: specifications must describe them; for example: fault – tolerance, size, extendibility, expected lifetime, power consumption, weight, user friendliness, electromagnetic compatibility etc. • Appropriate model of computation: computational models are required for describing computational models.

24. Advanced Embedded Systems 3.2. Models of computation • A model of computation defines the basic capabilities of an abstract computer; • In classical computers, the von Neumann sequential computing model was used; • It is not appropriate for embedded computing because it does not express time; • In embedded computing models of computation help to understand how to correctly and easily program complex systems; • Models of computation help us understand the expressiveness of different programming languages; • Expressiveness has several aspects: • It can show that a style of computing can do things that other styles cannot but also • Can show that a programming language is more adequate for a type of applications than others;

25. Advanced Embedded Systems • Expressiveness may lead to heterogeneous programming: • It means more than a language are used for programming a system; • An extra problem occurs: the communication between modules of different programming languages; • When more languages are used it is more difficult to verify the correctness of the design; the models used by each language and the conditions under which they can reliably communicate are critical steps in heterogeneous programming; • Models of computation can be described as follows: • Models of computation define components; examples: procedures, processes, functions, finite state machines; • Models of computation define communication protocols; they define the mechanisms by which components can interact; examples: asynchronous message passing, rendez – vous based communication; • Models of computation can also define what components know about each other; for example the components may share information about global variables;

26. Advanced Embedded Systems • Examples of models of computation: • Communicating finite state machines; • Discrete event model; • Differential equations; • Asynchronous and synchronous message passing; • Communicating finite state machines (CFSMs): • Are collections of finite state machines communicating with each other; • Methods for communication must be defined; • Finite state machines are easy to verify both in theory and practice; as a result they are important for embedded computing; • A FSM is typically defined as: M = {I, O, S, Δ, T} where I are the inputs, O are the outputs, S is the current state and Δ and T are states and transitions, respectively, of the state – transition graph; • Although there are models for asynchronous FSMs, the notion of synchronous operation is also implemented: inputs are accepted only at certain moments; • At each input the FSM determines its next state based on the input received and on the present state; • There are Moore and Mealy machines; • FSMs view time as integers not as real values;

27. Advanced Embedded Systems • Discrete event model: • In this model there are events carrying a totally ordered time stamp, indicating the time at which the event occurs; • Discrete event simulators typically contain a global event queue sorted by time; • The disadvantage is that it relies on a global notion of event queues and it is difficult to map the semantic model onto specific implementations; • Examples of languages using this model: VHDL, Verilog, Simulink; • Differential equations: they are useful in embedded system modeling since they can model analog circuits and physical systems; • Asynchronous message passing: • Processes communicate by sending messages through channels; • The sender does not need to wait until the receiver takes the message but will send the message only when the receiver announces it is ready; • The communication can be buffered or not;

28. Advanced Embedded Systems • A version of the AMP model is the Data flow model; • A program is modeled by a directed graph made by nodes and edges; the nodes represent the data operations and the edges represent the dependencies between the nodes; • The execution of a program is governed by firing rules; • An example is that a node executes an operation when the data, at its inputs, is present and another example is that a node executes an operation when the node at which its output is connected to requires it; • Each firing rule produces and consumes tokens; • Synchronous data flow model is a version of the data flow model in which processes must produce and execute a certain number of tokens each firing and each edge may be also labeled with a delay that describes the time from the moment a token is produced to the moment it is consumed; it can be statically scheduled so its implementation is very efficient; • The data flow model includes implicitly parallelism since operations are not executed sequentially but according to some rules which may be satisfied in several places simultaneously;

29. Advanced Embedded Systems • Synchronous message passing: • The components are processes which communicate in atomic, instantaneous actions, called rendez – vous; • The processes wait one after the other at different point of communications; • There is no risk for overflows but the speed may be affected; • The communication can be buffered or unbuffered; • In both cases, AMP and SMP, if buffers are used attention must be paid to their size;

30. Advanced Embedded Systems • An advantage of using an adequate model of computation is that it may be easier to identify and extract parallelism from the application; • Parallelism may be found at different levels of abstraction: • Instruction – level parallelism: is implemented in high – performance microprocessors and microcontrollers; the instruction level operations (loads, stores, ALU operations) are not accessible to the programmer so it can not intervene at this level; • Data – level parallelism: can be found in HLLs (for example C) by optimizing compilers; large scale data parallelism can be found in a nest of loops that perform array calculations; • Task – level parallelism: can be found in applications; it can be easy to exploit since tasks can be allocated to processors; • Different applications may require the use of different models; there are languages which implement a single model while others implement a mix of models.