The Xuropean The Xuropa Online Community Blog

In response to a cloud computing question I posted to an online forum discussion a concern was raised about security.  Here is the unedited response in full:

“I think cloud computing is extreamly dangerous. There are enough problems with viruses now. IF people were able to exploite holes in componants use din cloud modules or even write systems with back doors in would anyone be sure thyey have a sucure or safe system?”

As I noted in previous posts, security is indeed one of the key drivers of the adoption of cloud computing.  And trust will be a crucial ingredient in the “crossing of the chasm” of this technology and use model.

There is always mistrust of new technologies.  (Did you know that in the very early days of the motor car some scientists believed that passengers would suffocate at speeds over 20 mph?)  Some mistrust is well placed and drives innovative counter measures.  Others will need greater familiarity with the technology and leaders to follow.

To address the first aspect of the posters concern though - viruses and their contagion.

For a virus to be communicated three things need to occur.

1. Placement of the virus at the source.
2. Inadvertent download of the virus by the user.
3. Execution of the virus on the local machine.

There are three parties one could imagine placing the virus within the remote hosted application in the cloud: the cloud computing host company, the vendor of the hosted software, and users of the hosted software.  For a cloud computing company to go to all of the time and expense in developing sophisticated cloud computing platforms such as Xuropa’s Online Labs just to spread a virus is nonsensical.  Like-wise, for the owner of the electronic design software to place a virus within the Online Lab they are using does not make any sense whatsoever.  The last suspect, other users, could have the motive, but they will not have the means.

Consider the use model of a Cloud Computing-based EDA tool in the context of a Xuropa Online Lab as an example.  Every time the remote tool is accessed through a lab session, the environment is provisioned fresh and new from an image that is created by the tool vendor and Xuropa engineers for the Online Lab.  This image is inaccessible to a user.

While the session is active, only users that are explicitly invited into the lab session can have access to the work being carried out by the person who initiated the session.  There is no way for someone to sneak in via a “backdoor”.

If the user was malicious and did upload a virus to the Online Lab they would be very disappointed.  After every lab session has ended all data is erased, all processes on the lab are terminated and a thorough clean of the remote environment is carried out.

The Online Labs hosted on the Xuropa Platform today are even more secure in that they do not provide any upload or download capabilities by design.  No code is executed locally.  This talks to the gradual progression to the cloud of a previous post.  There are great benefits to be gained by leveraging cloud computing without leaping straight into design and development.  Training, demonstrations, workshops, pre-evaluation, and technical support to name just a few.

Which brings me to a follow up observation: mailing of CD’s for evaluation.

Today I opened the EDA Tech Forum magazine and it contained a CD from a nameless EDA vendor.  At the bottom of the CD is written “Every effort has been made to ensure that this disk is virus-free. “XYZ Company” is not responsible for any disruption, damage and/or loss to your data or system that may occur while using this CD.  As with all software we recommend running a virus scanner before use.”

I’m sure that this CD is fine.  The probability of it containing a virus is very, very low.  However, the reason why the lawyers of XYZ Company told their marketing department to include that disclaimer is because of control.  More specifically, it is because of the lack of control.  Once that CD leaves the door of the vendor they don’t know where it could go and through how many hands it will pass.  It is highly unlikely that they burned the CD themselves either.  They will have used a service provider that stamps out CD’s with the label by the hundreds at low cost.  Again, another point of loss of control that keeps the lawyers up at night.

However, with a Xuropa Online Lab you not only have complete control over the environment and who uses it, you also don’t have to go to the wasted expense of sending out hundreds and thousands of CD’s to people that have no interest in the product at all.  (Not a very green approach either.)

So in summary, the cloud is extremely secure.  It is in everybody’s best interest to make it even more secure.  For those malcontents with too much time on their hands life will actually get more limited with a move to the cloud.

You can reduce your overall marketing costs, decrease your “carbon footprint”, and let your lawyers sleep easier by moving to the cloud.

Keep control and keep lawyer fees to a minimum - not a bad thought going into the new year.

Posted under Features, Xuropa, business, industry, marketing

