Commentary
SoC realization: Finally the “Killer App” that will allow EDA to grow again?
Ajoy Bose
5/11/2011 4:46 AM EDT
The sweet spot of EDA growth
Today, I see two general areas where significant growth can come from in EDA:
1) Comprehensive support for the use of semiconductor IP as a new and higher level of abstraction for the design of a chip. Moving to a higher level of abstraction is a proven approach to manage complexity and cost, and cost is a significant challenge for advanced designs, see Figure 1. History has shown that such shifts always lead to new ideas, opportunities for new players to bring forth creative solutions and an inevitable expansion of the market. At this juncture, moving the use of semiconductor IP, either 3rd party or legacy, into the mainstream of chip design through efficient, easy to use and robust design techniques will have the same impact as a significant increase in the level of abstraction. The availability of diverse IPs on a large scale, their impact on improving design efficiency and the benefits they bring to architectural reuse and the creation of platforms and derivatives makes this an obvious winning strategy.
Figure 1: Rising cost of advanced IC development (Courtesy Gartner)
Both of these requirements are tied to and being driven by the continued adoption and evolution of SoC designs. Although we in EDA have been conversant in the concept of SoC for many years, it is just now truly taking hold in mainstream (read: high growth) markets. SoC is, in essence, the killer app of the semiconductor world, and it will benefit all supply chain members – systems companies, semiconductor suppliers, IP providers and manufacturing specialists. What is also clear is that the potential of SoC lies in the industry’s ability to develop them in a more fluid way. SoC, like ASIC before it, is a business model that allows a democratization for a system company’s access to powerful silicon.
Note: SoC is the new ASIC. It is both a technology and business model. Just like in the 1990’s when ASIC was first being widely introduced by the integrated device manufacturers (IDMs), it was the engine for EDA growth. SoC will be the growth engine for what EDA becomes.
And EDA stands to benefit from that need.
A critical gap exists in today’s SoC development process that threatens to undermine the potential of SoC. On one end, the detailed process for implementing complex designs in advanced silicon is well understood and is served adequately by traditional EDA tools and their tight connection to device physics and manufacturing. On the other end, the process of conceptualizing and analyzing designs at a system level, a high level of abstraction and without the restrictions of physical operating constraints, is also a well-proven, albeit somewhat less rigidly defined area.
Ideally, this system level implementation would be available to software application developers before the SoC is actually manufactured to test and debug the software and uncover any SoC architectural problems. Software is now king and will remain so. The hardware, or SoC, serves the king. As a result, there has been an inversion in the value chain in the last decade from software running on general hardware to software running on specially designed hardware (SoCs) that are optimized for the system software application.
Today, I see two general areas where significant growth can come from in EDA:
1) Comprehensive support for the use of semiconductor IP as a new and higher level of abstraction for the design of a chip. Moving to a higher level of abstraction is a proven approach to manage complexity and cost, and cost is a significant challenge for advanced designs, see Figure 1. History has shown that such shifts always lead to new ideas, opportunities for new players to bring forth creative solutions and an inevitable expansion of the market. At this juncture, moving the use of semiconductor IP, either 3rd party or legacy, into the mainstream of chip design through efficient, easy to use and robust design techniques will have the same impact as a significant increase in the level of abstraction. The availability of diverse IPs on a large scale, their impact on improving design efficiency and the benefits they bring to architectural reuse and the creation of platforms and derivatives makes this an obvious winning strategy.
Figure 1: Rising cost of advanced IC development (Courtesy Gartner)
2) Exploit the growing trend of companies with killer app products to leverage system on chip (SoC) designs as a part of their strategy. There are many examples of this trend, including Apple’s iPad, Google’s Android and even Microsoft’s commitment to an SoC-compatible version of Windows. This trend requires significantly improved SoC design by both the system companies making such products and the semiconductor companies supplying to them. These programs need to meet the significant pressures of integrating diverse functionality with lower cost, power, and design times as well as a fast ramp to volume. These are the typical harsh demands of a competitive consumer market.
Both of these requirements are tied to and being driven by the continued adoption and evolution of SoC designs. Although we in EDA have been conversant in the concept of SoC for many years, it is just now truly taking hold in mainstream (read: high growth) markets. SoC is, in essence, the killer app of the semiconductor world, and it will benefit all supply chain members – systems companies, semiconductor suppliers, IP providers and manufacturing specialists. What is also clear is that the potential of SoC lies in the industry’s ability to develop them in a more fluid way. SoC, like ASIC before it, is a business model that allows a democratization for a system company’s access to powerful silicon.
Note: SoC is the new ASIC. It is both a technology and business model. Just like in the 1990’s when ASIC was first being widely introduced by the integrated device manufacturers (IDMs), it was the engine for EDA growth. SoC will be the growth engine for what EDA becomes.
And EDA stands to benefit from that need.
A critical gap exists in today’s SoC development process that threatens to undermine the potential of SoC. On one end, the detailed process for implementing complex designs in advanced silicon is well understood and is served adequately by traditional EDA tools and their tight connection to device physics and manufacturing. On the other end, the process of conceptualizing and analyzing designs at a system level, a high level of abstraction and without the restrictions of physical operating constraints, is also a well-proven, albeit somewhat less rigidly defined area.
Ideally, this system level implementation would be available to software application developers before the SoC is actually manufactured to test and debug the software and uncover any SoC architectural problems. Software is now king and will remain so. The hardware, or SoC, serves the king. As a result, there has been an inversion in the value chain in the last decade from software running on general hardware to software running on specially designed hardware (SoCs) that are optimized for the system software application.
Operating at these two different levels of abstraction, most often performed by two (at least) different sets of operations, introduces a variety of risks and design management challenges. The most fundamental challenge is ensuring that what is intended at the highest level of abstraction actually gets implemented in silicon by the steps performed at lower levels of detail. Thus ensuring architectural intent or design coherence, making sure nothing gets “lost in translation” is a major issue within the current SoC design flow from concept through silicon implementation.
|
|
|
|
|
Navigate to related information
Frank Eory
5/11/2011 10:37 AM EDT
Excellent article! What you call "SoC Realization" is indeed an area where EDA can and must provide new solutions to bridge that gap between system definition and chip implementation.
Sign in to Reply
ahshabazz
5/12/2011 9:20 AM EDT
I think the problem with turnover in the US markets being so high, where are you going to find someone with the incredible depth and specialization to manage these tools when they come along?
Sign in to Reply
bigtallsimon
5/12/2011 9:23 AM EDT
Food for thought.
Your point about risk introduced by having at least two distinct teams (software at one end and silicon implementation at the other) is an important one. I agree that the hard boundaries drawn between the 'hardware' team and the 'software' team make it easy for cracks to open up - cracks which unrecorded architectural requirements or assumptions get lost in.
A breed of SoC engineer that understands the big architectural picture, the tools and techniques used at each stage and the methodologies for keeping the implementation in line with the system-level models would be of great value. Until there is a critical mass of such engineers, I wonder if the best tools in the world can be readily adopted...?
Sign in to Reply
bigtallsimon
5/12/2011 9:25 AM EDT
@ahshabazz Uncanny timing - exactly my point but 3 minutes sooner!
Sign in to Reply
KarlS
5/13/2011 4:45 PM EDT
Use of IP in an SoC is analogous to OOP, so much can be taken from OOP software development. The EDA tools today do nothing to assist the designer in the early stages, but rather seem to assume that the design is complete at day one. So synthesis optimization is part of the first compile when the design is not complete so it will throw away anything that is not totally connected then only says "sy6nthesized away these nodes". On the other hand an OOP compiler gives meaningful error messages. Another thing the OOP source editor provides selectable information for classes and methods at entry time. HDL source editors offer absolutely no help. Real chips are made up of and/or/invert, not if/else/case/always. The IP should be defined as a class so it can be compiled/instantiated along with the software in the system design. Then the function should be mapped onto the chip. Since the IP class would have been derived from the hardware design, it would be a matter of instantiating the IP modules.
Sign in to Reply