Jack started off the proceeding by pointing out that for most designs the software engineering costs more than the IC engineering. For him the business drivers were 16 bit designs all going to 32 bit, 32 bit designs going to 64 bit, multicore and virtualization (using a single core to run code binaries from what used to be several separate microprocessors). Tomas added the drive towards open source. And Jim emphasized the thrust of Linux into embedded.

Tomas talked a bit about why Intel had acquired Wind River and why they had also left it to remain independent. To ship a chip these days you need to ship it with a state-of-the-art software stack, so Intel wants to ensure that for its products. But unlike previous acquisitions, such as Freescale (then still Motorola) with Metroworks, Intel didn’t want to kill the ecosystem and devalue the software by taking everything in-house and making it Intel specific.

Everyone complained about the challenge of getting people to pay for software. In the IC world nobody would dream of trying to design a chip without software, or even writing all their own software. In the software world people won’t make the investment even if the ROI is there. So system companies place tremendous value on software but refuse to pay, and silicon provides less value but gets all the revenue.

Everyone thought partly that this was due to people not taking quality seriously. Apparently 40% of cars taken into dealers involve a re-flash of an ECU (electronic control unit) because the initial and ongoing quality is so poor. Perhaps the current woes at Toyota will cause a re-think on whether it is appropriate to invest for software quality.

Quailty is expensive. DO-178B (a standard for certifying avionics) costs $1000/line to validate. Meanwhile car companies are worrying about the number of resistors on the PCB. Quality will only happen when companies decide it is worth the money. Tomas talked of a system he was involved with that was validated. Since the early 1990s not a single bug has been found in it. And Jim boasted that he was involved at Ready Systems in 4K bytes of avionics code that was the first certified.

Tomas and Jim both emphasized that despite Linux being open-source it was still a viable business. Montavista has shipped over $250M of “free” software. But one cloud was that Android drives out differentiation and so squeezes vendors. It even marginalizes the hardware since it is now very generic.

The DNA of EDA and embedded software are very different. EDA is dominated by physics but software is dominated by psychology. So before EDA ventures into the software world it needs it understand it deeply since analogies don’t carry across.

This was brought home when Gary Smith asked about what they were going to do to write power-aware software. Everyone just took this as being a question about battery life rather than realizing that the big problem is going to be having a chip that we can’t light up all at once. It would help, of course, if the chip people added circuitry to make it easy for the software to monitor power, today’s chips rarely even have cache-miss counters which is one of the biggest contributors to power.

Power may turn out to be the thing that finally ties the software development process to the chip development process, since it will become impossible to develop software without worrying about it. It will even affect software architecture, not just detailed low-level stuff.

To sum up, there have been a number of different instruction set simulation technologies developed: Axys (which ARM acquired and then spat out again to Carbon when they decided they didn’t want to do all that modeling any more), Virtio (which Synopsys acquired a couple of years ago), VaST (which Syopsys acquired 2 weeks ago), Virtutech (which Intel/WindRiver acquired 1 week ago) and CoWare (which Synopsys acquired today). Phew. 

Simon Davidmann and Brian Bailey both pointed out, correctly, that I’d forgotten about Imperas when I talked earlier about which technologies were left out there. There is also, of course, Qemu which is an open-source instruction set simulator. The base technology of Imperas is also open-source, the open virtual platform, www.OVPworld.org although that is not how they started out. So in an act of contrition for forgetting Imperas, let me tell you where they are: they have 2000 registered users, adding about 150 per month, spread around about 400 companies. They have over 40 processor models ranging from the bizarre ones used in automotive up to quadcore MIPS processors running at 200-1200 MIPS. They are still self-funded but are growing and adding staff.

So going forward there is Imperas/OVP still independent. Synopsys with Virtio, VaST and CoWare technologies which they will presumably try and pull together into a single environment, and WindRiver/Virtutech. One distributing basically over the web and the other two with much bigger distribution channels than they had before although less focused than before. Let the games begin.

I think I was probably the only person who worked for both VaST and Virtutech (and I even did a consulting contract for the two companies jointly a couple of years ago) so it is interesting to look at why one company was so much more successful than the other. I haven’t seen the finances of either company recently, so I don’t know the revenue levels, profitability etc.

