Lehmann Hardware-dependent Software

A Classical Approach
1. Auflage 2017
ISBN: 978-3-7431-2976-4
Verlag: BoD - Books on Demand
Format: EPUB
Kopierschutz: 6 - ePub Watermark

E-Book, Englisch, 184 Seiten

Software is in many cases interacting with hardware, the peripheral devices, to interact with is physical environment. Those hardware-dependent software parts, in the context of an operating system better known as device driver, are crucial for system performance and stability. In order to design hardware-dependent software, the principles and foundations of the interaction between hardware and software needs to be understood on lowest level as well as on abstract level. The reader can follow the ideas and principles from foundations in computer architecture over low-level communication up to software design and development methods. Describing the interaction with UML gives the software engineer direct hints on how to design the software based on model driven techniques and show the limits its expressiveness in this area. The textbook avoids programming language or operating system dependencies to reveal the underlying, often hidden principles. Nevertheless, as software development is complex in this area, one focus point in the development cycle is on debugging techniques for hardware-dependent software.

Thomas Lehmann received a Doktor in computer science form University Paderborn on the synthesis of software for device driver. After developing software for medical X-ray systems he became professor for embedded systems at the University of Applied Science in Hamburg. Later he changed to the computer science department and has become professor for programming of distributed technical applications. He is teaching Programming and Software Engineering in Computer Science and Mechatronics.

Autoren/Hrsg.

Lehmann, Thomas

Leseproben

