The Real Differences Between HW And SW

How many times have we heard people say that hardware and software do not speak the same language? The two often have different terms for essentially the same thing. What hardware calls constrained random test is what software people call fuzzing.

Another one recently caught my eye in a conversation with Jama Software, a Portland software company that has made a name for itself in requirements management for software. The differences showed up when I talked to Derwyn Harris, one of the co-founders of Jama. He told me that requirements management and agile methods had defined the initial company development, but along the way they lost sight of their own requirements and decided that they needed to change. They also observed that many other companies in the industry faced the same issues.

“Traceability is driving people to solutions beyond documents,” said Harris. “Certification and regulation are driving the need for traceability and making it important in a live sense.”

By live, Harris is talking about the way in which agile has changed the software development process. “The one thing coming out of agile is that people want to be more iterative. That means they need processes that are more aligned and provide a seamless feedback loop. Software companies need the ability to move faster and to become more competitive, and they need to shift from a concentration on specification to one of requirements.”

Jama provided a brief demonstration of how it has been migrating some of their techniques into hardware, and that is when things got a little weird for me. In place of requirements I saw spec items, such as “has a DDR3 interface” or “must have four cores.” Could the term ‘requirements’ be used that differently between hardware and software? To get to the bottom of this I spoke to Adrian Rolufs, a senior consultant for Jama who comes from a semiconductor background and thus should be able to speak my language.

Rolufs responded to my confusion. “As a starting point, this (demo) project is what we would show a customer who is focused on chip development and not on the software that goes with a chip. The highest level of information that tends to be available for semiconductors is very low level in the bigger picture. You are building a chip that goes into something that probably goes into something else until you get to something that a person would interact with. The chip could also go into many different products. When working with semiconductor customers, the high-level requirements are usually very detailed and there may be requirements such as, ‘I must have a specific ball pitch or specific processor core because that is what my legacy code is written in.’ When requirements come in like that, they tend to be not very different from specification items. The difference is the context within the project.”

This means that most hardware is designed without a product focus. But what about standards such as ISO 26262 or DO-254, which are asking for requirements traceability? They don’t want to know that the unit has a DDR interface. They want to know that the bandwidth to memory meets a certain requirement, and they want to know how you demonstrated that to be the case.

Concurrency also complicates the question. Most of the time, software provides only a single way in which functionality is implemented, but hardware is very different in that respect. It often provides many ways in which something may happen, or in terms of what other things it is doing at the same time.

“When you are writing hardware requirements you are often developing architectures in parallel,” explains Rolufs. “You may be doing modeling at the top level to see if what you are writing makes sense. Every chip development that I am aware of has someone thinking about the solution as soon as a stakeholder requirement is mentioned. The first step in many chip developments is to develop a diagram showing the major blocks that will be in there. It is likely they have developed a similar product in the past, and they will have a bunch of stuff they are trying to reuse. They have experience. They have a lot of solution knowledge already available. So hardware never starts with a blank slate, and requirements are written in terms of a solution that is already known. Most hardware teams are not very good at innovation because they have already solved the problem and they want to stick with what they know works.”

Requirements tend to get very complex when you start looking at test case management. Making sure you have a test for every requirement is a lot of work—making sure you didn’t miss a case, or take into account process variability that can upset things. “Change management is important for many of these kinds of project,” says Rolufs. “Then they can track the impact of finding that a spec item cannot be met.”

At the end of the day, hardware design and verification is about probability. How likely is it that a bug has escaped? How likely is it that I have accounted for worst case conditions? How likely is it that 95% of the parts produced will meet the spec?

“While it may sound complex, this is what semiconductor guys are good at,” adds Rolufs. “That is their core expertise.”

Semiconductor companies traditionally have not written requirements. They did not start off with a set of customer needs; rather they develop a chip that they think people will want. It is probably less likely today that you can just build something because it is an interesting piece of engineering and expect there to be a customer. As slows, design will become increasingly important and requirements may start to be more of a driving force in semiconductors.

It also seems as if this may be another point where the concept of verification intent (what Accellera calls ) may start to integrate with other system level capabilities. Being able to show that a requirement is met by a path through a graph, and then being able to show the test cases that exercise that path, would enable all of these things to be linked. It would seem as if requirement management and traceability is a new skill that semiconductors companies will have to learn—and where the software industry already has expertise.

Related Stories
HW Vs. SW: Who’s Leading Whom?
Both sides have some specific problems and have developed solutions suited to their needs. But as hardware and software are forced closer together, who has the best ideas?
Cars, Security, And HW-SW Co-Design
Experts at the table, part two: Standards are helping address some issues in concurrently designing hardware and software. More challenges are ahead as automotive electronics and cybersecurity issues enter into the equation.
Cars, Security, And HW-SW Co-Design
Experts at the table, part 1: Hardware and software must be developed at the same time these days to shorten the time-to-market for advanced devices and electronics.