Comments on: SaaS - With None of the Benefits http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/ sharing insights into the people side of ASIC design Thu, 17 May 2012 15:09:49 +0000 http://wordpress.org/?v=2.3.2 By: Jeremy Ralph http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-428 Jeremy Ralph Mon, 02 Feb 2009 17:42:39 +0000 http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-428 I wonder if an in-house SaaS (aka intranet app) would meet John's requirements? That has it's cost, since such requirements restrict the economies of scale that tools can yield. For a given tool function, if there was both a SaaS and a non-SaaS version, the SaaS should have a lower cost structure. Even with such rigid requirements, if one needed an onsite installation of a SaaS, the easiest path to evaluation is via any online version. That cuts the evaluation cost at the earliest stages of engagement. An online SaaS also reduces the need to physically travel as much, reducing business and environmental costs. Shared servers can be optimized for massive scalability yielding reduced compute costs. >>My biggest concern about SaaS is that it implies that you only use a tool a few times during chip development and that it is better the rent than to buy. I guess some applications are better suited for SaaS, than others. With http://SpectaReg.com our experience is that the tool is used very frequently. Addressable register maps are constantly evolving and being improved to by the network of RTL, verification, firmware, applications engineers, and tech pubs. I wonder if an in-house SaaS (aka intranet app) would meet John’s requirements? That has it’s cost, since such requirements restrict the economies of scale that tools can yield. For a given tool function, if there was both a SaaS and a non-SaaS version, the SaaS should have a lower cost structure.

Even with such rigid requirements, if one needed an onsite installation of a SaaS, the easiest path to evaluation is via any online version. That cuts the evaluation cost at the earliest stages of engagement. An online SaaS also reduces the need to physically travel as much, reducing business and environmental costs. Shared servers can be optimized for massive scalability yielding reduced compute costs.

>>My biggest concern about SaaS is that it implies that you only use a tool a few times during chip development and that it is better the rent than to buy.

I guess some applications are better suited for SaaS, than others. With http://SpectaReg.com our experience is that the tool is used very frequently. Addressable register maps are constantly evolving and being improved to by the network of RTL, verification, firmware, applications engineers, and tech pubs.

]]> By: One Nanometer http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-422 One Nanometer Fri, 30 Jan 2009 05:55:48 +0000 http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-422 Last week i had spoken to a representative from <a href="http://www.cmrda.com/" rel="nofollow">CMR Design automation</a> here in Bangalore about the scope for SaaS in EDA and i got a very spontaneous "NO". They had done a survey on this in Oct last and found that 100% of the companies in Bangalore are against it mainly due to Third part issues, data security, legacy code support etc exactly the ones mentioned by john. Last week i had spoken to a representative from CMR Design automation here in Bangalore about the scope for SaaS in EDA and i got a very spontaneous “NO”. They had done a survey on this in Oct last and found that 100% of the companies in Bangalore are against it mainly due to Third part issues, data security, legacy code support etc exactly the ones mentioned by john.

]]> By: James Colgan http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-414 James Colgan Mon, 26 Jan 2009 23:44:37 +0000 http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-414 Exactly Amir. It's not a one-dimensional problem. There are multiple factors to consider. Factors that will change over time as conditions, perceptions, ROI calculations, etc. evolve. One challenge that is no longer of issue is the technology - it's <a href="http://www.xuropa.com/" rel="nofollow">here</a>. Exactly Amir. It’s not a one-dimensional problem. There are multiple factors to consider. Factors that will change over time as conditions, perceptions, ROI calculations, etc. evolve. One challenge that is no longer of issue is the technology - it’s here.

]]> By: Amir http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-413 Amir Mon, 26 Jan 2009 22:48:40 +0000 http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-413 A few readers on my blog also mentioned the EDA SaaS and the secret RTL issue. The rebel voice thinks this paranoia is a fatal flaw. If transforming the server farm capex into an opex vastly improves the business model of a design firm, then I wonder if the paranoid companies will still be able to compete with people who either trust their tool vendors or have been enlightened by the economics of sharing free things freely. A few readers on my blog also mentioned the EDA SaaS and the secret RTL issue. The rebel voice thinks this paranoia is a fatal flaw.

If transforming the server farm capex into an opex vastly improves the business model of a design firm, then I wonder if the paranoid companies will still be able to compete with people who either trust their tool vendors or have been enlightened by the economics of sharing free things freely.

]]> By: James Colgan http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-412 James Colgan Mon, 26 Jan 2009 16:05:31 +0000 http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-412 Between what John describes and what Blue Pearl could be doing is the entire spectrum of potential SaaS application. As I describe in my <a href="http://www.xuropa.com/blog/2008/12/09/cloud-computing-saas-and-electronic-design-part-1/" rel="nofollow">Cloud Computing, SaaS and Electronic Design</a> post, the move towards SaaS is not going to be a step function, but a gradual migration. Blue Pearl is demonstrating one perfect example of how SaaS could be used to a) solve a short term specific need at a customer, and b) cost effectively deliver that service to c) engage with a customer to generate a "traditional" EDA sale that depends upon the issues John raised above. Between what John describes and what Blue Pearl could be doing is the entire spectrum of potential SaaS application.
As I describe in my Cloud Computing, SaaS and Electronic Design post, the move towards SaaS is not going to be a step function, but a gradual migration. Blue Pearl is demonstrating one perfect example of how SaaS could be used to a) solve a short term specific need at a customer, and b) cost effectively deliver that service to c) engage with a customer to generate a “traditional” EDA sale that depends upon the issues John raised above.

]]> By: harry http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-410 harry Sun, 25 Jan 2009 19:51:16 +0000 http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-410 Hi John, You have several valid points regarding whether SaaS is yet a viable model for full chip development and as a replacement for your development environment. In fact, I'm in the process of putting a post together that talks about the disadvantages of the SaaS / Cloud model. Many of the points you mention (data security, CPU provisioning, licensing models) will be covered in that post. We probably agree on a lot of them. Blue Pearl's offering is different. Michael calls it "services using software in-house". I might also call it a "paid evaluation". Sean Murphy might call it <a href="http://www.skmurphy.com/blog/2007/10/04/benefits-of-saas-business-model/" rel="nofollow">pay-per-use</a>. In any case, we're talking about software deployed for 2 days for a specific single use on a single design with AE resources assisting. Logistically, isn't it easier to upload RTL to a working design environment than to create a working environment at the customer. Isn't it easier (and cheaper) to work online than to fly AEs from Silicon Valley to the customer. Isn't support easier for Blue Pearl in this environment than thru VNC to the customer. The issue of RTL being proprietary is the only one that I can see being a showstopper. And you are right that it is still a huge issue for the majority of companies. At the same time, there are many companies that completely outsource the RTL2GDSII implementation of their chips, so it's not a non-negotiable. harry Hi John,