One of the advantages of the software-as-a-service SaaS (or even a more broad Web 2.0) business model is that the starting costs could be relatively low and even with a few (good) engineers it’s possible to reach a revenue-generation point in a short amount of time.  However, what do you do so you are able to profitably grow after you hit the first-revenue point?

Posted under Xuropa, business, career, industry

So far we’ve been able to keep the Xuropa Platform an ad-free zone.  We provide value to our clients by enabling them to build engaging communities around their products.  They lower marketing and support costs, and are able to build and nurture relationships globally without having to get on a plane or attend an expensive trade show.  That’s how we aim to support our business and we’d like to keep it that way.

There’s another reason we’d like to keep ads off the platform - real estate.  One of the hardest aspects of building a platform of this degree of sophistication is the user interface and use model design.  We have lots of ideas for cool features and functions, but it’s always…”where do we put it?” and “how are people going to use it?”

However, when push-comes-to-shove and ads are your only source of revenue, other than a sense of “yikes!”, I can understand the compromises in design and usability that have to be made.  But, when the reader of your blog has to scroll down past three columns of ads to get to your post you’ve lost your way.

Lost Your Way I

When your ad is threaded within your post in such a way that the title of the post actually looks like it is “Ads by Google”, you’ve lost your way.

Lost Your Way II

When I was at the EDA Bloggers Birds-of-a-Feature meeting at ICCAD last month it was great when Rick Munden stated that he had taken all ads off his blog.  When I asked him “why?” he pointed at Sean Murphy (the organizer of the meeting), who came back with the perfect analogy.  “Why advertise cup holders when you’re selling a Cadillac?”

Sean’s absolutely spot-on.  Most of the bloggers that I see out there are doing it on the side as a marketing promotional tool for their day-job.  More often as not it appears to be consulting or contracting work - the Cadillac!

Unless you think that advertising can be a driving revenue stream for your business, don’t do it.  It can cheapen either the perception of your core product or the message within your post advertising your core product.

If the additional revenue stream can be a significant contributor to your business model, then please do yourself and your readers a favor.  Position your ads without compromising the readability of your post or the usability of your blog.

Less is definitely more in this case.

Posted under business, marketing

I visited Facebook last week.  I’ve gotten a lot of emails asking me about how my visit was so I promised everyone that I’d do a blog post about it.

It was a very interesting experience.  I went there to see a friend who is working in the R&D group.  What I saw there was a great feeling of team, bright individuals, innovation, energy, and openness.

It reminded me of EDA in the late 80’s — at least my experience in VLSI’s software group.  VLSI was a renegade semiconductor company which started the ASIC model along with LSI Logic.  Everyone viewed us as they view Facebook today: “This is all cool stuff, but how are they going to make a profitable business out of this?!!

At that point, VLSI only hired the best from the best schools (as Facebook does today).  We were mostly in our early 20’s (as Facebook today).  We worked together, had lunch together, partied together, shared housing together, even dated (as in Facebook today): Work was more than just work (and in fact to this day some of my closest friends post-college are those I met at VLSI).  As my friend and I had lunch in the Facebook café (yes, it was free food!), I noticed a lot of similarities with those days in EDA.

As it always happens, EDA matured (as semi had before that) and companies became “corporations”.  Work became just work.  It really makes me wonder about the whole dynamic around corporations: less entrepreneurial, closed, paranoid, ….  I always wondered, for example, why don’t corporations use Macs.  Macs are better (performance), must safer, cost compatible, and open.  My thought: Macs just don’t fit the bill because they’re just not “corporate”.  As it turns out, corporations are also having a hard time today dealing with Facebook, or social networking in general - Facebook is not “corporate” either.

In the mid 90’s, corporations were struggling to deal with “this internet thing”.  A lot of companies were limiting employees access because they feared employees would just waste their time browsing.  I used to hear that argument all the time.  Could you imagine if someone would limit the use of the internet at work today?  All employees (and management) would be up in arm asking “how’d we get our jobs done?!!”

