A Knowledge Sharing Framework for Fabs, SoC Design Houses and IP Vendors

Anne Meixner PhD, The Engineers’ Daughter LLC
Portland, OR, USA

Abstract:

The semiconductor industry has knowledge siloed into Design, Fab and Test. This paper proposes data structures specific to IP design characteristics for test manufacturing data system that can connect these silos. These structures enhance the ability to comprehend manufacturability at the IP level. Benefits for IDMs, Foundries, IP developers and System on a Chip (SoC) design houses are listed. Challenges in implementing these data structures in an IDM environment are included as well as data analysis examples.

I. THE NEED FOR DATA SHARING

System on a Chip (SoC) design style has resulted in more rapid design of IC products filling both IDM and Foundry Fabs. While SoC Design techniques have flourished and fostered the Fabless design eco-system, the backend- silicon production has not kept pace. Recent quotes from SoC design executives confirm dissatisfaction with the data shared on manufacturing of their silicon designs [1]. Semiconductor knowledge is siloed into IP/SoC Design, Fab, Test (see Figure 1). Both Integrated Device Manufacturers (IDMs) and the Foundry eco-system continue to suffer from lack of connections between these silos. This paper proposes connecting these knowledge silos by monitoring IP failures and by providing relevant IP design data. Metrics on IP manufacturability (yield related to pass/fail and performance) can provide SoC Designers and IP Vendors an opportunity to improve their design’s manufacturability. By providing design data to Fabs and OSATs the partnership between design and manufacturing can dissipate the dissatisfaction due to limited data sharing.

Figure 1 Product Knowledge Silos

The SoC model thrives on silicon proven IP for Hard IP and often Soft IP developers. Standards to address IP manufacturability have been limited to IP qualification [2] which relies upon test chip data. A test chip authenticates IP performance specifications and to the first order proves production worthiness. However, with today’s advanced process nodes and chip complexities, the intricacies of design-process interactions may only be fully understood with production data [2][4][5]. Understanding the IP manufacturing performance has a number of benefits that are currently not enabled with today’s test program and factory automation systems.

The industry needs to shift its view of manufacturing data from a “product” to an “IP” viewpoint. While Reuse statistics have focused on IP reuse with respect to design turns, the industry should look at IP usage across products. Regardless of who is responsible for yield, understanding of IC manufacturability needs to accommodate an IP view point due to the inherent value. A knowledge sharing framework for IP enables the following benefits:

• SoC Designers will have insight into the IP blocks having the largest yield impact and the ability to assess the ROI of revising the design,
• IP Vendors can learn about the manufacturability of their designs so that they can be improved,
• Fab engineers have the necessary design data to triage likely causes of yield excursions and assist with product ramps,
• Test engineers can compare IP performance across products.

Providing IP manufacturing metrics and the associated IP design data enables a healthier engineering system.

The remainder of this paper discusses in depth the framework to share data between Design, Fab, and Test engineering teams. Section II defines the design data of interest describes a data structure and discusses the enterprise data architecture options. The IP focused data analysis options are presented in Section III. The experiences in implementing this concept at a major IDM are shared in Section IV. Section V examines the benefits to the various engineering teams. The summary section, VI, includes a list of steps for design organizations to enable the proposed framework.

II. CONNECTING THE KNOWLEDGE SILOS

Connecting Fab and Design data via Test data necessitates well designed data structures, data governance and a thoughtful integration into the existing enterprise architecture for Fab, Test and Design data [6]. Adding a data structures specific to each IP design block can enable tracking IP manufacturability. In addition, it can provide key design data in the hands of the yield and test engineers. This section proposes the data structures, discusses enterprise architecture for the data and uses several IP blocks to illustrate the concepts.

IP blocks were chosen from the IP lists found at www.design-reuse.com and are used for illustrative purposes only. Following blocks were chosen:

• Soft IP MIPI Slave controller, from Cadence
• Soft IP USB 3.0 Device Controller from T2M
• Hard IP MIPI MIPI D-PHY 1.5 GBPS from Cadence
• Hard IP USB3 from OmniPhy