4. Communication and Synchronisation
As indicated in the previous chapter, a computer architecture can be reduced to a system of four components, the CPU, the bus-system, the memory, and peripheral devices (register file and device core). Functionality is executed on the CPU and the device cores. HdS executes as part of the functionality on the CPU. Thus it is a parallel computing system with two kinds of execution units, processor cores and digital circuits1. Crucial aspects of parallel systems are the communication and the synchronisation of the parallel executing components. The opposed execution paradigms as well as the bus-system and the register file behaviour, as element of the communication link, have an impact on communication and synchronisation. So the design of HdS starts with the communication between those parallel components, respectively the adapting register file for each side. Each side has a very different processing architecture, that leads to asymmetric handling of communication and synchronisation. Based on the execution model, the communication model, and the register file behaviour, the synchronisation means are analysed and implications on the software design are discussed in here. Figure 4.1.: Functionality determines HW, SW and Communication in Hardware/Software Codesign whereas the HW in combination with Communication determines the HdS-Design and hence Functionality It is assumed, that the peripheral device is set and cannot be changed in its behaviour at the interface. Even with Hardware/Software Codesign methodology, it is still widely-established practice, that a peripheral device is designed first and than integrated into a computer system or a microcontroller system as System-on-a-Chip (SoC). The section on communication starts with an analysis of the register file nature. The information exchange on lowest level will lead to a layered architecture on the software side that handles the encoding and transfer. General implementation issues will be discussed as well. The section on synchronisation starts with an overview on synchronisation principles. With the help of these principles, the somehow strange behaviour of some register file implementations will be explained. Additionally, modern CPU architectures have a strange communication behaviour as well (out-of-order), that has an impact on synchronisation and will be explained as well. As a result, a layering architecture for the HdS is derived. The layers provide a more abstract interface respectively interfaces with more semantic meaning. The low-level synchronisation will be extended to the exchange of message and functionality synchronisation. Here the two concepts of polling and message handling by Interrupt Service Routines will be discussed including communication between the two flows of control. The communication, low-level synchronisation, and the functional synchronisation are the foundations for the design of HdS. Based on the findings in this chapter, the design of the higher functionality, the counterpart of the device core functionality, is described in the following chapter. 4.1. Communication
Parallel executing functionality is never totally decoupled and those parallel threads need to communicate. The communication depends on the processing elements they are mapped to and the communication link in-between. HdS is mapped to the CPU and the associated functionality is mapped to the device core of the peripheral device. Crucial component in the communication between the software on the CPU and the device core is the register file interfacing the two execution and communication paradigms on each side. The typical register file design in combination with the connection to a bus-system leads to a layered architecture to transparently hide the communication on lowest level. 4.1.1. Nature of the Register File Inside the peripheral device, the register file (de-)couples the systems of opposed execution paradigms, the massive parallel hardware (device core) and the strict sequential software (HdS). Major objective is handling of the asynchronous information exchange. The software side of the register file is attached to the computer peripheral bus system, the other side is directly attached to the device core. Figure 4.2.: The Register File as coupler between device core and the peripheral bus towards the CPU The register file is organised as a matrix of storage cells, registers, similar to memory. Values of the byte-oriented transfer from the CPU are stored for further processing by the device. Vice versa, values from the device core are buffered until read from the software side. On the software side, the register file has to behave like byte-oriented memory, as we assume that the CPU does not distinguish between addresses in memory-address space and addresses where peripheral devices are located. Therefore, it is called ”memory mapped I/O”, as the same machine instructions in the CPU are used to access memory as well as register files. Figure 4.3.: Register cells organised in register file. Addressable by offset (row) and bit-position (column) The rows of the register file matrix have typically the width of the data bus, as part of the peripheral bus, or smaller, but usually multiple of bytes (depict in Fig. 4.3). Within this book, a register is the full row, whereas a register cell only keeps one bit of information. The rows are enumerated by an offset and the effective address for the access from CPU side is calculated as base address of the device plus offset. In some rare cases, the register width is smaller and either multiple rows are visible on the data bus or only a part of the data bus is attached to the peripheral device and the rest of the data bus holds arbitrary values (see Fig. 4.4, left ). In this case, the offset is multiplied with a factor, typically 2 or 4. Figure 4.4.: Possible mappings of register offsets to memory addresses depending on attachment to data bus: with gaps or 1:1 On the hardware side of the register file, the device core is directly attached with its inand output signal lines. The device core consists of state machines in the control paths and logical operations in the data paths. The state machines process input symbols and present as result output symbols. All symbols are binary coded. The logical paths have an arbitrary number of input and output signals. All input/output-symbols and the input/output data are represented by groups of bit and mapped to bit-fields in the registers. A bit-field contains at minimum one signal, a bit. The assignment of positions for the bit-fields in the register file is up to the register file developer, as in principle each signal from the device core can be routed to any register. Algorithmic assignment of signals to registers is possible as well and shown for instance in [76]. The algorithm groups read-only, write only and read-write registers and avoids automatically splitting of bit-files over multiple offsets. Figure 4.5.: Mapping of input/output signals to bit-fields in register The device core has a full parallel access to each register cell of the register file at any time. It can change the whole register file within one clock cycle or all components of the device core can react in parallel to a change of a single register. The register file is, as part of the peripheral device, a digital circuit with enhanced functionality in comparison to memory. Especially, the access to a register from software side (bus side) is recognised as the protocol state machine handling of the peripheral bus is part of the peripheral device (compare Fig. 3.7). So the device core is able to react on a register read or can react on writing to a register even if the content of the register does not change. This access observation is not feasible with parallel systems operating on shared memory, neither on dual-ported shared memory. The device core is able to observe the access from software side and can take automatic actions. For instance, FIFO-buffers can shift the contents after the head value has been read by software without any additional command from software side. In general, this observation feature is used for implicit synchronisation, as we see later on in Sec. 4.2.2. Other functionality is located in the register file as well. For instance, if state machines of the device core issue a transient signal, which for instance indicates the passing of a dedicated state, that signal can be buffered until it is read from the software side. For conceptual clarity, this behaviour can be allocated to a tiny state machine of the device core, whereas from the practical perspective, the device’s developer would implement the functionality in the register file (flip-flop). Additional special behaviour will be discussed later in Sec. 4.2.2. In conclusion, the communication of the device core and the ”shared memory” register file is simple, as state machines and logical operators exchange symbols and arbitrary data directly over dedicated lines. The access is fully parallel whereas the access on the software side to the register file is time-multiplexed and limited to chunks in the width of the data bus. Additionally, the hardware side can observe the access to registers which provides implicit synchronisation means,...