So 15 years later and now corporations are questioning Facebook.  They’re looking for ways to limit employees time on Facebook, or other social network/media for that matter.  Instead they can be greatly leveraging it.  There is an insightful article in FastCompany magazine this month about how Cisco is embracing social network within the company to dramatically invigorate innovation and leadership.  It’s a bold move by John Chambers (Cisco CEO), one that requires openness, something not typically “corporate”.

Cisco’s vision is highly appliable to electronic design companies.  Xuropa is enabling professional networking dynamics built around technology-networking (a la social-networking) focused on the entire electronic design supply chain.  Xuropa’s platform is something that electronic design companies can leverage (just as Cisco’s already doing using other social/professional networks), to revitalize innovation and leadership, and significantly impact the bottom line.

Back to Facebook:  We, as high tech professional, have been taught to believe that someone needs to have a need first, and then we’d create the solution — and more complicated the solution the better.  As I talk around the industry, I run into people who are upset (and even belligerent) about why Facebook is getting so much attention.   “What are they trying to solve?”, I’m often asked.

What I find Facebook’s genius to be is that they (most likely by luck, and perhaps because they just didn’t know anything different) identified a trend (that people spend more time on the web than TV, phone, radio, writing letters, reading books, etc. combined) and created a fairly simple platform to enable what people would usually do on TV, phone, etc.  They didn’t wait for a problem, they just closed their eyes and imagined “what if …”.  That is really the genius behind the Facebooks, the Nings, and the Xuropa’s.

Click here to read other posts or subscribe to my blog.

Posted under Xuropa, business, career, industry, marketing

Semiconductors have worked their way into the heart of democracy in Estonia.  According to an Information Week article, cell phone owners get a free authorized chips that verify the owner’s identity and participation in the system.

Also according to the article, this is the next step forward for the country that instituted voting by internet in 2007.

Here is an opportunity for the US government to invest in infrastructure building central to its democracy.  It would result in a nice bit of stimulation to the high-tech industry and the economy as a whole.

Anyone know who provides the technology behind the Estonian system?

Posted under business, industry

In the previous posts in this series we covered some definitions of cloud computing; drivers of the transition to cloud computing by electronic design tools; and a potential roadmap for how this transition could look over time for the EDA tool flow.

In this post we conclude the series with a discussion of different approaches to Cloud Computing.

Remote Access and Cloud Computing Approaches

Cloud Computing could be thought of in different ways, but as with the adoption of most new technologies it will be gradual and in different forms.

Tool Access Models

Beyond the completely locally hosted scenario, there are three basic remote access and SaaS models available today.

VNC (Virtual Network Computing)

This scenario is built upon technology and tools that have been commercially for a few years now. It takes quite a bit of maintenance and support on its own and is not extremely user friendly on its own. However, many electronic design firms are using this for different phases of technology adoption. Engineers also typically use VNC to access tools that are internally hosted.

This is not “Software as a Service”. It an ad hoc technology that provides remote access in a bare knuckle fashion. Software needs to be installed on the server and the client to set up the environment. Connections are set up from the command line and not very user friendly.

EDA SaaS 1.0

As has been productized within a Xuropa Online Lab™, this is an infrastructure that provides systematic, secure remote access to an EDA tool without any installation, setup or teardown by the user. The tool is available on demand and provides for an ideal environment within which to carry out many of the tool adoption phases above.

SaaS and Tool Adoption Process

Also, a Xuropa Online Lab can be extended to provide a design environment allowing the user to upload and download design files. This last model can be adapted to provide SaaS remote access to the EDA tool and would be ideally suited to perform evaluations and even utility of some tools under the right use-model.

For existing EDA tools, this is the shortest, most secure and economical way to place your product in the cloud to provide global access to your market.

The hardware supporting this environment could be a dedicated server or a server farm running virtualization software to maximize resource utility and lower costs. The hardware could be an internal or leased server farm with VMWare or Parallels software. There are other commercial providers of Cloud Computing, the most widely quoted is Amazon with their EC2 (Elastic Compute Cloud).

Above and beyond the Xuropa Online Lab, Xuropa provides services to extend this product to accommodate different use- and business-models. Please inquire for details: sales@xuropa.com.

EDA SaaS 2.0