The IP data shared below is representative in nature and does not represent a real design.

A. IP Identifier

The IP Identifier is the key data structure that can tie test results to associated IP design data. IP Identifier format would be as follows and is illustrated in Table 1:

IPblockname_IPConfiguration_IPprovider

Note the format is not significantly different than TSMC IP Tagging specification[6].

Table 1: IP Identifier Format Examples

IP	IP Identifier
Soft IP1	MIPI Slave Controller_NA_Cadence
Soft IP2	USB3.0 Device Controller_NA_T2M
Hard IP3	MIPI D-PHY_1.5Gbps_Cadence
Hard IP4	USB3_6GTs_OmniPhy

B. IP Design Data for Sharing

To interpret IP fail rates the data automation system can provide IP design data. This data enables yield/product engineers and SoC/IP design engineers to interpret IP manufacturability rates. The following essential data is agnostic to the IP being Soft or Hard:

• Device Types
• IP block dimensions: X, Y microns- assume square block
• IP block SE corner location on the die, X & Y microns, note assumes only 1 copy
• Layer, critical area

Table 2 summarizes representative data for two IP blocks.

Table 2 Essential IP Design Data Examples

Design Attribute	Soft IP1	Hard IP4
Device Types	nmosl, pmosl, nmosll, pmosll	nmos, pmos, nmosl, pmosl
IP Dimension X, Y	80 x 135 um	170 x 110 um
SE corner X, Y	500, 653 um	4500, 450 um
M1 critical area	863 um**2	1280 um**2
M2 critical area	547 um**2	788 um**2
M3 critical area	412 um**2	654 um**2

C. Additional Design Data of Interest

Deeper knowledge of an IP’s design implementation can further aid Fab, Test and Design engineers. Additional design data can be included for IPs, though the data of interest may vary according to IP type. The examples of additional design data in Table 3 came from discussions with Fab and IP design engineers. It is by no means an exhaustive list.

Table 3 Examples of Additional Design Data of Interest

Design Attribute	Example data
Standard Cell library	Low power Standard Cell library for TSMC 28nm
Standard Cell, # of occurrences in IP	StdcellA- 303, StdcellB-112, etc.
# of instances in design and XY Location(s)	Instance 1(200um 468 um) Instance 2(500 um 480 um)
Data rates for a SERDES	6.0 GTS
Synthesis parameters: clock rate	125 Mhz
Hard IP, layout orientation NS vs EW	NS
Hard IP, Input reference clock	125 Mhz

As the list can become quite large it would be cost prohibitive to include all of this data in test data log. However, it would be worthwhile to maintain this data in an off-line table.

D. Enterprise Data Architecture Considerations

In connecting knowledge silos, one needs to consider the existing factory automation system supporting factory operations and test results. In addition, the manner in which IP design data is provided needs careful consideration. For IP design data good information quality practices [8] need to be executed while comprehending data security.

The ability to connect data between the two separate data systems presents a challenge to both IDM and the Foundry eco-system. With the IP Identifier connecting the test program results with a separate design data base the enterprise architecture needs to assure the following:

• Engineers know where to find data,
• Access permission control administration exists as the information could be considered sensitive,
• Good Information Quality [8] practices established,
• Design data has an assigned Master Data owner [10].

Permissions to access the data need to follow an IDM company’s existing procedures. For the Foundry eco-system, the data accessibility needs to be understood with respect to the contractual obligations between the various parties.

Currently most factory data automation systems have become complex enterprise systems as capabilities and requirements are added over time. The pathfinding work at Intel (shared in Section IV) repurposed an underutilized 256- character existing data structure to report both the IP Identifier and design data. This data structure included the essential design data stored in a substring of variable lengths separated by a semicolon, “;”, and design data identifier starts the substring with followed by a colon, “:”. Example:

IP_Identifier;DEVICE:nmos1,pmos1,LPnmos ,LPpmos; DIMENSION:100 x 200; LOCATION: 500,337; M1:50; M2:60; M370.

