Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems Development

361 Pages·2009·3.74 MB·English

by  Gary Stringham

Newnes isanimprint of Elsevier
30Corporate Drive, Suite400, Burlington,MA 01803,USA
The Boulevard, Langford Lane,Kidlington,Oxford,OX51GB, UK
Copyright © 2010byElsevier Inc.All rights reserved.
No partof this publicationmay bereproduced ortransmitted inanyform or byanymeans,
electronic or mechanical, including photocopying,recording, or anyinformationstorage and
retrieval system, without permission inwriting from the publisher.Details onhowto seek
permission, further information about thePublisher’spermissions policies andourarrangements
with organizations suchas the Copyright Clearance Centerandthe Copyright LicensingAgency,
canbefoundat our website: www.elsevier.com/permissions.
Thisbookandthe individualcontributions contained in itareprotected undercopyright by
the Publisher (other than asmay benoted herein).
Notices
Knowledge andbestpractice in thisfield areconstantly changing.As newresearch andexperience
broaden ourunderstanding, changesin research methods,professional practices,or medical
treatment may becomenecessary.
Practitioners andresearchers mustalways rely ontheir ownexperience andknowledge in
evaluating andusing anyinformation, methods,compounds, or experimentsdescribed herein.In
using suchinformationor methods they shouldbemindful of theirown safety andthe safety
of others,including parties for whomthey haveaprofessional responsibility.
To thefullest extentof the law, neither thePublisher nor the authors,contributors, oreditors,
assume anyliability for anyinjuryand/or damage topersons or property as amatterof products
liability, negligenceor otherwise, or fromanyuse or operation of anymethods,products,
instructions, or ideas contained inthe material herein.
Library of Congress Cataloging-in-Publication Data
Application Submitted.
British Library Cataloguing-in-Publication Data
A cataloguerecordfor thisbookis available fromthe British Library.
ISBN: 978-1-85617-605-7
For informationonallNewnes publications
visit ourWeb siteat www.elsevierdirect.com
Typeset bydiacriTech, Chennai, India
Printed in the UnitedStates of America
08 09 10 10 9 8 7 6 5 4 3 2 1
Preface
You can find books written by hardware engineers teaching hardware engineers how to
design hardware. You can find books written by firmware engineers teaching firmware
engineers how to write firmware. This book is written by a firmware engineer but is
directed primarily to hardware engineers.
Many engineers have experienced problems when trying to get firmware working on
hardware. They are designed generally in isolation from each other and then are expected to
work when brought together. But problems and defects appear. At times it is unknown
where the defect is located—in hardware or firmware, or maybe the documentation.
There is very little written about how to get hardware and firmware to work well together.
This book attempts to fill that niche. It addresses the interface between the hardware and
firmware domains and provides practices that will reduce the time and effort required to
produce an embedded systems product. It covers all aspects of development surrounding the
hardware/firmware interface, including the process of development, the high-level design,
and the detailed design.
A key feature of this book are the 300+ Best Practices that give detailed instructions for
various aspects of the development process and design. These best practices apply perfectly,
but only for a given situation. They should be scrutinized for applicability in a given
situation. Throughout this book, the emphasis is for engineers to develop their own set of
best practices. They may start with these 300, but the set should evolve to be made their
own, as this increases the likelihood of success within their organization.
To help engineers understand the 300+ Best Practices, and to help them create their own
set, Seven Principles are presented that provide overarching guidelines and direction. These
principles, when internalized, will help engineers work in the right direction, even if there is
no specific best practice for that situation. Following the Seven Principles and 300+ Best
Practices will improve the design teams’ ability to produce successful embedded systems
products.
©2010byElsevierInc.Allrightsreserved. x
Preface
Chapter Summaries
The following chapter summaries provide an overview of the book and help the reader to
navigate through the book.
1. Introduction: This chapter establishes the foundation for the book. It discusses various
types of hardware and how they impact the hardware/firmware interface. It defines
principles and best practices, the target audience, and the product life cycle. It also
presents a case study used throughout the book.
2. Principles: This chapter presents the Seven Principles and provides a high-level view
and reasoning for the direction of this book. Understanding these principles is key to
understanding why the best practices are stated as they are.
3. Collaboration: Of key importance to the success of an embedded product is the proper
and sufficient collaboration between hardware and firmware engineers. This chapter
defines roles and processes in such an effort.
4. Planning: Before starting a project, planning must be done to determine and agree what
direction should be taken with the new product. This chapter covers several areas that
should be visited when planning a new project.
5. Documentation: Most engineers assigned to write documentation do not like the task.
And most engineers reading documentation get frustrated with incomplete and incorrect
documentation. This chapter discusses the types of documentation, when to write them,
how to review them, and what types of details to include in them.
6. Superblock: This chapter introduces the concept of a block that can do everything
within its own domain. It discusses why a superblock is good and how to set it up to be
used where needed. But it also discusses the reality of practical limitations and how to
handle those.
7. Design: Various design aspects are discussed in this chapter, such as events, power-on
sequences, communication, and control.
8. Registers: Registers are the fundamental interface between hardware and firmware. This
chapter discusses them in great detail, including addresses, bit locations, and types of bits.
9. Interrupts: Given a lack of consistency among interrupt designs used in the industry,
this chapter focuses in great detail how interrupts from hardware into firmware should
be managed. This chapter also contains a proposal for an interrupt standard and
discusses the proposal in detail.
10. Aborts, etc.: Too often very little thought is given to errors and how to recover from
them. This chapter discusses design elements necessary to allow firmware to abort
hardware operations, recover, and resume processing.
©2010byElsevierInc.Allrightsreserved. xi
Preface
11. Hooks: Logic analyzers cannot probe the internals of a chip but knowledge of what is
occurring inside is important when trying to get firmware working on hardware. Having
firmware-accessible hooks inside the chip allows firmware to retrieve information for
engineering analysis. This chapter contains many possible hooks that could be included.
12. Conclusion: This chapter wraps up the book. It also contains a couple of cartoon
illustrations used to help illustrate the concepts in the book.
Appendices
A. Best Practices: This appendix collects all the best practices in the book into
one place.
B. Block Specification: This appendix is a documentation template as explained and
described in Chapter 5, Documentation.
C. Using This Book in a University: This appendix provides suggestions on how to
use this book to teach hardware and firmware engineering students that have to
work together on a project.
D. Glossary: Given that this book addresses two different engineering disciplines,
hardware and firmware engineering, it covers terms from one domain that might
not be understood by the other.
Conventions Used in This Book
The bulk of the text in this book discusses the concept at hand. Interspersed in the text are
one or more of these elements: figures, listings, register maps, best practices, and tales from
the trenches.
Figures
Figure 0.1 is an example figure.
Firmware Listings
Listing 0.1 shows an example listing of firmware source code written in C.
A B C
Figure 0.1: Example figure.
©2010byElsevierInc.Allrightsreserved. xii
Preface
Listing 0.1: Example C code listing.
/* Readthecurrent listof pendinginterrupts */
interrupts =*interruptRegister;
Hardware Circuits
A few hardware circuits are illustrated in the book. Both a schematic drawing and its
equivalent Verilog listing will be given. Figure 0.2 is the schematic and Listing 0.2 is the
corresponding Verilog code for an example circuit.
Register Maps
This diagrammatic form is used in discussions about registers, how various bits are mapped
into the register, and the mode of operation and reset values of these bits. A detailed
explanation of this format is given in Chapter 5, Documentation.
MSB DailyRegister–0x0004 LSB
Bits 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
R/W - - - - - - - - - - - - - - - - - - - - - - - - - - - - - C B A
Reset 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
A This bit means one thing.
B This bit means another.
C And this bit means something else.
Best Practices
The book contains 300+ Best Practices related to the concepts being taught. In addition to
presentation throughout the book, these practices are collected in Appendix A, thereby
A
C
B
Figure 0.2: Schematic for example circuit.
Listing 0.2: Verilog code for example circuit.
// Asimple ANDgate.
assign c =a &b;
©2010byElsevierInc.Allrightsreserved. xiii
Preface
providing a concise checklist that can be used during chip design projects. They are also
provided in a spreadsheet available online at the publisher’s website, elsevierdirect.com/
companions, and at the author’s website, garystringham.com/hwfwbook.
Each best practice has an ID number, X.Y.Z, which is used in the body of the book, in
Appendix A, and in the spreadsheet.
þ Best Practice
1.1.1 Best Practices of Hardware/Firmware Interface Design.
Like the book, the Excel spreadsheet database is copyrighted material. Purchasers of this
book are entitled (and encouraged) to start with the database and modify it to suit the needs
of their design team, but some restrictions apply. See Appendix A for more details on the
database and its copyright permissions.
þ Best Practice
1.1.2 Copyright © 2009, Gary Stringham & Associates, LLC. All rights reserved. Do not
distribute beyond your team.
Tales from the Trenches
Scattered throughout this book are real-life stories that help illustrate the impact of the topic
at hand. These are stories from real engineers (mostly me) in the trenches, working away
designing and solving problems. The following is an example tale (not a real one).
& Tales from the Trenches
I remember hearing a story from a friend of a friend, who heard that an engineer had said
that he heard a manager tell her subordinate that–according to the rumor she had heard–it
was already broken to start with.
Companion Website
This book has a companion website at elsevierdirect.com/companions/9781856176057,
where you will find links to the spreadsheet database for the 300+ Best Practices, the
document template discussed in Chapter 5, Documentation, and other related content. Please
©2010byElsevierInc.Allrightsreserved. xiv
Preface
visit the author’s website at garystringham.com/hwfwbook for the same tools, plus
additional links to his work in this area and details of how to contact him directly.
How to Contact Me
If you have any questions about the content of this book or about your hardware/firmware
interface design, feel free to contact me at [email protected].
Acknowledgments
I would like to thank Jack Meador and Mike Merrell, the two unlucky hardware engineers
who had to put up with my constant questions, issues, and requests as we worked through
the project that was the catalyst for this book. They provided valuable insight and help from
within their hardware domain. They, along with other hardware and firmware engineers
within the organization and from other companies, provided much of the input used in
many of the best practices and tales from the trenches in this book.
I would also like to thank my immediate managers at the time, Warren Johnson and Tracy
Sauerwein, and managers above them, Sandy Lieske and Von Hansen. The book is finally
published—your unwarranted support, while tracing my progress from sandy to smooth, was
not in vain.
Me badly english writin’ was greatly improved through the patient tutelage of my technical
writing coach, Joel Saks. He has a gift with words that is way beyond my abilities. In
addition, he was a valuable resource for critical analysis of my concepts, pushing me to
clearly articulate and justify what seemed obvious to me.
I would also like to thank John Blyler, Clive “Max” Maxfield, Jack Meador, Mike Merrell,
Joel Saks, and three others (who wish to remain anonymous) for reviewing all or parts of
my book. Your comments provided valuable input and suggestions, making the book better
than otherwise. Thanks to Mike Merrell for his help with the Verilog code and to Kevin
Falk for drawing the car illustrations. And thanks to the many others who have given me
suggestions and enthusiastic encouragement during the 5 years it took me to complete this
project.
Most of all, I want to thank my wife and children for their patience and
long suffering as I spent evenings and weekends working on this book instead of making
repairs on the house, driving the children to their activities, and vacationing with the family.
©2010byElsevierInc.Allrightsreserved. xv
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)1 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.”
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
1 Forthe purposesof thisbook, the termASICwill also betakento encompassapplication-specific standard
products(ASSPs),systemonchips(SoCs),andfield-programmablegatearrays(FPGAs).(Seealsothedefinitions
later in thischapter.)
©2010byElsevierInc.Allrightsreserved.
DOI:10.1016/B978-1-85617-605-7.00003-4. 1
2 Chapter 1
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
www.newnespress.com