Using similar hardware configurations as described with SaaS 1.0, this architecture requires the replacement of an existing user interface with a web-based user interface. Alternatively, a new company wishing to broaden the reach of their core tool engine would begin by building a web interface and make it scalable and accessible globally from the start.

There are two early examples of this within electronic design today. Think Silicon provides IPGenius™ as a web service to generate IP cores from different configurations. PDTi™ provides a web-based tool called SpectaReg that is a web enabled collaborative development environment for addressable register interfaces within an SoC. In the past 3 or 4 years this space has become crowded with competing commercial solutions or internally developed frameworks. A SaaS approach is a great way to compete on business model and support model.

[You might want to have a paragraph of the issues/costs of maintaining two versions, one a “regular old” EDA version and a second SaaS version of the tool. And perhaps how Xuropa knows and can offer services to reduce that cost. Just a thought!]

The business model will also migrate from a per-seat time-license model that the user has little control over to a cost-per-“X”, model where “X” can be a number of different parameters. For example, X could be the number of bugs found, the number of cores integrated, the number of regressions run, the length of time the tool was used, the number of designs created, the number of micro-watts saved, etc. ie. the model could be a simpler time/user-based model, but it could also be more tightly tide to the value a particular tool delivers. And the real power of this model is that these metrics can be measured.

Not only can more creative business models be created, but they will make more sense and be more easily and naturally support by both vendor and user.

If there wasn’t such inertia within the existing EDA business models the business model could be a driver that trends gradually towards change, but then experience a significant “tipping point” as a major player changes the rules of the game.

Whether your company is looking to move an existing tool to the web, or is developing a tool for a SaaS model from scratch, it is important that you focus your resources on your core value proposition – your tool’s engine. Xuropa SaaS Design Services is the ideal strategic partner to collaborate with. Leverage our web and EDA expertise and the Xuropa Infrastructure to realize your SaaS vision. Contact us for more information sales@xuropa.com.

Conclusion

We’re at the beginning of a trend, but without a doubt it is a trend. There are 4 key drivers to the development of the use of Cloud Computing and the adoption of SaaS as a business model, and gradually these drivers will align for different products and different companies.

While the drivers do not align for some companies and products just yet, the electronic design industry is primed for a change of this magnitude. Business pressures due to macro-economic “re-adjustments” could be the catalyst for the trend. Also, for those start-up EDA companies that either cannot get funding or are not able to obtain their Series B or C, moving to a SaaS model could be the only way to penetrate accounts, global markets, lower the cost of sales and out maneuver their competition. It might even be a way to get VC’s interested in EDA again…maybe.

SaaS also offers opportunities to semiconductor vendors. It is a way for them to reduce their total cost of ownership and increase their flexibility. Not all of their CAD department is tightly coupled with their value proposition. In much the same way as having a fab no longer became essential to a semiconductor’s success, an internal CAD department could go the same way through SaaS and Cloud Computing.

Finally, there are many benefits to SaaS and a Cloud Computing model for the end user.  They always have access to the latest revision of the tool without the pain of installation and transition.  They also have an environment that is architected to operate in a distributed and collaborative fashion across specializations and teams.  This will remove a lot of the friction and inefficiencies within geographically distributed companies.  And the business will be a pay-as-you-use or a results/value-delivery model, which should result in a higher return-on-investmet.

If you’re considering making the move, drop us a line and let’s discuss. sales@xuropa.com or register within the community and send me an email from my Xuropa Professional Profile – Search for James Colgan within the Community area.

Posted under Features, Xuropa, business, industry, marketing

Cloud Computing Adoption Roadmap for Electronic Design

In previous posts in this series we covered some basic definitions and the basic drivers to adoption of cloud computing by the electronic design industry.

In this post we discuss a different vector along which to view cloud computing adoption and a potential roadmap of tool type transition.

A Different Vector of Adoption of SaaS Model

There is another vector of transition that is worth exploring. Even if some EDA tools do not lend themselves to moving directly to the cloud, there are phases of the adoption process that are.

Considering the adoption process, there are four main steps: demonstration, training, evaluation, and use.

Technology Adoption Process