With the redesign of test automation system data structures companies have the option to simplify implementing a data system to support IP manufacturability. When considering how to store the design data the enterprise architecture team can consider a developing SEMI standard. The SEMI CASTCollaborative- Alliance-Semiconductor-Test has been working on Rich Interactive Test Database RITdb [9]. It offers a framework in which all design data could be held in a static table with the IP identifier as a key. In reviewing the standard, there exists the Substrate_info category which describes the device under test. The test program data log would list the IP Identifier and the additional data can be accessed off-line via the RITdb database. It could then support subsequent dashboards that could be supported by the various data analytic tools.

III. NEW DATA VIEWS WITH IP MANUFACTURABILTY METRICS

With IP manufacturability tracked at the factory level the ability to create IP-centric dashboards and charts can be pursued. First, consider dashboards of IP manufacturability health. The metric of health could be simplistic in terms fails/performance hits or could be more realistic wrt to yield by noting the Si Area for the IP. Table 4 uses fail percentage defined as fails divided by product tested. This dashboard neglects multiple copies of an IP on a product.

Table 4 IP Fail Rate in Percent

IP	Prod A	Prod B	Prod C	Prod D
Soft IP 1	.02%	.05%	.03%	.05%
Soft IP 2	.04%	.05%	.03%	.04%
Hard IP 1	.10%	.12%	.24%	.15%
Hard IP2	.23%	.48%	.23%	.24%

One could have PCI Express of 4 lanes on one product and 8 lanes on another product. Having the IP design data per product would enable Table 5 which divides the fail rate per IP instance.

Table 5 IP Fail Rate in percent per IP instance

IP	Prod A	Prod B	Prod C	Prod D
Soft IP 1	.02%	.05%	.03%	.05%
Soft IP 2	.04%	.05%	.03%	.04%
Hard IP 1, 2 instances	.05%	.06%	.12%	.08%
Hard IP2, 4 instances	.06%	.12%	.06%	.06%

Another popular means of comprehending yield issues is a pareto chart. With IP metrics one can construct a chart as in Figure 2 which communicates IP fallout for a produt. For products which share IP one could compare manufacturing performance as illustrated by Figure 3. For correct interpretation the additional design data is required. A real advantage of IP failure rates is the ability to observe a yield issue sooner by aggregating failures of an IP across multiple products. Development of such an aggregation metric requires a thoughtful implementation and an initial metric will be provided in [11].

Figure 2 IP Pareto for a Product

Figure 3 IP Pareto for Two Products

IV. LEARNINGS FROM AN IDM IMPLEMENTATION

This section shares observations from Intel pathfinding work on two products, 32nm and 22nm process nodes respectively. For the pathfinding work the team focused on identifying the failing IP and providing the essential design data. Overall the team found the actual reporting of the data for a failing IP to be straightforward. Acquiring the design data per IP proved to be more difficult than expected. Implementing a new methodology uncovers some challenges. In the Intel case, none of the challenges were showstoppers; the details are shared in [6]. At a high level the issues include:

• Inability to uniquely identify which IP block caused the failure
• Inconsistent Test Data
• In ability to acquire the Design Data
• Inconsistent Design Data per IP
• Traceability of IP Names

Plausible solutions to the challenges exist and consist of standardization, SoC design practices, and test covering multiple IP. To effectively share knowledge silos, the solution needs to consider corporate organization, implementation and technical barriers. These barriers can be overcome with commitment and standardization.

V. BENEFITS TO THE SOC ECO-SYSTEM PARTNERS

The proposed framework for IP manufacturability benefits the Fab/Design Integrator/IP designer eco-system. In an IDM as well the Foundry eco-system Fab, Test, SoC Design and IP Design organizations operate as siloed organizations. Increasing data sharing between the engineering teams results in the ability to respond sooner to manufacturability issues and in an increased understanding of manufacturability of an IP. In the next few paragraphs the benefits will be discussed independent of eco-system type with an emphasis on design organizations. The differences between how these benefits would manifest itself in an IDM vs the Foundry eco-system will then be addressed.

