The increasing complexity of HW-SW interface

HW engineers are quite busy. Every year they release greater (in terms of speed, power consumption, functionality, flexibility, security etc.) chips that we can use in our products.

In the beginnings of the computer industry, the division of work between HW and SW was clear. All computation was to be done by SW on the CPU, and interaction with the external world (incl. networked computers, storage devices, printers, other peripherals, users) was to be done by HW. This basis also implied a clear and stable interface between HW and SW.

The advent of HW-accelerated graphics started changing this status quo. When the work was constrained to a specific form, HW was much faster and more efficient in doing it than SW. This introduced the design problem of how to distribute the work between HW and SW.[1]Studied under the broader term architectural exploration.

Today, when using an application-specific processor, we are given a lot of capabilities provided by the HW: accelerating 2D, 3D and vector-based graphics; image manipulation; video encoding and decoding; network protocol tasks like checksum calculation; management of flash-based media; cryptography calculations etc.[2]How much BSPs are lagging behind to keep up with the offered features is also an interesting discussion, maybe later. And when we decide to develop our own HW on an FPGA, the decision to implement some of the functionality on HW or SW is fully under our control and responsibility.

Freescale’s i.MX family is a series of multimedia-intensive application-specific processors, and it  has shown a steady evolution over the last ~10 years.[3]Since Freescale kept all processors in the same product family, the evolution is easy to observe. The same trend can also be observed in other vendors’ products with a little bit more … Continue reading In the graph below, I show the number of pages of selected processors’ reference manuals as a rough measure of complexity. As you can see, a developer working on an i.MX6-based product has to understand twice as much material as another developer working on i.MX28.

# pages in Reference Manuals of selected processors
# pages in reference manuals of selected i.MX processors

As SW engineers we try to contain this complexity using the Hardware Proxy pattern [4]Ref: Bruce Powel Douglass’ book Design Patterns for Embedded Systems in C.. Driver models provided by operating systems all follow this pattern. The idea is to have a specific interface for a class of devices, and to have SW components, a.k.a. drivers, handling the specifics of each device and providing the interface devised for the class. This way the higher layers of SW can operate on different devices without any modification.

An example of Hardware Proxy Pattern for Ethernet drivers
An example of Hardware Proxy Pattern for Ethernet drivers

The figure above gives an example of Hardware Proxy Pattern. Different vendors can release different kinds of Ethernet HW with varying functionality and HW-SW interfaces (comprising of registers, interrupts, shared memory regions). All of this complexity is contained by the related driver. And the interface provided by driver to higher layers is always the same regardless of the vendor or device model. On the outside of the system, the interface of the HW is defined by the Ethernet protocol specification. So, as a whole, the driver-HW couple is tightly-dependent on each other, while their outside interfaces are generic, and thereby easily interchangeable with other devices of the same class and testable with generic tools.

However, sometimes the foreseen interface is not sufficient to contain the complexity. One example is the IP protocols’ task offload features offered by network adapters. As you might know TCP, UDP and IP each have checksum fields to assure the integrity of the communication. And recent network adapters are offering capabilities to calculate these checksums (and more) themselves, offloading this task from the main CPU. In the TCP/IP model (4 layers: application, transport, internet, link) POV, network adapter HW is at the bottommost link layer, while TCP & UDP are at the transport layer; and IP is at the internet layer. So it is an exception to the SW architecture to have the checksums calculated in the link layer. Microsoft’s network subsystem NDIS resolves this issue by extending the existing interfaces. It adds some new OIDs to support the offload features.

Sometimes, extending interfaces is not sufficient. As an example, porting a graphics-intensive application to a 3D HW-accelerated platform is in most cases not possible. The old graphics API, e.g. GDI, needs to be dumped completely, and a new API like DirectX or OpenGL has to be used. Due to different architectural approaches it is not feasible to write a GDI-to-OpenGL adapter, so the whole architecture up to the application-level has to be revised.

Another aspect relating indirectly to the HW-SW interface is the number of HW “bugs”, a.k.a. errata, increasing with the level of complexity in HW. The graph below shows the number of pages in errata documents and reference manuals of selected i.MX processors. Number of pages in errata documents can again be used as a rough measure of errors made in HW development. The graph verifies our general assumption that the number of errors increase even faster than the level of complexity.

# pages in reference manuals and errata sheets of selected i.MX processors
# pages in reference manuals and errata sheets of selected i.MX processors (logarithmic scale)

These errors are again a contribution to the complexity that we as SW engineers must manage using the hardware proxy pattern, extending interfaces or revising architectures.

So, what do you think? What other tactics can you think of to manage this complexity?

Footnotes

Footnotes
1 Studied under the broader term architectural exploration.
2 How much BSPs are lagging behind to keep up with the offered features is also an interesting discussion, maybe later.
3 Since Freescale kept all processors in the same product family, the evolution is easy to observe. The same trend can also be observed in other vendors’ products with a little bit more difficulty.
4 Ref: Bruce Powel Douglass’ book Design Patterns for Embedded Systems in C.

2 thoughts on “The increasing complexity of HW-SW interface

Leave a Reply

Your email address will not be published. Required fields are marked *

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.