Demonstrating a tool via the web is already available using services such as Xuropa’s Online Labs. These integrated environments can also be used for training purposes. But this is only the beginning.

As each phase of the technology adoption process moves to the cloud, a positive psychological and behavioral effect will occur on the subsequent phase. Ie. for some tools, the user will question, “if I can get training for a tool online, why can’t I evaluate your next alpha release online too”. The value proposition will be convenience and time saved. There will be no installation required, less technical support and no conflicts with existing environments when the alpha release is used. Also, as bugs are fixed in the alpha release they are immediately reflected out to the user. This improves their experience and increases their potential of adopting the new revision of the tool when it goes to general release.

Again, the transition is not black and white. Some tools, some users, some situations lend themselves to a move to the cloud. However, as we move forward, each point in the process will undergo a “tipping point” and the transition will occur.

Transition of the Flow

As has been alluded to previously, a fundamental premise for this paper is that the transition will be gradual and it will depend on many components. Not least of which will be the architecture, use-model and implementation of the tool to make the transition.

Below is a much simplified abstraction of the semiconductor and software development flow. Considering the 4 Drivers described previously, it would be easier to note those pieces that would be slower to transition to the cloud.

Electronic Design Tool Flow

Hardware/Software co-design and co-verification has tool and methodology related technical challenges that could slow a transition. But the process of system development and the fact that the two teams holding the disciplines are often separated geographically would lend itself to a remote SaaS model. This could be valuable for at least the early stages of the product development project. It would resolve issues around versioning and facilitate collaboration between the disciplines.

Analog Mixed-Signal could well be a slow mover as simulation runs can take days and present a quality of service challenge. Top-level chip simulation could also be slow in adoption for the same reason.

Synthesis will be slow to move over due to the sheer massive amount of data involved. And test would be a challenge as the actual chip is needed.

However, all other parts of the flow should be possible to transition to SaaS, including emulation and test.

EDA Tool Adoption Curve

In the next post in this series we’ll look at different approaches in the transition to cloud computing and SaaS for electronic design.

Posted under Features, Xuropa, business, industry, marketing

I remember throughout my career, every time the economic situation was tightening, I kept hearing from my bosses and other executives to “do more with less”.  And needless to say, every time I heard that phrase, I found it extremely insulting.  As if I wasn’t already doing more with less?!!  To me it always sounded as if I was being told I was getting fewer resources (and perhaps needed to cut people), more work is getting piled on me, and that it really doesn’t matter what the quality of the results are.

What people don’t realize is that one **can** instead focus on getting more (even with fewer resources) by doing things better.  And doing better doesn’t necessarily mean doing more.

So how would you just do better?  The key to the answer if finding how to do better with less.  In my opinion, doing so relies heavily on how open you are to adopt new ideas.  Doing better with less means not necessarily doing the same but instead finding ways to fundamentally create a **positive** change (and not necessarily change for the sake of change).

Let me clarify with an example: Let’s say you spent $5,000 on a trade show and collect 500 leads.  500 for $5,000 leads may be a great or mediocre outcome depending on the industry, the trade show itself, etc.  so take that just as an example.  There are tons of ways to try to do better with less - one example being just improving the booth messaging (more clear, more targeted, more interesting, etc.) and hence spending $3,000 to shooting to get 600 leads  However, do get the more dramatic value is to step out and think about why you’re attending trade shows in the first place.

In my consulting practice, most clients are going through severe cost/benefit analysis, especially on trade shows.  What is driving this re-evaluation is the change that is taking place in sales and marketing in general.  Up to recently, marketing was what I refer to as “broadcast” marketing - the vendor(s) as well as users closely associated with the vendor(s) broadcast an integrated message to a target audience.  In the last few years (predominantly since 2004), sales and marketing is taking on more of an “engagement” model.  Marketers are not engaging target audiences in discussions and make their (still integrated and campaign-driven) points through communities, discussions, and blogs.

