With a compute farm, you have a fixed amount of computing resources. You rely on an engine like LSF (Load Sharing Facility) or SGE (Sun Grid Engine) to schedule and prioritize jobs to best use these fixed computing resources. The rule of the game is to keep the queue as short as possible, or better, to keep the relative processing time increase as small as possible.

Clearly having access to hundreds of compute nodes (or instances, to use the cloud terminology) on demand changes the game of parallel computing entirely. In the word of cloud computing, using 100 instances for 1 hour costs the same as using 1 instance for 100 hours (a bit more than 4 days). Assuming you can borrow as much as you want and that you can keep all the instances busy, there is no point in limiting the computing resources: the cost will be the same, but the wall time will be reduced.

Of course, this is more complicated in practice. You are billed by the hour. Thus starting a new instance to process jobs is wasteful if that instance is not fully utilized during a whole hour. Also starting or shutting down an instance takes a few minutes, during which that instance is unavailable. Thus you must be able to anticipate the upcoming job distribution and have a clear pictures of the instances’ load and how long they have before their hour expire to decide whether you should:

• Start a new instance to process jobs;
• Shut down an instance before being charged another hour;
• Queue a job.

You also want to account for hardware failures, which is more likely to happen if you have many instances for a long time. Also inter-instance communication, if needed, can become a major bottleneck in scaling up –unless there is a 10Gb network available.

The cloud has an appealing message –borrow when you need it. It is a paradigm shift for parallel computing. This means moving from “managing resources” in a compute farm to “managing cost” in the cloud. As explained above, managing cost in the cloud is substantially more complicated that scheduling jobs on a compute farm. Yet cloud computing gives the flexibility to design strategies that reduces wall time and keeps costs low. It will only benefit customers: borrow more for less time, pay the same, and get the result faster.

Related posts:

1. Cloud computing: an opportunity for EDA
2. Synopsys is getting into the cloud
3. Why EDA in the cloud will come from startups

But this is a hard step. There are many obstructions to viable cloud-backed EDA solutions:

• Both customers and providers of EDA are conservative communities. They are usually slow to adopt new technologies. The semiconductor industry is reluctant to invest in new design frameworks, as its wants to preserve its investment in working flows.
• Security remains a hot issue. EDA vendors want to control the usage of their tools, and they are uncomfortable making them available in a public cloud. And the EDA customers are paranoid about their designs slipping out in the wild.
• Massive parallelism is great, but data transfer via Internet is slow. Because some tasks require moving huge amount of data to and from applications, it is better to host the design data in the cloud for the whole design lifetime. This requires a drastic different mindset for project managers.
• The current TBL (Time-Based License) model makes no sense with massive parallelism. We need new business models based on actual usage (per hour, day, or week) to unlock the flexibility and scalability offered by cloud computing.

The big EDA companies have been slowly espousing the idea of making their tools available in the cloud. Cadence set up a (private) cloud offering a while back, but it has never been successful. Synopsys announced in March that it would provide a cloud computing solution for VCS simulation with AWS (Amazon Web Services). We will see how it unfolds.

Meanwhile, startups have been testing the water. Xuropa hosts demos and a CRM platform in the cloud, and counts Cadence and Synopsys as customers. Plunify proposes FPGA synthesis with multiple runs in the cloud. Nimbic (formerly known as Physware) uses the cloud to develop and deploy its tool. Same for Tabula (although in a private cloud). Xuropa, Plunify, and Nimbic are now making claims about moving other EDA applications in the cloud. And more stealth startups are working on their own solutions.

This is good news. Big EDA companies encounter many internal resistances to moving to the cloud: “this requires costly technical expertise”; “we cannot secure the usage of our tools”; “this is not our core competency”; “we will cannibalize our traditional TBL business and loose money”; “no customer is willing to put his data in the cloud”; etc.

These concerns are legitimate. Transitioning a +20 year old business to a pay-as-you-go model is a daunting, if not scary, proposition for well-established players. Also using cloud technology is much more than high-octane IT. This makes startups the best apt to answer the challenge, evangelize the solutions, and educate the customers. Parting from the TBL business model will take at least that much.

Related posts:

1. Synopsys is getting into the cloud
2. EDA in the cloud: shall we be scared?
3. Cloud computing: an opportunity for EDA

Not such big claim here. This post is simply about a recent experience that decided me to put in practice what I have been praising.