The companies targeted different markets. VaST did most of its business in Japan, almost all of it when I first joined them. They had customers in automotive, wireless and consumer. Consumer is mostly ARM. Automotive is mostly processors you’ve never heard of (NEC V850 anyone?). Virtutech went for the big iron, modeling complete base-stations for Ericsson, whole routers for Cisco and Huawei, servers for Sun and IBM, and aerospace systems. Almost coincidentally, most Virtutech customers were PowerPC based which leveraged the models and led to a close relationship with Freescale. These types of projects are much bigger and so have much bigger budgets, meaning larger deals.

Another issue, as I mentioned in my post about VaST earlier in the week, is that VaST’s cycle accurate models were more complex to build. For about the same revenue, VaST had four times as many people doing modeling as Virtutech which, plainly, means that they need to sell four times as many copies of any given model to get the same return. The fact that the end markets that VaST was targeting had different processor requirements aggravated this.

Virtutech was run much leaner than VaST. A couple of years ago, at a time when both companies revenues were the same, VaST had a full-time CFO and four people in finance. Virtutech had one finance person. A company doesn’t live or die by the size of its finance department, but G&A being too large is always a symptom of lax expense control.

One thing that both VaST and Virtutech did is have their engineering groups offshore. But it wasn’t an expense issue, with groups in India or China, but more an accident of history. VaST started in Sydney Australia and the engineering remained based there. Virtutech started in Stockholm Sweden and their engineering remained there. And I’ll give VaST the edge here; Sydney is a nicer place to visit than Stockholm, especially in winter!

One story about Virtutech, from before I worked there, was that Microsoft used Simics to port Windows to the 64-bit AMD processor before AMD could deliver any silicon. This was in the days when Intel was all Itanium going forward and Microsoft was supposedly on-board. In fact at first AMD tried to screen the fact that Microsoft was the end-user, it was so sensitive. And on the first day AMD delivered silicon, Windows booted. It would have been the ultimate customer success story but we weren’t allowed to talk about it.

When I joined Virtutech, Peter Magnusson was the CEO. He’d started the company in Sweden, where the engineering remained, before moving himself and his family to the US. It was a joke inside Virtutech that Simics was Peter’s Ph.D. thesis gone out of control. He has a reminiscence about Virtutech on his own blog.

So that just leaves CoWare out there as the only remaining independent supplier of this type of technology, and Carbon with their RTL acceleration technology.

By the time Alain Labatt came on board as CEO, I was at Virtutech which sorta competes with VaST in having similar technology and sorta doesn’t since they go after such different markets. We thought that this was great for us since Alain’s reputation was that he was good at two things: raising VC money, and then ramping up the expense run-rate to spend it all. He’d done that at Frequency/Sequence and then again at Tera Systems. And true to form he seems to have been successful again at both raising money and then spending it.

When I was at VaST we did most of our business in Japan. I opened up a couple of accounts in Europe and we had just one, Delphi, in the US. The dependence on Japan has apparently reduced, but still VaST is over-represented there. To be fair, the Japanese are ahead of Europe which is ahead of the US in terms of system level thinking, so Willie Sutton style, that’s where the money was. VaST was also over-represented in automotive. Japan and automotive have unfortunately been especially hard hit in the current downturn, so I’m guessing that VaST’s business declined dramatically. I assume the VCs didn’t want to put in more money since they couldn’t see a route to a fast growing profitable company and so they got Alain to shop the company around. Synopsys is its new home.

Synopsys already purchased Virtio a couple of years ago which had similar technology to VaST’s. VaST’s is cycle-accurate which makes for a number of issues: since VaST had no non-cycle-accurate models it couldn’t really get premium pricing for them since it didn’t have any non-premium models for people who didn’t value cycle-accuracy (when ARM was in the modeling business it sold cycle-accurate models for 6-8 times the price of non-cycle-accurate ones). Also, the verification issues of cycle-accurate models are much harder since not only do they have to be functionally correct, the cycle accounting has to be correct and there are many corner cases in a modern processor. So the combination of expensive models and an inability to get a premium price for them made for an unattractive combination. Potentially with VaST and Virtio now in the same stable, that problem goes away. Non-cycle-accurate models for people who don’t need them, and premium pricing for people who need the costly cycle-accurate models.

There are plenty of rumors that Virtutech is also in the throes of being acquired, but I’ve not seen any paperwork for that one yet. But if that is true it leaves only CoWare out there of the companies with virtual platform technology. Axys was acquired by ARM. Virtio and VaST by Synopsys. Virtutech and CoWare, for now, are still out there.

It is interesting to look at why these companies were not as successful as I thought they should have been. In the end, I think, you could get so much done with cross-compilation to your workstation that the market for people who valued the model accuracy was too small. Look at iPhone programming. Despite a litany of complaints about the simulator, which works by compiling your source-code to run directly on the Intel processor in your Mac, you don’t really need an platform able to run the ARM binary to get development done. An inaccurate simulator and the actual phone are enough. There isn’t a lot you can do with a more accurate platform squeezed into the gap between these two other solutions.

They do this by running the code and storing a trace of what goes on for later analysis. Previously they have done this only through simulation but now they can also use hardware boards to run the code. They don’t need a multicore CPU, just one with the same instruction set.

Having developed the trace they can do “what if there were 4 cores, or 32” type analysis without need to run it again. On typical code that wasn’t written with concurrency in mind the typical answer is “not much would happen” because there are too many dependencies. The example in the demo is doing a JPEG compression. Most of the time is spent in the DCT (discrete cosine transform) algorithm but the code doesn’t parallelize due to data dependencies. It turns out that the code was written in a way that makes sense in a single processor world: allocate a single workspace, run the loop 32 times using the workspace, then dispose of the workspace. Obviously if you try and parallelize this, then all iterations of the loop except one must block and wait for the workspace. If you move the workspace allocation into the loop (so that you allocate 32 of them) then all the iterations of the loop can run in parallel.

They don’t actually change the code. It turns out users wisely don’t want something mucking around with their code without their understanding what is going on. But they give users the tools to both move code onto multicore processors and simply get it ready. When doing maintenance on code, by using Prism a programmer can also remove unnecessary dependencies and thus get the code so that it will be able to take advantage of multicore processors (or to take advantage of larger numbers of cores) when they become available.

I’ve said before that microprocessor vendors, especially Intel, completely underestimated the difficulty of programming multicore processors when power constraints forced them to deliver computing power in the form of more cores rather than faster clock frequencies. Everyone realizes now that it is one of the major challenges in software going forward.

At DAC the nVidia keynote claimed that Amdahl’s law wasn’t really a limitation any more. I’m not a believer in that position. The part of any program that cannot be parallelized sets a firm bound on how much speedup can be obtained. Even if only 5% of the code cannot be parallelized, which seems high, that sets a limit of 20X speedup no matter how many cores are available. Critical Blue have an interesting  tool for teasing out whatever parallelization is possible, often with relatively simple changes to the code as in the example I described above.

As I’ve said before, I believe that it is going to be taking software, probably written in C  and C++ , and synthesizing parts of it into FPGAs and compiling the rest into binary to run on processors in the FPGA. This is what I’ve been calling software signoff for a long time. It’s more than just the software necessary to run on the FPGA or SoC. It is signing off hardware that co-optimizes the software.  The idea that conceptually we need to get the software that specifies the system right, and then hardware design is just creating a silicon fabric (SoC or FPGA)  which is able to run the software high enough performance  and at low enough power (because otherwise why bother to do anything other than simply execute it). Power, performance and price, the 3Ps again. 

There are two key pieces of technology here. The first is high-level synthesis, which should be thought of as a type of compilation  of behavior  into hardware . In the end the system product delivers a behavior or application.  It is not as  simple as  some sort of productivity tool as RTL designers move up the next level. RTL designers will be bypassed not made more productive.

The other key technology is FPGA technology itself. Today FPGAs offer almost unlimited capacity and unlimited pins. FPGAs will become the default implementation medium. The classic argument for not using FPGAs used to be that you could reduce the cost enough to amortize the cost of designing a chip. But very few designs will run in high enough volume to amortize the cost of doing an SoC or ASIC in today’s most leading edge processes, and the cost and risk of dealing with the variability (in terms of simulating hundreds of “corners” and the difficulty of getting design closure) is rising fast.  FPGA takes a lot of the silicon risk out of the implementation.  

Did you know that FPGAs represent more than half the volume of leading edge process nodes at the big foundries like TSMC and Samsung? FPGAs  are the first logic in a new foundry process and  drive the semiconductor learning curve. This is due to FPGA structural regularity that is much like memories but in a standard  CMOS  logic process.

If you need to do a 45nm design then far and away the easiest approach is to go and talk to Xilinx or Altera. To design your own chip is a $50M investment minimum so you’d better be wanting tens of millions of them when you are done. Only the highest volume consumer markets, such as cell-phones, or the most cutting edge performance needs, such as graphics processors, can justify it.

The decline in the FPGA market in the current downturn conceals the fact that new designs in the largest and most complex devices is growing at over 30% CAGR. It may only be 12% of the market (which, by the way, is something over 15,000 designs per year) but it generates 40% of the FPGA revenue. These designs, and the methodology for creating them, will go mainstream until it represents the bulk of the market. Not just the FPGA market, the electronic system market. Designing your own chip will be an esoteric niche methodology akin to analog design today. Howeve these new high complexity FPGA require an ASIC-like design methodology, not just a bunch of low-end tools from the FPGA vendor.

The challenge for EDA in this new world is to transition their technology base to take account of this new reality and go where system-scale designs are implemented in FPGAs. That is largely not in the big semiconductor companies that currently represent the 20% of customers that brings 80% of EDA revenue. It is much more dispersed similar to the last time that design was democratized with the invention of ASIC in the early 1980s that pushed design out into the system companies.

A lot of  RTL level  simulation will be required. And one of the high level synthesis companies will be a big winner. In the startup world there are a few companies attempting to offer HLS: Synfora, Forte and AutoESL. Synfora and Forte has been at it for a while (although Forte may be disqualifying themselves in this vision of the future by only supporting SystemC). AutoESL has started to make some progress as well, with one group at Microsoft using just this methodology. Mentor is the current leader with its Catapult synthesis; Cadence has created their own CtoSilicon technology. But Synopsys, who has synthesis running through their veins, have no real high level synthesis product (and, unless they are doing it with people who are unknown in the field, don’t have one in development).  Synopsys does have FPGA DNA through the acquisition of Synplicity.  My  opinion  is that once it becomes clear which HLS company is going to win, Synopsys will  likely  acquire them and for a serious price to complete their FPGA offering.  

As everyone knows the performance of a single processor is increasing only slowly due to power considerations. Instead we have to take our increased computing power in the form of additional processors. Architectures like this, such as nVidia’s chips, should continue to increase at about 70% per year for the foreseeable future. That is what I like to call “core’s law.” The number of cores on a chip is increasing exponentially. It’s just not all that obvious yet since we are still on the flat parts of the exponential curve.

Daily had some interesting analysis of the energy required to do a computation (such as a floating point multiply) versus the energy required to move the data a short distance, across the chip or off-chip. The bottom line is that computation is very cheap in both area and energy provided the data required is local, already close to the computational unit. When a lot of data is used in any sort of pipelined computation, where the output from one stage is immediately consumed by the next, then cached memory is a particularly bad architecture, something I’d never realized before. Writing the data out causes the cache-line to be fetched, then the data is read once. Finally, the value, which will never be used again, is written back to the main memory.

To take advantage of all this compute power, the programmer has to worry about managing the concurrency and worry about which memories are used to store which data. Programmers like to deal in abstractions which is why sequential programming and flat memory work so well. There are only 3 numbers in computer science, 0, 1 and infinity. Numbers like 50 processors each with 2K of memory are not something that the programmer wants to have to worry about.

But it seems there is no choice. The CUDA programming architecture gives a framework for writing these kinds of programs and certainly some of the results on computationally expensive algorithms are impressive. Done right, it is a one time cost to get back onto the performance curve as process generations unfold into the future. But it seems more like assembly language programming in some ways, since so much of the details of the hardware have to be taken into account. Chips like nVidia’s (and IBM’s cell architecture used in the Playstation) are notoriously hard to deal with because of this mismatch between computational resource and the programmer’s mental model of what has to be done.

This stuff is now being taught in universities so it will be interesting to see if a new generation of programmers who think this way find it any easier. It still seems really hard to take a lot of small computers and put them together so that they behave as one really huge one. But the payoff when it can be done is enormous. However, getting the software right continues to be the biggest problem in software.