If you think engagement marketing only applies to consumer market, you’re fooling yourself.  In 2005, when I was VP of marketing and business development at Calypto, I was pitched by our PR agency to start looking at blogs as a way to reach our audiences.  My reaction was that I was being **pitched** for more services and ultimately being asked to spend more money with the agency (which I’m sure was partly the case).  So I dismissed the idea quickly.  Blogging was probably too early for the deeply technically rooted electronic design industry, but I do acknowledge that I wasn’t being open to doing things “better”.  Three years later, and I see evidently that smart marketers, even in the electronic design industry, are turning into leveraging communities and blogs to reach their audiences **better** (and doing it with less resources).

Another example: Virtual trade shows have been around for a couple of years now - but they’re built on the conventional broadcast marketing paradigm.  Virtual trade shows **could** probably allow you to do more with less.  However, there are key new technologies out there to accommodate the shift to engagement marketing.  One great example is Xuropa.  Xuropa is a new community (with all of the bells and whistles), built around the electronic design community, which enables user-user and user-vendor discussions, engagement, and even collaboration.  It not only provides for broadcast marketing, but these days we’re dealing with a whole new set of sophisticated users who dislike being broadcasted to and would rather prefer to have an active voice with their vendors.

###

Bottom line:  There are many ways to approach the “need to do more with less” pep talk.   However, to “get the most” you might need to step out of the box and look for new ways and technology to exceed your objectives.  Doing this might also avoid turning off your employees by the pep talk, and instead motivate them and bring new energy during the budget crisis.

……

Click here to read other posts or subscribe to my blog

Posted under Xuropa, business, career, industry, marketing

The Drivers of Cloud Computing Adoption

The previous post in this series laid out some basic definitions and a premise of where the EDA industry is with respect to the adoption of Cloud Computing and SaaS.

As with any move to a new technology, there are drivers towards adoption and points of inertia slowing down the transition.

Outside of trust, the number one objection that I hear to Cloud Computing is performance.  And indeed, this is a key inhibitor to many parts of the EDA flow. But not all.

Cloud Computing Adoption Drivers

Above is the start of a model that could help us understand if there is indeed a path towards Cloud Computing and what the environment would have to look like to get us there.

“Trust” has not been called out separately. In reality, “Trust” is a nebulous combination of all of the above factors and is individual to the specific potential user. The added mystery ingredient being, “who else is using it?”. (Consider the psychology around the use of credit cards on the web in the mid-90’s or the adoption of an IP core.) The other aspect that could be added is “Robustness”. Maybe that driver is significant enough to have its own representation, but for now I’m considering it within “Performance”.

Business Model

This is where it really all starts. If vendors and users were perfectly happy with the current business model within EDA this conversation would never likely arise. However, as has been brought into stark relief recently, the business model could well be the largest challenge that the EDA industry faces today. Above and beyond moving to the next process node.

This can be broken down to two aspects:

1. Revenue generation
2. Cost of sales

Though large EDA vendors have revenue streams to protect, they are constantly pressured to reduce costs. Even with a focus on just the top “10” or “20” semiconductor vendors, there are design centers spread all over the world that need technical support and training. To put an AE on a plane or ship out lap tops for training is expensive. Also, Webex-like tools have limitations that impact the usefulness of online tutorials and training. Especially across time-zones.  Users need to have access to the tools themselves - not just be shown them.

The change in business model for a large EDA vendor would be a significant inhibitor to moving to a cloud computing SaaS model. However, as mentioned later, the move beyond EDA to become a “development infrastructure” provider could be an attractive way to look at the problem differently and stimulate growth.

Alternatively, this could be a business model to support infrastructure partners, such as design and verification service companies. By providing their tools as a SaaS (is this “TaaS” – Tools-as-a-Service?) to these partners would encourage proliferation into the service provider’s clients and also lower the overall costs to the partner directly.

Smaller companies have both the cost and the revenue generation challenges. They cannot afford to put in place a large sales team to penetrate a global market. And they’re also open to trying new business models as a means to differentiate and compete.

For medium to small EDA vendors the benefits are clearer. The SaaS model not only enables a smaller company to compete with the large vendors on a new front, it enables them to overcome sales resource limitations. By providing their products via the web instead of directly, a small EDA vendor can now serve the global market without building an expensive sales team.

