In Part II of the hardware-software domain interplay, Agile insights are offered by Jama Software, ARM, and Imec.
By John Blyler, Editorial Director
In Part I, the real differences between hardware and software methodologies and tools were explored. Now, the focus shifts to a specific case, i.e., applying Agile software methodologies and processes to the design of integrated circuits hardare. To maintain consistency, I will once again including comments from technical experts including Eric Nguyen, Director of Business Intelligence at Jama Software; Harmke De Groot, Program Director Ultra-Low Power Technologies at Imec; and Jonathan Austin, Senior Software Engineer at ARM; and Vincent Korstanje, VP of marketing, Systems and Software Group at ARM. What follows is a portion of their responses. — JB
Blyler: Do you think that the push to apply software methodologies and processes ( e.g., Agile) to design of hardware like integrated circuits is the right approach? Why or why not? What can one domain learn from the other, i.e., hardware vs. software.
De Groot @ Imec: This fully depends on what you like to achieve. In general, Agile methodologies can work well for co-developing new applications or user interactions especially when we are not sure on what the actual requirements or killer features are. In this case the challenge is to make sure that we don’t spend too much time and budget developing features or solving technical challenges which nobody will care in an actual product. It is especially helpful when there might be a potential misunderstanding of the target group or an unclear application or market. For off the shelf hardware integration and new software as well as FPGA type of digital implementations it is sometimes suitable. However, Agile development has some known potential disadvantages especially in the area of guaranteeing quality and maintainability. If your objective is to create a scalable architecture, which can fulfill many requirements including some notoriously vertical ones as for example security and privacy, scalability, traceability and maintainability an Agile development method is not preferred from my point of view. For those types of projects you better spend more time in the beginning thinking about the right specifications and all the different user scenarios you might encounter. For the implementation phase you can still work with smaller blocks or in iterations or chose to not implement certain features in earlier versions. My preference for another development methodology and process for this type of development is valid both for Software as well as Hardware, including IC, development.
Austin @ ARM: We had a long discussion on this, too. Here’s the general summary (on how hardware could benefit from software approaches):
- Code review is really great. It could be done more in hardware design and the structures we have in software like branches, merging, etc. are valuable for this. Note that reviews are good BOTH for improving quality of hardware now, and also in the future because of the way they train engineers to be better!
- However, a lot of software methodologies are enabled by the ability to split a system into clearly defined blocks. As mentioned above, the requirements of meeting timing make building hardware in such a modular way more difficult. It is harder to have a well defined ‘feature branch’ if the feature is ‘work across the whole design to improve performance by 4%’!
- In the discussion, one thing that the hardware folks (I’m a ‘software guy’ ) really felt they could bring from the software into the hardware world was well designed continuous integration. Something that provides good reports on a regular basis about breakage of the build, etc.
- Finally on hardware learning from software, many of the software engineers felt like hardware people were insufficiently demanding of their tools to help them!
Here are a few key things that software people can learn from their hardware counterparts:
- Formal verification – I’d like to see security software, etc., much more firmly validated and verified. There’s a strong emphasis on correctness in hardware design and that means there are tools that aim to prove that *before* shipping.
- Software is actually harder to change than we realize, and hence thinking about it more like hardware in terms of quality is important. Consider the recent OpenSSL bug – it will be years before all broken instances of OpenSSL are gone, but yet the illusion that ‘it can be fixed later’ may have lead to a false sense of security.
- It can really help to have clear engineering specs before starting work. At least in ARM, we have a few very defined stages our hardware design processes go through (Initial Investigation, Detailed Design, etc) and recognizing the need to firmly transition through these stages, rather than just drift towards completeness is important.
The really high level summary would be that most of the differences come from the different constraints around performance. For example, if my Python runs 10% slower than yours, who cares, really? If my core is 10% slower than yours, I may not have a product and hence the relative cost/benefit of extra abstraction.
Nguyen @ Jama Software: Agile is one of the software methodologies being applied to hardware. This approach highlights a much more customer-focused, iterative mindset and is being drive by the realization that it’s all about the overall customer experience. Software has really come out of the browser to be fully integrated and embedded into physical technology that we all use – smart phones, wearables and the IoT. This makes the entire development process more complex. It’s not just the user experience within the context of that application but across many different mediums.
The iterative mindset of software requires quick feedback loops and prioritization to make critical trade-offs. As more software becomes embedded into hardware, the design times have become greatly reduced. Thus, the hardware designers are being pushed to iterate more quickly – in months instead of years. And it’s becoming highly competitive due to the customer focus. The key challenge is to understand the interfaces between the hardware and software. Once the hardware hooks are locked down, then the software teams can iterate. That is why collaboration between the hardware and software teams is so critical.
Korstanje @ ARM: Models, emulation and FPGAs should be used extensively to enable software development as early as possible. These tools allow designers to deliver large programs using 64-bit instruction set across the large software ecosystem. Ultimately, the hardware development and the software development become much more closely aligned.