You have several valid points regarding whether SaaS is yet a viable model for full chip development and as a replacement for your development environment. In fact, I’m in the process of putting a post together that talks about the disadvantages of the SaaS / Cloud model. Many of the points you mention (data security, CPU provisioning, licensing models) will be covered in that post. We probably agree on a lot of them.

Blue Pearl’s offering is different. Michael calls it “services using software in-house”. I might also call it a “paid evaluation”. Sean Murphy might call it pay-per-use. In any case, we’re talking about software deployed for 2 days for a specific single use on a single design with AE resources assisting. Logistically, isn’t it easier to upload RTL to a working design environment than to create a working environment at the customer. Isn’t it easier (and cheaper) to work online than to fly AEs from Silicon Valley to the customer. Isn’t support easier for Blue Pearl in this environment than thru VNC to the customer.

The issue of RTL being proprietary is the only one that I can see being a showstopper. And you are right that it is still a huge issue for the majority of companies. At the same time, there are many companies that completely outsource the RTL2GDSII implementation of their chips, so it’s not a non-negotiable.

harry

]]> By: Maèstro http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-405 Maèstro Sun, 25 Jan 2009 17:32:29 +0000 http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-405 Yes. Xuropa would be a great match to deliver these type of services. BTW: I wouldn't call what Blue Pearl is doing as SaaS. They're merely offering "Services" as a mean to generate revenue, and their using software in-house to perform the services. Yes. Xuropa would be a great match to deliver these type of services. BTW: I wouldn’t call what Blue Pearl is doing as SaaS. They’re merely offering “Services” as a mean to generate revenue, and their using software in-house to perform the services.

]]> By: John Eaton http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-404 John Eaton Sun, 25 Jan 2009 16:56:26 +0000 http://theasicguy.com/2009/01/23/saas-with-none-of-the-benefits/#comment-404 Instead, why not: * make the software available online * let the designer upload his RTL and work from his desk * let the AE work remotely from his office ---------------------------------------------------------------------------------- So Harry, There are certain government agencies that would need to know the gps location of your servers so that when they finish their project and need to purge all the working data would know where to target the cruise missiles. We are not quite that bad but we have a firm rule that we never give our rtl to third parties. This includes our asic vendors with whom we have well established relationships and NDA's. SaaS would be a non-starter in my group as well as many others. There is also the issue of archiving. If I have to pull an old chip out the mothballs to revise and rerelease then I want to start with the same toolset and revisions that I originally used. Do you support this? We currently archive all our tools and keep old revisions online for several years after a part is released. How big is your server farm? We have dedicated boxes in the data center that the asic team manages. We never have to wait for resources because of heavy use by other groups. My biggest concern about SaaS is that it implies that you only use a tool a few times during chip development and that it is better the rent than to buy. That is simply not the case. Tools are in constant use. You don't synthesis once and ship it. You run it thousands of times on every level through out the development cycle. You run experiments to see if you can change the rtl and improve things. We do a full chip release every week simply to check out the process and catch problems quickly. Once the chip is released you continue to work on your process and ip for the next chip. There is no time when we aren't running our design tools. Having these tools running on our machines is important. John Eaton Instead, why not:

* make the software available online
* let the designer upload his RTL and work from his desk
* let the AE work remotely from his office
———————————————————————————-
So Harry, There are certain government agencies that would need to know the gps location of your servers so that when they finish their project and need to purge all the working data would know where to target the cruise missiles.

We are not quite that bad but we have a firm rule that we never give our rtl to third parties. This includes our asic vendors with whom we have well established relationships and NDA’s. SaaS would be a non-starter in my group as well as many others.

There is also the issue of archiving. If I have to pull an old chip out the mothballs to revise and rerelease then I want to start with the same toolset and revisions that I originally used. Do you support this?
We currently archive all our tools and keep old revisions online for several years after a part is released.

How big is your server farm? We have dedicated boxes in the data center that the asic team manages. We never have to wait for resources because of heavy use by other groups.

My biggest concern about SaaS is that it implies that you only use a tool a few times during chip development and that it is better the rent than to buy.

That is simply not the case. Tools are in constant use. You don’t synthesis once and ship it. You run it thousands of times on every level through out the development cycle. You run experiments to see if you can change the rtl and improve things. We do a full chip release every week simply to check out the process and catch problems quickly.

Once the chip is released you continue to work on your process and ip for the next chip. There is no time when we aren’t running our design tools.

Having these tools running on our machines is important.

John Eaton

]]>