Hardware/Firmware Interface Design Best Practices for Improving Embedded Systems Development
	Description Reviews Downloads Table of Contents Excerpts Errata	Available now at:
		Elsevier (publisher) Amazon.com Barnes & Noble Borders and other book retailers

Gary has authored a book with practical concepts that can be used while designing ASICs, ASSPs, SoCs, and FPGAs which will solve many firmware programming issues and help avoid chip respins. It contains over 300 best practices, some of which have been discussed in his newsletters. These best practices help get your products and projects completed sooner and more effectively!

Whether you are primarily a hardware engineer or firmware engineer, this book will help you optimize the hardware/firmware interface within your project or product. Key topics covered include register layout, interrupts, timing and performance, aborts, and errors. Real-world case studies help to solidify the principles and best practices and focus you on cleaner designs, shorter schedules, and better implementations.

• Dennis L Feucht on EN-Genius Network: Book Reviews - “I did not have to read too far into this book to realize that the author has extensive experience... ...it is the kind of knowledge useful to analog engineers who work on products [that need to interface] with microcontrollers...”
• Michael Barr on Amazon.com: Buy This Book for the Engineers Over in FPGA Design! - “...the price of the book will pay off in fewer [FPGA] revisions. ...this well-written book will serve as the launching pad...”
• Christopher Svec on Said Svec: Book Review: “Hardware/Firmware Interface Design” - “...I think both [hardware engineers and firmware engineers] should read this book.”
• Embedded Intel Solutions, Spring 2010, page 28-29: Hardware/Firmware Design: Special Feature - “If all companies that produce chips were to use this interrupt standard, many problems will be avoided in firmware.”
• IEEE Computer magazine, May 2010, page 73: Bookshelf - “The book can help engineers minimize delays and glitches in their designs...”

• Appendix A: Best Practices - The best practices in an Excel spreadsheet database. Free with purchase of book. Send email to Gary for details.
• Appendix B: Bicycle Controller Specification - This is a sample document of a block. This is discussed in Chapter 5 and can be used in parts or whole as a template for your own documentation. Format: .doc.
• Appendix C: Using This Book in a University - This was left out of the printed book because of lack of space. Format: .pdf.

From Chapter 1: Introduction

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.”

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.

From Chapter 5: Documentation

Firmware and hardware engineers conduct a “computerized review” of their code simply by compiling or synthesizing their code and then running test suites. If the compilation/ synthesis or a test suite fails, there is a problem in the code. However, there is no “computerized review” available to verify accurate syntax, details, and completeness with regard to documentation. Thus, an important aspect of writing documentation is to have it reviewed.

Since this book focuses on improving collaboration between hardware and firmware engineers, this next section will discuss when reviews should occur and the responsibilities of firmware engineers with regards to reviewing the hardware documents written by hardware engineers.

From Chapter 8: Registers

Taking the chip ID concept down farther, each block within a chip should contain its own ID and version registers. This allows firmware to base its versions on the block itself, and not have to decode which chip IDs map into which version of the block, especially when the same block is instantiated across many chips. This also allows existing device drivers to work on new chips, even though the new chip has a different chip-level ID and version. The existing device drivers do not need to be updated simply to add a new chip-level ID and version to its list.

This block-level ID and version is ideally suited for use on FPGAs, which are, by their nature, changing quite frequently. A chip-level version number has to change every time any one of the blocks makes a change. This impacts all device drivers, even those whose blocks did not change, causing each one to add the new chip-level version to its list. By using block-level version, only the blocks that changed need to have their respective device drivers change. This is especially useful if several versions of the FPGA code are being used throughout the development lab.

• Page ix, Appendix C: should read, “Appendix C: Using This Book in a University ... Available at elsevierdirect.com/companions/9781856176057 or garystringham.com/hwfwbook”