http://jbsystech.com/hardware-and-software-methodologies-challenge-the-iot/

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

The 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.

Commentary, I think this artice is very good as giving some understanding of the changes that we have seen at QUIK, with most of the allocation in the past yr in software.

this snip

 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.)

consider that this is a good explanation for the S3,  It will deal with complexity and do just as the above says.

Also good at showing it is complex stuff to get it all put together in the right fashion.