Hardware dependent software

Contents Introduction Objectives of Hardware-dependent Software Computer Architecture Foundations 3.1 Central Processing Unit 3.2 Bus-System 3.3 Peripheral Devices 3.3.1 Device Core 3.3.2 Register File 3.3.3 Device and Computer System Structure 3.4 Conclusion Communication and Synchronisation 4.1 Communication 4.1.1 Nature of the Register File 4.1.2 Communication on Software Side 4.2 Synchronisation 4.2.1 Synchronisation Principles 4.2.2 Strange Behaviour of Register Files 4.2.3 Message Transfers 4.2.4 Functionality Adjustment 4.2.5 The Semantic Layer 4.2.6 Functional Synchronisation Design 5.1 Object-Oriented Design 5.1.1 Object-Oriented Layering 5.1.2 Applying Design Pattern 5.1.3 Device Counterparts 5.1.4 Topology Analysis 5.1.5 Descriptors and Caching 5.2 Activity Based Design 5.2.1 Overview 5.2.2 Data Acquisition Example 5.2.3 Conclusion and Open Problems 5.3 State Machine Based Design 5.3.1 Finte State Machines 5.3.2 Hardware/Software-Codesign Perspective 5.3.3 Software Modelling with FSM 5.3.4 Conclusion Device Driver 6.1 Interfacing Device Drivers 6.2 System Start-up and Shut-down 6.3 Management of Devices 6.3.1 Handling Single Devices 6.3.2 Multiple Devices and Va riant Management 106 6.3.3 Service Addressing 6.3.4 Hot-Plugging 6.3.5 Reconfigurable Devices Development 7.1 Software Engineering 7.1.1 Life Cycle and Project Management 7.1.2 Requirements Engineering 7.1.3 Architecture and Design 7.1.4 Implementation and Integration 7.2 Debugging 7.2.1 Observing the System 7.2.2 Software Side Debugging 7.2.3 Hardware Side Debugging 7.3 System Simulation/Emulation and Te sting 7.3.1 System Simulation 7.3.2 Subs, Mocks and other Integrated Simulations 7.3.3 Device Simulation 7.4 Summary A Appendix A.1 Replacement Techniques A.1.1 Control by Configuration Management A.1.2 Code Changes on Calling Side A.1.3 Binding Time Selections A.1.4 Dynamic Branching during Runtime Introduction What is Hardware-dependent Software (HdS) in comparison to ”normal software”? What is the difference? What is specific to a device driver or a Hardware Abstraction Layer (HAL)? First of all, the term ”normal software” is already hard to define which makes the comparison more difficult Within this book, Hardware-dependent Software (HdS) is seen as a Software System which operates in close relationship with digital hardware, often called peripheral device or simply device HdS interacts with the device, controls it, steers it Furthermore, it extends the hardware functionality, restricts it, and hides away or encapsulates problems of the hardware/software interaction Functionality in software components and on the opposite in hardware operate in their own execution domains HdS interacts with those execution domains in hardware The execution domains need to be connected and synchronised, which is in the responsibility of HdS This synchronisation is a mayor topic, so this book will focus on it HdS is more than a Hardware Abstraction Layer (HAL) that just provides a first common interface of the underlying hardware platform A common interface as a low-level abstraction focusing on portability on lowest level or closest level to the hardware Figure 1.1.: HdS as part of the system, without HAL or as dominating part Within the microcontroller domain, a whole application can be interpreted as HdS, as in most cases the software just coordinates the interaction of the peripheral devices Or the control logic of the application is a fraction in comparison to the part that can be interpreted as HdS Within that domain, HdS can additionally be seen as a library for the development of embedded applications So the HdS is here the basement for higher-level applications It provides, as a component, services similar to a software library but including hardware interaction (see Figure 1.2) Regarding the functionality provided, HdS and so called device driver are closely related To distinguish HdS from device driver, a device driver is here a hardware-dependent software component that is integrated or operates in the context of an operating system (OS) This needs extra considerations on the design, as the OS on the one hand restricts interfaces and communication channels, respectively determines parts of the architecture On the other hand, the OS provides common services, that ease the design of device drivers So software, that is typically denoted as device driver, is here HdS in the environment of an operating system Figure 1.2.: Hardware-Dependent Software in comparison to libraries Figure 1.3.: HdS as low-level component of a library/OS Peripheral devices often interact with other (hardware) components, or to be more precise, an outside world As software contains a model of the domain it is designed for, the behaviour of the outside world and the interaction needs consideration during the design of the HdS But the focus stays on the interaction with peripheral devices So the control of a robot, factory, UAV, etc falls into the application domain is off topic here Nevertheless it is a smooth transition HdS ranges from a tiny HAL, via more complex modules, device drivers, up to nearly full applications All are closely related or interact with hardware devices This interaction leads to typical structures and makes the software design often look tricky On the other hand, the exploding demand of embedded systems with realtime, reliability, security and safety constraints make the design of HdS a crucial domain Within this book, interaction means are analysed and designs approaches discussed So the whole book is organised in a bottom-up approach All topics are discussed as general as possible, to emphasis on principles and methodology, and not on ”and in case of the controller x454B92A, you have to create a function that toggles bit 5 ” The later can be found in various books on microcontroller programming, but without looking at the underlying principles and methodologies This book starts with a short discussion on the intention of HdS After that, a brief review on computer architecture principles follows to have a common understanding on the underlying hardware architecture HdS and hardware devices are parallel executing elements In parallel systems, the communication and synchronisation means are essential Hardware devices and software execute according to different paradigms Both sides need consideration to design software components which aim to reach higher levels of abstraction HdS can be designed with usual software engineering methods for parallel systems based on the found communication and interaction model A software design is driven by different views on the system The design of HdS from different perspectives is discussed based on the design and modelling with description languages like the Unified Modelling Language (UML) Specific issues on device management, device drivers, and software development in this special area are later on discussed in separate chapters Objectives of Hardware-dependent Software Hardware-dependent Software is software that provides services in cooperation with hardware, the device Main objective is to make hardware-services available to other higher-level software components Furthermore the Hardware-dependent Software may emulate missing functionality or restricts the access to hardware functionality So the hardware and the environment it interacts with is protected against illegal operation requests Another objective is the management of multiple devices as hot-plugging techniques and power-management let the devices disappear during runtime This chapter briefly introduces the objectives in order to give an overview were the other analysis and design steps of the following chapters are aiming for For now lets focus on the nature of Hardware-dependent Software (HdS) for a moment We will return to the hardware part in the section on computer architecture again In this section, the various objectives of a HdS shall be introduced to give a first inside into the complexity of HdSdesign within this domain Hardware-dependent Software is often denoted as low1-level software This is true, as it operates close to the hardware of the execution platform and its peripheral components, simply denoted as devices In embedded systems, the focus of the system is on the interaction with a physical environment via those peripheral components/devices Hence, the majority of software components are related to hardware Furthermore, operating systems can be seen as a collection of device drivers which are in terms of this book Hardware-dependent Software components within an operating system environment Figure 2.1.: Overwiew of the interaction First of all, HdS makes the hardware functionality available to higher level software At the beginning with the initialisation and configuration of the device for the expected operations, later with interaction functions The availability of device functionality is often crucial for the commercial success of the device vendor If the functionality isn’t available with the required performance and quality by the driver (HdS), the device cannot demonstrate its full potential One key competence is to reveal this potential and grand interoperation with it The design of the HdS determines which part of the hardware is available via the interface towards higher software functionality, here denoted as Application Which level of abstraction is reached at the application interface? Furthermore, as the hardware may interact with other hardware components or the outside world, does the HdS provide appropriate access to them? These questions must be determined by the intended use and influence the design For one kind of applications, a very low-level channel to parts of the hardware is required, for other applications, a very high-level view is needed Figure 2.2.: HdS as adaptor layer between application and hardware So in some cases, the HdS allows transparent access to parts of the device and at the same time a transparent access to devices beyond the own device with a high level of abstraction However, HdS is the adaptor between the needs of an application and the provided capabilities of the peripheral device and the associated end point(s) inside the device core Figure 2.3.: HdS accesses different endpoints in device core Software on CPU and hardware devices execute in parallel, whereas the digital circuit in the device is a massive parallel system itself The functionality of the software side and on the hardware side needs to synchronise at specific points Devices provide a wide range of synchronisation means which must be understood and the counterpart in software needs to be realised Hardware devices and HdS in combination provide a service as a whole So functionality can be either implemented in hardware or in software (compare the HW/SW-Co-Design approach) Thus HdS not only makes hardware functions available, it can extend them with additional functionality (compare a in Figure 2.4) The functionality is emulated in software by using resources of the target platform, like the main CPU and main memory In extreme cases, the HdS provides the service just with the later ones and without any real existing device A good example is the RAM-disk It behaves like a hard-disk but is emulated with the CPU and the main memory by the RAM-disk driver Another mid-level approach is to emulate a behaviour at the application interface with the support of hardware of different kind (compare Figure 2.4 b)) For example, a CD-ROM is emulated with a hard-disk Read access to the disk image is supported, but write is not allowed (or just only for initialisation) in order to fulfil the semantic of a write-only device The partial emulation of devices implies another approach, that not all functionality of a device is accessible and usable via the HdS (compare additional hardware-ports in Figure 2.4 c)) The non-availability restricts the usage of the device This is often the case, where hardware devices are designed for a superset of possible use-cases For marketing or production reasons, the combination of specific HdS, mostly in the sense of device driver, and the common device determine as a whole the set of available services The variation of the software determines the functionality variant In summary, HdS provides a restricted access, enables the full potential of a device, or extends it by emulation of additional functionality of control is part of the access flow of control (compare Fig A.7), so the access is registered simply by execution of the simulation Figure A.7.: Request is rejected by first simulation (not responsible) and served by second simulation including performing the simulation step as part of the request Base idea is, that simulation objects are responsible for a dedicated address space, where it simulates the register file and the device behaviour attached to the register file It computes the responses of read and write transactions to the register file Additionally, for each transaction the object signals whether it has been responsible for that transaction or not All simulation objects, with non-overlapping address-spaces5, form the Chain of Responsibility Figure A.8.: Chain of Responsibility to manage device simulations The managing object (of class TransferAccessPoint in Fig A.8 and A.9) for the chain replaces the transfer layer in an address oriented communication system, usually the bus-system access (compare same interfaces in Fig A.9) The invocation of a transaction is passed to the first object in chain of responsibility If that object is responsible (access within its address range), it performs the (simulated) transaction and returns the result, including signalling its responsibility (success) If an object is not responsible, it signals that, and the request is passed to the next object in the chain In case non of the objects is responsible, as default reaction the request is executed as real transaction on the communication channel, the bus-system (see Fig A.10) Figure A.9.: Chain of Responsibility to manage device simulations with real access as last object in chain Either the chain managing object passes the call to the real access object or the object for the real access is the last object in the chain, dedicated to perform real transactions if no simulation claims responsibility (compare different interfaces for BusAccess class in Fig A.8) Figure A.10.: Processing of write transaction in chain with success on second simulation object and hand over to real access on fail A factory method (compare [21]) sets up the chain, to separate that concern from the entrance object The factory incarnates and configures the simulation objects, and establishes the chain The configuration is hard-coded or depends for instance on a description (file) processed by the factory method The chain configuration set-up is not bound to the start-up, it can be altered at any time, so that maybe the real device is accessed during start-up and the simulation takes over at a dedicated point whilst operation Hence, the design space is the address-range an chain-object is responsible for and the time when it is part of the chain of responsibility So for multiple devices of the same kind, differentiated by base-address, one device can be simulated by an simulation object, the other devices are really accessed The more real devices are available, the shorter the chain, until all devices are ready and a simulation is no longer needed The moment the chain is empty, the entrance object is replaced with the real transfer object to increase performance Even if simulations require a higher development effort, they help to reduce risks in misunderstandings or allow the test of critical scenarios Finally, depending on the actual development situation, various approaches can be combined 1As long as the compiler/linker does no dead code elimination 2Redirection of the flow of control on source code level should not be done manually for the different variants It is boring and hence error prone 3Version control works on file level, hence the method must work on file level as well 4The SystemC approach follow the same idea, the system is modelled as a high-level executable SystemC model and than implemented in hardware and software 5In case of overlapping address spaces, the first responsible object in the chain wins and serves the request Bibliography [1] D Anderson and Inc MindShare FireWire System Architecture: IEEE 1394a PC System Architecture Series Addison-Wesley, 1999 [2] Kernel Programming Guide https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/KernelProgramming/K Accessed 18 Sep 2013, 2013 [3] ARM Limited Embedded Trace Macrocell Architecture Specification, 2011 [4] C Warren Axelrod Engineering Safe and Secure Software Systems Artech House, Boston, 2013 [5] Background Debug Mode https://en.wikipedia.org/wiki/Background_debug_mode_interface Accessed 30 Jan 2016, 2016 [6] Daniel Bimschas, Oliver Kleine, and Dennis Pfisterer Debugging the Internet of Things: A 6LoWPAN/CoAP Testbed Infrastructure In ADHOC-NOW, pages 207–220, 2012 [7] Frederick P Brooks The Design of Design: Essays from a Computer Scientist AddisonWesley Professional, 1st edition, 2010 [8] R Budruk, D Anderson, and T Shanley PCI Express System Architecture PC System Architecture Series Addison-Wesley, 2004 [9] ISO 11898 Road vehicles Controller area network, 2003 [10] Scott Chacon and Ben Straub Pro Git Apress, Berkely, CA, USA, 2nd edition, 2009 [11] Laura Chappell Wireshark 101: Essential Skills for Network Analysis Chappell University, 1 edition, 2013 [12] Lim Chinghway, N Singh, and S Yajnik A Log Mining Approach to Failure Analysis of Enterprise Telephony Systems In Dependable Systems and Networks With FTCS and DCC, 2008 DSN 2008 IEEE International Conference on, pages 398–403, June 2008 [13] Marcello Cinque, Domenico Cotroneo, and Antonio Pecchia Event Logs for the Analysis of Software Failures: A Rule-Based Approach IEEE Transactions on Software Engineering, 39(6):806–821, 2013 [14] HyperTransport Technology Consortium HyperTransport I/O Link Specification, Revision 1.03 Technical report, 2001 [15] Jonathan Corbet Towards more Reliable Logging https://lwn.net/Articles/492125 Accessed 2014-01-18, April 2012 [16] Mirko Dölle Namensgeber c’t, 23:188, 2008 [17] External Bypassing http://www.dspace.com/en/pub/home/products/systems/functp/bypassing.cfm Accessed 30 Jan 2016 [18] W Ecker, W Müller, and R Dömer Hardware-dependent Software: Principles and Practice Springer, 2009 [19] McCullough et al Trace Reporting Method and System, Sep 2003 [20] M Fowler, K Beck, J Brant, W Opdyke, and D Roberts Refactoring: Improving the Design of Existing Code Addison-Wesley Object Technology Series Pearson Education, 2012 [21] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1995 [22] GDB and Reverse Debugging https://www.gnu.org/software/gdb/news/reversible.html Accessed 15 Jun 2016, 2012 [23] U Gleim and T Schüle Multicore-Software: Grundlagen, Architektur und Implementierung in C/C++, Java und C Dpunkt.Verlag GmbH, 2011 [24] Mark G Graff and Kenneth R van Wyk Secure Coding - Principles and Practices O’Reilly, 2003 [25] Thorsten Grötker, Ulrich Holtmann, Holger Keding, and Markus Wloka The Developer’s Guide to Debugging Springer Publishing Company, Incorporated, 1st edition, 2008 [26] U Hammerschall and G.H Beneken Software Requirements Pearson it: Informatik Pearson, 2013 [27] John L Hennessy and David A Patterson Computer Architecture, Fourth Edition: A Quantitative Approach Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2006 [28] IBM Microelectronics Division, Research Triangle Park, NC The PowerPC 440 Core, 09 1999 [29] Medical Device Software Software Life Cycle Processes, 2006 [30] IEEE Standard for a High-Performance Serial Bus, 2008 [31] 1149.1-2013 - IEEE Standard for Test Access Port and Boundary-Scan Architecture, 2013 [32] INCOSE, editor Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities John Wiley and Sons, Inc,, Hoboken, NJ, USA, version 4.0 edition, 2015 [33] An Introduction to the Intel Quickpath Interconnect Technical report, Intel Corporation, 2009 [34] Interrupt https://en.wikipedia.org/wiki/Interrupt Accessed 23 Jan 2016, Nov 2015 [35] Noriaki KANO, Nobuhiko SERAKU, Fumio TAKAHASHI, and Shin-ichi TSUJI Attractive Quality and Must-Be Quality Journal of the Japanese Society for Quality Control, 14(2):147–156, apr 1984 [36] Bjrn Ldemann Synthesis of human-readable Statecharts from Sequence Diagrams Diploma thesis, Christian-Albrechts-Universität zu Kiel, Kiel, August 2005 [37] Thomas Lehmann Towards Device Driver Synthesis PhD thesis, University of Paderborn, 2003 [38] Thomas Lehmann and Mauro Zanella Modeling and Software Synthesis of Interrupt Systems In GI/ITG/GMM Workshop: Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systemen, Tübingen, Fe b 2002 GI/IT-G/GMM [39] Marc-Ruben Lorbeer Realisierung linearer und nichtlinearer Rekonstruktionsansätze auf der CUDA-Architektur zur Rekonstruktion optischer computertomographischer Daten Masterthesis, HAW Hamburg, HAW Hamburg, Berliner Tor 7, 20099 Hamburg, October 2011 [40] Robert C Martin Clean Code: A Handbook of Agile Software Craftsmanship Prentice Hall PTR, Upper Saddle River, NJ, USA, 1 edition, 2008 [41] Adam Oliner What Supercomputers Say: A Study of Five System Logs In Proc of DSN 2007, 2007 [42] Adam Oliner, Archana Ganapathi, and Wei Xu Advances and Challenges in Log Analysis Commun ACM, 55(2):55–61, 2012 [43] OMG Systems Modeling Language (OMG SysMLTM), September 2015 [44] OMG Unified Modeling LanguageTM (OMG UML), Superstructure, August 2011 [45] Walter Oney Programming the Microsoft Windows Driver Model Microsoft Press, Redmond, WA, USA, 2nd edition, 2003 [46] Frank Opitz, Edris Sahak, and Bernd Schwarz Accelerating Distributed Computing with FPGAs Xcell Journal, pages 20–27, 2012 [47] Thomas W Parsons An Introduction to Compiler Construction W.H Freeman and Company, 1997 [48] D.A Patterson and J.L Hennessy Computer Organization and Design, Fourth Edition: The Hardware/Software Interface The Morgan Kaufmann Series in Computer Architecture and Design Elsevier Science, 2008 [49] PCI Specification 2.2 http://www.pcisig.com Accessed 15 Jun 2016, 1998 [50] Mario Porrmann, Ulf Witkowski, and Ulrich Rückert Implementation of Self-Organizing Feature Maps in Reconfigurable Hardware In Amos Omondi and Jagath Rajapakse, editors, FPGA Implementations of Neural Networks Springer-Verlag, 2005 [51] Kplugs http://www.kplugs.org Accessed 15 Jun 2016, 2016 [52] QNX Operating System: System Architecture QNX Software Systems Ltd., 1997 [53] J Quade and E.K Kunst Linux-Treiber entwickeln: Eine systematische Einführung in die Gerätetreiber- und Kernelprogrammierung Dpunkt.Verlag GmbH, 2011 [54] Martin Reddy API Design for C++ Academic Press, 2011 [55] J Reichardt and B Schwarz VHDL-Synthese: Entwurf digitaler Schaltungen und Systeme Oldenbourg Wissenschaftsverlag, 2012 [56] Steven Rostedt KernelShark http://rostedt.homelinux.com/kernelshark Accessed 11 May 2013 [57] Steven Rostedt Debugging the Kernel using Ftrace http://lwn.net/Articles/365835 Accessed 11 May 2013, Dezember 2009 [58] M Samek Practical UML Statecharts in C/C++: Event-Driven Programming for Embedded Systems Electronics & Electrical Newnes/Elsevier, 2009 [59] Stefan Sarstedt Semantic Foundation and Tool Support for Model-Driven Development with UML 2 Activity Diagrams PhD thesis, University of Ulm, 2006 [60] Christian Schamott Einsatzmöglichkeiten von SysML und Methoden des Variantenmanagements im Entwicklungsprozess eines Flurförderzeugs Masterthesis, HAW Hamburg, Hamburg, Nov 2011 [61] Simulink http://de.mathworks.com/products/simulink Accessed 29 Jan 2016 [62] Ian Sommerville Software Engineering Pearson Studium Addison-Wesley, edition, 2007 [63] A Spillner, T Linz, and H Schaefer Software Testing Foundations: A Study Guide for the Certified Tester Exam Rocky Nook, 2014 [64] RM0008 - Reference manual STM32F101xx, STM32F102xx, STM32F103xx, STM32F105xx and STM32F107xx advanced ARM-based 32-bit MCUs, Doc ID 13902 Rev 11 edition, April 2010 [65] STM8 SWIM Communication Protocol and Debug Module, 2011 [66] Andrew S Tanenbaum Modern Operating Systems Prentice Hall, 3rd edition, 2007 [67] The BeOS Development Team BeOS Advanced Topics-The Official Documentation for the BeOS O’Reilly, 1998 [68] W M P van der Aalst Inheritance of Dynamic Behavior in UML In Proceedings of the Second Workshop on Modelling of Objects, Components and Agents (MOCA 2002), volume 561, pages 105–120, Aarhus, Denmark, August 2002 [69] Sreekrishnan Venkateswaran Essential Linux Device Drivers Prentice Hall Press, Upper Saddle River, NJ, USA, first edition, 2008 [70] Michael Williams Low Pin-count Debug Interfaces for Multi-device Systems Technical report, ARM Limited, 2009 [71] Wind River Wind River(R) Workbench User’Guide, 2.5 edition, 2006 [72] Vxworks Operating System http://www.windriver.com/products/vxworks Accessed 11 May 2013 [73] WinDriver - Driver Development Tool http://www.jungo.com/st/products/windriver Accessed 11 May 2013 [74] Xilinx Inc ChipScope Pro 13.1 Software and Cores, v13.1 edition, March 2011 UG029 [75] Xilinx, Inc ML505/ML506/ML507 Evaluation Platform User Guide, ug347 (v3.1.2) edition, May 2011 [76] Fabian Zahn Code-Generierung aus SysML-Konnektoren mit gemischten Hardware/Software-Endpunkten Bachelorthesis, University of Applied Sciences, Hamburg, 2011 [77] Andreas Zeller Why Programs Fail: A Guide to Systematic Debugging Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 2005 Index access detection, →, → non-aligned, → acknowledge on access, → activity diagram, →, → data buffer, → ForkNode, → JoinNode, →, → swimlane, → address decoding, → adjustment tool, → analog to digital converter, →, → analogous world, → API, →, → ASIC, →, → automaton Mealy, → Moore, → babbling idiot, → base address, →, → bit-field, →, → operations, →, → spreading, →, → build management, → bus bridge, →, → bus-system, → cache, →, → cache line, → caching, → register values, → call-back function, →, → combined transfers, → communication bus side, → device core side, → compatible, → compile time, →, → computer topology, →, → configuration management, → control data, → cost estimation, → CPU register, → transfer from/to, → data bus, →, →, → debugger, →, → front end, → hardware, → in-circuit, → in-circuit debug interface, → software, →, →, → system, → target debugger, → debugging, → breakpoint, →, → bus protocol, → cross-side, → cross-site, → external trigger, → halt CPU, → halt peripherals, → hardware breakpoint, → holding the system, → instruction pointer, → log-file, → log-file analysis, → log-file filtering, → logging system, → logic analyser, → memory access, → post-mortem, → setting breakpoints, → software breakpoint, → stack trace, → state examination, → system hold, → tags, → trace, →, → tracing, →, → tracing depth, → tracing system, → dependency injection, →, → design pattern, → adaptor, → chain of responsibility, →, →, → dependency injection, → facade, →, → factory, →, →, →, →, →, → leaky bucket, → observer, → reactor, → development process, → device class, → device core, →, → parallel access, → device descriptor, →, →, → device driver, → device header, → device identification, →, → digital storage oszilloscope, → digital to analog converter, → driver architecture, →, → driver initialisation, → dual-port memory, → dynamic link library, → effective address, → emulation, →, → endian, → big, → little, → event driven, → execution in-order, → massive parallel, → out-of-order, →, → execution domains, →, → parallel, → sequential, → field programmable gate array, →, → field programmable gate arrays, → FIFO-buffer, →, → finite state machine, →, → finte state machine, → in hardware, →, →, → in software, →, → partitioning, → firmware, → flag, →, → clear-on-access, → FPGA, see also field programmable gate array ASIC emulation, → FSM, see also finte state machine ftrace, → function emulation, →, → function pointer, → functional adjustment, → decision point, → graphical processing unit, → Guard, → HAL, →, → handle, → hardware in the loop, → hardware-dependent software, →, →, → hardware/software-codesign, → hazardous situations, → Heisenbug, →, → hot-plugging, →, →, →, → checkpointing, → electrical level, → pluggable device, → reconfigurable device, → serial communication links, → un-plugging, → inlining, → input/output, → integration project, → interprocess communication, →, → interrupt handling, → interrupt request, →, →, →, →, → interrupt service routine, →, →, →, →, →, →, → system freeze, → IPC, see also interprocess communication IRQ, see also interrupt request, see also interrupt request ISR, see also interrupt service routine JTAG, → Kano-model, → kernel-thread, → late linking, →, → layer manipulation layer, →, →, → semantic layer, →, →, → transfer layer, → layered architecture, →, → layering, → live cycle, → logic-analyser, → major number, → manipulation layer, →, → mapping CPU-register, → mask, →, → masking, → memory cell, → memory map, → gaps, → one-to-one, → memory mapped I/O, →, →, → memory-barrier, → message transfer, →, → messages, → long messages, → short messages, → minor number, → mock object, →, → model mental, → multi-core, → mutex, → observation probes, → operating system, → paradigms execution in simulation, → parallel system non-syncronised, → PCI, → peripheral bus, →, →, →, →, →, → peripheral device, → polling, →, →, → advantage over ISR, → polymorphism, → power down, → power management, →, → processing element, →, →, →, → processor local bus, → program to an interface, → project planning, → protocol state machine, → proxy, → PWM measurement, → race condition, → read-modify-write, →, → cycle, → reconfigurable devices, →, → register, → access observation, → register cell, →, → register file, →, →, →, → as adaptor, → byte-oriented memory behaviour, → domain adaptor, → enhanced functionality, → memory cell behaviour, → read access detection, → read-only behaviour, →, →, → reduced manipulation means, → set- and clear-register, → special encodings, → strange behaviour, → write access detection, → write-only, → write-only behaviour, → register reaction read, write, → requirements engineering, → restart cold, → warm, → revision, → run time, → run to completion, → runtime, → runtime patching, → safety, → safety integrity, → security, → Semantic Layer, → separation of concern, → service end-point, → service entry-point, →, → services, → shadow buffer, →, →, →, → shared memory access observation, → simulation, →, →, → device, → system, →, → sleep mode, → Software Life Cycle, → stakeholder, → state qualitative, → quantitative, → state machine ChangeEvent, → modelling with, → orthogonal region, → stub, →, → synchronisation, → by token and time, → device and CPU, → logic analyser and debugger, → non-interlocked, → shared-token principle, → two-token principle, →, → synchronisation schema fully interlocked, → fully-interlocked, → half-interlocked, →, →, → non-interlocked, → synchronous sampling, → syncronisation implicit, → SysML, → system architecture, → system boot, → system context, → system observation, → system on programmable chip, → system shut down, → system shut-down, → system start-up, →, → technical risk, → timestamp, →, →, → top-down approach, → transfer atomic, →, → non-atomic, → transfer layer, →, →, → interface of, → Trigger, →, → UML, →, →, → unit under test, → USB device driver, → host controller, → interface semantic, → variant, →, →, → variant code, →, → variant management, →, → variation point, → vendor ID, → version, →, → version code, → version control system, → version management, → wait blocking, → non-blocking, → Bibliografische Information der Deutschen Nationalbibliothek: Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über www.dnb.de abrufbar Copyright © Thomas Lehmann, 2017 Cover design and pictures: Thomas Lehmann Print and publishing: BoD - Books on Demand GmbH, Norderstedt ISBN: 978-3-7431-2976-4 Products and company names mentioned in this book may be trademarks of their owners ... device drivers, and software development in this special area are later on discussed in separate chapters 2 Objectives of Hardware- dependent Software Hardware- dependent Software is software that provides services in cooperation with hardware, ... Hardware- dependent Software is software that provides services in cooperation with hardware, the device Main objective is to make hardware- services available to other higher-level software components Furthermore the Hardware- dependent Software may emulate missing functionality or... the hardware/ software interaction Functionality in software components and on the opposite in hardware operate in their own execution domains HdS interacts with those execution domains in hardware