Cloud Computing Adoption Roadmap for Electronic Design
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.
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.
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.
In the next post in this series we’ll look at different approaches in the transition to cloud computing and SaaS for electronic design.
Connect with me:
This post was written by James Colgan on December 11, 2008