For the Factory (Fab, Assembly & Test) having essential IP design data reported out with IP fails/performance degradation aids in the deciphering manufacturability issues. A test engineer will be interested in understanding fallout results per IP and the ability to compare IP pareto across products. More detailed design data available in a database can greatly assist in the determination of yield/performance losses. It also enables an engineer to determine if differences between an IP’s yield across different products is due to design implementation differences. Yield and test engineering teams can provide an IP manufacturability report to design teams.

For the SoC design team increasing a products manufacturability has an impact on product profitability. With access to IP manufacturability data an SoC design team can be informed about potential issues for products which reuse IP. In addition, IP failure rates can inform SoC design teams on how IP implementation choices impacted manufacturability. In design of Soft IP an SoC design team may have different standard cell libraries to choose from and have synthesis choices that impact manufacturability [14]. Several papers have highlighted the difference that a standard cell choice can have on manufacturability [12][13][14]. Synthesis strategies historically have focused on timing, power and die area. As noted in [14], adding DFM metrics would assist in increasing yield. Matching the design data in the secondary data base with the Factory data could inform choices on the next implementation and perhaps the overall strategy. Finally, SoC designs enable the quick turnaround of a design due to the disciplined usage of a connection fabric like SONICs. If the yield loss suggests revising an IP design, then the ROI analysis can be done to determine if a revised design will benefit the profitability.

The IP design team resides furthest removed from manufacturability issues both physically and philosophically. The latter is a result of the evaluation of IP in terms of ease of design integration. The Quality Intellectual Property Metric, IEEE 1734, focuses on documentation, ease of integration, design & verification quality. Not a single check box for manufacturability exists in that standard. Standards to address the manufacturability have been limited to foundry IP qualification [2]. For the proposed framework to share data, IP design teams play a crucial role. While performance and ease of integration primarily dictate the choice of an IP in an SoC design the ability to get product to market is the ultimate proving ground for any Si design. Providing design data to their SoC design and Factory partners adds to their value as a part of the eco-system. The proposed framework to share data can provide feedback in particular for Hard IP designers. Hard IP reuse sometimes has subtle differences between “identical” IP that could impact manufacturability. For instance the reference clock into a USB block can differ from one product to another.

SoC design companies choose either purchasing a wafer or Known Good Die (KGD) from Foundries. For wafer purchase manufacturability issues become a financial interest of the SoC design company. To effectively respond to yield issues, SoC design companies can successfully partner with Foundries and OSATs by enabling IP monitoring in the test program and by providing IP design data. This data sharing requires additional contract obligations. With a KGD purchase the Foundry bears the yield loss burden. Via contract Foundries can require IP design data and test program monitoring of IP fails to enable faster yield improvement.

The differences between the IDM and the Fabless eco-systems may impact the ability of placing design data at a factory engineer’s disposable and enabling designers (SoC and IP) insight into an IP’s manufacturability. The differences lie primarily in the business transactions in the Foundry eco-systems. In the IDM system no financial boundaries exist, albeit there remain the organization boundaries that form the foundation of the knowledge silos. For the Fabless eco-system, the business transactions come into to play but are not insurmountable. The Foundry eco-systems relays upon the external business relationships which necessitate contractual obligations. To enable data sharing these contracts can be augmented to partner on data sharing.

VI. SUMMARY

In a SoC design eco-system IP reuse provides faster product to the Fab. To enable a correspondingly faster product ramp semiconductor manufacturing data analysis needs to shift from a product to an IP viewpoint. Connecting the knowledge silos of Design, Fab and Test with relevant IP design data enables multiple engineering teams to be more efficient and innovative. This paper presented a framework to monitor IP manufacturability and to provide IP design data. This design data can augment existing data analytic tools which can then enable disparate engineering teams to share insights with each other. The paper thoroughly discussed the value in comprehending manufacturability at the IP level has to Design, Fab and Test engineering teams. The author shared experiences piloting these ideas at an IDM which revealed implementation challenges, none were show stoppers.