For the past decade I always had several computers at home –two to five Windows PCs, a Mac, and another couple of Linux machines. Very early I was interested in having a storage unit I could share on my LAN between all my computers. Having one central unit to archive, backup, and serve medias (pictures, music, video) is pretty handy.

Back in 2004 I bought a 250Gb Ximeta Netdisk. Technically it is not a NAS (Network Attached Storage), as you have to install a small program on every computer you want to access the disk from. But the device worked just fine, and it still does. Later in 2007 I upgraded to a real NAS (i.e., using TCP/IP for all communications with the devices on the LAN) for my storage needs with a 500Gb LaCie Ethernet Disk mini.

Soon I placed all my data on my Lacie drive: email, business related documents, publications, presentations, C/C++ and Java code, tech articles, books, tax declarations, music, photos, etc. A few days ago, after 4 years of good service, the drive quit on me: it just ceased to power up. Since I had 260Gb of data on that disk, you can imagine my reaction. “Do not panic. The disk itself is fine. It’s only the drive mechanism or the controller that is fried”.

Here is the email exchange I had with Jon L. from Lacie’s support:

Jon: “[…] according to the serial information, the drive appears to be past the two-year warranty. […] Although the drive is no longer serviceable by our repair department, we strive to provide all of our customers with a positive experience with our service and products. LaCie would like to offer you a discount on a replacement product.”

Me: “Nice thought. But what about my data?”

Jon: “[…] a qualified technician may be able to replace the failed internal drive and reconfigure the unit to accept the new drive.  […] We can not assist with this third party repair process.”

Me: “The most important part for me is to retrieve the data stored on the drive. It looks to me that the disk itself is fine –the electronic and control part just stopped to function. Do you provide data recovery service?”

Jon: “Pricing is simple:

• Single drive recovery, no clean room = $399
• Single drive recovery, requires clean room = $1299”

Me: “Ouch!”

So retrieving my data via this service would cost about twice as much as what I paid originally for the disk four years ago. Come on, for $399 I can buy a brand new 4Tb RAID-1 Gigabit Ethernet NAS from Lacie!

The lesson: having a NAS at home is nice to share pictures and music. But if you want to use it as a central repository and backup, you need to think about what happens if that unit fails. Sure, you can use another disk to mirror the backup. Or use a RAID-1 disk, which adds redundancy for higher reliability. But it became clear to me that I was ready to put in practice what I have been advocating for the industry: use the cloud.

Don’t get a backup for the backup, just put the data in the cloud. Then you can always access it –instead of carrying around an external hard drive, as I used to do. Use a service that guarantees replication and redundancy to preserve the integrity of the data, even in case of catastrophic event (e.g., the recent hurricane on the east coast that flooded a few hosting data centers). Encrypt the data at the source, so that nobody but you can read the data.

Eventually I recovered my data for $99 (a fourth of the price Lacie quoted to me) at a computer repair shop in Mountain View. Since then I have been hunting for some cloud data service. I will share my findings and my experiences in a couple of weeks.

Related posts:

1. EDA in the cloud: shall we be scared?

Amazon released a full description of what happened. In a nutshell, Amazon shifted traffic in one of its zones from one network to another in order to upgrade a network. The traffic was mistakenly shifted to a lower capacity network, which was unable to handle the traffic. This caused Amazon EBS volumes (Elastic Block Store, a persistent storage unit for database and file system) in one US East Region zone to become unable to perform read/write operations.

Besides the many websites taken down during the outage, it turned out that 0.07% of the data stored in the EBS volumes in one zone have also been lost. Chartbeat reports losing 11 hours of historical data to their customers saying it is ‘irrecoverable’.

Since then a lot has been written about the dangers of the cloud. It looks like Amazon’s outage brought weight to those opposing security concerns against EDA’s cloud aspirations. What to think of Synopsys’ recent announcement that they will provide SaaS in Amazon Web Services?

But many companies that are entirely relying on Amazon’s cloud services were not significantly affected by the outage. Twilio did not shut down. And more notably, Netflix, which runs its massive infrastructure entirely in Amazon’s cloud, did not shut down.

Why were some websites taken down while others were unaffected? Because some systems are designed to be resilient to all sort of failures. Taken from Netflix’ experience when moving its infrastructure to AWS:

