how we perform reverse engineering over usage data of same level is therefore used to extract the
legacy EDA functions to identify EDA service sequence-dependent relative frequencies of next functions
components and flow sequences among them (C2). in an order-n Markov chain model. Given an n-step
Finally, we shall present our ideas on design and sequence, there can be many next functions, e.g., B, C,
implementation of a collaboration platform for EDA and D after the 1-step sequence of B in Figure 4. The
service composition and management (C3). relative frequency of using C next can be calculated by
dividing the total number of B-C sequence with the total
III. Procedure Modeling and Extraction number of B-X sequences in the sample usage data,
An EDA procedure consists of a sequence of analysis where X is any EDA function. To extract procedures
steps, where a step may be the application of an EDA common to many engineers, we set a threshold for each
function or an analysis decision by an engineer. In each given sequence to filter out infrequently used next
step, there involves data/information query, processing functions for the state; namely, if the relative frequency of
and presentation, which belong to information services using a next function is lower than the threshold, this next
that are needed to realize individual EDA steps. Our function will not be included as part of the EDA
procedure modeling is focused on modeling the procedural knowledge with the given sequence. Based on
application sequences of EDA functions of based on such ideas, a Markov chain-based procedural knowledge
empirical usage data of using a legacy EDA system. Once extraction (MCPKE) algorithm is developed.
modeling and extraction methods are available, futuristic III.3 Validation and applications
EDA service requirements will be developed by With input of some a priori knowledge about
extending the methods through interviews with veteran standard operation procedures for yield analysis, the
engineers who are working on advanced process MCPKE algorithm is applied to EDA usage data of more
technologies and next generation fabs. than two hundred engineers over a three months period.
In identifying engineers’ application sequences of Veteran engineers were invited to review the extraction
EDA functions to problem solving, we first adopt Markov results. The Markov chain-based procedural knowledge
models of various orders to represent EDA function models indeed capture many key procedural features and
sequences. We then design an algorithm to extract, from reveal many phenomena for further exploration. Figure
engineers’ usage data, the relative frequency information 2 depicts an example of a partial EDA function flow
of applying a specific EDA function after a given derived from fab data.
sequence of EDA functions. Key ideas and results are as The modeling and extraction methods automate
follows. EDA procedural knowledge extraction. At the current
III.1 Procedure modeling by Markov models stage, it at least helps document common practices of
The motivation that we consider Markov models is EDA users if not the golden practice. On the user side, the
that the application of an EDA function at step n+m is documented EDA procedures can then be used as
affected by the functions used at steps m to m+n-1. If i) a reference foundation for communications and
we consider the application of an EDA function as a collaborations among engineers, and
“state,” the dependency of a state to the n previous states ii) training guidance for rookie engineers.
can then be modeled as an order-n Markov chain. The On the system developer side, it may serve as
transition probability from an n-state sequence to a next iii) a basis for aggregation or segregation of functions
state corresponds to relative frequency of adopting a into reusable SCs by examining the sequence
specific EDA function after a sequence of n EDA dependency among functions over various
functions. Such a modeling concept matches procedures,
practitioners’ intuition about EDA procedure for yield which we shall elaborate in the next section.
analysis. Figure 2 depicts an exemplary analysis flow in
an order-1 Markov chain. IV. Reverse Identification of Service Components
III.2 Procedural knowledge extraction With EDA procedures extracted from engineers’
On top of the Markov models, we then exploit usage data, we now adopt the method of reverse
empirical EDA function usage data to extract the specific identification [WXZ05] to identify EDA function
states (EDA functions) and state transition probabilities sequences of strong dependency, high reuse value and/or
(relative usage frequencies) of EDA function flow good reuse performance. Such function sequences will
sequences, which we consider as the procedural then be put respectively as SCs to support effective reuse
knowledge. Figure 3 gives an exemplary usage data of of EDA function software. We propose four steps to
one user, where there are function start times and dates. identify EDA SCs:
Exploiting the timing information, one may find the Step1: Legacy function usage classification
sequence of applying these functions. In this example, Each EDA function has at least one purpose for
function A is the starting one followed by function B. yield analysis. EDA functions are classified into different
After applying functions A and B, the next function can function categories according to their individual purposes.
be B, C or D. Function C is followed by function D. One function may belong to more than one function
The sequences are depicted in Figure 4. It is well categories.
recognized that EDA procedures vary among engineers, Step2: Function to service category mapping
not only among those of different levels of experience or This step maps EDA functions to services because
background but also among individuals at a similar level. users understand what kind of EDA services they need
EDA function usage data of multiple users at the but may not have a good grasp of the functionality of
every EDA function. However, the granularity of SCs that program through the wrapper while the WS
make of services affects the flexibility of service communicates with the wrapper. The legacy functions
composition, reusability of SCs, and efficiency of service remain as the actual service providers. Such an
delivery. Instead of finding an optimal granularity, we implementation allows scalability and easy addition of
adopt a heuristic that maps EDA function categories to new SCs.
EDA service categories based on the extracted procedure To facilitate EDA knowledge and system service
models and only considers aggregation among functions sharing and resource reusability, we design a vocabulary
in the same service category. hierarchy, service descriptions and a service directory.
Step3: Aggregation in a service category The vocabulary hierarchy is designed based on EDA
Within a service category, functions may be function input and output items and their relation to wafer
aggregated based on their procedural dependency lot, process, product and parameters. This vocabulary
extracted from empirical data. By analyzing EDA hierarchy provides a systematic way and standardized
procedures extracted from fab data, we identify two vocabularies to describe EDA services and interfaces.
possible types of aggregation and illustrate the ideas in Engineering knowledge can then be shared through
Figures 5(a) and (c). Figure 5(a) is an aggregation of standardized vocabularies for knowledge description, and
functions in a frequently used and strongly dependent services and their requirements can be effectively
function sequence into a SC. For this case, we define the communicated via service descriptions. Through them,
strength of sequential dependency between functions i EDA developers can also effectively search for,
and j, S ij , as understand and reuse available SCs and services.
In the EDA service management platform, a service
Pij ≡ prob( next function j | current function i ) GUI is designed that supports drag-and-drop EDA service
Sij ≡ Cij * Pij , where A A composition. The drag-and-drop composition is based on
BPEL technology [Ecl07], which is used to orchestrate
⎧ 1, if function i and j in the same category ⎫ existed web services. The drag-and-drop EDA
Cij = ⎨ ⎬.
⎩0, if function i and j in different categores ⎭ composition interface shown in Figure 7 enables
high S ij value indicates that functions i and j could be engineers to flexibly compose their own analysis flows
based on the available EDA SCs, which can then be
aggregated into the same service component. Figure 5(c) automatically documented for future reference,
illustrates a case that functions C, D and F are all used performance analysis and sharing with others.
between functions B and X. There may very likely be
redundancy among them. Further analysis can be used VI. Conclusions
to determine their similarity and opportunity for In this paper, we consider EDA as a problem domain.
aggregation into one SC. We have developed a pragmatic methodology that
Step4: Segregation of a legacy function combines Markov chain-based EDA procedure modeling
Our object-oriented system analysis of various EDA and knowledge extraction with an identification method
functions in a legacy system shows that duplications of of re-usable service components from the extracted EDA
code exist among various functions, which could be procedures. We have also designed a EDA service
segregated into small and reusable SCs. Figure 5(b) management platform architecture that adopts a service
illustrates the segregation of functions into commonly oriented architecture and the web service technology.
used sub-functions; each of these sub-functions can then The methodology development and platform design
be re-code into an independent SC. Limited by time and together will allow us to establish an environment for
resources, we currently consider EDA function quick, flexible and collaborative composition and
segregation a low priority and treat each EDA function as provision of EDA services.
the smallest unit for composing a SC.
Such efforts for SC identification allows EDA system References
developers to shorten EDA service development turn [Ecl07] WS BPEL2.0 Tutorial, www.eclipse.org/tptp/
around time, reduce cost, and make SC easily platform/documents/; 2007.
comprehensible to users while retaining good flexibility [FCC05] C. M. Fan, S.C. Chang, H. Chang, “Design of
for service composition. Collaborative Engineering Data System (CEDS): an
Application Case of Process Integration,” Proceedings of
ISSM2005, San Jose, CA, Sept. 2005, pp. 43-46.
V. Service Composition and Management Platform
[ITR05] International Technology Roadmap for Semiconductors
Once EDA SCs are defined, we design and develop a (ITRS), 2005.
EDA service management platform for service discovery, [MKI06] H. Morinaga, H. Kakinuma, T. Ito , T. Higashiki,
composition and provision. Figure 6 gives the platform “Development of a Platform for Collaborative Engineering
architecture. In the platform, we implement SCs Data Flow between Design and Manufacturing,” Proceedings
identified from legacy systems by using Web Service of ISSM2006, Tokyo, Sept. 25-27.
(WS) technology. The legacy EDA system we study is [SGC04] Y.-H. Su, R.-S. Guo, S.-C. Chang, “Manufacturing and
tightly coupled with GUI and can not be deployed as a Engineering Collaboration Mechanism between Foundry and
WS directly. We develop a WS wrapper for each legacy Fabless,” Proceedings of ISSM2004, Tokyo, Japan, Sept.
EDA functions. A wrapper can get input and output from
[TaA06] D. Tapscott, A. D. Williams, Wikinomics: How Mass
the legacy function it wraps without using the legacy GUI. Collaboration Changes Everything, Portfolio, 2006.
Hence a legacy EDA function can act as a background [WXZ05] Z.J. Wang, X.F. Xu, D.C. Zhan, “A Survey of
Business Component Identification Methods and Related
Techniques,” International Journal of Information
Technology, Vol. 2, No. 4, 2005, pp. 229-238.
[YBS06] Y. Yan, H. Boley, B. Spencer, “Tutorial on Service
Oriented Architecture,” http://icec06.net/WorkshopsAnd
Tutorials/SOATutorial/SOA-Tutorial : 2006.
Figure 5 EDA Service Component Identification
Figure 1 Schematic EDA System Structure
Figure 6 EDA Service Management Platform
Figure 3 Example of EDA Function Usage Data
of a User
Figure 4 An Exemplary Markov Chain Model
Figure 7 Drag-n-drop EDA Service Composition
0.02 yield and factorA
Generation of yield 0.58 Generation of
trend charts & reports Defect distribution
Correlation between Correlation between
0.02 factor B and factor A
yield and factor B 0.08
Figure 2 Exemplary EDA Function Flow Extracted from Usage Data