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