by Ramesh Chandra, STMicroelectronics, IncSan Diego, USAABSTRACT
Prevailing IP-Reuse methodologies are based on sharing designs at either Physical level called Hard-IP or at RTL level using HDL models called Soft-IP. Design re-use based on RTL based Soft-IP has been in use for many years now with limited success in certain domains. This paper will analyze the nature of design style and scope of re-use at RTL level. The increasing pressure in design productivity for ever more challenging system designs is pushing us to revisit the correct level of abstraction for Designs for Re-use.
This paper will also outline some of the basic characteristics desired of the IP blocks at levels higher than RTL. The platform based design methodologies by their nature also promote an architecture and system re-use techniques. The paper will also highlight how the platform based design methodologies could be used to define these system level IP for re-use.1. INTRODUCTION
The size and complexity involved in designing of electronic devices and systems is continuously out-pacing the designer productivity, and we have to regularly thrive for new solutions in terms of design tools & methodology to provide that leap required to cope up with the design task.
Over the years a number of design methodologies have been developed and adopted to help improve our capabilities to handle larger designs. Starting from the schematic entry based circuit design techniques following design methodologies have been developed to raise the design abstraction level.1.1 ASIC design methodology
This design technique based on HDL descriptions and automatic synthesis from a standard abstraction level called RTL has played a significant role in the VLSI design during the entire last decade. This methodology based on the simplicity of clocked based synchronous designs also became extremely popular with a new breed of VLSI designers. Making the designs technology independent provided the productivity leap.
Built around the Register-Transfer Level HDL descriptions and automatic synthesis is also a complete fleet of fast simulation, emulation and formal verification tools to help alleviate the design verification issues. This all contributes to the wide usage and success of this methodology.
In spite of all the nice features of this methodology, the sheer complexity of new SoCs makes it very difficult for design teams to design these devices all by themselves. A typical SoC nowadays involves processor cores, on-chip interconnects, application domain specific digital IP, analog and RF components. Competences required to design all these IP under one roof or even within the same company, combined with the ever increasing time to market pressure have naturally led to the IP-Reuse techniques. 1.2 IP-Reuse methodology
This methodology has been introduced to cope up with very large & complex designs. It basically involves partitioning of the designs into smaller IP blocks with well-defined functionality that can be re-used across multiple designs. IP-Reuse though a simple and compelling concept has not been associated with huge success. In the next section we will look at some of advantages and issues involved with this methodology. But first we look at another methodology that has potential for further advancing the productivity gain. 1.3 Platform-Based design methodology
This new emerging design methodology described here is a natural sequel to both ASIC design methodology & IP-Reuse methodology. Just as ASIC design methodology provided a big boost in design productivity by making designs technology independent, platform based methodology can cater for an architecture independent system design. At the same time it will extend the IP-Reuse to architecture level reuse paradigm. 2. IP-Reuse Methodology
IP-Reuse simply means reusing some part of the design previously done by others for our design. In some sense every design benefits a lot from the previous work either in terms of technology or in terms of design techniques. But what is commonly termed as IP Reuse refers to direct inclusion of a piece of design from an existing design. IP Reuse may refer to reuse of designs within a design group, within a company or from external IP providers. Though conceptually identical, these reuse methods differ in the protocols and issues involved with reuse.
IP-Reuse may be as simple as using standard cell libraries developed internally or externally, meant for general ASIC designs or specifically designed for high performance designs. Other flavors of IP-reuse involve some common design entities like memories, PLL etc or application specific complex modules. It’s this last category of IP-Reuse that is the most interesting and challenging in terms of reuse methodology.2.1 IP-Reuse Criteria
The question of whether to design an IP internally or reuse an existing piece of design from an external source is not always an easy one. Some of the considerations that are made by design managers in making IP-reuse decisions are described next.
2.2 IP-Reuse Issues
- Unavailability of the right competences internally is normally an easy and straightforward reason to look for reusable IP externally. As mentioned previously SoC designs involve a significant variety of design IP such as processor cores and not all SoC product design teams are equipped with resources or infra-structure to develop them internally.
- Time to Market is another strong reason to opt against an internal IP development. For example, even if competence did exist for designing a new and dedicated processor for a new SoC product in a design team, the time to design and verify a new processor could be prohibitive for the product in question.
- A factor that plays in favor of indigenous development may be the performance or any other design parameter critical to the product design. An internal development normally would provide a better control on design optimization and product differentiation.
- Cost is always an important facotr in deciding to reuse. One has to compare the cost of internal design and verification of IP against the licensing costs and royalties associated with external IP.
- Marketing strategy and standards compliance can also play a role in this decision process. Sometimes a product may be easily accepted in the market if it is known to incorporate industry accepted IP. Examples of this include industry standard interconnect buses.
IP-Reuse based on modular design and leveraging on existing designs has shown to improve design productivity in many applications. Nevertheless in practice it does suffer from certain drawbacks that have hindered its wide spread adoption.
Some of the issues involved in IP-Reuse are described here. These issues relate both to development of IP for reuse as well as reuse of external IP.
- Extra cost of IP design for reuse coupled with always increasing time to market pressure sometimes prohibits even designers with good intentions from approaching their development with reuse objective.
- Design for reuse, is at times viewed by designers as making those other guys life easy at the cost of pain for me. Designers view the extra cost of making their IP blocks re-usable as favor to others.
- Designers also view IP-Reuse as a direct attack on their ownership of the IP.
- Resistance to use of external IP can come from the desire to demonstrate superior design capability with respect to external designs.
- IP distribution and validation is a major hurdle in adoption of IP-Reuse methodology. Since the IP, is used by the designers who do not directly have access to original design process, they need a lot of information packaged with the IP. This includes documentation, all design views required by the ASIC methodology, verification plan and tests etc.
- Proper definition and selection of IP is also sometimes not an easy task. Certain applications have greatly benefited from definition of standard IP blocks and their availability from number of sources. In general though, for different application domains and products it is hard to properly define the IP block which can be used in an optimized manner for new systems.
- IP-Reuse through IP integration itself is not always painless. Due to the very nature of synchronous designs (the most popular design style where IP-Reuse is applied today), the functionality of the IP is closely related to the timing. IP block having been designed in one technology and used in one design doesn’t always lend itself easily in the context of the new design as far as timing is concerned.
In spite of issues involved with current IP-Reuse, in order to achieve productivity gains for new SoC design, we not only need to sort out some of the these issues related to development, validation and distribution of reusable IP but we will also need to extend the scope of IP-Reuse to higher abstraction levels. 3. Reuse at Different Levels
The IP-Reuse at current RTL level not only has some issues associated with IP integration but also limits the scope of IP reuse from a system design perspective. Higher productivity gains may be achieved by taking the IP reuse to higher abstraction levels.
There is nothing in the Intellectual Property term that implies it’s binding to RTL. Therefore we should look for extending the IP definition and reuse to different levels of abstraction.
This involves defining the type of reusability, configurability and scalability of IP at each abstraction level as well as figuring out the usage of these IP and their consistency when used in a design flow. We will address the defining of right characteristics of IP at each abstraction level in this section and deal with the consistency and design flow in the next section on Platform Based Design Methodology.
At the lowest level of abstraction the design is modeled using circuit description. The entities we deal with are voltages and current. The IP-reuse model at this level is called Hard-IP and refers to a technology specific layout level IP block. At this level the type of flexibility or generality added to the design includes adhering to standard layout practices in terms of pin positions, metal layer usages etc so as to facilitate easier physical integration by the designers reusing it.
The gate-level design takes the design complexity to more manageable level by relying on Boolean equations rather than voltage and currents. The reuse at this level may be termed Logic-IP. This involves exchange of technology specific gate level netlists, which can be then implemented by physical design. This type of IP reuse is not in common use paving way directly for RTL based Soft IP.
Apart from some specific blocks like memory or highly critical design blocks generated as Hard-IP, the most common usage of the term IP-Reuse refers to a synthesizable RTL level block called Soft-IP. The basic unit of design modeled at this level is a clock cycle. The RTL model defines the micro-architecture of a design laying the internal states and the behavior between these cycles of the design. Accordingly the Soft IP, flexibility and scalability are also related to cycle based behavior. The scalability is generally in terms of width of the data paths or in terms of selection of interface protocols.
The next natural extension of IP-reuse will be Arch-IP. The basic entity modeled here is system tasks. The model at this level specifies the computational or communication processes and the parallelism that exists in the design. And hence the scalability or flexibility of the IP at this level should involve scalability of computation or communication power provided by the IP.
The last but not the least is the important aspect of functional IP design for SoC. At this level we are dealing with functions of the system. And the flexibility required is in terms of interfaces to these functions similar to software function definitions and reuse. A good definition and development of functional IP can go a long way in proper selection, system integration and verification of complex SoC.4.Platform Based Design Methodology
As it represents a buzzword in the industry today, there is bound to exist some confusion about the definition of this term. Confusion also exists because it has evolved out of or relates to a number of other techniques involved in system design.
We would first like to define different types of platforms before we start talking about platform based design methodology.HW Platform
s refer to the programmable SoC design that provides a common architecture for applications.SW Platforms
may similarly be defined to be a stack of software modules facilitating development of an application.System Platforms
can be defined to be a system model that captures the essentials of a system relating to an application domain. This would involve the system functionality, the parallelism that exists in the system tasks and the essentials of the underlying architectures.
Our definition of Platform-Based design methodology is based on definitions used at UC Berkeley  and involves application specific system platforms.
This methodology is characterized by
- System design & modeling through multiple layers of abstraction.
- A systematic approach for manual, semi-automatic or automatic mapping between successive abstraction layers of the system modeling.
- Design space exploration at each abstraction level through architectural analysis using adequate design parameters.
- A system platform is a common negotiating point for application space and architecture space.
The most important aspect of this methodology is to design the complex system by addressing the different aspects of the system at different levels of abstraction and doing some amount of design space exploration at each step. Off course the success of this methodology mainly depends on proper definition of modeling at each level.
Based on the definition of design content at each abstraction level, proper mapping methods can be defined. The success of these mapping techniques will also depend on the correct abstraction and representation of lower level models to the higher-level models.
A proper verification methodology is needed to provide the consistency between different levels.
Such a SoC design approach will not only promote the development of flexible and scalable application specific system platforms but thanks to the systematic multi-layer design approach it will also facilitate the IP-Reuse at various abstraction levels. Any IP developed using the platform approach will automatically provide the representations of that IP at various levels and hence facilitate re-use. The verification and consistency in IP views for reuse is same as the one used for the initial system development.5 Summary
We have analyzed in this paper the necessity of Reuse techniques in order to handle the complexity and size of current and future SoC designs. Careful analysis of issues related with current IP-Reuse gives us clues to reinforce IP Reuse by extending the reuse to above RTL levels. This can be facilitated by the systematic layered system design approach defined by Platform Based Design Methodology. This methodology not only provides for a natural flow for reusable IP at all levels but also enables architecture reuse.6. References
 System Level Design with Embedded Platforms
Tutorial at DAC2000.