Cloud securityToday’s cloud market is hard to estimate and depends a lot on the analyst. One report predicts that the global cloud computing market is expected to grow from $37.8 billion in 2010 to $121.1 billion in 2015, with SaaS (Software as a Service) contributing for three quarter of this market. Regardless of the actual size, cloud computing means to commoditize processing power, leading to economy of scale and flexibility.

I wrote, like many others, that cloud-based EDA solutions are inevitable: there is no magic algorithm that will reduce the ever-increasing complexity of designing and verifying a digital device (FPGA, ASIC, or SW/HW co-design). The only way to keep pace with the complexity is massive parallelism.

Some claim that EDA is not ready for cloud computing because it requires a lot of CPU power with very fast access to a massive amount of data. That is because EDA tools have not been designed to take advantage of very large clusters of machines with a relatively low bandwidth network, each machine having a fraction of the data. It will not be long before tools are re-architected for that purpose. E.g., physical and logical verification are the most obvious candidates to benefit from partitioning techniques and to become SaaS in the cloud.

The other obstacle to EDA in the cloud is not specific to EDA: security is the most cited reason to explain the resistance of potential customers. Semi conductor companies and design houses are reluctant to let their sensitive data go into a cloud they feel they have no control of.

These are the typical questions when security in the cloud is raised:

  1. Who has privileged access to the data?
  2. Which data encryption is used, and how are managed the keys?
  3. Where is the data located?
  4. Is the data segregated from other customer’s data?
  5. Can the data be recovered in case of disaster?

The relevance of (1) and (2) is no different than when the data is managed internally. Topics (3) and (4) come up when customers feel safer with a precise hosting location, or by excluding some location (e.g., some foreign country). However the principle of data fragmentation hosted in different, non-predictable locations, makes the whole data safer, because breaching one or more data center is not sufficient to rebuild the complete file. This also answers question (5): assuming the complete loss of a few data centers, it is possible to reconstruct the whole data thanks to fragmentation and embedded redundancies hosted in the other data centers.

Customers will feel more confident if these questions are clearly answered by providers, and if independent security audits assess the quality of the services. Also the definition of widely accepted security certification would help the adoption of cloud services.

The reality is that cloud services, as other IT services, are the target of thieves and spies. There have been and there will be well-publicized security breaches in clouds (Gmail, Twitter), like there are many told and untold intrusions in private networks. I think it is misleading to believe that hosting one’s data in one’s own facility is any safer than relying on a well-vetted cloud: most of the cloud providers will be better at security than customers will ever be.

Tags: , , ,

