You have been there before – and if not, you will be. After a seemingly infinite number of requirement changes and a schedule so short that you have given up all semblance of a life for the last two months, your design has finally passed all block and system-level simulations. You should be happy. But you are not. Because you are about to enter the most difficult, stressful, and aggravating part of any project: hardware/ software integration.

Hardware/software integration is a sore spot at virtually every company. Just ask friends working for other companies; like the pointy-haired manager, hardware/software integration woes are universal. Take a stroll through the technical section of your local bookstore; you will find volumes about designing for high speed, real time, high performance, low power, and test. What you will not find is a book about designing for integration.

No one has figured out the magic formula for integration – not even Xilinx®. This article is not intended to be a cure-all for your integration woes, but we can show you a few ways to ease the pain.

Hardware Said ...
The design flow shown in Figure 1 is typical of what happens in the course of a hardware design from conception to completion. The majority of the flow is straightforward – despite the feedback paths, rarely do you encounter anything that you cannot overcome. Once you have completed coding the design and passed simulation, you either have boards waiting or are expecting them shortly.

Once the initial smoke tests are done on the board, you begin bringing the design to life. You start with basic access tests to ensure that the host can communicate with the board. You write basic software test code to test the interfaces to memory, the interfaces and operation between chips, and the interface to the host processor. You write and execute code testing the memory map, interrupts, status, and control registers, and verify the timing. Now it is time to hand the tested board over to the software team.

Now that you have delivered the board to software, guess what – the hardware does not work. It is irrelevant that the test code you wrote verified the design because nothing works. The data is corrupt, the interrupts don’t clear (if they work at all), and you are lucky the system doesn’t explode the moment they power it on.

You sit down with the software engineer and ask what they are doing. You explain that your test code works and that you are sure the hardware is correct. You wonder what these guys have been doing for the last six months – don’t they even have basic software functioning?

Software Said ...
The design flow shown in Figure 1 is typical of what happens in the course of a software design from conception to completion. The majority of the flow is straightforward – despite the feedback paths, rarely do you encounter anything that you cannot overcome. In the absence of a hardware platform at the onset of the project, you developed an emulated host environment that allows you to develop and test your code.

You start with basic tests of the OS. You test function calls, interrupts, and the GUI. You optimize the code for performance and verify the operational paths. You check the algorithms and verify the corner cases. You do everything possible to ensure that the software will be ready when the boards are available, only to be told you will receive the hardware six weeks later than expected. (The project end date does not move.) You finally receive the hardware.

You track down the power supply and cables that did not show up with the board. You power up the board – the system appears dead. Now you begin the arduous task of debugging and working through the system. You discover that the hardware is Big Endian, despite an earlier agreement that data will be transferred in Little Endian format.

You sit down with the hardware engineer and ask what they are doing. They immediately start telling you how their test code works and that they are sure the hardware is correct. You wonder what these guys have been doing for the last six months – don’t they even have basic hardware functioning?

The Counselor Says ...
Although the preceding sections are somewhat exaggerated, the odds are that you recognized either a past or current project in them. But the reason why you may not see a lot written about this subject is because the issues involved don’t make much sense.

If Figure 1 applies to both hardware and software, then obviously the design flows are very similar and almost interchangeable – shouldn’t that help with integration? What about the software/hardware interface document (or whatever you call it at your company) that describes how the hardware and software interact – wouldn’t it preclude any problems when integrating?

The issue here is not what is common but what is not. The design community as a whole has spent much more time and resources developing hardware simulators and emulators. This began in earnest with the advent of VHDL by the military and has expanded to Verilog and more recently C-to-gates technology. Simulation technology has developed to the point that it is quite reliable and accurate. Most vendors now provide HDL models that you can use to simulate entire hardware systems as opposed to individual devices. On the flip side, the engineering community has largely ignored the other parts of the system.

Software testing without a target platform relies on the designers to build a model of the system on a host. Software engineers have to develop and test the system software using this model. And although this model is, in many cases, even more complex than the software to be designed, it cannot accurately model all of the facets of a system (much less all individual components).

Unlike the hardware models available to hardware designers, few companies offer similar models to software designers. Co-simulation offers little advantage to either software or hardware designers, because it can be prohibitively time-consuming to simulate even a few simple instructions – much less an entire routine or operation. The design flows may look basically the same, but when it comes to the way in which they are executed they are quite different.

It is this difference (and the lack of understanding the difference) that accounts for the majority of the issues during integration. To some extent, the hardware team does not understand that the software team requires the actual hardware to truly validate even what the hardware team may consider a simple function.

On the other hand, the hardware team has become in many cases overreliant on technology. Most hardware designers will tell you that the person writing a test bench and the person doing the design should be different people. However hardware engineers will write their own test code for board debug and could be lulled into a false sense of validation, making the same wrong assumptions writing the test code as when designing the logic.

To minimize the pain of integration, you must rely not on technology, but communication, understanding, and empathy. Understanding what your counterparts on the other side of the wall are doing and the processes and techniques they follow and use will allow you to better prepare for integration. Communicating with them will minimize the time and pain associated with integration. Initially this will require a little extra effort on both sides.

One of the best ideas is to have the software team write the test code that the hardware team uses to verify the board. Although this is typically not planned or scheduled, it makes sense from several angles. First, if the software team writes the test code, it minimizes the possibility that a requirement could be interpreted differently by the two teams – it will be resolved in this early phase. Second, many of the small problems that can cause major delays later (such as Big Endian versus Little Endian) will be found and their impacts minimized. This, combined with a software test plan that allows the hardware team to know what software will be tested (and in what order) can go a long way in easing integration.

The second idea is to have the hardware team document their design early and often. As the software team cannot truly test until they have target hardware, they must rely heavily on the documentation supplied by the hardware team. It is critical that the software team receives complete documentation – and that the documentation is kept up to date. The hardware team must also consult with the software team before making design changes. Although a change may seem trivial from a hardware perspective, it could result in an extensive software change, particularly in the latter stages of the project.

Finally, the software team must have a stable target platform. This does not mean a perfect, bug-free platform but rather a consistent, known platform. It is important that the hardware team relay any and all known board/logic issues to the software team. This will prevent the software team from wasting time chasing down a known problem.

Happily Ever After ...
Specifications may fluctuate. Timelines may change. Management may have pointy hair. Many technical and operational challenges exist in every project, but nothing jeopardizes a project or brings more stress to a design engineer than when hardware and software are integrated. The challenge is to plan and design for that event from the beginning.

There is no magic formula for a smooth hardware/software integration plan. However, there should be a plan and an understanding of what the other guy is doing – or is going to do. Having this understanding and actually talking with your hardware or software counterpart will make integration a lot less painful. A few sacrifices now will be rewarded in the end.

Although the software team may not have planned on writing test code for the hardware team, burning a few extra cycles to write it will allow both teams to detect and correct problems early. This – combined with a good integration/test plan, well-documented hardware (including unintended design features), and a stable hardware platform – will go a long way in making integration easier.

Printable PDF version of this article with graphics.  (7/11/05) 225 KB