Basics of hardware/firmware interface codesign -

Basics of hardware/firmware interface codesign

Editor’s Note: In this article, excerpted from Hardware/Firmware Interface Design , by Gary Stringham, the author provides seven principles of embedded hardware/firmware codesign that will ensure that such collaborations are a success.

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 tool sets 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 have to integrate successfully to build a product, it is imperative that the hardware/firmware interface – including people, technical disciplines, tools and technology – be designed properly

This article provides seven principles hardware/firmware codesign that if followed will ensure that such collaborations are a success. They are:

  1. Collaborate on the Design;
  2. Set and Adhere to Standards;
  3. Balance the Load;
  4. Design for Compatibility;
  5. Anticipate the Impacts;
  6. Design for Contingencies; and
  7. Plan Ahead.

Collaborate on the Design
Designing and producing an embedded product is a team effort. Hardware engineers cannot produce the product without the firmware team; likewise, firmware engineers cannot produce the product without the hardware team.

Even though the two groups know that the other exists, they sometimes don’t communicate with each other very well. Yet it is very important that the interface where the hardware and firmware meet—the registers and interrupts—be designed carefully and with input from both sides.

Collaborating implies proactive participation on both sides. Figure 2.1 shows a picture of a team rowing a boat. Some are rowing on the right side and some on the left. There is a leader steering the boat and keeping the team rowing in unison. Both sides have to work and work together. If one side slacks off, it is very difficult for the other side and the leader to keep the boat going straight.

Figure 1: Both sides row to keep the boat going straight. (Photo © Pepple Photography)

In order to collaborate, both the hardware and firmware teams should get together to discuss a design or solve a problem. Collaboration needs to start from the very early stages of conceptual hardware design all the way to the late stages of final firmware development. Each side has a different perspective, that is, a view from their own environment, domain, or angle.

Collaboration helps engineers increase their knowledge of the system as a whole, allowing them to make better decisions and provide the necessary features in the design. The quality of the product will be higher because both sides are working from the same agenda and specification.

Documentation is the most important collaborative tool. It ranges from high-level product specification down to low-level implementation details. The hardware specification written by hardware engineers with details about the bits and registers forming the hardware/ firmware interface is the most valuable tool for firmware engineers. They have to have this to correctly code up the firmware. Of course, it goes without saying that this specification must be complete and correct.

Software tools are available on the market to assist in collaborative efforts. In some, the chip specifications are entered and the tool generates a variety of hardware (Verilog, VHDL. . . ), firmware (C, C++ . . . ), and documentation (*.rtf, *.xls, *.txt . . . ) files. Other collaborative tools aid parallel development during the hardware design phase, such as co-simulation, virtual prototypes, FPGA-based prototype boards, and modifying old products.

Collaboration needs to happen, whether it is achieved by walking over to the desk on the same floor, or by using email, phone, and video conferencing, or by occasional trips to another site in the same country or halfway around the world.

This principle, collaboration, is the foundation to all of the other principles. As we shall see, all of the other principles require some amount of collaboration between the hardware and firmware teams to be successful.

Set and Adhere to Standards
Standards need to be set and followed within the organization. I group standards into industry standards and internal standards.

Industry standards exist in many areas, such as ANSI C, POSIX, PCI Express, and JTAG. Stay true to industry standards. Don’t change them. Changing a standard will break the protocol, interoperability, and any off-the-shelf components, such as IP, device drivers, and test suites.

For example, USB is widely known and used for connecting devices to computers. If this standard is adhered to, any USB-enabled device can plug into any computer and a well-defined behavior will occur (even if it is “unknown USB device installed”).

Industry standards evolve but still behave in a well-defined manner. USB has evolved, from 1.1, to 2.0, and now 3.0, but it still has a well-defined behavior when plugging one version into another.

By internal standards, I mean that you have set standards, rules, and guidelines that everybody must follow within your organization. Modules are written in a certain fashion, specific quality checks are performed, and documentation is written in a specified format. Common practices and methods are defined to promote reuse and avoid the complexity of multiple, redundant ways of doing the same thing.