The bottom line - a requirement to improve ROI, regardless of size.

Cost

I wonder what the percentage utility of the servers in the data centers of large semiconductor vendors is? I would bet that it’s pretty bursty over time and on average fairly low. (Anyone got any data?)  If they’ve employed virtualization, utility would have increased significantly, but it’s still a burdensome cost.

Building and maintaining sophisticated server farms is an expensive proposition. Importantly, across the industry it represents gross duplication of investment that does not lend itself to a semiconductor vendors core value proposition. This makes it a prime target for outsourcing to a specialized outfit that can amortize overall costs across multiple customers. Thus reducing the total cost of ownership to individual semiconductor vendors.

An additional benefit to moving EDA flows and their accompanying hardware into the cloud is the conversion of a capital expenditure into an operational one. Acquisition of a service is more streamlined, cheaper and flexible. This would be extremely attractive to start-ups and provide a cost effective method for EDA companies to support them.

Of course, challenges exist for an EDA company to offer their tools via the cloud and to take on additional costs. However, this is an opportunity to differentiate and provide more value to their customers. To move from a tool provider to a “development infrastructure” provider.

One more benefit would be the potential to reduce product development costs. Moving product deployment to a SaaS model would mean that all users are using the latest revision of a tool all at the same time. Upgrade control would be in the hands of the vendor. This would reduce the cost of tool maintenance that would increase the overall efficiency of the industry.

In essence, the movement of costs and the overall opportunity to reduce them provide opportunities and benefits to both EDA and semiconductor vendors alike.

Performance

Performance requirements can drive a tool to or from the cloud depending on the use model and the application itself.

Tool Use Model

Tools that are used continuously with tight iterations may need to stay “local” for a while depending upon their resource requirements. “Bursty” use-models (eg. regression testing) and developments that are stretched geographically would lend themselves to a transition to the cloud.

Some EDA tools are extremely resource intensive. In the past processor, memory and hard-disk requirements would have presented a significant challenge. However, there are infrastructure services available that could accommodate many tools out there.

The challenge that would slow down some applications making the move is bandwidth and latency. For example, interacting with 3D representations of a stacked die would be annoyingly slow when compared to a local application.

However, performing design verification should be straight forward and in our opinion is an application area ripe for transfer to the cloud.

Many engineers are already using VNC to connect to remote servers hosting tools. Many tools are operated in batch mode from scripts and after set up and test are not actively interacted with by the engineer. These types of use-models do lend themselves to transfer to the cloud. Compute intensive applications however, will keep some tools local.

A significant aspect of performance is continuity of service. Service guarantees built into license agreements will be needed to move cloud computing beyond the early adopter phase.

So, depending on the tool, this driver can go either way right now.

Security

This is likely the biggest hurdle to the adoption of cloud computing wholesale. The transition to the cloud will be largely dictated by the degree of actual and perceived exposure and the associated cost-benefit.

Releasing fundamental intellectual property outside of a semiconductor vendor’s “walls” will take the building of tremendous trust and the accompanying legal and technical infrastructure to support it. However, I know of large semiconductor vendors that are already allowing IP onto their supplier’s servers. In particular in the verification domain. It won’t be the whole chip, but it will be individual cores or small “tiles” (sub-systems).

The transition will continue over time and at different rates, but this obstacle is not insurmountable.

So, in summary, there are four main drivers that either accelerate or slow the transition of tools to the cloud. It is because it is not clear-cut and that there are opportunities to compete, reduce costs and create efficiencies that the transition has not only started, but it will continue.

In the next post we will discuss a different way to look at the adoption of cloud computing and SaaS by EDA vendors.  A potential cloud computing adoption roadmap for electronic design.

Posted under Features, Xuropa, business, industry, marketing

Cloud Computing and SaaS (Software-as-a-Service) have been at the heart of the vision of the Xuropa Platform from the very beginning…on the proverbial napkin back in May, 2007. It’s current incarnation is captured with our Online Lab facility, and our development progress is metered by the adoption rate of key concepts by the electronic design industry.

