Home » IoT Embedded Systems » Featured Stories » Is Hardware Really That Much Different From Software

Is Hardware Really That Much Different From Software

When can hardware be considered as software? Are software flows less complex? Why are hardware tools less up-to-date? Experts from ARM, Jama Software and Imec propose the answers.

By John Blyler, Editorial Director

HiResThe Internet-of-Things will bring hardware and software designers into closer collaboration than every before. Understanding the working differences between both technical domains in terms of design approaches and terminology will be the first step in harmonizing the relationships between these occasionally contentious camps. What are the these differences in hardware and software design approaches? To answer that question, I talked with the technical experts including Harmke De Groot, Program Director Ultra-Low Power Technologies at Imec; Jonathan Austin, Senior Software Engineer at ARM; and Eric Nguyen, Director of Business Intelligence at Jama Software; . What follows is a portion of their responses. — JB

Blyler: The Internet-of-Things (IoT) will bring a greater mix of both HW and SW IP issues to systems developers. But hardware and software developers use the same words to mean different things. What do you see as the real differences between hardware and software IP?

De Groot: Hardware IP, and with that I include very low level software, is usually optimized for different categories of devices, i.e. devices on small batteries or harvesters, medium size batteries like mobile phones and laptops and connected to the mains. Software IP, especially for the higher layers, i.e. middleware and up can easier be developed to scale and fit many platforms with less adaptation. However practice learns that scaling for IoT of software also has its limitations, for very resource limited devices special measures have to be taken. For example direct retrieval of data from the cloud and combining this with local sensor data by a very small sensor node is a partly unsolved challenge today. For mobiles, laptops and more performing devices there are reasonable solutions (though also not perfect yet) to retrieve cloud data and combine this with the sensor information from the device in real-time. For sensoric devices with more resource constraints working on smaller batteries this is not so easy, especially not with heterogeneous networking challenges. Sending data to the cloud (potentially via a gateway device as a mobile phone, laptop or special router) seems to work reasonably, but retrieving the right data from the cloud to combine with the sensor data of the small sensor node itself for real-time use is a challenge to be solved.

Austin: Personally, I see two significant differences between the real differences between hardware and software design and tools:

  1. How hard it is to change something when you get it wrong? It is ‘really hard’ for hardware, and somewhere on spectrum from ‘really hard’ to ‘completely trivial’ in software.
  2. The tradeoffs around adding abstraction to help deal with complexity. Software is typically able to ‘absorb’ more of this overhead than hardware. Also, in software it is far easier to only optimize the fast path. In fact, there usually isn’t as much impact to an unoptimised slow path (as would be the case in hardware.)
  3. There are differences in the tool sets. This was an interesting part of an ongoing debate with my colleagues. We couldn’t quite get to the bottom of why it is so common for hardware projects to stick with really old tools for so long. Some possible ideas included:
  • The (hardware) flow is more complex, so getting something that works well takes longer, requires more investment and results in a higher cost to switch tools.
  • There’s far less competition in the hardware design space so things aren’t pushed as much. This point is compounded by the one above, but the two sort of play together to slow things down.
  • The tools are hardware to write and more complex to use. This was contentious, but I think on balance, some of the simplicity and elegance available in software comes because people solve some really touch physical issues in the hardware tools.

So, this sort of thinking led me to an analogy of considering hardware to be very low level software. We could have a similar debate about javascript productivity versus C – and I think the arguments on either side would like quite similar to the software versus hardware arguments.

Finally on tools, I think it might be significant that the tools for building hardware are *software* tools, and the tools for building software are *also* software tools. If a tool for building software (say a compiler) is broken, or poor in some way, the software engineer feels able to fix it. If a hardware tool is broken in some way, the hardware engineer is less likely to feel like it is easy to just switch tasks quickly and fix it. So that is I guess to say, software tools are build for software engineers by software engineers, and hardware tools are built by software engineers to be sold to companies, to be given to hardware engineers!

Nguyen: One of the historical differences relates to the way integrated system companies organized their teams. As marketing requirements came in, the systems engineers in the hardware group would lay out the overall design. Most of the required features and functionality were very electrical and mechanical in nature, where software was limited to drivers and firmware for embedded electronics.

Today, software plays a much bigger role than hardware and many large companies have difficulties incorporating this new mindset. Software teams move at a much faster pace than hardware. On the other hand, software teams have a hard time integrating with the tool sets, processes and methodologies of the hardware teams. From a management perspective, the “hardware first” paradigm has been flipped. Now it is a more of software driven design process where the main question is how much of the initial requirements can be accomplished in software. The hardware is then seen as the enabler for the overall (end-user) experience. For example, consider Google’s Nest Thermostat. It was designed as a software experience with the hardware brought in later.

Blyler: Thank you.

Great information delivered straight to your inbox


  1. I like Jonathan’s debate about tools, and I’ll add my own response.

    An important factor to consider is culture. EDA (Electronic Design Automation), the industry that produces the tools for the semiconductor industry, is like a window opened to the past; if you look through the window you can see how things were done 20 years ago. Startups were not yet a thing, open source was in its infancy and most tools were proprietary. Big companies working with big companies and setting up monopolies.

    Now you say that software engineers can fix bugs in the software tools they use. Well it’s only true if they have access to the source code, isn’t? I don’t think it’s a problem of skills, the problems EDA software solve (like synthesis, place and route, etc.) are pretty hard, so the software engineers are necessarily very good. So the problem must be somewhere else, as I said I bet on culture/vision.

    Many software developers are as agile as it gets, exploring and embracing new solutions. Change is perceived as an opportunity for improvement rather than as a threat. Now talk with hardware designers, can you hear the difference? Change is perceived as disruptive (with a negative connotation) and feared. As a result, progress is slow, and innovation is largely incremental (how we gain 12% without disrupting your flow) rather than disruptive (why you should do things in a radically different way for a several-fold productivity increase). Even the potentially-disruptive HLS has settled to use “standards” to reduce the fear, even when it is obvious that these standards won’t work. (see my comment on EETimes http://www.eetimes.com/author.asp?section_id=36&doc_id=1325215&piddl_msgorder=asc#msgs about this).

    The solution? Stop caring too much about hardware designers for a moment, start with early adopters in the software development community, cross the chasm in that space, and finally go back to the hardware design community, in which it seems that a lot more people belong to the late/conservative majority than expected/predicted by the technology adoption lifecycle. I have written a couple of articles on the subject, such as https://blog.synflow.com/are-you-pre-chasm/ and https://blog.synflow.com/marketing-disruptive-innovation/

  2. Hi Matthieu. I agree with your estimation of the EDA community. This article was intended to focus on EDA-Board-End Product designs. Still, it starts with EDA.

    The challenge now is the ever shrinking development windows and the need for end-user driven designs, especially in IoT systems. These processes are very familiar to the software world but not their hardware brethren. – JB

Leave a Reply

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