English
IP Exchange Procedure
by Rosamaria Balestri, STMicroelectronics
Catania, Italy
Abstract:
Today, complex SoC (System-on-Chip) designs are typically IP (Intellectual Property) based. IPs are developed in specialist teams who release the same IPs to various SoC teams. Conversely, to build the complete chip, each SoC team integrates IPs designed by different IP providers.
In this context efficient IP re-use is the key factor for quick, easy and high quality SoC integration; hence having a set of rules to manage IPs exchange is more than just a quality requirement. ‘IP Exchange’ includes the entire process by which the SoC team requests an IP, the IP team commits to the development and eventually delivers that IP.
Experience showed that this process is rarely conducted with proper care. The approach to IP exchange varies from heavy procedures originally written for chip development to informal contacts between parties, this wide range leading to painful integration histories. How to address that?
ST focused on dynamics and issues related to internal IP exchange, and put in place a simple and efficient process model to improve communication between IP supplier and integrator (IP Exchange Procedure). This approach was well accepted on the ground and is now in widespread use in a number of groups.
This paper describes the ST experience, with an overview of the reasoning behind the proposed approach, the exchange model and some details about the intranet application supporting this process.
Overview
SoC design often relies on integration of IPs coming from different sources, either internal or external to the company.
In case of design outsourcing, the integration team typically passes IP requirements to an IP Procurement department, which looks after any detail associated with IP deals. Otherwise, for IP provided internally to the company, contacts between integrator and IP design team are usually point-to-point and less formal, hence fast but sometimes leaving room for inefficiency, adversely affecting the system integration. Typical symptoms are: incomplete or incorrect specifications, design development not firmly requested or committed, generic timescales and failing integration checks.
Some pragmatism is needed between the two sides and probably the supplier is the most able to change. The IP design process cannot be overloaded with heavy formalities; however, just a few basic rules provide a good compromise between a process totally out control and one too constrained. When supported by daily working tools they need not represent any extra cost for the design community.
Exchange model
The reasoning outlined above drove the identification of the minimal set of steps that ensures light, formal and clear transitions for internal IP exchange, namely who does what and by when. Those ‘steps’ are the key phases of the IP Exchange process, and in the following are globally referred to as the Exchange Procedure (see Fig. 1).
If Customer is the SoC team, and Provider the IP design team, the Customer, who submits an IP Request to the Provider, initiates the process. The request can be for a brand new IP, or an existing one with or without some rework to fit specific SoC requirements.
If the IP is required as it is, the Provider generally releases it and then waits for feedback about the usage from the Customer, otherwise he needs some time to evaluate development efforts, but at least acknowledges the request and commits to a date by when a plan with schedules will be available. When the Provider issues a development proposal the Customer either agrees, so the process advances to design development, or he tries to negotiate some details, or refuses the proposal which then closes the request.
When design development is completed the Provider does a release and waits for feedback from the Customer. If the IP is easily integrated the request is completed. Sometimes a little rework is necessary before an IP matches the SoC requirements.
A frequent and worrying event is Customers making additional change requests (ACRs) after design has started. This is quite dangerous, as the Provider can rarely stop design, make the additional estimation and wait for Customer acceptance, so typically design progresses (with old specs) and at some point extra features are added without clear visibility of impact on the original timescales. To avoid that an ACR is treated independently from the ‘parent’ request. While the original IP development progresses the Provider evaluates the additional effort related to new requests and only if accepted by the Customer are new features implemented in the design, otherwise the ACR is closed with no adverse impact. If an ACR occurs after design for the ‘parent’ request is completed it is treated as an independent request.
Fig. 1: Exchange Procedure
In summary, Exchange Procedure highlights roles (who) and actions (what, by when) related to three main steps:
In the aforementioned context critical events are: IP Request, Proposal Commitment, Development Proposal, Proposal Acceptance and Non Conformance report. Information passed during those events should be kept to a minimum whilst being efficiently circulated to key people, so templates and logging features should be used.
Intranet Application
The original purpose was to identify basic steps and supporting tools that would improve controllability of the exchange process with minimal resource effort and largest scope.
Based on that, ST has developed an application that covers request/delivery flow, with automatic notifications to key people about Request progress. According to the exchange model described above, the Customer initiates the process by filling an on-line Request form. Each Request is notified to the Provider who was earlier registered as reference for that IP, and similarly, any critical event about a given request is notified to related people (Customer, Provider, key Designers). While the IP design progresses, the request status is updated until it is eventually closed, and available in the archive. The automation results from integration of daily tools such as emails, spreadsheets and database primitives on an intranet platform. This application is the key feature of a central portal dedicated to IP Exchange, linking any information useful to both IP and SoC teams (e.g. IP Catalog, Design Standards) which is fully used and, as an aside, deploying the policy of Knowledge Sharing.
Outcome
Exchange Procedures and the intranet application have been in usage respectively for 2 years and 1 year and whilst the automation was under development people used Excel templates.
Regardless of implementation maturity all users have seen real benefits in this new approach:
Providers
Conclusions.
Though IP re-use is the consolidated solution to speed up large system integration, the approach to IP Exchange is often inadequate compared to its possible impact. ST has drawn a light and efficient process model that covers the IP request/delivery flow, clarifying roles and actions associated with that. This process model also called the IP Exchange Procedure was implemented as an intranet application, so today Providers have a tool supporting them in daily IP management, and Customers have more visibility to track their requests allowing them to better coordinate SoC integration.
The Procedures are appreciated by end-users and accepted as good practice during their daily work, which is essential for the inspiration of new features potentially leading to a company-wide methodology.
Catania, Italy
Abstract:
Today, complex SoC (System-on-Chip) designs are typically IP (Intellectual Property) based. IPs are developed in specialist teams who release the same IPs to various SoC teams. Conversely, to build the complete chip, each SoC team integrates IPs designed by different IP providers.
In this context efficient IP re-use is the key factor for quick, easy and high quality SoC integration; hence having a set of rules to manage IPs exchange is more than just a quality requirement. ‘IP Exchange’ includes the entire process by which the SoC team requests an IP, the IP team commits to the development and eventually delivers that IP.
Experience showed that this process is rarely conducted with proper care. The approach to IP exchange varies from heavy procedures originally written for chip development to informal contacts between parties, this wide range leading to painful integration histories. How to address that?
ST focused on dynamics and issues related to internal IP exchange, and put in place a simple and efficient process model to improve communication between IP supplier and integrator (IP Exchange Procedure). This approach was well accepted on the ground and is now in widespread use in a number of groups.
This paper describes the ST experience, with an overview of the reasoning behind the proposed approach, the exchange model and some details about the intranet application supporting this process.
Overview
SoC design often relies on integration of IPs coming from different sources, either internal or external to the company.
In case of design outsourcing, the integration team typically passes IP requirements to an IP Procurement department, which looks after any detail associated with IP deals. Otherwise, for IP provided internally to the company, contacts between integrator and IP design team are usually point-to-point and less formal, hence fast but sometimes leaving room for inefficiency, adversely affecting the system integration. Typical symptoms are: incomplete or incorrect specifications, design development not firmly requested or committed, generic timescales and failing integration checks.
Some pragmatism is needed between the two sides and probably the supplier is the most able to change. The IP design process cannot be overloaded with heavy formalities; however, just a few basic rules provide a good compromise between a process totally out control and one too constrained. When supported by daily working tools they need not represent any extra cost for the design community.
Exchange model
The reasoning outlined above drove the identification of the minimal set of steps that ensures light, formal and clear transitions for internal IP exchange, namely who does what and by when. Those ‘steps’ are the key phases of the IP Exchange process, and in the following are globally referred to as the Exchange Procedure (see Fig. 1).
If Customer is the SoC team, and Provider the IP design team, the Customer, who submits an IP Request to the Provider, initiates the process. The request can be for a brand new IP, or an existing one with or without some rework to fit specific SoC requirements.
If the IP is required as it is, the Provider generally releases it and then waits for feedback about the usage from the Customer, otherwise he needs some time to evaluate development efforts, but at least acknowledges the request and commits to a date by when a plan with schedules will be available. When the Provider issues a development proposal the Customer either agrees, so the process advances to design development, or he tries to negotiate some details, or refuses the proposal which then closes the request.
When design development is completed the Provider does a release and waits for feedback from the Customer. If the IP is easily integrated the request is completed. Sometimes a little rework is necessary before an IP matches the SoC requirements.
A frequent and worrying event is Customers making additional change requests (ACRs) after design has started. This is quite dangerous, as the Provider can rarely stop design, make the additional estimation and wait for Customer acceptance, so typically design progresses (with old specs) and at some point extra features are added without clear visibility of impact on the original timescales. To avoid that an ACR is treated independently from the ‘parent’ request. While the original IP development progresses the Provider evaluates the additional effort related to new requests and only if accepted by the Customer are new features implemented in the design, otherwise the ACR is closed with no adverse impact. If an ACR occurs after design for the ‘parent’ request is completed it is treated as an independent request.
Fig. 1: Exchange Procedure
In summary, Exchange Procedure highlights roles (who) and actions (what, by when) related to three main steps:
- Request, Customer submits SoC requirement for that IP
- Proposal, Provider estimates development effort and issues a plan
- Acceptance, Customer acknowledges integration or reports possible issues.
In the aforementioned context critical events are: IP Request, Proposal Commitment, Development Proposal, Proposal Acceptance and Non Conformance report. Information passed during those events should be kept to a minimum whilst being efficiently circulated to key people, so templates and logging features should be used.
Intranet Application
The original purpose was to identify basic steps and supporting tools that would improve controllability of the exchange process with minimal resource effort and largest scope.
Based on that, ST has developed an application that covers request/delivery flow, with automatic notifications to key people about Request progress. According to the exchange model described above, the Customer initiates the process by filling an on-line Request form. Each Request is notified to the Provider who was earlier registered as reference for that IP, and similarly, any critical event about a given request is notified to related people (Customer, Provider, key Designers). While the IP design progresses, the request status is updated until it is eventually closed, and available in the archive. The automation results from integration of daily tools such as emails, spreadsheets and database primitives on an intranet platform. This application is the key feature of a central portal dedicated to IP Exchange, linking any information useful to both IP and SoC teams (e.g. IP Catalog, Design Standards) which is fully used and, as an aside, deploying the policy of Knowledge Sharing.
Outcome
Exchange Procedures and the intranet application have been in usage respectively for 2 years and 1 year and whilst the automation was under development people used Excel templates.
Regardless of implementation maturity all users have seen real benefits in this new approach:
Providers
- are clear about who is requesting what, and by when, with evidence of misunderstandings having decreased
- have a standard way to manage ACR
- have single repository for received request
- dramatically reduced paper work duplication
- can run statistics on work effort and quality of work (through on-line Customer Satisfaction Survey)
- have more visibility about development of requested IP
- have visibility of design ongoing for other products
- can check request status and follow-up
Conclusions.
Though IP re-use is the consolidated solution to speed up large system integration, the approach to IP Exchange is often inadequate compared to its possible impact. ST has drawn a light and efficient process model that covers the IP request/delivery flow, clarifying roles and actions associated with that. This process model also called the IP Exchange Procedure was implemented as an intranet application, so today Providers have a tool supporting them in daily IP management, and Customers have more visibility to track their requests allowing them to better coordinate SoC integration.
The Procedures are appreciated by end-users and accepted as good practice during their daily work, which is essential for the inspiration of new features potentially leading to a company-wide methodology.
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
|
E-mail This Article | 
|
|
Printer-Friendly Page |