SaaS - With None of the Benefits

A friend just made me aware of a new “No EDA Tool Purchase” plan from Blue Pearl Software.

Hmmm …. sounds like Software-as-a-Service with none of the benefits for customer or vendor:

  • Customer still needs to generate a PO. (By old school thinking, that’s a way to “qualify” the customer.  New school, that’s a barrier to customers actually trying your tool).
  • Still need to install software at the customer’s site. (”What OS are you running? What version? Do you have the right version of ActiveTcl installed?” Ugh!!!)
  • Still need to incur the cost of travel. (Nuff said)
  • Have to get the work done in a 2-day fixed window (Is anything ever done in this short a timeframe? If not, then what?)
  • Have to schedule to when the AE is available, so customer can’t do this on a moment’s notice. (How does a month from now sound … Oh … never mind … AE is out that week … how about the following week).
  • Need to dedicate an AE full-time per customer. (What’s he do while the customer goes to meetings?)

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

No PO required. No installation issues. No travel. Easy to schedule and staff and extend if needed. (See what Xuropa is doing). Heck, why not just sell the software that way while you’re at it.

Maybe I’m missing something.  Maybe someone from Blue Pearl wants to explain what the thinking behind this is.

And if you’re interested in topics like this, stay tuned for more on the upcoming SaaS EDA Roundtable at DVCon.

harry the ASIC guy

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Tags: , , , ,

8 Responses to “SaaS - With None of the Benefits”

  1. John Eaton Says:

    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

  2. Maèstro Says:

    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.

  3. harry Says:

    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.


  4. James Colgan Says:

    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.

  5. Amir Says:

    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.

  6. James Colgan Says:

    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.

  7. One Nanometer Says:

    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.

  8. Jeremy Ralph Says:

    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 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.

Leave a Reply