Hardware and System Configuration - 57359860 Designing Embedded Communications Software

Layering is also subject to the hardware and system configuration. For example, we may split TCP functionality to provide termination and data transfer on a line card while performing the control processing on a separate control card. Similarly, the encapsulation scheme may put a new twist on layering—there are cases where a frame relay packet may be encapsulated inside PPP (Point to Point Protocol—used on serial links to carry Layer 3 and Layer 2 traffic) and other cases where a PPP packet may be encapsulated inside a frame relay packet.

The conclusion is that while layering is a good way to partition the protocol functionality, we may not always be able to implement it in a strict fashion.

Designing Embedded Communications Software

by T. Sridhar ISBN:157820125x

With this foundation, you explore a development model that addresses the complete range of issues in the design of embedded communications software, including real-time operating systems, hardware and software partitioning, layering, and protocol stacks.

Table of Contents

Designing Embedded Communications Software Foreword

Preface

Chapter 1 - Introduction

Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning

Chapter 4 - Protocol Software

Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software

Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development

Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References

Index List of Figures List of Tables List of Listings List of Sidebars

3.2 Tasks and Modules

The simplest way to partition the software is to decompose it into functional units called modules. Each module performs a specific function. An Ethernet driver module is responsible for configuration, reception, and transmission of Ethernet frames over one or more Ethernet interfaces. A TCP module is an implementation of the TCP protocol.

A module can be implemented as one or more tasks. We make the distinction between a task and a module as:

A module is a unit implementing a specific function. A task is a thread of execution.

A thread is a schedulable entity with its own context (stack, program counter, registers). A module can be implemented as one or more tasks (i.e., multiple threads of execution), or a task can be

implemented with multiple modules. Consider the implementation of the IP networking layer as an IP task, an ICMP (Internet Control Message Protocol) task, and an ARP (Address Resolution Protocol) task. Alternately, the complete TCP/IP networking function can be implemented as a single task with multiple modules—a TCP module, an IP module, and so on. This is usually done in small–form factor devices, where both memory requirements and context switching overheads are to be minimized.

3.2.1 Processes versus Tasks

In desktop systems, a process represents the basic unit of execution. Though the terms process and task are used interchangeably, the term “process” usually implies a thread of execution with its own memory protection and priority [see Figure 3.2]. In embedded systems, the term “task” is encountered more often. Tasks do not have memory protection—so a task can access routines which “belong” to another task. Two tasks can also access the same global memory; this is not possible with processes.

Figure 3.2: Processes and tasks.

A process can also have multiple threads of execution. A thread is a lightweight process, which can share access to global data with other threads. There can be multiple threads inside a process, each able to access the global data in the process. Thread scheduling depends upon the system. Threads can be scheduled whenever the process is scheduled with round-robin or thread priority scheduling, or they can be part of a system- wide thread scheduling pool. A key point to note is:

In embedded systems with no memory protection, a task is the equivalent of a thread—so we can consider the software for such an embedded system as one large process with multiple threads.

3.2.2 Task Implementation

Independent functions and those that need to be scheduled at different times can be implemented as

Designing Embedded Communications Software

by T. Sridhar ISBN:157820125x

Table of Contents

Designing Embedded Communications Software Foreword

Preface

Chapter 1 - Introduction

Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning

Chapter 4 - Protocol Software

Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software

Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development

Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References

Index List of Figures List of Tables List of Listings List of Sidebars

tasks, subject to the performance issues related to context switching. Consider a system with eight interfaces, where four of the interfaces run Frame Relay, while the other four run PPP. The two protocols are functionally independent and can run as independent tasks.

Even when tasks are dependent upon each other, they may have different timing constraints. In a TCP/IP implementation, IP may require its own timers for reassembly, while TCP will have its own set of connection timers. The need to keep the timers independent and flexible, can result in TCP and IP being separate tasks.

In summary, once the software has been split into functional modules, the following questions are to be considered for implementation as tasks or modules:

Are the software modules independent, with little interaction? If yes, use tasks.

Is the context-switching overhead between tasks acceptable for normal operation of the system? If not, use modules as much as possible.

Do the tasks require their own timers for proper operation? If so, consider implementing them as separate tasks subject to 1 and 2.

3.2.3 Task Scheduling

There are two types of scheduling that are common in embedded communications systems. The first and most common scheduling method in real-time operating systems is preemptive priority-based scheduling, where a lower priority task is preempted by a higher priority task when it becomes ready to run. The second type is non-preemptive scheduling, where a task continues to run until it decides to relinquish control. One mechanism by which it makes this decision is based on CPU usage, where it checks to see if its running time exceeds a threshold. If that is the case, the process relinquishes control back to the task scheduler. While non-preemptive scheduling is less common, some developers prefer preemptive scheduling because of the control it provides. However, for the same reason, this mechanism is not for novice programmers.

Several commercially available RTOSes use preemptive priority-based scheduling with a time slice for tasks of equal priority. Consider 4 tasks, A, B, C, and D, which need to be scheduled. If Task A, B, and C are at a higher priority than Task D, any of them can preempt D. With the time slice option, A, B, and C can all preempt Task D, but if the three tasks are of equal priority, they will share the CPU. A time slice value determines the time before one priority task is scheduled out for the next equal-priority task to run.

For our discussions, we will assume hereafter the preemptive priority-based scheduling model. Time slicing is not assumed unless explicitly specified.

Designing Embedded Communications Software

