Hardware Interface Design Patterns Ahmet Selman Bozkır – Hacettepe Univ.

Slides:



Advertisements
Similar presentations
Computer Architecture
Advertisements

System Integration and Performance
purpose Search : automation methods for device driver development in IP-based embedded systems in order to achieve high reliability, productivity, reusability.
INPUT-OUTPUT ORGANIZATION
Chapter 10 Input/Output Organization. Connections between a CPU and an I/O device Types of bus (Figure 10.1) –Address bus –Data bus –Control bus.
1/1/ / faculty of Electrical Engineering eindhoven university of technology Architectures of Digital Information Systems Part 1: Interrupts and DMA dr.ir.
CS-334: Computer Architecture
1/1/ / faculty of Electrical Engineering eindhoven university of technology Introduction Part 3: Input/output and co-processors dr.ir. A.C. Verschueren.
FIU Chapter 7: Input/Output Jerome Crooks Panyawat Chiamprasert
Reporter:PCLee With a significant increase in the design complexity of cores and associated communication among them, post-silicon validation.
Dr.Basem Alkazemi
USB: Data Flow Sukesh Shenoy. USB implementation areas.
Basic Input/Output Operations
Input/Output and Communication
Group 7 Jhonathan Briceño Reginal Etienne Christian Kruger Felix Martinez Dane Minott Immer S Rivera Ander Sahonero.
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
INPUT-OUTPUT ORGANIZATION
Input/Output. Input/Output Problems Wide variety of peripherals —Delivering different amounts of data —At different speeds —In different formats All slower.
Chapter 7 Input/Output Luisa Botero Santiago Del Portillo Ivan Vega.
Chapter 10: Input / Output Devices Dr Mohamed Menacer Taibah University
Input/OUTPUT [I/O Module structure].
The University of New Hampshire InterOperability Laboratory Introduction To PCIe Express © 2011 University of New Hampshire.
Cis303a_chapt06_exam.ppt CIS303A: System Architecture Exam - Chapter 6 Name: __________________ Date: _______________ 1. What connects the CPU with other.
Interrupts and DMA CSCI The Role of the Operating System in Performing I/O Two main jobs of a computer are: –Processing –Performing I/O manage and.
1 Lecture 20: I/O n I/O hardware n I/O structure n communication with controllers n device interrupts n device drivers n streams.
Internet Addresses. Universal Identifiers Universal Communication Service - Communication system which allows any host to communicate with any other host.
Universal Synchronous/Asynchronous Receiver/Transmitter (USART)
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Principles of I/0 hardware.
CHAPTER 3 TOP LEVEL VIEW OF COMPUTER FUNCTION AND INTERCONNECTION
1-1 Embedded Network Interface (ENI) API Concepts Shared RAM vs. FIFO modes ENI API’s.
Recall: Three I/O Methods Synchronous: Wait for I/O operation to complete. Asynchronous: Post I/O request and switch to other work. DMA (Direct Memory.
Computer Architecture Lecture10: Input/output devices Piotr Bilski.
(More) Interfacing concepts. Introduction Overview of I/O operations Programmed I/O – Standard I/O – Memory Mapped I/O Device synchronization Readings:
CE Operating Systems Lecture 11 Windows – Object manager and process management.
Dr Mohamed Menacer College of Computer Science and Engineering Taibah University CE-321: Computer.
Device Drivers CPU I/O Interface Device Driver DEVICECONTROL OPERATIONSDATA TRANSFER OPERATIONS Disk Seek to Sector, Track, Cyl. Seek Home Position.
Input/Output Computer component : Input/Output I/O Modules External Devices I/O Modules Function and Structure I/O Operation Techniques I/O Channels and.
Accessing I/O Devices Processor Memory BUS I/O Device 1 I/O Device 2.
Modes of transfer in computer
Organisasi Sistem Komputer Materi VIII (Input Output)
CH10 Input/Output DDDData Transfer EEEExternal Devices IIII/O Modules PPPProgrammed I/O IIIInterrupt-Driven I/O DDDDirect Memory.
I/O, Devices & Device Drivers I/O subsystem It is the responsibility of the I/O subsystem of an OS to schedule, manage, & control the interactions between.
PART 7 CPU Externals CHAPTER 7: INPUT/OUTPUT 1. Input/Output Problems Wide variety of peripherals – Delivering different amounts of data – At different.
Unit 1 Lecture 4.
Protocol Layering Chapter 11.
Input/Output Problems Wide variety of peripherals —Delivering different amounts of data —At different speeds —In different formats All slower than CPU.
IT3002 Computer Architecture
Device Driver Concepts Digital UNIX Internals II Device Driver Concepts Chapter 13.
Input Output Techniques Programmed Interrupt driven Direct Memory Access (DMA)
Rohini Ravichandran Kaushik Narayanan A MINI STEREO DIGITAL AUDIO PROCESSOR (BEHAVIORAL MODEL)
N ETWORKING Standards and Protocols. S TANDARDS AND P ROTOCOLS The OSI Model.
1 Device Controller I/O units typically consist of A mechanical component: the device itself An electronic component: the device controller or adapter.
8251 USART.
Tiva C TM4C123GH6PM UART Embedded Systems ECE 4437 Fall 2015 Team 2:
Architectures of Digital Information Systems Part 1: Interrupts and DMA dr.ir. A.C. Verschueren Eindhoven University of Technology Section of Digital.
I/O SYSTEMS MANAGEMENT Krishna Kumar Ahirwar ( )
Click to edit Master subtitle style
UNIT – Microcontroller.
Operating Systems (CS 340 D)
CS703 - Advanced Operating Systems
Operating Systems Chapter 5: Input/Output Management
Chapter 13: I/O Systems.
Introduction Communication Modes Transmission Modes
Chapter 13: I/O Systems “The two main jobs of a computer are I/O and [CPU] processing. In many cases, the main job is I/O, and the [CPU] processing is.
Presentation transcript:

Hardware Interface Design Patterns Ahmet Selman Bozkır – Hacettepe Univ.

Subjects Serial Port Design Pattern High Speed Serial Port Design Pattern Hardware Device Design Pattern Synchronizer Design Pattern

Serial Port Design Pattern Embedded software has to interact with hardware devices of various types. In this article we will consider a design pattern for handling hardware interfaces for a serial port. HDLC, RS-232, RS-422

Serial Port Design Pattern Intent The Serial Port design pattern defines a generic interface with a serial port device. The main intention here is to completely encapsulate the interface with the serial port hardware device. All classes interfacing with the serial port will not be impacted by change in the hardware device.

Serial Port Design Pattern What we’ll get? To minimize dependency on hardware. Because; changing the interface due to: Cost End-of-life functionality Improvements

Serial Port Design Pattern Serial port design pattern encapsulates the register and interrupt handling specific to a device. Change in the device will just result in changes to just the classes involved in implementing this design pattern.

Serial Port Design Pattern Applicability This pattern is applicable to all serial devices that involve direct byte transfers to and from the device using program instructions. In such devices, serial transmission is implemented by the device interrupting the processor for data bytes. When data is received on the serial link, the device interrupts the processor to transfer data.

Serial Port Design Pattern Serial Port Manager: Manages all the Serial Ports on the board. Interrupt Service Routine: Implemented as a static method in Serial Port Manager. Serial Port: Handles the interface with a single serial port device. Transmit Queue: This queue contains messages awaiting transmission on the serial port. Receive Queue: Messages received on the serial link are stored in this queue. S erial Port is implemented with the SerialPort and SerialPortManager classes. The SerialPortManager maintains an array of SerialPort objects. Each SerialPort object manages the transmit and receive buffers. The SerialPortManager class also implements the interrupt service routine.

Serial Port Design Pattern Known Uses This pattern can be used to implement serial interfaces where data handling is handled in interrupt service routines. It is not suitable for direct memory access (DMA) based serial devices.

DMA based High Speed Serial Port Design Pattern

High Speed Serial Port Design Pattern Embedded processors now-a-days are connected with each other via high speed serial links. There links can range from 1 Mbps to 1000 Mbps. At these high link speeds, the byte by byte transfers described in the serial port design pattern prove inadequate. High speed transfers require devices that can directly transfer data to and from memory without interrupting the processor.

High Speed Serial Port Design Pattern This design pattern covers interfacing techniques with high speed serial communication devices. The main objective is to encapsulate the interface with the device and provide a hardware independent interface to the high speed serial port. High speed serial port design pattern encapsulates DMA configuration, register interfacing and interrupt handling specific to a device. Change in the device will just result in changes to just the classes involved in implementing this design pattern.

High Speed Serial Port Design Pattern Applicability This pattern is applicable to all serial devices that involve DMA (direct memory access) transfers to and from the device. In such devices serial transmission and reception are completely handled by the serial device. The device operates as a bus master and transfers data to and from the memory without main processor intervention.

High Speed Serial Port Design Pattern Structure Serial Port is implemented with the SerialPort and SerialPortManager classes. The SerialPortManager maintains an array of SerialPort objects. Each SerialPort object manages the transmit and receive buffers. The SerialPortManager class also implements the interrupt service routine. As mentioned earlier, the serial port is intelligent. The device needs to be programmed with the addresses of the transmit and receive message queues. Once these addresses have been programmed, the device automatically reads the buffer header to determine the current state of the buffer. For example, when the device finishes transmission of a buffer, it reads the buffer header for the next buffer to determine there is a new message ready for transmission. If a new message is found, the device initiates transmission immediately, without involving the processor.

High Speed Serial Port Design Pattern

So what? This pattern is used to design serial port interfaces with intelligent devices which are capable of performing DMA operations to manage buffers in the memory. These devices only interrupt the processor when complete messages have been received/transmitted.

Hardware Device Design Pattern

We have already looked at classes that provide a high level interface to the underlying hardware (e.g. Serial Port).Serial Port Here we will look at the design of classes corresponding to the individual devices. The main objective is to keep all register programming information at one place.

Hardware Device Design Pattern Aim: Very often the lowest level of code that interfaces with the hardware is difficult to understand and maintain. One of the main reasons for this is the idiosyncrasies of register level programming model of hardware devices. Very often devices require registers to be accessed in a certain sequence. Defining a class to represent the device can go a long way in simplifying the code by decoupling the low level code and register manipulation. Another motivation for this design pattern is skill sets. Often details about intricacies of register programming in devices are understood only by the persons familiar with the hardware design. Many times other low level code might be written by software engineers with just basic understanding of hardware. Also note that separating the device programming and logic simplifies porting of the code to a different hardware platform.

Hardware Device Design Pattern Structure: The structure of class in this design pattern largely depends upon the register programming model of the device being programmed. In most cases, this design pattern would be implemented as a single class representing the device. In case of complex devices, the device might be modeled as a main device class and other subclasses modeling different parts of the device.

Hardware Device Design Pattern Sample Implementation: Status Register (STAT): This read only register contains the following status bits: Bit 0: Transmit Buffer Has Empty Space Bit 1: Receive Buffer Has Data Bit 2: Transmit under run Bit 3: Receive overrun Action Register (ACT): Bits in this write only register correspond to the bits in the status register. A condition in the status register can be cleared by writing the corresponding bit as 1. Note that bit 0 automatically gets cleared when writes are performed to the transmit buffer. Bit 1 is cleared automatically when reads are performed from the receive buffer. Bit 2 and 3 however need to be cleared explicitly. Transmit Buffer (TXBUF): Write only buffer in which bytes meant for transmission should be written. Receive Buffer (RXBUF): Read only buffer in which received bytes are stored.

Hardware Device Design Pattern class Serial_Device { enum Register_Offsets { STAT_REG_OFFSET = 0, ACT_REG_OFFSET = 0, TXBUF_OFFSET = 1, RXBUF_OFFSET = 2 }; enum Status_Register_Bits { TX_EMPTY, RX_DATA, TX_UNDERRUN, RX_OVERRUN }; const long m_status_Register; const long m_action_Register; const long m_transmit_Register; const long m_receive_Register; public: Serial_Device(long baseAddress) : m_status_Register(baseAddress + STAT_REG_OFFSET), m_action_Register(baseAddress + ACT_REG_OFFSET), m_transmit_Register(baseAddress + TXBUF_OFFSET), m_receive_Register(baseAddress + RXBUF_OFFSET) { }

Hardware Device Design Pattern bool Transmitter_Has_Space() const { return ((io_read(m_status_Register) & TX_EMPTY) == TX_EMPTY); } // This method returns true if a receive interrupt is pending bool Receiver_Has_Data() const { return ((io_read(m_status_Register) & RX_DATA) == RX_DATA); } // Returns true if transmit error interrupt is active bool Transmitter_Has_Error() const { return ((io_read(m_status_Register) & TX_UNDERRUN) == TX_UNDERRUN); } // Returns true if receive error interrupt is active bool Receiver_Has_Error() const { return ((io_read(m_status_Register) & RX_OVERRUN) == RX_OVERRUN); } // Clear all the error conditions void Clear_Errors() const { io_write(m_action_Register, TX_UNDERRUN | TX_OVERRUN); }

Synchronizer Design Pattern

Aim: Many systems used in digital communication send data in synchronous back-to-back frames. When a receiver tunes to such a data stream, it has no knowledge of the frame boundaries. The Synchronizer Design Pattern is used to look at the raw incoming bit or byte stream and detect and align to the frame structure. The frame structure is detected by searching for a sync pattern in the frame. Once the synchronization is achieved, the Synchronizer confirms the presence of the sync pattern in every frame. If the sync pattern in missed a certain number of times, loss of sync is declared.

Synchronizer Design Pattern On many occasions there is need to maintain synchronization between two entities connected at opposite ends of a link. This design pattern provides mechanisms for: Achieving initial synchronization (sync) Once sync is achieved, confirming the presence of the sync framing Initiating loss of sync procedures Synchronizer state machine class is the key participant in this pattern. The state machine uses state classes to keep track of state.

Synchronizer Design Pattern It is clear from the figure below that the state machine is organized into two high-level states, synchronized and unsynchronized. These states act as the base class for the following sub-states:

Synchronizer Design Pattern The implementation is explained in terms of the following scenarios: Attaining Synchronization Loosing Synchronization

Synchronizer Design Pattern Attaining Synchronization 1.System starts up in "Searching For Sync" state. In this state, the incoming data stream is being analyzed bit by bit, looking for the occurrence of the sync pattern. 2.As a soon as a first sync pattern is detected, the system transitions to the "Confirming Sync Pattern" state. 3.Now the system checks if the sync pattern is repeating as expected. This check is made according to the specified periodicity. 4.If the sync pattern is repeating, the system transitions to the "In Sync" state. (If the sync pattern was not found, the system would have transitioned back to the "Searching For Sync" state) 5.At this point, the system is considered to be synchronized.

Loosing Synchronization 1.When the system is synchronized, it is in the "In Sync" state. In this state, the system is constantly monitoring the periodic occurrence of the sync pattern. 2.If an expected sync pattern is found to be missing, the system transitions to the "Confirming Sync Loss". The system is still in a synchronized state. The main purpose of the "Confirming Sync Loss" state is to check if the loss of sync was an isolated event or it represents complete loss of sync. 3.In the "Confirming Sync Loss" state, the system looks for the sync pattern at the expected time interval. If the sync pattern is seen again, the system transitions back to the "In Sync" state. 4.In this case, the sync pattern is not detected for a preconfigured number of times. 5.The system is now in sync loss state. The system is transitioned to the "Searching For Sync" state.

Synchronizer Design Pattern

So what? Use of this pattern has the following benefits: Provides a common framework for implementing synchronization logic Use of hierarchical state machine reduces the amount of code by reducing code duplication in various states. Use of a state machine forces the developer to handle all possible cases of synchronization events.

Resources Visio 2003 Thanks for listening me!