A figure of merit of an IP’s implementation can often be estimated pre-silicon. Matching these predictions to reality requires the ability to measure it and this paper proposes monitoring IP failure rates. The proposed design data can augment existing data analytic tools which have enabled disparate engineering teams to comprehend the overall yield and manufacturability of silicon products. To move forward on making this knowledge sharing framework a reality SoC and IP designers can contribute as follows:

• Define and provide the IP design data parameters to share.
  • Determine ownership of suppling the design parameters, i.e. SoC integrator and/or IP vendor.
  • Assign a Master Data team to own keeping one true record that engineering teams can rely upon.
• Address the traceability of IP names from IP Design to SoC Design to Test Program.

Manufacturing and Design organization have silos of expertise and knowledge; joining these knowledge bases have both organizational, implementation and technical barriers. This framework addresses increased sharing of data across the engineering teams responsible for the design and manufacturing of the product. This capability enables engineers to make informed decisions. With appropriate design data yield/product engineers can make informed decisions when deciphering a yield issue. IP manufacturability metrics can assist design engineers to make informed decisions regarding IP choice and IP implementations. Test Engineers can comprehend product yield in terms of the IP blocks and can compare an IP block’s yield on other products. Joining these knowledge bases have both organizational, implementation and technical barriers that need to be overcome. The benefits are well worth the required effort.

ACKNOWLEDGMENTS

The author thanks Jai Mishra, Anand Shah, Randy Schackmann, Brian Magill and Ciaran O’Donohue, colleagues at Intel Corporation, for conversations and pathfinding work on the ideas proposed in this paper. She is grateful to Derek Feltham for encouraging the exploration of this framework at Intel. She thanks Staci Ajouri of Texas Instruments for discussing the CAST RITdb standard. Finally, she acknowledges conversations with the following colleagues who provided useful feedback to applying these ideas in the Fabless eco-system: Dr John M Acken- Portland State University, Brian Bailey- EDA Consultant, Claude Gauthier-OmniPhy.

REFERENCES

[1] Sperling, Ed; “Grappling with Manufacturing Data,” 22 September 2016

[2] TSMC 9000: IP Validation Center

[3] Maly, W; “Future of testing: Reintegration of design, testing and manufacturing;” 1996 Proceedings of European Design and Test Conference.

[4] Aitken, R, etal; “DFM is dead - Long live DFM;” 2014 IEEE 32nd International Conference on Computer Design (ICCD); pg 300-307.

[5] Appello, D etal; “Enabling Effective Yi9eld Learning trough Actual DFM-Closure at the SoC Level;” 2007 IEEE/SEMI Advanced Semiconductor Manufacturing Conference; pg 148-152.

[6] Meixner,Anne; “Improved Understanding of IP Manufacturability—A Proposal to Share Data between Fab, Test and Design;” 2016 DATA Workshop.

[7] TSMC9000 IP Tagging Specification V1.3 May 2013

[8] R Schackmann and R Hunter “How to Capture Your Management’s Attention and Kick-Start your informationi Quality Program Leveraging IQ Scoring;: Enterprise Data World Conference 2016.

[9] Semi Cast RITdb Introductory slides location to be published on the LinkedIn group Semiconductor Big Data – RITdb the next gen STDF.

[10] Master Data Definition https://en.wikipedia.org/wiki/Master_data

[11] Meixner, Anne; “Enhancing Yield Learning on SoC Designs by Tracking IP Manufacturability;” submitted to 2017 Advanced Semiconductor Manufacturing Conference.

[12] Epinat, A, etal; “Yield Enhancement Methodology for CMOS Standard Cells;” ISQED 2006, 496-502.

[13] V. Kheterpal, et al.; “Design Methodology for IC Manufacturability Based on Regular Logic Bricks;” Proceedings of the 42nd Conference on Design Automation, pages 353–358, 2005.

[14] Liebmann, L, et.al.; “Simplify to Survive, prescriptive layouts ensure proftable scaling to 32nm and beyond;” SPIE March 2009.

[15] S.A. Shaikh, J. Khare, H.T. Heinken; “Manufacturability and Testability Oriented Synthesis;” Proceeds inf VLSI Design, 200; pg 185-191.

If you wish to download a copy of this white paper, click here