by T. Sridhar ISBN:157820125x

Table of Contents

Designing Embedded Communications Software Foreword

Preface

Chapter 1 - Introduction

Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning

Chapter 4 - Protocol Software

Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software

Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development

Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References

Index List of Figures List of Tables List of Listings List of Sidebars

3.3 Module and Task Decomposition

This section will discuss design considerations with respect to partitioning the system into tasks and modules. It will then use the example of a Layer 2 Ethernet switch to illustrate the concepts. The assumption is that the system is a single-processor system running an RTOS. Systems with multiple boards and processors are discussed in Chapter 8.

The following list is a set of guidelines for organizing the modules and tasks in a communications system:

There are one or more drivers which need to handle the various physical ports on the system.

Each driver can be implemented as a task or module. There are one or more Interrupt Service Routines (ISRs) for each driver.

The drivers interface with a higher layer demultiplexing/multiplexing task for reception and transmission of data. This is the single point of entry into the system for received frames.

Similarly, this task is the only entity which interfaces to the driver for transmission.

Each protocol is designed as a module. It can be implemented as a task if it requires independent scheduling and handling of events, such as timers. If the overhead of context switching and message passing between the tasks is unacceptable, multiple protocol modules can run as one task.

Control and data plane functions, along with fast/slow path considerations will be used for grouping tasks and modules. Hardware acceleration will also play a part here.

Housekeeping and management plane functions like SNMP agents and Command Line Interface (CLI) will need to have their own task(s).

If memory protection is used, the interfaces between the tasks will be via messages. Otherwise, functional interfaces can be used. This will be discussed in greater detail in Section 3.6

The above guidelines are applied in the example of the Layer 2 switch, as discussed below.

Designing Embedded Communications Software

by T. Sridhar ISBN:157820125x

Table of Contents

Designing Embedded Communications Software Foreword

Preface

Chapter 1 - Introduction

Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning

Chapter 4 - Protocol Software

Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software

Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development

Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References

Index List of Figures List of Tables List of Listings List of Sidebars

3.4 Partitioning Case Study—Layer 2 Switch

Consider a Layer 2 Ethernet switch, which switches Ethernet frames between ports. This example system consists of 8 Ethernet ports for switching traffic and a management Ethernet port. It contains a CPU which runs the software for the system. For now, assume that there is no hardware acceleration and that all the switching is done by software running on the CPU.

Figure 3.3 shows the software architecture of the device. It requires the following:

Driver(s) to transmit and receive Ethernet frames from the ports A set of modules/tasks to run the protocols required for the switch

A set of modules/tasks required for the system operation and management

Figure 3.3: Typical Architecture of a Layer 2 Switch.

3.4.1 Device Driver

The device driver is the module closest to the hardware and is responsible for transmission and reception of frames. For transmission, the driver obtains the data from its higher layer, while, for reception, the driver needs to pass the received frame to its higher layer. The driver typically handles frames received from the hardware controller by either polling or by interrupts generated when a frame is received. The method used depends on application requirements.

With polling, the driver polls the device for received frames at periodic intervals. If the device indicates that frames have been received, the driver reads these frames from the device, frees buffers for the device to read frames into, and passes the frames to the higher layer. With interrupts, the driver receives an indication that a frame has been received, based on which it can read the frames from the device.

Polling is a relatively inefficient way to handle frames, especially if frames arrive infrequently. The driver polls the device even when no frames have been received, expending processing time which could be spent in other operations. Interrupts are more efficient but can easily swamp the system when frames arrive at a rapid rate. In the Layer 2 switch, frames can arrive at a maximum rate of 14,880 64 byte frames/second on a 10 Mbps Ethernet. If an interrupt is generated for each of the frames, it can easily overload the system. To handle this, drivers use a combination of interrupts and polling in conjunction with the controller, as described below.

Optimization of Reception

Designing Embedded Communications Software

by T. Sridhar ISBN:157820125x

Table of Contents

Designing Embedded Communications Software Foreword

Preface

Chapter 1 - Introduction

Chapter 2 - Software Considerations in Communications Systems Chapter 3 - Software Partitioning

Chapter 4 - Protocol Software

Chapter 5 - Tables and Other Data Structures Chapter 6 - Buffer and Timer Management Chapter 7 - Management Software

Chapter 8 - Multi-Board Communications Software Design Chapter 9 - Going About the Development

Appendix A- Examples from Commercial Systems Glossary of- Common Terms and Acronyms References

Index List of Figures List of Tables List of Listings List of Sidebars

Several techniques are used to optimize controllers for receiving frames. Consider a case in which a list of multicast Ethernet addresses are to be recognized. In the Layer 2 switch, one such multicast address is used for Spanning Tree Protocol (STP) frames. STP is used to ensure that loops are detected and eliminated in the bridge topology. It involves periodic transmission of frames between bridges.

The STP frames use the multicast MAC address 01-80-C2-00-00-00, so the Ethernet controller needs to receive and pass up all MAC frames with this multicast address in the destination address field, whenever STP is enabled. The controller can perform this match on chip registers which store the MAC addresses. The driver programs this register with the MAC addresses based on the higher layer configuration. The higher layer configuration can take place via a Command Line Interface (CLI) with a command like “Enable STP”, which, in turn, causes the “enable” event to be propagated all the way to the driver to receive STP multicast frames, Thus, higher layers need not be aware of the details at the driver level.

In document 57359860 Designing Embedded Communications Software (Page 41-46)