In the same way that industry standards allow many companies to produce similar products, following internal standards allows many engineers to work together and encourages them to make refinements to the design. It provides consistency among modules, creation of common test suites and debugging tools, and it spreads expertise among all the engineers.

Look at the standards within your organization. Look for best practices that are being used and formalize them to make them into standards that everybody abides by. There are many methods and techniques in the industry that help with this, such as CMMI (capability maturity model integration, an approach for improving processes;, ISO (International Organization for Standardization, international standards for business, government, and society;, and Agile (software development methods promoting regular inspection and adaptation;

Adapt and change your internal standards as necessary. If a change needs to be made, it needs to go through a review and approval process by all interested parties.

Once such a change has been approved, make sure that it is published within your organization. Apply version numbers if necessary. There is no such thing as a “customized standard.” Something is either a standard or customized, but not both. If you break away from a standard, be sure you have a good reason.

Balance the Load
Hardware and firmware each have their strengths and weaknesses when it comes to performing tasks. The challenge is to achieve the right balance between the two. What applies in one embedded system will not necessarily apply in another. Differences exist in CPU performance, bus architectures, clock speeds, memory, firmware load, and other parameters.

Proper balance between hardware and firmware depends on the given product and constraints. It requires studying what the tradeoffs will be for a given situation and adjusting as necessary.

An embedded system without a proper balance between hardware and firmware may have bottlenecks, performance issues, and stability problems. If firmware has too much work, it might be slow responding to hardware and/or it might not be able to keep hardware busy.

Alternatively, hardware might have too big of a load, processing and moving data excessively, which may impact its ability to keep up with firmware requests. The quality of the system is also impacted by improper load balancing. The side with the heavier load may be forced to take shortcuts, fall behind, or lose some work.

A simple example to illustrate this point is to calculate the parity of a byte, a task often required in communication and storage applications. A firmware routine has to use a for() loop to look at each bit in the byte to calculate its parity. Listing 2.1 is an example in C of a for() loop to calculate parity by exclusive-ORing each bit.

  // Generate the parity of a byte
  char generate_parity (char byte);
    char parity; // Contains the current parity value
    char bit; // Contains the bit being looked at
    char pos; // Bit position in the byte
    parity = 0;
    for (pos=0; pos<8; pos++) // For each bit in the byte
      bit = byte >> pos; // Shift bit into position
      bit &= 0x1; // Mask out the rest of the byte
      parity ^= bit; // Exclusive OR with parity
    return (parity);

Listing 2.1: C code for generating parity in firmware.

The four-step for() loop translates into several assembly language steps that must be repeated eight times requiring multiple CPU cycles to do so. Other algorithms exist with various impacts on time and memory, but none can get close to the performance that can be achieved using a hardware implementation. Figure 2.2 and Listing 2.2 illustrate how hardware can exclusive-OR all eight bits together in a single clock cycle.

  module parity(
  input [7:0] Data;
  output Parity;
  assign Parity = Data[0]^Data[1]^Data[2]^Data[3]^

Listing 2.2: Verilog code for generating parity in hardware.

Like the firmware version, the hardware version has several steps (levels of logic) to it. But since it can access all eight bits at once, the parity is generated in a single clock cycle. In fact, the parity can be generated while the byte is being transferred on the bus.

Figure 2.2: Schematic drawing of a circuit to generate parity in hardware.

Another example is the tradeoff for calculating floating-point numbers. It is faster to calculate them in hardware with a floating-point coprocessor but it adds to the material costs of the product. Performing the calculations in firmware is slower but reduces parts costs.

The lesson here is to consider the tradeoffs between the hardware and firmware tasks and to determine whether the balance needs adjusting. Do the I/O buffers need to be expanded? Do interrupt priorities need to be adjusted? Are there firmware tasks that could be performed faster in hardware? Are there hardware tasks that require the flexibility of firmware? Are there handshaking protocols between hardware and firmware that could be better tuned? Are there ways to reduce material costs by having firmware do more?

Balancing the load between hardware and firmware requires collaboration between the hardware and firmware engineers. Engineers understand the load impact associated with a task in their own domain but may not fully realize how it impacts the other. A principle of economics applies here—two parties will be more productive if they work together, but with each working on the tasks that suits them best.Design for Compatibility
Designing for compatibility means todesign in such a way as to facilitate, where possible, the ability forany version of firmware and any version of hardware to be paired up.Cell phones are a good example of this. Many, many different models ofcell phones exist but some are very alike.

Different phones mayhave a variety of skins and colors but their hardware and firmware canbe very similar. Cell phones can be upgraded with newer versions offirmware with new features; meanwhile, different (but similar) models ofcell phones may be equipped with the same firmware.

In somecases, for example, firmware can be set up to support many features andthen—through the use of configuration files, NVRAM settings,compile-time switches, and so on—only the required features will beenabled. The relevant hardware blocks would be designed with fullsupport for all features, while the firmware would control whichfeatures are actually used. This allows the same hardware to beinstalled in different models of the product while still presentingdifferent features to the outside world.

Designing forcompatibility also means that when a new version of hardware is releasedwith new features, it won’t break when paired with older versions ofthe device driver, thereby allowing reuse of the old device driver. Thisis accomplished by following rules such as not moving bits andregisters around.

Compatibility is especially useful whenmultiple versions of hardware and firmware are deployed during productdevelopment and among customers. It reduces development time, savescosts, and gets the product out to customers sooner.

Firmware isbecoming more and more expensive; in some cases, developing firmware cancost more than hardware. Also, it can be difficult to change firmwaredue to its many components, layers, and architecture. This increases theimportance of striving for compatibility in hardware so as to minimizechanges forced upon firmware.

Pairing any version of firmwarewith any version of hardware is ideal but not practical all of the time.However, it is a vision to strive for. Bearing compatibility in mindwhile designing from the beginning will lead to decisions that movetoward that goal.

Anticipate the Impacts
In the game ofgolf, the golfer selects the club, puts the ball on the tee, looks downthe fairway, checks the wind, lines up the club to the ball, and checkshis stance. He is anticipating the impact of his club on the ball. Hedoes this because he does not want to miss or slice the ball, sending itinto the rough.

Similarly, when creating a new hardware designor changing an existing design, you want to anticipate the impact onfirmware. I chose the word “anticipate” because it implies a proactiveeffort. The dictionary lists “foresee” and “prevent” as synonyms. It isnot enough to understand the impact or prepare for the impact; instead,you should anticipate, foresee, and prevent the impact.

Whendesigning a new block, group bits into registers according to usage;don’t mix different types of bits in the same register; and limit howmany registers need to be accessed by more than one device driver. Whenmaking changes to an existing block, make the new version of the blockwork with the old device driver. Do not move bit locations and registeraddresses around.

Thus far I have been discussing the avoidanceof negative impact. On the flip side, you want to look for positiveimpact. For example, providing a DMA with chaining capabilities or alarger I/O buffer will reduce the firmware load.

The concept ofcollaboration is also applicable here because one of the best ways todetermine if and how a hardware change is going to affect firmware is totalk to firmware engineers. They are best-suited to determine theimpact.

Returning to the golf metaphor, the golfer does want tohave an impact, but he wants it where the ball flies straight down thefairway. He may not get a hole in one, but he will be headed in theright direction with fewer strokes. As you anticipate the impact, yourproduct development will be in the right direction without wasting timein the rough.

Design for Contingencies
Why do you carryinsurance on your car (beside the fact that in many places the lawrequires it)? Why pay the insurance premium? Do you want to collect onit? Are you going to purposefully get into an accident so you cancollect? No. But when you do get into an accident, you will be glad youhave it. You are prepared for that contingency.

On September 21,2005, JetBlue flight 292 with 139 passengers took off from Burbank,California. Unfortunately, the plane’s nose gear got stuck sideward.After circling Los Angeles for 3 hours to burn off fuel, the flight crewcame in for a successful landing (;,2933,170076,00.html).

It was amazing thatthe nose gear did not collapse. It was rugged. It was designed forcontingencies, although no one anticipated what the gear would be calledupon to do. Figure 2.3 shows the sparks from the plane when landing andhow the wheels were ground down.

Figure2.3: JetBlue flight 292 landing with the nose gear stuck sideward. (Topphoto is copyrighted by the submitter, And rewmarino, Reproduced withthe permission. Bottom two photos are in the public domain.)

Designing for contingencies means that you do what you can to prepare for problems that may appear.

Onemanager of a young hardware design team told me how his team hadinformed him that they had completed their design. The manager thensaid, “Six months from now, you are going to get the chip back and itwon’t turn on. What are you going to need to debug that chip?” The teamwent off, thought about it, and added some test and debug hooks. Whenyou are trying to get a chip to work, you will need to know what isgoing on inside.

If you are using a software simulator, you haveclear view of every internal signal and flip-flop. Similarly, if you areworking with an in-circuit emulator or JTAG, you have a good view as towhat is going on inside your design. But when you are trying to getfirmware working on a physical chip mounted inside the product,visibility inside the device is very limited.

Visibility insidethe chip can be provided to firmware by adding test and debug hooks inthe device. Adding additional read/write access to internal flip-flopsand signals gives firmware “peek-and-poke” capabilities. It is likehaving a basic logic analyzer built into the chip. These addedcapabilities cost a little in terms of space on the silicon and timerequired designing and verifying them, but this is similar to payinginsurance. You hope you don’t have to collect, but if there areproblems, you will be very happy that your premiums have been paid.

Furthermore,test and debug hooks in the chip are not solely for diagnosing andworking around defects in the hardware. They are also very useful forlocating and identifying defects in the firmware.

Plan Ahead
Peoplewho look to the future toward retirement prepare now by putting awaymoney. Those who are short-sighted spend their whole paycheck withoutany thought for the future. Businesses that plan ahead will take actiontoday to get them to where they want to be 3 to 5 years from now. Theydon’t focus solely on maximizing this quarter’s results. They do have toproduce good numbers for this quarter, but they don’t lose focus on thefuture.

Making decisions based solely on current effort and timeconstraints, without regard to its impact on the future, is to simplypostpone corrective action until later when it will be difficult andexpensive to fix.

Similarly, when designing embedded systemproducts, look ahead and make good decisions today that will pay off inthe future while not sacrificing the current product. Put a framework inthe design that will allow new features and expansion to occur.Modularity, abstraction, and reuse are techniques that support planningahead.

Returning to cell phones, the manufacturers regularly putout newer models having slightly different versions of hardware andfirmware. They are able to accomplish this because they look ahead anddevelop a framework to support this capability.

Someone oncescrawled on a white board, “There is never enough time to do it right,but there is always time to do it again.” Obviously this is not desiredbehavior. By taking the time now to plan ahead and do it right, you willsave time and money in the future when developing your next product.

This article is an excerpt from Hardware/Firmware Interface Design by Gary Stringham, copyright 2010, used by permission from Newnes, an imprint of Elsevier Publishing.

Gary Stringham is the founder and president of Gary Stringham & Associates, LLC .He has engineering experience in R&D and manufacturing with aproven track-record of cost-savings and innovation in the design,implementation, and testing of firmware, hardware, and softwaresolutions. He also has extensive expertise in diagnosing and resolving abroad range of engineering problems. Gary worked for Hewlett-PackardCompany for over 21 years, working in Fort Collins, Colorado; Exeter,New Hampshire; Böblingen, Germany; and Boise, Idaho. He can be contactedat .

Leave a Reply

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