Cloud-computing and SaaS – follow up
Sorry if this is not strictly DFT-related, but it’s interesting to me, and well, it’s my blog. 
Anyway, I got a couple of good comments, in Facebook, no less, that I wanted to share. I figure the people promoting these ideas would like to hear as many opinions as possible from different areas.
So, as I said, one of my Facebook friends, with whom I worked during my WDC days, John Firth (now at LSI) read my post, and had this to say:
[...] what about IP issues? I would think that engineering management would be very skittish about their precious IP getting out on the net. I’ve worked for guys/companies that wouldn’t let unencrypted data be transferred across the Internet period. No unencrypted ftp to customers or suppliers. Cloud computing will have to have answers for these guys to get any traction.
That’s definitely one of the first issues that comes to mind, at least from a design-house point-of-view, when working with contractors – where is the work done? Where is the data, where are the tools? On top of the the security issue, I’d add the issue of database size. The CC/SaaS paradigm locates the tools in a cloud, accessible through the web. So one must upload the design to be processed elsewhere. If you’re working on a sizable chip, it is not a small task to get it from one place to another; it gets worse with a multi-vendor flow.
CC/SaaS proponents and vendors aren’t worried much about security issues; the technology exists to mitigate them. As Jeremy Ralph of PDTi, a vendor and panel member at the upcoming roundtable says in this post on his blog,
Encryption can go a long way to make the transmission un-interceptable. Obfuscation can make the code nearly impossible to understand.
Well, I’m all for encryption, but obfuscation is plain wrong, from a maintainability standpoint, and in my opinion is unjustifiable as a means to the end. Hopefully that is the point Mr. Ralph was making…
Then my friend John hit on another point – clearly he’s been through this before…
Tool versions/hotfixes/patches/hardware interactions/phase-of-the-moon-during-installation issues are always dogging us. That is a real stumbling block in the cloud computing model’s application to EDA that most other applications don’t face.
It seems like one rarely, if ever, gets a chip out without building a house of cards of all of the specific tool versions required only to see it fall as a required bugfix ripples through all of the tools, forcing you to rebuild the house of cards once again.
Hardly the model of homogeneous software availability that would be ideal for a cloud
I guess I see this as a problem that will never go away. No matter where the software is served, there will always be situations where things work with one version better than another. I experienced this as I wrote this post, believe it or not…
But then again, what if you end up changing your source code or scripts to work better with one vendors tools? Then you’d have to re-ship code to other vendor sites – there’s more work involved in this case – seems like there are some revision management issues that may arise.
Bottom line, I suppose, is that one could travel down many roads of what if?, because there are many issues to resolve. But there are probably just as many reasons to make it work. Again, if you’re interested, go see the roundtable this Wednesday at DVCon.
Stumble It!
Hi John,
The SaaS and Cloud Computing session is mentioned on the DVCon website homepage (http://dvcon.org) on the right side panel as an additional meeting. It was not part of the original sessions as I organized it afterwards.
Regarding the objections, they are all absolutely relevant. RTL and IP concerns are both issues of comfort and legal issues that won’t quickly be overcome across the industry. The size of data transfers forces us to consider putting more than just a single point-tool in the cloud, but rather an entire sub-flow of the design process (e.g. verification), to reduce back and forth transfers. And the issue of tool version management is actually, I believe, better addressed is the cloud than in the enterprise.
To be clear, I believe cloud computing and a SaaS-like model will influence EDA to a great extent in the next 5 years as more applications become remotely hosted. What exactly that final result will be, is very much open to debate. I guess that debate has already begun and will continue this week at DVCon. Should be very interesting.
harry
Hello John,
All good points that need to be addressed, but it will be a gradual process. As you describe it, a “step function” all-or-nothing approach is unrealistic, however, there are benefits to SaaS/CC that can’t be ignored and there may be a fit for some applications. (I blog about this gradual approach here: http://tinyurl.com/6ha3ud )
A small example: verification of an AXI to PCIExpress bridge. As neither of these protocols are trivial, I really don’t want to be verifying this with directed tests. But do I really want to buy annual licensess for two Verification IP’s if I don’t have them already?
How proprietary could this bridge be? And it’s really not that large a design, so transfer shouldn’t be an issue.
Given a secure communication link and trusted provider, wouldn’t it be much more cost effective and efficient if I could upload the bridge to the vendor’s “cloud” and verify it there?
A pay-as-I-go pricing model with no license fee to guide through the legal processes is compelling in this case.
Something else to consider – training and evaluation. Vendors spend a great deal of time and resources training customers and prospects. It’s getting harder and harder the more geographically dispersed design teams are. Also, first phase evaluation of a VIP (for example) could be accelerated using SaaS/CC. No installations and no license agreements to sign – that is attractive to vendor and engineer alike.
This last point was made by a very large IDM to Cadence when they saw that Cadence has their MIPI Verification IP hosted within a Xuropa Online Lab. Their next question was – “When are you going to get USB3 up there for us to take a look at?” (http://www.xuropa.com and go to one of the Cadence Labs to check it out.)
As with everything, there is a technology adoption curve. Some things make it up the curve, and some things don’t. EDA and semiconductor design is too broad and complex to say all of it will make it into the cloud. But for the same reasons, it cannot be said that none of it will make it either.
- James
Harry, James:
Thanks for reading! You know, it’s funny, this is one of those times when I have to go re-read my post and figure out what I said. I didn’t intend for it to come off as negative as it sounded, but it did, sort of…
I’m actually on-board with the CC/SaaS idea completely – but I got these other comments as a response to my first post (which read a little bit more positive), and think they’re valid, so I gave them air. I agree with you that the transition will be gradual, as the issues are ironed out.
I do suffer from a slightly narrow point of view. I haven’t “been around” in the industry – I’ve spent my life in mass storage and communications devices, all of which have grown to hideous sizes in the recent past. So moving a database is a big deal to me. As a DFT guy, I also deal just as much in gates as I do RTL, and gate-level stuff (w/ SDF, SPEF, SDC, etc) gets big real quick.
I haven’t thought of the training angle yet. Let me you you that it would definitely improve my life if product traingin were served remotely in an organized and efficient fashion (perhaps on Xuropa!). It’s never convenient for me to fly to the bay area for a week to learn a new tool. So normally, I fly by the seat of my pants instead and bug the hell out of the AE on the phone. BTW, I learned Verilog on video tapes produced by Cadence almost 20 years ago…
Thanks again for your comments. I can’t wait to hear how the roundtable come out!
JMF
I should be going to sleep for my 7AM flight to DVCon, but I want to chime in again.
The objections are real. They are not misguided attempts by threatened CAD managers to save their jobs. Just as there are real tangible benefits of SaaS, there are real issues. I CANNOT transfer RAMBUS’s DDR3 IP anywhere I want without their permission. Case closed.
However…the real question is whether the benefits of SaaS greatly outweigh the issues, to all parties involved. IP issues can be solved. Security concerns can be addressed. We just need to decide to go after these.
We’ll see on Wednesday what people think. Should be interesting.
I agree that managing the deck of cards of tool version numbering is a real pain… there is no reason that the SaaS vendor can not take on this management and add more value. For example, there is no reason why a user couldn’t check what version of a specifc tool library and the SaaS can manage that.
For large files, the Internet is getting better and better with that. Especially with more and more video content.
Regarding obfuscation, I’m not saying that’s the way to go but it is an option for certain problems. For example, if a SaaS customer has an issue/bug to share with the vendor. The SaaS system could allow the customer to share obfuscated data with the vendor to re-produce the issue without exposing design intent.