This first post in a series of 4 was spurred by Daya Nadamuni’s article in EETimes.com and many conversations with a huge proponent of Cloud Computing and SaaS for EDA, Harry Gries (aka The ASIC Guy). I thought it was time that I took a crack at articulating how I see this technology evolution and it’s application and adoption within the electronic design industry.

Definitions

As with any “next big thing”, the definition of Cloud Computing will evolve over time as it’s better understood and the software industry moves the ball forward. However, it’s important to note what Cloud Computing is not. As we saw within EDA and the stretching and pirating of the definition of “ESL” in the early days, it’s important to have a common understanding.

Wikipedia offers a pretty good and comprehensive description and definition of Cloud Computing.

I’ve paraphrased points here for convenience.

What it is not:

- Grid Computing: “The application of several computers to a single problem at the same time.”

- Utility Computing: “The packaging of computing resources, such as computation and storage, as a metered service similar to a traditional public utility.”

- Autonomic Computing: “computer systems capable of self-management, to overcome the rapidly growing complexity of computing systems management, and to reduce the barrier that complexity poses to further growth”

It’s a little tricky, because as is noted in the Wikipedia entry, “many cloud computing deployments are today powered by grids, have autonomic characteristics and are billed like utilities, but cloud computing can be seen as a natural next step from the grid-utility model.”

Cloud Computing Components

I’m a huge fan of models like the OSI Seven Layer Model, and the Wikipedia editors of the Cloud Computing entry have taken a shot at capturing a hierarchy of its components. I’m not sure I completely agree with this model yet, but it’s a good start.

Cloud Computing Stack

Client: self explanatory. The combined device and browser system.

Services: These are support services intended to be used by Applications. Eg. Google Maps and PayPal.

Application: Software applications that are accessed via the web and leverage cloud infrastructure. Peer-to-peer (Skype); web-based application (Facebook, Xuropa (networking, news, and other applications) ); SaaS (SalesForce, Xuropa (Online Suite, Booth, and Kiosk); software+services (Microsoft Online Services)

Platform: A software application delivery environment. A key differentiator between a Platform and an Application is the degree of openness. In the case of Facebook Apps, the API is open and is written to by third parties who then have their application delivered to users within the Facebook environment. In the case of a Xuropa Online Lab it does not make sense to create an API for software vendors to write their tools to. And so we took the “API” down to the logical level – the Operating System.

Storage: Remote storage that is made accessible via the web and charged as a utility. Pay as you go/use. Eg. Amazon S3 (Simple Storage Service)

Infrastructure: Essentially the hardware resources and utilities to manage and make upper layers of the stack available via the web. Eg. Amazon EC2 (Elastic Compute Cloud).

Another example may be illustrative:

A database accessible via the web can be presented in three different ways to users.

• Raw database that is accessible via the web: Application
• Database with a UI (eg. Salesforce): Application
• Database with a macro API that can be written to and the resultant applet/macro/widget hosted and accessed by other users of the database: Platform

Adoption By Electronic Design: Where are we?

As can been seen from reviewing the above model, aspects of Cloud Computing are being used by the electronic design industry today: webex, Skype, salesforce.com, etc. But these are support services in the context of the EDA industry.

The rest of this series discusses the use of Cloud Computing and SaaS at the heart of the EDA business: delivery and monetization of electronic design software applications via the web.

99% of people in the industry to whom I mention Cloud Computing state with great conviction that it will never happen - “it’s been tried before”. And if they’re anticipating a step-function adoption that will stretch across the entire flow and be able to serve mainstream semiconductor vendors from the start, then they’re probably right. But that’s never the way things happen.

[“All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.” -- Arthur Schopenhauer]

A common theme that recurs across these conversations is “trust”. And as with any new dislocating technology, this is a major hurdle to mainstream adoption.

So, regardless of all the buzz out there, this is where I think we are today:

Cloud Computing Technology Adoption Curve

So far, not very far.

The next post in this series will address The Drivers of Cloud Computing Adoption.  What industry components make cloud computing and SaaS attractive, and what would potentially slow adoption down.

Part three of the series presents a potential roadmap of cloud computing adoption for electronic design.

Posted under Features, Xuropa, business, industry, marketing