The following is a checklist for engineering software in the presence of hardware acceleration. The underlying premise is that the software is modular, so it will be efficient with and without acceleration.
Design the code to be modular so that functions in the data plane can be easily plugged in or out depending upon hardware or software implementation.
Separate the fast-path and slow-path implementation of the data plane up front
Maximize performance in the data plane even if it is a software-only implementation—it is very likely that the software implementation is sufficient for some low-end systems. This includes efficient search algorithms and data structures.
Handle all exception processing in software
Ensure that interrupt processing code is efficient—for example, read counters and other parameters from the hardware via software as fast as possible, since they run the risk of being overwritten.
Do not restrict the design such that only certain parts of the data plane may be built in hardware.
Network processor devices can move several data plane functions into software.
Ensure that performance calculations are made for the system both with and without hardware acceleration—this is also one way to determine the effectiveness of the partitioning.
When interfacing to hardware, use generic APIs instead of direct calls to manipulate registers on the controller. This will ensure that only the API implementations need to be changed when a new hardware controller is used. Applications will see no change since the same API is used.
The use of hardware acceleration is a function of the product requirements and the engineering budget. While it is certainly a desirable, developers should not depend upon it as a way to fix all the performance bottlenecks in their code.
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
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
2.3 Summary
Hosts, which communicate with peers, implement their networking software functions over a host operating system like UNIX. The functions can be in the user mode or kernel mode. STREAMS is an example of a framework for building networking stacks in the UNIX environment. The performance of host-based networking software is not high, due to several reasons-restrictions of the operating system, legacy code, kernel- to user-mode transitions, and so on.
Embedded communications devices typically use a real-time operating system as the platform for building their software functions. The RTOSes may be available from vendors or built in house. Using a commercial RTOS with standard APIs permits application portability. Memory considerations like booting, flash, and DRAM versus SRAM are all important in embedded communications systems.
An implementation of the system will require clear partitioning of the control plane, data plane, and management plane. In the data plane, both fast-path and slow-path processing will need to be identified. Hardware acceleration via ASICs and NPs can be used for specific functions in the data plane fast path.
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
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
2.4 For Further Study
Berger [2002] discusses the hardware-software partitioning issue as well as checklist for choosing an RTOS. Comer [2003] details the need for custom silicon like ASICs and network processors.
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
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
2.6 Exercises
List reasons why you think a commercial communications appliance can use a host operating system as the base OS.
1.
Determine which RTOS vendors support a STREAMS framework either directly or from third-party vendors.
2.
How does a security chip work in conjunction with a network processor? Provide a simple diagram of the solution.
3.
Detail the advantages and disadvantages of using a configurable ASIC versus a programmable network processor.
4.
A powerful hardware acceleration device is being considered by the hardware team. The problem is that its APIs and documentation are limited. The hardware and system engineers are going ahead with it despite these limitations. Explain how you would approach this situation and the steps you would take to de-risk the software development using this chip.
5.
Designing Embedded Communications Software
by T. Sridhar ISBN:157820125x
CMP Books © 2003 (207 pages)
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
Chapter 3: Software Partitioning
This chapter addresses issues related to partitioning in communications software, both in terms of functionality and system implementation. While the OSI model can be used to partition the protocol software functionality, it is very rigid in terms of design. For performance reasons, some visibility into the higher and lower layers may be required, as explained below.
The discussion then moves on to the delineation between tasks and modules and how a typical communications system is implemented. An example of a Layer 2 switch is used to outline the various modules—including the device driver, protocol tasks and system/management modules. The chapter concludes with a description of the inter-module interfaces, including the use of standards-based and proprietary interfaces.
3.1 Limitations of Strict Layering
Chapter 1 detailed the OSI Seven Layer Model. The simplest way to partition the system is to follow this model by designing each protocol layer as a single module with clear interfaces with its upper and lower layers. If strict layering is followed, each protocol module will be unaware and independent of its upper and lower layers. This, however, is difficult to implement in practice, the key reasons being: