Subscribe to EDN

VaST

February 3, 2010

Finally it is public knowledge that Synopsys has acquired VaST Systems Technology. I was VP marketing there for a bit over a year back when Graham was still CEO. Since I exercised my options when I left, I’ve been inundated with paperwork on the merger, although the acquiring  company name was redacted everywhere it appeared (although everyone knew who it was). I don’t suppose I’m giving away too many secrets to reveal that I’m not going to get my money back. The common stock is lucky to get anything at all, but they did need bribe us a little to sign off on the merger.

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.

Posted by Paul McLellan on February 3, 2010 | Comments (3)

February 4, 2010
In response to: VaST
Jakob E commented:

I wonder about the "squeeze" argument: rather, it seems to me that the accurate models are being squeezed out as they are too expensive to build unless you created them using Carbon tools. So Carbon is squeezing out most of that -- except the in-house engineering models (see the webpage at jakob.engbloms.se/archives/153). "Fast" models are alive and well, as shown by Virtutech, CoWare, Synopsys-Virtio, and ARM's System Generator tools. Not to mention other tools like AMD SimNow!, Qemu, IBM Mambo, and IBM CECsim. It might be true that cross-compile is a decent solution for simple API-based systems like an iPhone. But that is not the typical embedded system. With multiple cores, processors, and boards, the value of an approximate model is pretty high. I think you know that Paul from your Virtutech days :) It just makes it simpler to work with a complex target system.


February 4, 2010
In response to: VaST
Bill Neifert commented:

Hi Paul, interesting post. At Carbon Design Systems we've long recognized the inherent weakness of hand-written "cycle-accurate" models. They take forever to write, even longer to validate and you can never really be sure that they're really correct. This is why Carbon has been quite successful over the past few years even in the midst of the downturn. We provide the tools to compile RTL into 100% accurate models. The cycle accurate models you mention that ARM used to command a premium price for are no longer sold or supported by ARM. All the accurate ARM models in the virtual platform space now come from Carbon where we generate them directly from the RTL to guarantee 100% accuracy. MIPS recently adopted this technology as well for their processor models. Models are ultimately what define the behavior of any virtual platform. Synopsys has stated their belief in this before (see Frank Schirrmeister's excellent ARM IQ Piece "It's All About Models") If you're using your platform to perform tasks which require accuracy (architectural analysis, firmware development, etc) then you need to have models in your platform which are accurate enough to meet your needs. How accurate is accurate enough? Well, we've seen plenty of cases where models that were "99% accurate" seemed to have all sorts of issues in the complicated corner cases of today's advanced fabric configurations. We've had multiple customers tell us that if a model isn't 100% accurate then it's inaccurate and can't be relied upon to make important decisions. Our 100% accurate models of ARM fabric IP have been crediting with saving respins at several customers where their handwritten models gave them one result but the Carbon model gave them a different, correct one. You mention that there "isn't a lot you can do with a more accurate platform squeezed into the gap" While this may be true for some cases there are a lot of things you can do with an accurate platform that you simply can't do with real hardware: You can peer inside the hardware at any point during the execution to see exactly what is going on. You can monitor traffic on any of the components in the device to see how to write your software to use hardware more efficiently. You can replicate all possible scenarios with 100% reproducibility. (Try debugging a multicore synchronization issue across three different clock domains in real hardware and you'll get a small sampling of the pain we're solving here) There are plenty more where those came from but I should stop since my response is threatening to take up more space than your original post. :) One more thing, Virtutech and CoWare aren't the only companies left out there with a virtual platform. Carbon's SoC Designer's virtual platform is in active use by 50+ design teams and at 16 of the top 20 semiconductor companies. SoC Designer was sold to Carbon by ARM when ARM exited the cycle accurate model business and we've been busily expanding the tool to support IP from any vendor and also support models running at any level of abstraction.


February 4, 2010
In response to: VaST
Grant Martin commented:

Just a clarification on Axys - after being in ARM for a while, the tools from Axys (SoC Designer) moved to Carbon Design Systems in the summer of 2008 and Carbon continues to sell it as SoC Designer today.

POST A COMMENT
Display Name
captcha

Before submitting this form, please type the characters displayed above. Note the letters are case sensitive:

Advertisement
Advertisement
Advertisement
About EDN   |   Site Map   |   Contact Us   |   Subscription   |   RSS
© 2012 UBM Electronics. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy

Please visit these other UBM Canon sites

UBM Canon | Design News | Test & Measurement World | Packaging Digest | EDN | Qmed | Pharmalive | Appliance Magazine | Plastics Today | Powder Bulk Solids | Canon Trade Shows