“One of the first systems our engineers built in AWS is called the Chaos Monkey. The Chaos Monkey’s job is to randomly kill instances and services within our architecture. If we aren’t constantly testing our ability to succeed despite failure, then it isn’t likely to work when it matters most – in the event of an unexpected outage.”

In short, being in the cloud does not mean you are inherently safer or more exposed. It means that you have to design your system so that it can recover from defects –any defect. From G. Reese in O’Reilly:

“If your systems failed in the Amazon cloud this week, it wasn’t Amazon’s fault. You either deemed an outage of this nature an acceptable risk or you failed to design for Amazon’s cloud computing model. The strength of cloud computing is that it puts control over application availability in the hands of the application developer and not in the hands of your IT staff, data center limitations, or a managed services provider.”

And I’ll stand by this too.

Related posts:

1. Cloud computing: an opportunity for EDA
2. Synopsys is getting into the cloud
3. EDA in the cloud: shall we be scared?

I wrote a few posts on EDA and cloud computing –the latest was as recent as last week, where I posted about security in the cloud after a thread of comments on a previous post–. Bottom line was, EDA in the cloud will happen, because it’s a necessity.

Today, Synopsys announced that it will use AWS (Amazon Web Services) to provide a cloud computing solution for VCS simulation. Synopsys is not the first big EDA player venturing into cloud computing –Cadence already did–. But as the market leader, Synopsys sends a strong signal to the EDA community and its customers: EDA SaaS (Software as a Service) in the cloud is about to get very real.

Just need to figure out a good business model…

Related posts:

1. Cloud computing: an opportunity for EDA
2. EDA in the cloud: shall we be scared?
3. Why Synopsys buying Magma is good

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.

Related posts:

1. Cloud computing: an opportunity for EDA
2. Synopsys is getting into the cloud
3. Plunify, a glimpse at EDA in the cloud

ASIC and digital system design is a computing resource-hungry task that would certainly benefit from cloud computing. Still, EDA is mostly staying on the sideline while so many other industries are rapidly shifting towards cloud-based platforms.

Granted, there have been a few incursions of EDA into the cloud.

Synopsys and other EDA vendors have been using Amazon Web Services (AWS) to provide web-based training services. Both Synopsys and Cadence now prefer Xuropa as a web-based training platform, because Xuropa offers a service more tailored to EDA needs (e.g., input/output languages and format).  These services are Infrastructure as a Service (IaaS), i.e., it gives the customer the ability to use processing, network, and storage resources in a flexible manner.

Physware and Plunify are two startups sitting firmly on the cloud-based Software as a Service (SaaS) side. Physware simulates an IC with a true 3D field solver, providing signal integrity, power integrity, and electro-migration analysis. Plunify runs multiple synthesis scenarios to offer a wide area/performance tradeoff to the user. Both use cloud computing to offer a very short, scalable, turn-around-time to their customers. Cadence also has its own cloud-based SaaS offering, with mitigated success so far.

Oh yes, and IBM has been using cloud computing for its own EDA tools for years –with more than 20,000 cores, 150 Tb of memory, running 40,000 jobs per day.

But where does that leave the big three, Synopsys, Cadence, and Mentor, as provider of EDA solutions in the cloud? For instance, physical verification is known to be very tolerant to design partitioning, so a number of physical verification tools can easily take advantage of cloud computing. Logic simulation can also benefit from massive parallelism, even though it is more challenging –partitioning a test bench is trivial, but taking advantage of a design partition for logic simulation is tricky.

It is not like the Big Three do not know what is at stake: unless there is some revolutionary technology in the making, the largest SoC will simply exceed the capacity of today’s synthesis and verification tools. Which means that the semiconductor industry should be eager to access cloud-based SaaS. However there are a few obstacles on the way:

• Tools needs to be revamped to fit the cloud infrastructure. For verification and simulation, this is not a major bottleneck though.
• It is unclear what will be the business model of a SaaS EDA in the cloud. But this is a chance to propose new models that would lift the EDA market. Shall we charge by CPU/hour plus bandwidth? Or by the TAT reduction (the more servers, the smaller the TAT, the higher the fee)?
• Last but not least, security is a major obstacle for design houses to let their IP go into the cloud. But those that express their concerns about security are the same that have a private email in the cloud (Yahoo email, Gmail, Hotmail) and go happily shop on-line. Also data are arguably more reliable in the cloud because of the inherent redundancy required by fault-tolerant platforms.  With time people will come to accept that the cloud is secured enough.

