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:
- Collaborate on the Design;
- Set and Adhere to Standards;
- Balance the Load;
- Design for Compatibility;
- Anticipate the Impacts;
- Design for Contingencies; and
- 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.
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; sei.cmu.edu/cmmi), ISO (International Organization for Standardization, international standards for business, government, and society; iso.org), and Agile (software development methods promoting regular inspection and adaptation; agilealliance.org).
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
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.
input [7:0] Data;
assign Parity = Data^Data^Data^Data^
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.
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.
Currently no items