Archive for August, 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.

Looking at the design flow from the top, embedded software is a key part of the design flow. Customers I have been talking to vehemently agree. Recent IDC research even suggested a $1B market for “virtualized software development”. But why then is the market for embedded software still about 5 times smaller than the market for hardware electronic design automation? Is it the number of fundamental transformations which happen in hardware compared to seemingly simple compilation in the software world?

What caught my attention and caused this post is the recent IDC research quoted in a Virtutech press release arriving at a total available market of “just of $1B” for the playground in which Virtutech plays with Simics, Vast with Comet and Meteor, CoWare with Platform Architect, Synopsys with its Innovator Virtual Platforms and ARM with their System Generator product line. In the detailed quote Stephen D. Hendrick, group vice president for application development and deployment research, says that “Virtualized software development is an important advance in the development and maintenance of applications for electronic devices. There are a number of unique advantages specific to VSD when compared to traditional approaches that include faster time to market, cost-effective scalability, and more advanced diagnostics.” Well. I agree. And I love the total available market (TAM) predicted here.

However, it leaves me somewhat uneasy. Here is why. If I add up all the players in the so called software market I seem to arrive only at about $1B total. And this even includes UML tools like Rational Rose from Rational (now IBM), Telelogic Tau (now also IBM) and a good portion of the Mathworks with their Real Time Workshop solutions for embedded software development.

In contrast the EDA market easily can be summed up to be between $4B and $5B, just by adding up the major players Synopsys, Cadence, Mentor Graphics and Magma.

So why is that, especially in light of more and more importance being assigned to software development? What about the seemingly universal desire to advance it in the design flow to a stage as early as possible? Well, let me try an explanation.

Going back to the abstractions which I had talked about earlier, this graphic here shows a very basic design flow in the center. Starting from a system specification – which may be executable in some language like C or C++ or may use techniques like UML – there are really three different flows. First, on the left, there is the development of hardware blocks. This includes dedicated hardware blocks on the chip, processors, on chip accelerators etc. The chip integration portion is taking the different blocks and assembling them, typically adding communication structures like busses etc. The result of that flow is the actual chip, which then in exchange is integrated with other chips on the board creating the end product – our phone, PDA or media player. The third column is the software development, resulting in the software which runs on the chips used on the board.

The columns to the left and right indicate the abstraction or design entry levels starting from the transaction level (TLM), through register transfer level (RTL), gates, transistors and then finally to the layout for the chip. The final “transformation” created the board layout with integrated chips. On the software side we only find one major transformation – from a high-level description into the assembler / binary code which is then executed on the processor. Each major transformation on the hardware implementation path represents in itself quite a healthy market. On the software side only one major transformation happens from a high level language into implementation code. The software market size has a comparable order of magnitude as the hardware markets. The market numbers indicated in the graph I loosely derived from a DAC presentation I saw Daya Nadamuni give in 2006 – at that time she was with Dataquest. She very convincingly argued at the time that the RTL market was about 4x bigger than the market for gate-level tools, brightening up the outlook for the ESL and related Embedded Software markets.

So where is the money now? Well, there is the next level up, the notion of system specification which in its essence is independent from hardware and software implementations. Here is where a recent dinner in London with Allan Kennedy comes in. Allan is CEO of Kennedy Carter, a pioneer of executable UML products. Albeit slightly liquored up, we did eventually arrive at the conclusion that one key component in the hardware flow is its “seamlessness”. The output of each implementation phase is directly used as input into the next. In the software world that process is just entering mainstream in some application markets. Allan identified three major areas of UML usage – the use model of “sketches”, graphically outlining the intent of functionality, the “blueprint” use model in which the actual software architecture is described but its implementation is still unknown and then the “executable” use model in which an action semantic is added to UML and with model generators the xUML entry can be directly mapped into target implementations. It is this third use model, which directly links the output of the xUML specification phase into implementation, where I am very optimistic about significant market growths beyond the current markets. Once directly linked into the implementation flow, model investment at that level becomes safe and re-usable.

Ah yes, this of course assumes that somebody is willing to pay reasonable prices for tools in that market. Just like in the market of “virtualized software development”, tool vendors like us are facing the issue that the end user species of software developers is in numbers found about 10x as often as hardware designers but also has price expectations at least ten times smaller than the traditional hardware developers in the EDA world are used to.

Well, but that obstacle aside, it looks like there is plenty of room to grow upwards beyond the current abstraction levels and I do not need to worry to run out of them …