Hardware/Firmware Interface Design

Best Practices for Improving Embedded Systems Development

Gary Stringham

• Publisher: Newnes
• Year: 2009
• Print ISBN: 9781856176057
• eBook ISBN: 9780080880198
• Topic: Computer Science
• Subtopic: Hardware
• Index: Computer Science

Why care about hardware/firmware interaction? These interfaces are critical, a solid hardware design married with adaptive firmware can access all the capabilities of an application and overcome limitations caused by poor communication. For the first time, a book has come along that will help hardware engineers and firmware engineers work together to mitigate or eliminate problems that occur when hardware and firmware are not optimally compatible. Solving these issues will save time and money, getting products to market sooner to create more revenue.The principles and best practices presented in this book will prove to be a valuable resource for both hardware and firmware engineers. Topics include register layout, interrupts, timing and performance, aborts, and errors. Real world cases studies will help to solidify the principles and best practices with an aim towards cleaner designs, shorter schedules, and better implementation!- Reduce product development delays with the best practices in this book- Concepts apply to ASICs, ASSPs, SoCs, and FPGAs- Real-world examples and case studies highlight the good and bad of design processes

CHAPTER 1. Introduction

Hardware and firmware engineering design teams often run into problems and conflicts when trying to work together. They come from different development environments, have different toolsets, and use different terminology. Often they are in different locations within the same company or work for different companies. The two teams have to work together but often have conflicting differences in procedures and methods. Since their resulting hardware and firmware work has to integrate successfully to produce a product, it is imperative that the hardware/firmware interface—including people, technical disciplines, tools, and technology—be designed properly.

Because of the nature of embedded systems, hardware design will always precede firmware design. While some tools and techniques are available to permit a more parallel effort, in the end, the hardware must be created before the firmware team can carry out its final development and testing efforts. Although a significant amount of effort is expended to ensure correct design at the hardware/firmware interface, problems will still appear when hardware and firmware are integrated as a system.

Problems found in firmware are relatively easy to fix compared to problems found in hardware. Respinning an application-specific integrated circuit (ASIC) ¹ can take up to 4 months and cost several million dollars, depending on the process node at which the chip is being developed, such as 90 nm, 65 nm, and so on. So pressure is put on the firmware teams to try to work around any hardware problems to avoid the delay and cost. As Jack Ganssle, an embedded systems expert, humorously stated, “Quality is firmware's fault—because it is too late to fix it in hardware.”

¹For the purposes of this book, the term ASIC will also be taken to encompass application-specific standard products (ASSPs), system on chips (SoCs), and field-programmable gate arrays (FPGAs). (See also the definitions later in this chapter.)

Chips are expensive and hard to design and build; getting them “right” is a business necessity. Designing chips for firmware engineers is a key enabler. This book provides a rigorous study of common sense approaches to chip design based on years of experience in writing firmware for chips. It captures practical and sensible ideas and applies structure and rigor to the design. The goal of the book is to provide principles and best practices that allow hardware and firmware engineers to improve the development and integration of embedded systems. This book is most useful during the development phase of the product, specifically during the development of both the chip and the firmware for a product.

This first chapter provides background into the subject matter and lays the groundwork for the remainder of the book. The second chapter discusses seven principles of hardware/firmware interface design. The rest of the book contains over 300 best practices. Obviously the list of best practices presented here cannot be an exhaustive one in this area. As you read through the following chapters, you will think about best practices that you use and will get ideas for others. Write them down so you can apply them to your work and share them with others.

1.1. What Is the Hardware/Firmware Interface?

The hardware/firmware interface is the junction where hardware and firmware meet and communicate with each other. On the hardware side, it is a collection of addressable registers that are accessible to firmware via reads and writes. This includes the interrupts that notify firmware of events. On the firmware side, it is the device drivers or low-level software that controls the hardware by writing values to registers, interprets the information read from the registers, and responds to interrupt requests from the hardware. Of course, there is more to hardware than registers and interrupts, and more to firmware than device drivers, but this is the interface between the two and where engineers on both sides must be concerned to achieve successful integration.

The terms “hardware” and “firmware” vary in scope and meaning in the industry, so let's define how they are used in this book.

1.1.1. What Are Hardware, Chips, and Blocks?

In the electrical engineering context, the term “hardware” includes all electronic circuits in an embedded product, including printed circuit boards, passives like resistors and capacitors, and chips. It can also refer to nonelectrical, mechanical components, such as bolts, spacers, and housing/enclosures. Meanwhile, the term “chips” includes any devices made from silicon or other semiconducting materials containing multiple transistors that implement digital or analog functions. They can be simple, single-function devices or complex, multi-function devices containing processors, memory, interfaces, and other functional circuitry.

For the purposes of this book, “hardware” and “chips” refers to just a subset of devices (such as ASICs and FPGAs): specifically, the components that interact with firmware via registers and interrupts. It does not include microprocessors, microcontrollers, or memory. Furthermore, “hardware” and “chips” are used almost interchangeably in this book; for example, “The hardware team designs the chips.”

A “chip” will contain one or more functional “blocks,” such as a USB communications function, an MPEG compressor, and a memory controller. There may be more than one instantiation (copy) of a particular block, such as two UARTs. Blocks within a chip typically communicate with each other and with external memory via a shared bus. Each block is typically designed as an individual unit. When a new chip is designed, it may comprise a mixture of blocks used in previous designs and new blocks.

Within the scope of “chips,” are several general families of integrated circuits, each with their own minor differences with regard to the context of this book, but the concepts generally apply to all.

ASICs

ASICs (application-specific integrated circuits) are designed to be used in a specific product of a specific brand. It contains a customized mix of standard and/or proprietary blocks. ASICs are high-volume chips optimized for power, performance, and cost. This means that there are many different ASICs in use, each with its own hardware and firmware design teams. These hardware and firmware teams continue to work together as they produce variations of the ASICs for various product families and multiple generations of the products.

Both of the teams may be working for the company producing the product; alternatively, one or both of the teams might be working for other companies hired to do the work. Whatever the case, close coupling between the teams must still be present so as to provide the hardware team with more opportunities to make changes and improvements because they can collaborate with the firmware team in advance.

ASSPs

ASSPs (application-specific standard product) are like ASICs except that they are designed for a specific application area and are sold to more than one customer—hence the name “standard product.” By contrast, an ASIC is designed and built to order for a specific customer. ASSPs have only standard functionality, allowing them to be used in a variety of embedded systems by a variety of companies. This means that one company generates an ASSP, while potentially many companies generate firmware for that ASSP. Device drivers are typically needed for a variety of operating systems (OSs) and versions; these device drivers will be specific to the firmware of the target embedded system. Thus many different firmware teams from multiple companies are typically involved. The firmware teams generally do not have ready access to the hardware team that designed the ASSP. There is no one-to-one relationship as found in ASIC teams.

This puts the burden on the hardw...

Table of contents

• Cover image
• Table of Contents
• Copyright
• Preface
• CHAPTER 1. Introduction
• CHAPTER 2. Principles
• CHAPTER 3. Collaboration
• CHAPTER 4. Planning
• CHAPTER 5. Documentation
• CHAPTER 6. Superblock
• CHAPTER 7. Design
• CHAPTER 8. Registers
• CHAPTER 9. Interrupts
• CHAPTER 10. Aborts, etc.
• CHAPTER 11. Hooks
• CHAPTER 12. Conclusion
• Appendix A. Best Practices
• Appendix B. Bicycle Controller Specification
• Glossary
• Index