There's been a lot of attention being paid to the SaaS(software-as-a-service) model in EDA recently. Harry (The ASIC Guy) started it all with his views on (re)deploying the SaaS model in the EDA industry. Gabe Moretti and Daya Nadamuni are publishing an ongoing series about SaaS in EDA. What's all the fuss about?
What does SaaS model offer ASIC design companies?
- Unlimited licenses (The concept of buying a license does not exist in SaaS model. It's pay as you go.)
- No upfront license cost (Pay as you go, remember?)
- Lower IT investment (Since the EDA applications are hosted, the cost of compute and storage resources are built into the rate the vendor charges you).
- Scalability (Since both tools and infrastructure are no longer your concern, scalability is only limited by your engineering team).
- Constant revenue stream (Rather than one lumpsum payment, the EDA company receives a stream of revenue. Value-adds such as storage and compute services increase your revenue.)
- Increased Margins (The pay-as-you-go model allows EDA companies to charge higher rates than the current model)
- Unlocked Revenue (Since small customers can now rent tools, compute and storage resources rather than invest in them upfront, the market size that can be addressed the SaaS model is larger than the current ratable model).
The reality is that ASIC design companies rarely use tools from one vendor across all flows. Given this, can one company moving to the SaaS model make an impact? You may think you're achieving lock-in but end up being locked out. Sure, an EDA company can put in hooks that allow tools from other vendors to run on their SaaS platform but I'm not sure that option will even be permitted. I really don't see one EDA company handing over its tools and licenses to run on a competitor's network. If you now have to transfer data to/from/across SaaS platforms to use tools from different vendors, it's going to be a real mess. ASIC design companies want to use the tools that they want to use and it's up to the industry to figure out a way to allow that. Self-hosted SaaS platforms do not seem to be a viable option for EDA companies. One option I see is the creation of independent third-party(non-EDA) vendors that host applications from all vendors.
What are the implications of the switch to SaaS for EDA Companies?
- Interoperability: Once every tool is available on one unified SaaS platform, interoperability becomes more crucial than ever. Users will expect that best-in-class tools from different vendors work seamlessly.
- Best-In-Class Tools as Profit Centers: Right now, every major vendor is trying offer solutions for all aspects of design and selling them as such. Under the SaaS model, each tool will stand alone. The ease of switching tools is so low that best-in-class tools are the only ones that will survive in the end. EDA companies may see that trying to support a large number of tools to address the entire flow may actually be detrimental to their business.
Tags : ASIC, VLSI
The early usage has been by smaller consulting firms using open source tools on cloud platforms (e.g. AWS) followed by smaller EDA firms offering stand-alone analysis tools as SaaS (e.g. SpectaReg offering). This is already happening.
ReplyDeleteThere may be a parallel between SaaS and FTP distribution of software in the early 90's. FTP was used to distribute software by the Verilog niche players before being adopted by the majors. I don't see the major players as early adopters of SaaS because, to your point, it's harder to migrate a flow than a point tool.
Also there are bandwidth issues that will likely confine this more to front-end and PCB related areas (e.g. BOM and part models) before companies start moving 100GB databases around. But a few megabytes of compressed Verilog can represent a significant chunk of an SOC or perhaps an entire FPGA.
I think you're right about the bandwidth issues restricting the SaaS model to the front-end areas. There is no way that someone is going to spend their time uploading and downloading volcanos, milkyways, DEFs and SPEFs from one SaaS platform to the next. The data, in my opinion, has to be on the platform and we (asic design engineers) operate upon it using thin clients.
ReplyDeleteThe holy grail will be the day when you can access all tools from all vendors:
ReplyDelete1) In a single ubiquitous universally accessible environment (e.g. a cloud)
2) Using a flexible licensing model ranging from pay-per-use to long-term
3) All wrapped in a fully interoperable vendor independent design flow that enables point tools to be swapped in & out and implements virtualization.
The security issue can be addressed and the transfer of data can be minimized if all/most data resides on the cloud. Almost all customers would love to have this as a viable option. The real question is how to get there from here?
I think this will start with some of the small-medium sized EDA companies that have less to lose and more to gain with this option. We're already seeing that from individual companies. The next step is to pull together several related products into a design subflow and offer it as a SaaS. Then you'll start to get some attention.
@Aditya: I agree with your overall assessment but think there may be an opportunity for Google or Google Maps like applications that give me a sip from a large database to answer some detailed questions about one neighborhood of the design.
ReplyDelete@Harry: I would be careful mistaking your clear view for a short distance (with apologies to Paul Saffo). The folks using the cloud today are doing so because it's cheaper than their other options. I think we will see mashups of part data and bills of material before we see design flows.
Great topic Aditya!
ReplyDeleteSome additional things SaaS offers ASIC companies include:
- Offloading of maintenance. This is something that SpectaReg.com customers really value, since they don't need to install patches or updates. We update SpectaReg behind the scenes transparently to the user.
- Ease of evaluation. Users can quickly try the tool, for free, without having to download or install any software
- Collaboration. Having a tool that is simultaneoulsy connected over the network to all members at the team as they are working allows for some interesting new features. Google Docs has some pretty cool collaboration features...
Some additional things SaaS offers EDA vendors:
- More control over the software. EDA vendors can ensure each customer is running the most recent version in the correct way. Vendors can also ensure that no-one is pirating the software. Vendors can better understand how customers are using the software and better adapt to customer needs.
- Platform independence. Tools offered over a web-browser can be accessed from any OS. For example, SpectaReg has been successfully used on an iPhone.
In terms of flows, I don't see SaaS being an obstacle to that. Web applications can have a GUI and they can take in files and output files... isn't that how tools work in a flow today? Web applications can be scripted using web-service APIs and client side scripting. So the ASIC developer can script their flows and move files between different web-applications / web-services.
Jeremy, I would be a little careful about "Offloading of maintenance" since many customers may consciously decide to avoid an update on the eve of a tapeout to live with the problems that they are already aware of and managing. The first time that you inadvertently introduce a new bug (and what software product these days ships with perfect regression testing and 100% functional coverage) your customers may ask that you make older revisions available as well to eliminate one possible source of problems.
ReplyDeleteI suspect that SaaS in an electronic design flow may look different from Salesforce or Socialtext. That said, there is nothing to prevent you from running two versions in parallel, comparing the results, and letting the user pick which one they want.
As to your two benefits for EDA vendors:
1. What you view as more control your customer may see as a greater risk for IP leakage. Today many firms will report bugs using a design that's been simplified to remove as much intellectual property as possible but still trigger the software defect.
2. You may also find that you have substituted platform independence for browser version dependence.
As to your comment on flows: I am not aware of any web services based flows that move even hundreds of gigabytes of data around using web service API's. There are many production EDA flows that have terabytes of design data being passed between tools.
Hi Sean, yes we have had some requirements to maintain older versions of the server, or a least older versions of the code generation service. For the UI, for collaboratively capturing register Specs, it really hasn't been an issue.
ReplyDeleteRegarding EDA vendor benefits of SaaS:
1. I agree, that some companies may see hosted solutions as a risk. At first, with Internet banking people were concerned about security too, and eventually people warmed up to it. For those companies that don't want to have us host the tool, we install an onsite intranet version of the web-app. That, however, carries a higher price tag.
2. Browser version dependency is a concern, and can be difficult for those who don't know how to write browser independent AJAX. We've learned how to support the main browsers with minimal effort.
Transferring Gig/Tere files is not currently practical, I agree. Hence, the front-end is more suitable for SaaS... like Verification, Embedded SW, and RTL where file sizes are minimal. I've touched on this on my blog at RegisterBits.com.