A View from the Top: A Virtual Prototyping Blog

 

How Much Money is in Software Automation – Really?

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.

Hardware and Software Implementation Markets

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 …

Share and Enjoy:
  • del.icio.us
  • Digg
  • Facebook
  • Google Bookmarks
  • Print
  • Twitter
  • StumbleUpon
  • LinkedIn
  • RSS