Given that the cloud infrastructure becomes more mainstream thanks to the many open-source resources and accumulated experience in many industries, it is just a matter of time before EDA and its customers are serious about cloud-based SaaS. Let’s just hope that the EDA companies will size the opportunity to reiterate itself as a major enabler of the semiconductor industry, and to propose a new business model that would benefit the industry.

[UPDATE: follow-up post on security and the cloud]

Related posts:

1. Cloud computing is not grid computing
2. EDA in the cloud: shall we be scared?
3. Synopsys is getting into the cloud

Plunify’s motto is to simplify the FPGA design process. The founders’ claim is that there are too many, somewhat disjointed steps, to produce an operational FPGA: synthesis, IPs, place-and-route, testing, debugging, many steps which yield much iteration before reaching the desired performance trade-off. That is not including the hassle to install and maintain the software, as well as the hardware resources. Last but not least, it is difficult to compare performances for multiple devices across multiple FPGA vendors –and device price should eventually be part of the trade-off picture.

Plunify aims at making FPGA design as simple as possible. Its use of Amazon’s cloud infrastructure results in a platform that abstracts unnecessary details away from users. Using the cloud also significantly speed up synthesis and place-and-route for multiple trade-offs. Plunify’s current beta platform supports Altera and Xilinx, as well as two open source simulators, Icarus Verilog and GHDL.

Plunify is currently offering three different packages: Walk, Run, and Fly. Each package includes 750 hours in the cloud (this is one full CPU time month), with full access to Xilinx and Altera devices and IPs. CPU speed, RAM and disk space increases with the level of the package, starting at 1.7Gb RAM and 1Gb disk space with “Walk”. Although pricing is not fully frozen, the base “Walk” package should be available for around $350 USD. Given the service it provides, this is a very compelling value.

Plunify is currently working on new features. One consists in allowing the user to input a range of timing constraints to let Plunify’s cloud-based platform explore these optimization scenarios in parallel, which will come up with optimum solutions in a fraction of the time an iterative flow would take. Another is to enable online collaboration and version control for round-the-clock, distributed design teams.

Granted, automatically exploring a range of timing constraints in parallel is not totally new. Both Xilinx and Altera, as well as some EDA vendors, have works in progress in that area. But Plunify pushes automation and ease-of-use way further: on-line, vendor agnostic, diligent performance tradeoffs delivery. When it comes to being in the cloud, security is design houses’ top concern. Plunify uses SSL for all communication to its website, and it uses the proven and pretty much de-facto standard Amazon S3 for storage. Still I anticipate that security will be one of the major hurdle to Plunify’s success. The next year will show how Plunify is received by the FPGA design community. Personally, I like to think that Plunify is a hint at the future of EDA: online, streamlined, and in the cloud. And of course, a totally different business model.

Related posts:

1. Cloud computing: an opportunity for EDA
2. EDA in the cloud: shall we be scared?
3. Synopsys is getting into the cloud

Instead, I have chosen to share my absolutely non-exhaustive, completely biased view of DAC. I will then publish a couple of posts focused on specific themes in the next few days.

Attendance

The 47^th DAC was held June 13-18 at the Anaheim Convention Center in California. The preliminary attendance numbers are reported as follow:

• Total full conference: 1554
• Total exhibit attendees: 3444 (24% international)
• Exhibitors, visitors, and guests: 2557
• Total attendees: 6001

The final attendance numbers are usually a few percent higher.

For a fair comparison, I pulled out the preliminary attendance numbers of the past conferences. I was first fooled by the way the numbers were labeled this year –see the comments below, and a big thanks to Sean to bring me the correct interpretation. The table below shows the correct data, excluding booth staff. It shows a sharp decline (33%) of the total attendance compared to last year in San Francisco. Not having DAC in San Francisco means higher cost for most of the attendees –many of them are from the Silicon Valley–, which is clearly reflected in the attendance numbers.  But if we compare this year’s numbers with the 2008 DAC venue held at the same location, we see the same sharp decline (28%). Note the drop in exhibits-only attendees (-41% w.r.t. 2009, -21% w.r.t. 2008), not a good sign as this number captures most of the customer audience.

DAC preliminary attendance numbers (not including booth staff)