14 Comments on EDA in the cloud: shall we be scared?

  1. I received a letter in the mail the other day from a former health insurer of mine (HealthNet) that informed me that the disk drives with my personal information were missing from their IT provider (IBM). Ultimately, nothing is 100% safe. Not data storage, not driving a car, not even walking down the street.

    It comes down to a tradeoff between convenience and cost vs. risk. Each company will have to make that choice based on their personal POV. Smaller companies with less to lose will be first, followed by the mainstream.

    Which brings up an interesting thought. Most of the discussions I’ve seen regarding the cloud for EDA seem to phrase it as an all or nothing proposition. In fact, the same old technology adoption curve applies to the cloud for EDA as for any technology. There will the the bleeding edge, followed by the early adopters, and eventually the mainstream. We’re at the early part of the curve still.

  2. Harry, I could not agree more. This is a trade-off between risk and benefit. Once people will come to realize that you cannot remove the risk entirely, they will come to accept the risk that comes with operating in the cloud. In many ways it is no worse than having your own IT with hundreds of people that can access sensitive data from the inside.

  3. Girish says:

    As you say we need massive parallelism. But most of the cloud systems are CPU based. They dont make use of other super parallel hardware like GPU and IBM cell processors which provides more performance/watt and performance/$$. I can get a 1600 core ATI GPU for 500$s. With assistance of such hardware I can get the same or better performance in my laptop compared to a high end CPU server. The catch is its hard to map all the problems to the way GPU likes.

    In the ideal world there should be a framework like map reduce where user can express the problem in terms of split and merge operations. User doesn’t care what hardware is available. The framework transforms the user code to OpenCL code that runs on all the heterogeneous parallel hardware available in the machine.

  4. Joao Geada says:

    I’d go further: you don’t have to move into the cloud in one go. You could start using the cloud to offload peak demand, thus allowing for optimization of your existing infrastructure without any loss of capability when the need arises.

    Or sometimes this particular task needs to be done *right now* and it can be a life saver to on-demand be able to deploy a couple hundred extra CPUs for an overnight run.

    But all this does require that EDA vendors be ready to provide

    a) licensing models that permit this, with predictable cost structures.

    b) software architectures that can harness this scaling in available CPU and/or servers to deliver faster/better results to the user. This requires addressing both computational loads as well as potentially dealing with distributed data models.

  5. Hi Girish,

    This is a good point. For now you can use such HW and get some significant speedup, but (1) will that scale with the size of the problems?, and (2) can you tackle every EDA tasks that way? Question (1) is still unclear, and I would argue that the answer to (2) is a definite “no”. There is still much to do before costly design and verification tasks are redesigned to fit a massive parallel framework. Note that how fast you can move data from one node to another node dictates a lot of the end architecture.

    For the most part EDA has been looking at parallelism as an extension of multi-threading: lots of CPUs, everything in RAM (meaning, very fast access to data). This is no longer true, and I have personally seen some very well known EDA tools choking on the latest designs because they couldn’t even fit on a 18Gb or 24Gb RAM 64-bit linux machine! The future, besides trimming memory to the bone and using fast compression/decompression techniques, is to design tools so that they assume upfront some upper bound on RAM, and a lower bound on loading data chunks in RAM. This will change some tools quite radically –think about synthesis and timing.

  6. Hi Joao,

    Yes, you are right, it requires EDA vendors to work out a licensing model that makes sense for the cloud. Only using the number of licenses necessary to run on large clusters will be a thing from the past. EDA vendors need to price the service in terms of CPU/h, storage utilization, and TAT. I hope this will lead to creative business models that will be attractive for customers and make EDA vendors stronger –it’s all about the value that is provided.

    As for SW architecture, please see my comment above: we are still a long way from it, but this should boost EDA innovation quite a bit.

  7. Joao Geada says:


    Don’t judge EDA architectures just by what you see coming out of the big players; us smaller players are not handicapped by legacy systems and have been able to do a fair bit of innovation in this space, resulting in architectures and systems designed with multi-cpu clusters in mind, whether those CPUs are all local to a machine (threading) or spread around (distributed). Yes, it requires having a different type of database underpinning the tools and a different approach to managing data.

    The fundamental idea is that each work unit has a some chunk of data that it needs to operate on; only that data needs to live together with the CPU that is doing the work. Everything else is managing the movement of work/data around the system safely and efficiently. An interesting perspective on the types of things you need to be aware:

  8. Hi Joao,

    Having startups venturing into the cloud is good –after all, the purpose of a startup is to go where the establish players don’t. However given the means of a Synopsys or a Cadence, I am surprised that they do not go aggressively into exploring cloud-based solutions, which require, as you note, a rethinking of those tools used for synthesis and verification (for logic, timing, SI/power, and physical). Good for startups I guess, even though finding VC money in EDA is pretty challenging.

  9. Liz says:

    Olivier –

    I agree that security is a stumbling block for many. It is for me. But there is also the question of convenience. Will the customer want to commit the extra time and effort, as Tom Kozas points out in this interview?

  10. […] reading a post by Olivier Coudert, I decided to provide a high-level description of some of the main techniques used to secure a […]

  11. Thanks for another interesting post Olivier. Good discussion. Your points about the constraints that the size of RAM place on tools are real game-changers. Not just for using tools, but how about demonstrating them? Or training customers on using them? You can’t build an AE’s laptop the same way you can build a server. Clearly, when it comes to compute, we’re well into a period of flux.
    Back to security, your list of questions is very useful in framing the conversation. Breaking out the different points of the problem (the client, the cloud, the network) I’ve described some of the common techniques that have been used for years to secure clouds and access to them:

  12. Hi James,

    Thanks for sharing Xuropa’s real-life experience regarding security, I recommend people to read this post.

  13. […] considerations in this very complicated topic. Some recent discussions (on Olivier Coudert’s blog, for example) are insightful and valuable. Some recent articles, well, not so […]

Leave a Reply