Commentary
SoC realization: Finally the “Killer App” that will allow EDA to grow again?
Ajoy Bose
5/11/2011 4:46 AM EDT
SoC realization fills a void
This void, where important system level information must be transformed to the next level of abstraction and analyzed, is where I see the best growth opportunity for EDA. It is here where an SoC has more degrees of optimization and critical decisions are made on issues such as which building blocks are used, what operating characteristics the SoC will have, and whether it will work as intended once committed to a silicon device. It is the cockpit for guiding the design from concept to implementation and ensuring design coherence from one level to the next. It is also the place where software development finds its voice to impact hardware design.
To better understand this relationship let’s look at a high level SoC development flow. In early 2010, Cadence Design Systems presented a White Paper entitled “EDA360, the Way Forward for Electronic Design”. That paper proposed a definition of the macro steps involved in electronic system design that, in my view, hit the mark. I will borrow some concepts and terminology from that piece here:
System realization: The development of a complete hardware/software platform that will provide all the necessary support for end-user applications. The platform includes one or more SoCs and adds an embedded software infrastructure that typically includes an OS, middleware, and reference applications. This step is increasingly driven by the system software applications that will run on the completed system.
SoC realization: The new and critical “bridge” step to take a system concept to a well-defined design that can be implemented at a detailed level. It involves the all important steps of choosing the right architecture and IP, validation of the IP, assembling it all on a workable platform, and performing a variety of analysis and verification tasks to ensure that it can be implemented as a viable, working SoC device.
Silicon realization: This represents the set of steps necessary to take a verified SoC design consisting of hardware and software functions, and implement it in working silicon. This is the domain of traditional EDA providers who work closely with semiconductor manufacturers such as TSMC. We often call this “EDA classic”.
Of the three steps, SoC Realization holds the most potential to dramatically improve SoC development time and bring new levels of value to the electronic design process. It is also the most adjacent area to EDA classic to consider and is today serviced by a fractured collection of in-house and commercial offerings. In a way, EDA needs to occupy all three domains. It is my belief that the path to System Realization requires a strong foundation of SoC Realization that is served piecemeal today. Figure 2 illustrates a macro view of a unified SoC development flow.
Figure 2: Unified SoC development flow
This void, where important system level information must be transformed to the next level of abstraction and analyzed, is where I see the best growth opportunity for EDA. It is here where an SoC has more degrees of optimization and critical decisions are made on issues such as which building blocks are used, what operating characteristics the SoC will have, and whether it will work as intended once committed to a silicon device. It is the cockpit for guiding the design from concept to implementation and ensuring design coherence from one level to the next. It is also the place where software development finds its voice to impact hardware design.
To better understand this relationship let’s look at a high level SoC development flow. In early 2010, Cadence Design Systems presented a White Paper entitled “EDA360, the Way Forward for Electronic Design”. That paper proposed a definition of the macro steps involved in electronic system design that, in my view, hit the mark. I will borrow some concepts and terminology from that piece here:
System realization: The development of a complete hardware/software platform that will provide all the necessary support for end-user applications. The platform includes one or more SoCs and adds an embedded software infrastructure that typically includes an OS, middleware, and reference applications. This step is increasingly driven by the system software applications that will run on the completed system.
SoC realization: The new and critical “bridge” step to take a system concept to a well-defined design that can be implemented at a detailed level. It involves the all important steps of choosing the right architecture and IP, validation of the IP, assembling it all on a workable platform, and performing a variety of analysis and verification tasks to ensure that it can be implemented as a viable, working SoC device.
Silicon realization: This represents the set of steps necessary to take a verified SoC design consisting of hardware and software functions, and implement it in working silicon. This is the domain of traditional EDA providers who work closely with semiconductor manufacturers such as TSMC. We often call this “EDA classic”.
Of the three steps, SoC Realization holds the most potential to dramatically improve SoC development time and bring new levels of value to the electronic design process. It is also the most adjacent area to EDA classic to consider and is today serviced by a fractured collection of in-house and commercial offerings. In a way, EDA needs to occupy all three domains. It is my belief that the path to System Realization requires a strong foundation of SoC Realization that is served piecemeal today. Figure 2 illustrates a macro view of a unified SoC development flow.
Figure 2: Unified SoC development flow
|
|
|
|
|
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