Headlines

Headlines

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

By Gary Stringham

“Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems Development” is a book with practical concepts that can be used while designing ASICs, ASSPs, SoCs, and FPGAs which will solve many firmware (embedded software) programming issues and help avoid chip respins. It contains over 300 best practices which help get products and projects completed sooner and more effectively.

Targeted to both hardware engineers and firmware engineers, this book helps optimize the hardware/firmware interface within the project or product by mitigating or eliminating problems that occur when hardware and firmware are not optimally compatible. 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 on cleaner designs, shorter schedules, and better implementations.

Communication and Control

Imperative to proper operation as a system, hardware and firmware must work well together. This includes support from hardware to give firmware a wide variety of information it may need to make decisions (communication) and give firmware a wide variety of options for configuring and launching tasks in hardware (control). This section will discuss several aspects of communication and control.

Necessary Information

Firmware is best able to make proper decisions if it has necessary information to do so. The following is a list of some types of information:

  • Current state of the block and I/O signals
  • Performance data
  • Buffer contents
  • Error information

Tales from the Trenches

An engineer from a startup company was adding an I2C bus switch to an I2C bus in an embedded power supply. The switch’s data sheet cautioned that the upstream bus master should not switch in a downstream bus if the downstream bus was in the middle of a data transfer. The problem was that when the downstream bus was switched out, the upstream bus master could not know whether a data transfer was in progress. The bus switch did not provide any help to know that.

A bus monitor feature in the switch would have solved that problem. The switch could monitor the state of the downstream bus and know whether data transfers are active. The upstream bus master queries the switch regarding the current state of the switchedout bus and, when data transfer stops, then switch in the bus.

A good way to know what kind of information firmware would need is to collaborate with firmware engineers; ask them what they need to know or would like to know to help firmware operations.

Best Practice

8.5.1 Collaborate with the firmware team to determine any internal information that each block should make accessible to firmware.

Interrupts

The previous chapter discussed registers, which is how firmware invokes action in the hardware. This chapter is about interrupts, which is how hardware invokes action in the firmware. Hardware uses interrupts to notify firmware that some event has occurred. When an interrupt occurs, firmware sets aside its current task and services the interrupt.

Because of the problems and confusion due to the variety of interrupt behaviors in use by the industry today, I have dedicated a separate chapter to this topic. These problems and confusion are due to a lack of consistency and clarity in the function and behavior of interrupts. What one chip calls Enable, another chip calls Mask. It may be that a 1 is written to “ack” (acknowledge) an interrupt on one chip, whereas a 0 is written on another.

This inconsistency leads to confusion and problems as firmware engineers write device drivers for different blocks, for different chips, and for chips from different companies. Leveraging skills and device driver code from one style of behavior to another leads to firmware defects, some of which are very difficult to debug.

Enforcing the same interrupt behavior in all blocks, in all chips, and across all companies will greatly reduce problems in firmware. As long as the behavior, whether logical or esoteric, is consistent throughout, engineers will know the method and understand it and will be able to leverage firmware code from one device driver to another.

Using a standard implementation has benefits. As an example, electrical engineers know what a flip-flop is, but because there are a variety of implementations in use, exact details are not known. But there are standard flip-flop types that are defined and understood, such as RS, D, and JK flip-flops. Once the type of flip-flop is specified, such as a D flip-flop, engineers know immediately how it works, its truth table, and how to wire it up. Standard flip-flops have fixed parts, such as a data and clock input, and it has optional parts, such as an enable or clear. These are also understood by engineers.

In contrast, an interrupt module can be implemented in many different ways, but no standard implementation exists.

In this chapter, I will discuss implementation variations and their impact on firmware. And I will state which variation should be part of an interrupt standard. If all companies that produce chips were to use this interrupt standard, many problems will be avoided in firmware, especially by those writing firmware for chips from various companies. Firmware functions and techniques that work with this interrupt standard can be written and distributed.

Design

In this section, I will discuss a few design guidelines regarding the interrupt module.

An Interrupt Supermodule

With the goal of providing consistency in the design of the interrupt module, it is logical to design the module to be instantiated wherever an interrupt module is needed. This lends itself to becoming a supermodule following the concepts discussed in Chapter 6, Superblock. The interrupt supermodule provides support for the superset of functionality and includes the following list of features:

  • Consistency in the behavior of the module
  • Consistency in the address offsets of the registers
  • Consistency in the bit positions among the various registers
  • The ability to specify the number of interrupt channels needed
  • The ability to specify which optional registers are implemented

Best Practice

9.1.1 Design the interrupt module as a supermodule to provide the superset of all features needed by all chips instantiating the module.

Each of these will be explained in greater detail in this chapter.

Excerpts taken from Hardware/Firmware Interface Design: Best Practices for Improving Embedded Systems Development by Gary Stringham, 376pp, 2010, ISBN 9781856176057. Published by Newnes. Excerpt copyright (c) 2010 by Elsevier Inc. All rights reserved. For further information please visit the publisher’s site at www.elsevierdirect.com/9781856176057 or visit the author’s site at www.garystringham.com/hwfwbook.

Gary Stringham is an embedded systems expert and consultant with a specialization in the hardware/ firmware interface. He is the founder of Gary Stringham & Associates, LLC (www.garystringham.com). With over 25 years of industry experience, Gary focuses on diagnosing and resolving difficult hardware/firmware integration issues, reducing chip respins, and producing solid solutions to prevent future occurrences of those issues.