This year’s DAC comes after one of the worst recession, but looking forward to a very strong semiconductor growth in 2010 and 2011, which should eventually translate into a mildly better business for EDA. The exhibition was well attended on Monday, with a sharp decline on Wednesday –lots of people left by that time.

The buzz

With Cadence’s EDA360 campaign in the background, and the fresh acquisitions of Denali by Cadence and Virage Logic by Synopsys, it felt that IP was the buzzword of the day. IP design here, IP verification there, verification IP everywhere, the overall SoC design looked like an IP integration problem that EDA was gearing up to take on. Embedded software and ESL were also showcased by Cadence and Mentor Graphics as part of their SoC focus.

Verification

There was a booth dedicated to UVM/OVM (Universal Verification Methodology/Open Verification Methodology). These methodologies offer open and interoperable verification solutions. They both support multiple languages and simulators, and enable verification IP, so critical to SoC design. The message was well received and had a strong attendance.

Still on the verification side, new products and startups are trying to repeat the success of Certess (acquired by SpringSoft last year). Advanced formal verification tools (e.g., property checkers) are slow to find acceptance by the design community. Instead these new products and startups leverage the existing test bench and simulation methodology in place to produce better coverage or faster simulation. Notably missing in this space was NuSym, a no-show at this year’s DAC, confirming the rumors that the startup that demonstrated “intelligent” simulation two years ago is actively looking for a buyer.

The whole simulation and emulation space was strong. Mentor’s Veloce is showing impressive numbers, and is ready to take on Cadence’s Palladium. Eve will likely take notice, and this may bring it closer to Synopsys.

Magma’s Tekton offers sign-off quality multi-mode/multi-corner static timing analysis for multi-million gate circuits. The tool has been designed from the ground up, and tailored for multi-threading and distributed systems. It is a clear competitor to Synopsys’ PrimeTime, even though running PrimeTime *is* the signoff for most customers.

Design and implementation

On the P&R and backend side, nothing really stood out. Synopsys clearly gained in QoR, Mentor’s momentum with Sierra’s Olympus is still strong, and Magma keeps lagging behind, especially in runtime. Atoptech and Azuro, although showing pretty good numbers (verified at customers’), are still considered more like add-ons that comprehensive solutions. This segment looks more and more commoditized, and only the high-end (20nm and below) and 3D seem to offer new growth opportunities in that space.

Oasys, the darling of last year’s DAC, did not make as much as a splash this time, despite its recent announcement with Juniper Networks and Xilinx. Nobody question the speed and capacity of their tool, as well as the clock cycle it can achieve. But some raised concerns regarding the area of their netlists for ASIC.

On the fringe

This is the “stuff I liked that may be too small to be noticed”, even more so since two of these three companies didn’t have a booth at DAC…

Low power is still under-represented, even though power gets worse with smaller geometries, and power management remains mostly a very manual process. In that space I liked Docea Power, which can simulate system-level models to analyze power consumptions and thermal behaviors. System-level analysis can bring the biggest power savings. It also has a significant impact on the packaging, which is still a domain where conservative approaches are preferred to more cost-efficient, but riskier, choices.

A comprehensive system-level design framework is really an IDE (Integrated Development Environment) for SoC, where hardware and software can be designed together, written and simulated together, and where the HW/SW tradeoffs can easily be explored. IDEs have been used in software for a long time, but are a novelty to hardware designers. Sigasi proposes an IDE for VHDL –what Microsoft’s Visual Studio is to C++. Although this is still light-years away from a SoC IDE, this is a hint into the future of writing RTL.

We heard several claims that cloud computing is coming to EDA (or the converse?). Xuropa best illustrates that (slow) move. They provide turn-key online community solutions for the electronic design industry. Their main customers, Cadence and Synopsys, are using the services for CRM and virtual demo only. But Xuropa could become a platform that enables collaborative design in the cloud, providing secured access to a multi-vendor flows. More on this in a future post.

Last words

I felt that there was a lot of system-centric messages (best captured by EDA360), and attempts at rising the abstraction level for higher productivity. EDA vendors are forced to see the big picture –full system design, software and hardware together. But as pointed out by Steve Jones (TI) at Cadence’s Silicon Realization Luncheon, EDA is still missing out on two important parts of the SoC design. One is that customers want a first-silicon that is functionally operational, and Steve singled out the need for useable verification IP –UVM/OVM is a step in the right direction. The other is analog –mixed-signal design is the rule, and there is no good integration there.

No related posts.