Commentary
SoC realization: Finally the “Killer App” that will allow EDA to grow again?
Ajoy Bose
5/11/2011 4:46 AM EDT
Definition of SoC realization – Efficient management of IP
Enabling an SoC Realization solution revolves around how IP is managed, and I see three critical areas driving the approach:
• IP sourcing: Is the IP chosen of sufficient quality? Is it silicon proven? Will it meet my power, performance and area requirements and is it implementation ready? Bad choices here will usually cause a chip re-spin, which can spell disaster for an SoC project.
• SoC creation: Is the architecture chosen for the SoC the “right” one? Will it allow the entire system to be synchronized, hardware and software? Will it be scalable across at least two generations of systems products and does it support compatibility with legacy software?
• SoC handoff: Once the IP and platform has been chosen, is the resulting SoC ready for implementation based on the desired specifications? Can the impact of decisions associated with cost, time and market be measured? Are all the design files in place and has design intent been adequately communicated?
There is also an important modeling issue that spans all three areas:
• Design coherence: As one moves up and down the design hierarchy and associated levels of abstraction, is there confidence that the accuracy and completeness of the system model is maintained? Is systems intent maintained in the translation to more silicon specific implementations?
Figure 3 summarizes the key aspects of these processes.
Figure 3: IP management requirements
Enabling an SoC Realization solution revolves around how IP is managed, and I see three critical areas driving the approach:
• IP sourcing: Is the IP chosen of sufficient quality? Is it silicon proven? Will it meet my power, performance and area requirements and is it implementation ready? Bad choices here will usually cause a chip re-spin, which can spell disaster for an SoC project.
• SoC creation: Is the architecture chosen for the SoC the “right” one? Will it allow the entire system to be synchronized, hardware and software? Will it be scalable across at least two generations of systems products and does it support compatibility with legacy software?
• SoC handoff: Once the IP and platform has been chosen, is the resulting SoC ready for implementation based on the desired specifications? Can the impact of decisions associated with cost, time and market be measured? Are all the design files in place and has design intent been adequately communicated?
There is also an important modeling issue that spans all three areas:
• Design coherence: As one moves up and down the design hierarchy and associated levels of abstraction, is there confidence that the accuracy and completeness of the system model is maintained? Is systems intent maintained in the translation to more silicon specific implementations?
Figure 3 summarizes the key aspects of these processes.
Figure 3: IP management requirements
An SoC Realization environment addresses each of these issues with a set of tools, methods and integrated approaches that represent a new level of abstraction that streamline the process from a higher level concept to a “ready to implement” design. The result of a design concept being transformed through an SoC Realization environment is that the design intent is targeted optimally for silicon implementation and the developer can be assured that it will work as intended once passed to the next phase of the process – design implementation and manufacturing.
SoC Realization represents the next natural and necessary step up in abstraction from existing EDA methodologies and is a necessary bridge from the more abstract world of system-level design that is helping drive SoC-enabled products. I started this discussion with a reference to the iPad as a killer app. It is well-known that Apple develops its own SoCs to fuel innovations like the iPad. SoC Realization elevates IP as a new level of abstraction and fuels the development of SoCs. It represents the confluence of the two growth areas I see for the EDA industry. Does that make it a killer app for EDA? I think so. It certainly leverages some very powerful forces that are being driven by the giants of the electronics industry. I believe it offers much promise for growth if we can harness it effectively.
Atrenta has developed a White Paper that discusses the changes mentioned here in more detail. We explore SoC Realization and its implications on electronics innovation and EDA. I invite you to download this White Paper and learn more about these important trends at http://www.atrenta.com/Atrenta-SoC-Realization.pdf
About the author:
Ajoy K. Bose PhD, Chairman, President and CEO
Dr. Bose founded Atrenta, Inc. in 2001. He began his career at AT&T Bell Laboratories in Murray Hill, N.J. and spent 12 years in a series of increasingly responsible positions ending as Department Head, Integrated Circuit Design Automation Department. From AT&T, he moved to Cadence Design Systems where he served as Vice President of Engineering. In this role, he managed and led the team that pioneered the Verilog simulation products. Prior to establishing Atrenta, Dr. Bose was founder and president of Software & Technologies, Inc. and Interra, Inc. During his tenure as Chairman and CEO of Interra, Dr. Bose incubated and spun out a number of successful ventures in EDA, Digital Video, and IT services. Dr. Bose received a Bachelors degree in Electrical Engineering from the Indian Institute of Technology in Kanpur, India which recently awarded him the Distinguished Alumni award. He earned his MS and PhD in Electrical and Computer Engineering from the University of Texas at Austin.
SoC Realization represents the next natural and necessary step up in abstraction from existing EDA methodologies and is a necessary bridge from the more abstract world of system-level design that is helping drive SoC-enabled products. I started this discussion with a reference to the iPad as a killer app. It is well-known that Apple develops its own SoCs to fuel innovations like the iPad. SoC Realization elevates IP as a new level of abstraction and fuels the development of SoCs. It represents the confluence of the two growth areas I see for the EDA industry. Does that make it a killer app for EDA? I think so. It certainly leverages some very powerful forces that are being driven by the giants of the electronics industry. I believe it offers much promise for growth if we can harness it effectively.
Atrenta has developed a White Paper that discusses the changes mentioned here in more detail. We explore SoC Realization and its implications on electronics innovation and EDA. I invite you to download this White Paper and learn more about these important trends at http://www.atrenta.com/Atrenta-SoC-Realization.pdf
About the author:
Ajoy K. Bose PhD, Chairman, President and CEODr. Bose founded Atrenta, Inc. in 2001. He began his career at AT&T Bell Laboratories in Murray Hill, N.J. and spent 12 years in a series of increasingly responsible positions ending as Department Head, Integrated Circuit Design Automation Department. From AT&T, he moved to Cadence Design Systems where he served as Vice President of Engineering. In this role, he managed and led the team that pioneered the Verilog simulation products. Prior to establishing Atrenta, Dr. Bose was founder and president of Software & Technologies, Inc. and Interra, Inc. During his tenure as Chairman and CEO of Interra, Dr. Bose incubated and spun out a number of successful ventures in EDA, Digital Video, and IT services. Dr. Bose received a Bachelors degree in Electrical Engineering from the Indian Institute of Technology in Kanpur, India which recently awarded him the Distinguished Alumni award. He earned his MS and PhD in Electrical and Computer Engineering from the University of Texas at Austin.
|
|
|
|
|
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