Achim Nohl
Achim Nohl is a solution architect at Synopsys, responsible for virtual prototypes in context of software development and verification. Achim holds a diploma degree in Electrical Engineering from the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany. Before joining Synopsys, Achim has been working in various engineering and marketing roles for LISATek and CoWare.Software Developer Attitude Issues – “Let’s Just Get on With it!”
Posted by frank schirrmeister on August 23rd, 2008
Well, who doesn’t believe in coincidence? First, I meet with CriticalBlue’s Skip Hovsmith and we have a interesting discussion about multi core software development practices (or lack thereof) and on the same day I run across Glenn Perry’s article “Art Imitating Life: Hardware Development Imitating Software Development“. It made me think again about which discipline is really ahead in technology and methodology – hardware design or software design? My answer once again is: It depends!
Skip Hovsmith has been a system-level expert for years. I met him actually back in 1998, when he was at National Semiconductor and he worked closely with Cadence on the Felix initiative, Cadence’s attempt at the time to crack the system-level tools market. Skip is now at CriticalBlue and heavily involved in the Multicore Assciation Best Practices working group. This working group is on a quite important mission, trying to define best practices around programming for multicore devices. This will be important going forward. My interest in that group stems from the need, to make sure our virtual platforms are modeled with enough fidelity to enable debug issues expressed at the multicore programming level. Example would be semaphores, where one best practice is to always call locks in the same order in order to avoid processes to lock up indefinitely. When discussing techniques how to enter software more efficiently, we ultimately arrived at UML and Skip’s comment struck me as perfectly correct: “UML is great to understand how things work [read: "to reason about things"] but once issues are understood programmers just get on with it and start hacking the code”. This goes back directly to my last post, in which I argued – besides other things – that a development phase only will find adoption if its output can be reused directly in the next.
Then I found Glenn Perry’s article “Art Imitating Life: Hardware Development Imitating Software Development“, in which he argues quite convincingly that software development is ahead because of technologies like object oriented programming. I am a true believer that hardware development has something to learn from software development. Hey, I even wrote articles like “Transferring software engineering methods to VLSI-design: a statistical approach” way back in 1994 as part of my never finished Ph.D. thesis (real life development projects got too interesting; bad excuse, I know).
However, I then went off and contacted people like Tom DeMarco and Fred Brooks, authors of the classic “The Mythical Man Month” and “No Silver Bullett“. I though they would be thrilled that somebody is trying to adopt function points from software engineering into the hardware world. Their response was interesting. “Why are you trying to do this? Isn’t hardware engineering perfect because you have a tape out and cannot fix issues with a new release of the software”.
That’s where these things tie together in my mind. While I agree with Glenn that the technology in software engineering may be more advanced, for example around languages, I am certain that the required methodologies are fundamentally incompatible. The reason? In hardware engineering the project team always has the “Sword of Damocles” hanging over their head. Mess up the tape out and you will cost the company several millions in NRE (Non recurring engineering, or, “N”ever “R”eturn “E”ver). In addition you have to consider the lost product revenue because of the several months the project is now delaying production.
In contrast, in software engineering there is always service pack 2. The requirement to get everything right is not as deadly as it is in hardware engineering. And as a result of all that Skip Hovsmith is perfectly right – “Just get on with it” is unfortunately often the approach taken in software engineering. It looks to like things have to get a lot worse before this approach changes.
RSS
Jakob:
Excellent augmentation and comments on my post, thanks a lot!
I fully agree with your assertion that there are different types of software with different types of requirements. For critical software I would argue that there also is a “Sword of Damocles” in delivery, just like in hardware. That’s why Jack Little was able to show in his keynote at DAC examples of flight systems fully automatically generated from model based design technologies (http://www.synopsysoc.org/viewfromtop/?p=37), just as Kennedy Carter shows F16 code automatically generated from xUML (http://www.inf.u-szeged.hu/stf/slides/e19.ppt). In these mission critical designs a failure in the software is so catastrophic, that the design flow just has the same requirements as you will find in hardware – no bugs allowed at release.
But then again, there still are the counter examples too, like “F-22 Squadron Shot Down by the International Date Line” (http://www.defenseindustrydaily.com/f22-squadron-shot-down-by-the-international-date-line-03087/) or “Segways recalled because of software glitch” (http://www.msnbc.msn.com/id/14831843/).
Looks like we are not quite there yet.
Thanks, Frank
Cool software feature here: something somewhere picked up my post on my blog and put a ping here. Interesting. I did not do that
Anyway, thanks for an interesting and thought-provoking post.
But a key problem none of us has answered is really why the hard requirements on correctness means that you need to use old methodologies in your tools. And old tools as well. It would seem that it would be useful to adopt new methods especially when you are doing something as difficult as building correct hardware?
/jakob
Jakob:
Good point. I would, however, question that these are “old methodologies” and “old tools”. It just has created interesting market dynamics in the hardware space.
The pressure to get the hardware rigth has created a huge focus on verification, which spawned – besides others – very successful companies like Verisity with tools and methodologies which are not old at all. Everything seesm to align now in this space arund SystemVerilog. When does the design team know that they have verified enough and are done? Like the insurance business this is all somehwat “fear-based” and as a result design of the hardware makes up for about 25% to 30%, while verification of it makes up 70% to 75%. And the verification tools are quite valuable here, based on RTL simulation.
I asked a related question to a panel at DATE in Munich (you were there and blogged about it I believe). the panel was touching on software verification. I then asked whether the absence of a tape out does lead to less pressure. The answer was that at last for the initial design the software has to be right as well. However, even if that is true, the number of “initial desgns” is pretty small – most of the designs are derivative. At the end of the day though the pressure is present at least in safety critical designs – as you pointed out. Now the question is whether UML plus code generation is new or old technology?
Fundamentally I do agree with your conclusion though – virtual platforms are an elegant solution to help here as well.
Thanks again for your comments!
Frank:
Very interesting point, but I don’t fully agree that the required methodologies are “fundamentally incompatible”.
For example, virtual platforms are sort of preliminary version of a system, which does not have contain all implementation details but instead abstracts these in such a way that early system performance analysis can be carried out, or SW be developed without having to wait for the HW part to be completed etc. Jakob stressed that this is where HW and SW meet. It is definitely true in terms of having a common language to describe the virtual platform, but I think it is also true in terms of development process. A virtual platform really looks like a typical executable deliverable in an iterative software development process, where the system is gradually built with increasing amount of knowledge and detail.
Besides, model-based techniques and automatic code generation from signal processing design environments such as Simulink or SystemStudio make it also possible to build gradually executable models with increasing amount of detail, while guaranteeing a path towards implementation. Without mentioning the possibility of generating embedded SW code from the same source/environment. Looks really close to the Model Driven Architecture (MDA), Platform Independent Model (PIM), Platform Specific Model (PSM) etc. list of terms from OMG, except that the application domain is narrowed to signal processing intensive systems in this case.
I think we are slowly observing the emergence of a systems engineering methodology, which combines hardware and software development processes, with the help of ESL tools which support behavioral synthesis or even 1-to-1 translation from higher level modeling environments. But of course the final sword of Damocles of the tapeout will always be there…
Regarding your question if UML + code generation is new or old technology, TMHO the main point of regarding it as new is how it is applied, in which context, and for which purposes. One could then say that it is an “old” technology from a software viewpoint but a new one from a hardware perspective, because 1) its use is not as widespread and 2) the generated languages are different (HDL, C/C++ variants for HW design like SystemC or Handel-C, etc.), 3) parts of the HW platform may not be available at start and must be synthesized, 4) users want first to have means to explore quickly partitioning alternatives, instead of just code generation, …
Yves:
You are right, “fundamentally incomp[atible” is a tad strong. What I meant was that the requirements are fundametally different, given that the tape out in the hardware world has lead to a set of verification tools, helping the designer to “sleep better the night after tape out” (I have been there) given that “verification is done”. This is where the sofwtare world is behind. While verification tools exist, their use does not seem to be as mandatory as it is in the hardware world.
Thanks for your comment!
Best, Frank
> Jakob stressed that this is where HW and SW meet. It is definitely true in terms of having a common language to describe the virtual platform, but I think it is also true in terms of development process.
I really do not see virtual platforms and software as necessarily having the same language at all. The platform is certainly written in C and C++ for the most part, and then adding in home-grown languages, generative languages like LISA, ADL, etc. And obviously SystemC. And some assembler for the performance-critical pieces, but that is host (x86) assembler.
While the target software in my view tends to be assembler (PPC, DSP, ARM, MIPS, etc.), C++, Java, C, Ada, Python, shell scripts, Erlang, etc. Quite a different set of tools for a different set of problems.
> A virtual platform really looks like a typical executable deliverable in an iterative software development process, where the system is gradually built with increasing amount of knowledge and detail.
I see VPs being used and built in that way to a large extent. There are lots of examples of gradual moves from old to new hardware platforms while moving the operating system and software base along, as well as building a new VP from scratch piece by piece.
> I really do not see virtual platforms and software as necessarily having the same language at all. The platform is certainly written in C and C++ for the most part, and then adding in home-grown languages, generative languages like LISA, ADL, etc. And obviously SystemC. And some assembler for the performance-critical pieces, but that is host (x86) assembler. While the target software in my view tends to be assembler (PPC, DSP, ARM, MIPS, etc.), C++, Java, C, Ada, Python, shell scripts, Erlang, etc. Quite a different set of tools for a different set of problems.
Thanks for your point. But with such a large scope of languages, it is also definitely possible to elaborate a long list on the HW side as well, ranging from architectural description languages (SystemC, SystemVerilog, other C/C++ variants, etc.; actually LISA and the likes, such as nML, could also be included here), design languages (VHDL, Verilog, Spice, …) to verification languages (SystemVerilog, e, PSL, Sugar) etc. My point is that there is at least a possibility to bridge the gap by describing a system on the same language base, that is C/C++.
Years ago, in a previous life in the industry, I worked on a solution to encapsulate within a SystemC model of the system (i.e. a virtual platform describing the HW part) software pieces intended to run on an ASIP and an ARM, so that we could verify early the system performance. In a second phase, the encapsulated software code (pure C) was extracted and cross-compiled on the target processor. You can call SystemC a different language, but it is C++ which is under the hood. You can argue than one might want to bring target-specific assembly (an assembler is a tool, not a language) in the picture, but you are then deep in the design phase, similarly to the HW designer who is busy implementing (or refining, to use a term from the software development process jargon) with an HDL language the hardware part of the system initially described at a higher abstraction level, in SystemC. The platform was then useful as a reference for verification purposes (generation of test stimuli and golden results). We also investigated how to co-simulate the SystemC model with the Instruction Set Simulator of the ASIP and the ARM, that is, bring different tools together and bridge the gap between the investigation of the architecture with SystemC and the concrete design.
Nowadays the picture would be a bit different on the HW side with the arrival of tools that would automate parts of the process (behavioral synthesis, co-simulation), but the basic principles remain the same.
Trackbacks/Pingbacks
[...] just read an opinion-provoking piece “Software developer attitudes: just get on with it” by Frank Schirrmeister, as well as the article “Life imitating art: Hardware development imitating software [...]