A Schema-Based Approach to CAD Task ... - UCSD VLSI CAD by fjzhangweiqun



A Schema-Based Approach to CAD Task Management

                    A DISSERTATION

                     for the degree of

                DOCTOR OF PHILOSOPHY
            Electrical and Computer Engineering


                   Jay Barrett Brockman

                Carnegie Mellon University
                 Pittsburgh, Pennsylvania
                        June, 1992
                                                                              Page ii


CAD frameworks are expected to provide a broad spectrum of services to designers
and CAD system developers, including tool integration, data management, process
management, and methodology management. One of the difficulties in realizing this
overall goal is the wide variation in requirements for modeling the information asso-
ciated with each of these services, and the rough or nonexistent interfaces between
them. One such gray area is the conceptual gap between tool invocation and higher
level design methodology management. To address this issue, we have introduced
the notion of tool-independent CAD tasks as an intermediate representation. A new
information model, called the task schema, is used to capture the dependencies
between classes of tool and data objects for a given design domain. In this paper, we
describe the task schema information model, and present its role in managing design
activity in the Hercules CAD Task Management System.
                                                                              Page iii


I can’t begin to express enough gratitude to Steve Director for his guidance, support,
and friendship throughout my years of grad school at Carnegie Mellon. While the
completion of my degree may mark the end of a chapter, I look forward to continuing
to work with Steve in the future. Next, I’d like to thank the other members of my the-
sis committee, Andrzej Strojwas and Art Westerberg of CMU and Tom Rhyne of
MCC Corporation for their careful review of my dissertation. None of this work
would have been possible without generous funding from the Semiconductor
Research Corporation and equipment provided by Digital and IBM.

Many, many thanks go to the students of the CAD Center at CMU, for everything
from their helpful insights on research to making grad school as much fun as it was.
In particular, I’d like to mention the following individuals who contributed so much
to the evolution of Hercules:

Marquet Anderson      Tom Cobourn           Peter Feldmann       Tony Gadient
Margarida Jacome      Kannan Krishna        Tony Leal            Juan Carlos Lopez
Becky Lott            Peter Sutton          Lei Zhou
                                                                            Page iv

Thanks also to Cathy Snyder, Lynn Philibin, and Elaine Lawrence for their adminis-
trative help and for keeping me on track.

Mom, Dad, Rob, Reed, Jean, Helen, Bob, Maren, Molly, and Zoe: I love you all.

Finally, I’d like to thank the following teachers, from Canton High School, Brown
University, and Carnegie Mellon University, whose example has taught me so much
about teaching:

Martin Badoian       Robert Rice
William Jordy        Joanna Ziegler
Stephen Director     Ronald Rohrer
                                                                          Page v


This dissertation is dedicated to my grandfather, Mr. Abraham Brockman.
                                                                       Page vi

CHAPTER 1        Introduction 9

CHAPTER 2        Previous Work 15
  2.1   Introduction 15
  2.2   Early Design Systems 16
        2.2.1 Environments for Exploratory Design 16
        2.2.2 Ulysses 18
        2.2.3 Yoda 20
  2.3   Design Databases and Tool Integration Systems 21
        2.3.1 Data-Oriented Design Systems and Design Process Control 21
        2.3.2 Cadweld: A Tool-Oriented Design System 22
  2.4   Recent Efforts in Design Methodology Management 24
        2.4.1 NELSIS 25
        2.4.2 van den Hamer and Treffers: “Data Flow Based Architecture” 26
        2.4.3 Chiueh and Katz: “History Model” 28
        2.4.4 Vov 29

CHAPTER 3        The Task Schema 30
  3.1   Information Modeling and Task Management 30
  3.2   Motivation for the Model—A Complex Task 32
  3.3   The Task Derivation Model and the Task Schema 33
        3.3.1 Task Entities 33
        3.3.2 Construction Rules and Tool Encapsulation 36
        3.3.3 Tasks 37
        3.3.4 Dependency Relationships and the Task Schema Diagram 38
        3.3.5 Representation of Alternative Construction Rules 41
  3.4   Summary of Task Schema and Task Derivation Models 43
  3.5   Persistent Storage of the Design Derivation History 45
        3.5.1 Mapping a Task Schema to the Relational Model 46
        3.5.2 Strengths and Limitation of a Schema-Based Task Database 49

CHAPTER 4        Designing a Design System 52
  4.1   Bottom-Up / Top-Down Approach 52
  4.2   Multiple Encapsulation of Tools 54
  4.3   Representing Task Scenarios 55
                                                                           Page vii

        4.3.1 Inspection 55
        4.3.2 Verification 56
        4.3.3 Editing Tasks and Versioning 57
        4.3.4 Consistency between Design Facets 60
        4.3.5 Tools Created during Design Process 63
  4.4   Representing Distributed Access to Tasks 64

CHAPTER 5        The Hercules CAD Task Management System 66
  5.1   Introduction 66
  5.2   The Task Tree 68
        5.2.1 Structure 68
        5.2.2 Operations 69
     Operations on the Extent of the Task Tree 70
     Operations on Working Sets Involving a Single Entity 71
     Operations on Working Sets Using Dependency Relation-
                      ships 72
     Operations that Create or Destroy Instances in the Task Data-
                      base 74
  5.3   The Hercules Graphical User Interface 76
        5.3.1 Organization 76
     The Task Window 77
     The Instance Browser Window 78
     The Help Facility 79
        5.3.2 User Interaction 81
     Running a Task 81
     The History Operation and the Use of Prototypes 84
     Forward-Chaining Query 86

CHAPTER 6        Conclusions 88

CHAPTER 7        Future Work 91
  7.1   Adding Hierarchy to the Task Schema 91
  7.2   Distributed Task Execution 91
  7.3   Development of Applications 92

APPENDIX A Representation of Tools and Data 93
                                      Page viii

  A.1 Classification with Types 93
  A.2 Functions as Typed Objects 95

References 99
CHAPTER 1                Introduction

Since their inception in the 1960s, integrated circuits have seen a tremendous rise in
complexity, of the designs themselves as well as in the process needed to complete
them. Today integrated circuits may contain millions of transistors, and advances in
technology are certain to increase this number by orders of magnitude. Furthermore,
a single IC chip is typically a system of highly complex and specialized subsystems,
where many ICs today contain both analog and digital processing circuitry, as well as
memory. In order to design such circuits, the skills of many engineers are often
needed, and the ability to efficiently communicate information about a design
between them is critical. The situation is further complicated when one expands
design responsibility to include manufacturing concerns. In order for a design to be
successful as a product, it must be able to be fabricated and tested economically,
while still meeting customer demands on quality and reliability.

Today’s ICs could not be produced without the aid of a computer. While the lithogra-
phy for the first integrated circuits was drawn with a straightedge and a razor, today,
graphical editors and placement and routing programs are needed to craft the physi-
cal layout of a chip. Simulation programs are required to verify the behavior of
designs, as well as to model the fabrication process. Computer programs are also
used to develop testing procedures, finding the minimal set of tests that need to be
performed on a circuit in order to guarantee that a chip meets specifications. The role
Introduction                                                                    Page 10

of computers in IC design has become so pervasive that the development and supply
of computer-aided design (CAD) tools has itself become a major industry. In order to
be able to produce chips that are competitive, IC design houses must continue to
invest in increasingly accurate, efficient, and specialized CAD software.

As the number and diversity of computer-aided design tools used by VLSI circuit
designers continue to grow, the need for systems that help manage the design process
increases. These design management systems have come to be known as CAD frame-
works. CAD frameworks are expected to provide a broad spectrum of services to
designers and CAD system developers, including tool integration, data management,
process management, and methodology management [37]. Some of the difficulties in
realizing this overall goal, however, are the wide variation in requirements for mod-
eling the information associated with each of these services, and the rough or nonex-
istent interfaces between them. Beginning with the Ulysses[16] and Cadweld[25]
systems, Carnegie Mellon’s focus in framework research has been to develop open
design systems that support simplified integration of new CAD tools and design
methodologies. Our current framework effort, called Odyssey[9], is aimed at provid-
ing extensive design process management capabilities. One of the main goals of
Odyssey has been to identify and deliver domain-independent design management
services, along with modeling languages that may be used to capture the knowledge
associated with a given domain. In essence, the specification of a design system for a
given domain may itself be viewed as a design problem; Odyssey’s objective is to
provide the facilities for realizing a framework for any given domain.

The Odyssey CAD Framework partitions design activities into four levels of abstrac-
tion: the component level, the resource level, the task level, and the problem level, as
shown in Fig. 1. This paradigm gives Odyssey a novel theoretical underpinning that
results in a very flexible and powerful CAD system. The component level is the lowest
level of abstraction in Odyssey. CAD components consist of raw CAD tools and their
requisite input and output files exactly as they come from their developers or distrib-
utors. For example, a CAD framework implemented for the domain of VLSI design
may include components such as the circuit simulator HSPICE [50], HSPICE input
decks, and HSPICE output files. Designers working directly at the component level
must therefore be familiar with all the syntactic details associated with each particu-
lar tool.
Introduction                                                                     Page 11

                                 Design Process Level


                               ckt                     device
                            simulator      netlist     model
                                        Task Level

                                                ckt simulator
                             netlist device model
                                     Resource Level

                      MetaSoftware                        CMU
                       HSPICE                           FABRICS

                                   Component Level
                FIGURE 1. Abstraction levels in Odyssey CAD Framework.

The next level of abstraction, the resource level, provides a first-order classification and
encapsulation of CAD components. CAD resources provide all component-level tools
and data with well-defined and consistent interfaces, thereby enabling them to inter-
act through the framework. At the resource level, designers may think of particular
tools, such as HSPICE, as being elements of a set of circuit simulators, where each ele-
ment has certain properties in common with all other elements of the set. Similarly,
files, such as an HSPICE input deck, can be broken down into resources such as
netlists, device model parameters and stimuli. Resource encapsulations thus shield
designers from the syntactic details of components, allowing designers to manipulate
tool and data objects at a more meaningful level of abstraction. Resource-level ser-
vices in Odyssey are handled by the Cyclops Resource Manager [24].

The highest level of abstraction in the Odyssey model, as implemented with the Min-
erva Design Process Planner, is the design process level [40]. At this level, the designer
Introduction                                                                    Page 12

carries out design directly in terms of design problems, such as “design an opera-
tional amplifier to meet a set of specifications,” or “verify the performance of this
ALU.” In order to enable designers to interact with designs at the process level, it is
necessary to have an intermediate representation that relates design activities to CAD
resources. In response to this issue, we introduce the notion of tool-independent
CAD tasks. Examples of such tasks are “perform a transient analysis of a circuit,” or
“generate a layout from a netlist,” where the binding of appropriate tools to a task is
subject to the resources currently available in the framework.

While Odyssey has been conceived to function as a complete design system that pro-
vides support facilities at each of the four levels of abstraction, clients may choose to
interact directly at any one of the intermediate levels. The cost associated with inter-
acting at a higher level is the need to characterize domain knowledge at that level.
For example, if a designer wishes to work directly at the component level, very little
effort is required to install tools into the system. In return, however, Odyssey pro-
vides few services, save perhaps a simpler command syntax for invoking certain
tools. Far greater benefits are available to designers working at the resource level,
most notably, the ability to assemble a suite of tools from different sources and enable
them to exchange data. In return for these benefits, however, tools and data must be
encapsulated. In general, the time and effort required to encapsulate tools can be con-
siderable, though the Cyclops Resource Manager provides facilities that help keep
this cost to a minimum. In addition, standardization efforts through organizations
such as the CAD Framework Initiative should further reduce the cost of encapsula-

While resource-level services focus primarily on making tools easier to integrate, the
task level in Odyssey is the first level that supports management of the design pro-
cess itself. In particular, the Hercules CAD Task Manager[13] provides the following

1. Support for coexistence and cooperation of a variety of heterogeneous CAD
   tools. This property concurs with the principal guidelines of the CAD Framework
   Initiative, a cooperative effort sponsored by several major CAD and workstation
   companies, begun in the late 1980’s. To satisfy this property, a design system must
   support design activities using CAD tools from different sources, with different
   data formats, that run across a network of computers. Most of this capability
   derives from the resource management facilities provided by Cyclops; Hercules
   makes use of these services to provide clients a more flexible view of tasks.
Introduction                                                                     Page 13

2. Support for concurrent design. Hercules supports access to tasks for multiple
   designers across a network of workstations.
3. Support for the development and execution of task flows. Hercules provides
   facilities for clients to compose task sequences, assign tool and data resources to
   these tasks, and then automatically control their execution. For example, suppose a
   user wants to extract a circuit from a layout and then simulate its performance and
   plot the results. Hercules supports the user in creating this three-step task with
   task construction rules, and then allows the user to assign a circuit extractor, simu-
   lator, and graphing tool to the task. Hercules then works with Cyclops to automat-
   ically execute the task.
4. Support for the capture and inspection of a persistent record of design activity
   (design history). While Cyclops provides facilities for encapsulating the actual
   design data, Hercules maintains a database of the metadata that records which tool
   and data resources were used in tasks. This enables designers to trace the deriva-
   tion history of a design in progress, and also supports backtracking and the use of
   prototypes to specify new design activities.
5. Support for client interaction. While Hercules provides a powerful graphical user
   interface, this feature has deeper implications. In particular, Hercules introduces
   an internal representation for tasks, called a task tree, that also forms the basis for
   visualizing tasks during both execution and browsing activities.
6. Customization so as to meet the needs of a given design environment. The above
   properties must be able to be applied to a variety of design domains.

Task management thus supports clients with significant services beyond those avail-
able through resource management alone. This dissertation presents an approach to
task management that incurs a very low marginal cost beyond that needed for tool
and data encapsulation, in terms of both system integration and task execution over-

The key to providing task management services at a low marginal cost is a new infor-
mation model for representing domain knowledge at the task level, called a task
schema. The task schema may be viewed as a dependency graph that specifies con-
struction rules by which tool and data resources can be combined to form tasks,
while providing a sufficient specification for automatically configuring a database to
store the design derivation history. A task schema not only plays a central role in
organizing information at the task level, but also serves as a blueprint for defining the
requirements of tool and data encapsulations. Furthermore, because it provides a for-
mal means for specifying the relationships between tool and data objects, a task
schema also supports the clients’ view of tasks. In short, a task schema is a powerful,
yet simple means for representing domain-specific, task-level information.
Introduction                                                                  Page 14

The remainder of this thesis will discuss the schema-based approach to CAD task
management. Chapter 2 provides a brief survey of previous work. Chapter 3 contin-
ues with a full development of the task schema information model. Next, Chapter 4
describes, with examples, how a task schema may itself be designed to represent
design activity for a given domain. Chapter 5 examines in detail the structures and
operations required for providing domain-independent, schema-based task manage-
ment services such as execution and browsing, and presents their implementation in
the Hercules CAD Task Management System. Having thus described the schema-
based approach to task management, Chapter 6 returns to take a closer look at sev-
eral related research projects, and to discuss their relationships with this research.
Chapter 7 draws conclusions about the schema-based approach to CAD task man-
agement and Chapter 8 outlines possible future extensions to this work.
CHAPTER 2                Previous Work

2.1 Introduction
The need for VLSI design management systems has been a growing concern since the
early 1980’s, a decade that culminated with the formation of the CAD Framework Ini-
tiative (CFI), “to develop industry acceptable guidelines for design automation
frameworks which will enable the coexistence and cooperation of a variety of tools
[17].” In general, the history of VLSI design management systems has been character-
ized by a wide diversity of opinion as to how CAD systems should be structured, and
as to what services they should provide. Throughout this history, there has been an
ongoing debate over which aspects of the design process should be automated, and
which should be left to the control of human designers.

Roughly speaking, CAD systems thus far have undergone three phases of develop-
ment. The first phase in VLSI CAD systems development was characterized by
design environments that generally employed a customized suite of tools and in
some cases sought to fully automate the design process. The difficulties encountered
and issues raised by these systems led to a more pragmatic second phase, which
focused upon methods for characterizing, storing, and encapsulating existing CAD
tools and data. The third and current phase in CAD systems marks a shift in empha-
sis from tools and data back to the design process itself, revisiting topics addressed
by some of the earliest systems, while building upon the tool and data infrastructure
Previous Work                                                                  Page 16

developed during the second phase. The work described in this dissertation is part of
this latest phase.

In this Chapter, we will provide a brief review of previous work in each of these three
phases of CAD systems development. Rather than attempting to cite an exhaustive
listing of all such systems, we will instead focus upon a few representative systems
and the manner in which they addressed certain key problems. In particular, we will
consider the following issues:

• how design methodologies are described and represented within the various sys-
• the roles of both the designer and the design system in triggering design actions;
• how systems represent the state of a design in progress and the extent to which
  they support the ability to return to a previous state and to apply an alternative
  approach towards reaching a new state.

2.2 Early Design Systems
By the late 1980’s, designers were demanding that CAD frameworks serve as a means
for standardizing the incompatibilities between the many tools available on the mar-
ket. Most of the earliest VLSI CAD systems, however, were not conceived as open
systems for integrating existing, foreign CAD tools, but rather as complete design
environments in which the tools, the design representations, and the framework were
customized to work together. Carnegie Mellon’s framework research began in
response to these systems with the Ulysses framework, in an effort to provide an
open architecture that would accomodate existing CAD tools.

In this section, we will first examine the motivations of these early design environ-
ments. Next, we will discuss the Ulysses framework [16], highlighting the aspects
that have had the greatest impact on this research. Finally, we will conclude with a
review of the VLSI system planner, Yoda [26].

2.2.1 Environments for Exploratory Design
Following the publication of Mead and Conway’s [49] structured approach to VLSI
design, there was considerable optimism towards the possibility of fully automating
the VLSI design process. One approach to VLSI design automation was through sili-
con compilers. Silicon compilers such as Bristle Blocks [42] and MacPitts [58] investi-
Previous Work                                                                    Page 17

gated algorithmic transformations from either behavioral or schematic description of
circuits down to the physical layout of chips. While they have since met with some
success for generating routine modules, silicon compilers were limited in their ability
to produce competitive designs for complete chips from arbitrary specifications.
These limitations arose from the fact that prior knowledge of optimal algorithms for
transforming behavior to structure were oftentimes not available. In practice, the
design of complex systems involves the analysis of various tradeoffs, and there is no
unique path from an initial set of specifications to a final, working product. In short,
the activities of a silicon compiler were limited to synthesis, and did not include verifi-
cation or optimization. Finally, with few exceptions [65], silicon compilers did not
allow the designer to intervene in the design process, nor did they support backtrack-
ing of any kind.

By contrast, design environments such as Designer’s Workbench [54], Palladio [14] ,
ADAM [44], Schema [23], and Ulysses [16] viewed design not as a linear, uninter-
rupted sequence of transformations, but rather as an iterative, exploratory process.
Although these systems differed greatly in implementation and in services offered,
each embodied the following notion of a design process:

• Design consists of applying an appropriate operator to move a design from a “cur-
  rent state” towards a “goal state.”
• Should it become apparent at some point in the process that a design will fail to
  meet its goal specifications, it is then necessary to backtrack to an earlier state and
  try a different operation.

The exploratory nature of design leads to two sources of complexity for the designer.
On the one hand, the designer must keep track of different versions of his or her
design data, each corresponding to a different outcome of an alternative design deci-
sion. On the other hand, the designer is confronted with a wide assortment of tools
that can be applied at any point in time during the design process, and he or she must
be able to select an appropriate tool at the proper time, and also must be skilled in
actually running the tool.

The design environments listed above took a variety of approaches towards making
exploratory design more manageable. Designer’s Workbench [54] from Bell Labora-
tories was unique at the time in adopting a “less is more” viewpoint towards design
process support. Rather than attempting to control the design process, Designer’s
Workbench instead concentrated upon simplifying tool invocation across a network
Previous Work                                                                   Page 18

of computers through a common user interface and facilities for tool integration.
Additionally, Designer’s Workbench could check the syntax of input and output files
between tools, and could automatically translate a file if the output format of one tool
differed from the input format of another. Designer’s Workbench also contained a
design library management facility and could flag data that was out-of-date as a
result of changes to certain files. The system was deployed in an industrial setting
and was well-received by the engineers who used it.

While Designer’s Workbench left design process control issues up to the designer,
Palladio [14] , ADAM [44], Schema [23], and Ulysses [16] each used the computer to
fully or partially automate the sequencing of design operations, as well as to main-
tain the status of performance or structural constraints on the design. In each of these
systems, artificial intelligence techniques were used to provide a central control
mechanism. While Palladio, ADAM, and Schema were build to use customized suites
of tools and operators, Ulysses was developed to accomodate off-the-shelf CAD
tools. In the next section, we will briefly review Ulysses, considering both its
approach to tool integration and to design methodology management.

2.2.2 Ulysses
Ulysses[16] was the first attempt at providing an open framework for integrating a
heterogeneous set of CAD tools to automatically perform a variety of design tasks. In
creating Ulysses, Bushnell set the ambitious goal of providing an environment that
supported not only task execution but also design methodology management and
some aspects of planning. The environment was intended to behave as an intelligent
assistant to the designer, with sufficient knowledge about design goals, CAD tool
operation, exception handling, and activity scheduling, to guide the user to a satisfac-
tory design solution.

Bushnell recognized that the VLSI design process is characterized by exploratory as
well as routine design activities. While routine activities permit a sequential applica-
tion of CAD tools and hence are amenable to a procedural programming style,
exploratory activities allow only weak problem solving methods that are better
suited to a goal-oriented programming paradigm. To achieve these diverse and ill-
conditioned objectives, Bushnell employed a knowledge-based expert system to con-
trol CAD tool execution.
Previous Work                                                                  Page 19

Ulysses was built upon a blackboard architecture [28] coupled with a procedural
descriptive language for encoding the design methodology. Both the CAD tools and
the human user were represented as knowledge sources in Ulysses that were invoked in
response to the current state of the blackboard in order to move closer to the goal
state. A rating policy was also represented as a knowledge source that evaluated the
current design point with respect to criteria supplied either by a design task or the
user. The blackboard in Ulysses served as the general data repository for the design
in progress and was divided into three section. The CAD-tool section held pointers to
the CAD tools and the design files. The assertion section contained error information
should CAD tool execution terminate abnormally. Finally the scheduling section
maintained current design goals as well as the broader design methodology. A snap-
shot of the blackboard at any point in time was a design point; the complete collection
of design points with the temporal links between them comprised the design space.

The original blackboard model demonstrated by the Hearsay-II speech understand-
ing system [28] relied solely upon goals posted on the blackboard to control knowl-
edge source invocation; it provided no formal means for allowing competing
problem solving methods. Such a control mechanism was overly restrictive for a
CAD framework for, as Bushnell noted, VLSI design can proceed according to a vari-
ety of approaches, such as standard cell versus manual layout, that could be used in
exclusion or in conjunction to obtain a satisfactory design solution. He developed a
Scripts Language for specifying the design methodology. The Scripts Language pro-
vided constructs for declaring CAD file types, describing the knowledge sources, and
encoding tasks and consistency maintenance rules. The tasks themselves were large-
grain production rules whose right-hand-side could procedurally call several CAD
tools. A Scripts compiler translated the design methodology into production rules that
were interpreted by the scheduler.

As an early attempt at an open design framework, Ulysses raised many issues that
deserved further attention. Ulysses’s goal of integrating all of these features into a
single environment proved to be its greatest liability. In particular, the Scripts Lan-
guage was a cumbersome, if not untenable, means for capturing the full design meth-
odology, including tool integration as well as methodology management. Although
Ulysses tasks did allow for the opportunistic use of CAD tools at runtime, the Scripts
programmer had to have a detailed understanding of available resources. Scripts
programming was further hampered by the fact that Ulysses did not provide a clear
method for organizing information at the conceptual level prior to coding. Subse-
Previous Work                                                                   Page 20

quent research efforts have focused upon issues highlighted by Ulysses, such as CAD
tool integration, task specification, and design space navigation.

2.2.3 Yoda
While Knapp and Bushnell employed knowledge-based methods to directly control
CAD tool execution in ADAM and Ulysses, Dewey introduced a new level of abstrac-
tion into the design process, called conceptual design [26], to support a design in ana-
lyzing design tradeoffs prior to execution. He demonstrated the feasibility of
conceptual design with Yoda[26], a system planner for the domain of digital filter

Dewey observed that much of VLSI design today is conducted in a top-down, hierar-
chical manner. In such a design style, conceptual errors made early in the design pro-
cess can be very costly, greatly reducing chances that the final design will be
completed on schedule and meet specifications. Yoda allowed designers to examine
the outcomes of alternative high-level decisions before beginning the expensive pro-
cess of instantiating a design, thus allowing a breadth-first rather than depth-first
exploration of the design space. Yoda was implemented as a self-contained program
with two subsystems. The alternatives exploration subsystem supported the user in
checking constraints, displaying design options, and recording decisions. The design
assistance subsystem integrated design advisors and performance prediction models
as knowledge sources to aid the designer in making proper decisions. Yoda’s results
were impressive; it was able to predict the area, speed, and power dissipation of three
commercial digital filter IC’s to within ten percent from high-level design descrip-

As a stand-alone CAD tool, Yoda treated planning as an activity apart from the rest of
the design process that should be completed before design instantiation begins. We
believe that opening Yoda’s closed architecture to work in conjunction with a CAD
framework will have profound advantages for both system planning and the frame-
work itself. In Minerva, Jacome is exploring a more general view of planning that dis-
tributes planning activities throughout the design process [40]. By integrating a
generalized, distributed planner into a CAD framework, the task and resource man-
agement portions of the framework can support the planner by integrating design
advisors and prediction models as CAD tools and supervising task execution, while
the planner can assist the framework by managing design goals. The requisite com-
Previous Work                                                                   Page 21

munication protocol between the planner and the framework has had a direct impact
on the Odyssey framework architecture.

2.3 Design Databases and Tool Integration Systems
Given the theoretical basis set by the early design environments, the second genera-
tion of VLSI CAD systems addressed mechanisms for making tools and data more
accessible to designers. On one side, the second phase of CAD system development
saw the advent of data-oriented design systems that emphasize modeling and storing
design data, while on the other it witnessed the introduction of tool-oriented systems
that emphasize tool integration. As a result, it also marked a division that persists
until today in which tool management and data management were to be treated as
separate issues. In this dissertation, we will argue that this bifurcation is unnecessary
and overly restrictive.

2.3.1 Data-Oriented Design Systems and Design Process Control
Data-oriented design systems, such as OCT [36] from the University of California at
Berkeley and PLAYOUT [56] from the University of Kaiserslauten in Germany, have
greatly eased the burden on designers for organizing large amounts of design data.
Typically, these systems provide a data model and a central design database built
upon this model to store instantiations of different views of a design. In these sys-
tems, CAD tools must adhere to strict data type and access requirements, which in
OCT are called policies. In general, CAD tools must be developed expressly to work
within a data-oriented design system; incorporating existing, foreign CAD tools into
the system requires rewriting the tools’ input and output sections or providing a pro-
cedureal interface to meet policy requirements. A further limitation is that since the
data model does not provide a means of representing the functionality of the tools,
these systems cannot support the opportunistic use of competing tools. Thus, if sev-
eral tools can be used interchangeably to perform a function, the system cannot pro-
vide support in arbitrating between them. Finally, since tools are treated at a low
level of abstraction, the user must know the proper invocation sequences to run the
tools. Because of the disparity between the sophistication of data and tool modeling,
CAD tasks can only be supported at a low level of abstraction.
Previous Work                                                                    Page 22

2.3.2 Cadweld: A Tool-Oriented Design System
While OCT provided data modeling and storage facilities without chararacterizing
tools, Cadweld [25], from Carnegie Mellon, provided tool modeling and integration
service exclusive of design data. In a sense, these two systems were the complement
of each other, and as we will show, they were ultimately confronted with the same
limitations in regard to task management.

Deciding that full design automation as sought by Ulysses was a distant goal, Daniell
developed Cadweld with the intent of making CAD tools more accessible to users.
Cadweld’s major contribution was alleviating the bottleneck of the Ulysses’s Scripts
by encapsulating CAD tools and tasks as objects in an object-oriented programming
paradigm. Unlike Ulysses, which concentrated the entire design methodology in
compiled Scripts, Cadweld distributed tool-specific control information in CAD tool
knowledge objects (CTKO’s) [25]. While Designer’s Workbench [54] left all decisions as
to which tools to invoke up to the designer, CTKO’s in Cadweld were requested to
volunteer to activate, in response to blackboard posts issued by the designer or by
tasks. Final control decisions were made by the initiator of the posts. Tools were inte-
grated into the system by binding them to representative models to create CTKO’s
that gave each of the heterogeneous tools a common look and feel within the frame-
work. A CTKO had six parts, some of which were optional:

• Frame Body–Contained declarative information about the tool
• Control Body–Showed how the tool was controlled (i.e. what it can volunteer to do)
• Argument Body–Modeled each command line argument that was used to invoke
  the tool
• External Dependencies–Showed hidden computer resources that the tool required
• File Body–Held runtime pointers to files that the tool either read or created
• Error Handlers–Modeled how to handle different errors encountered in using the

Individual CTKO’s were modeled within a CAD tool class hierarchy that enabled more
specific classes of tools, such as circuit simulators and timing simulators, to inherit
attributes from more generic classes, such as simulators.

The content of Cadweld and Ulysses task descriptions were similar in that both spec-
ified a sequence of design operations, with the important difference that the author of
Cadweld tasks needed not be aware of the specific CAD tools available in the frame-
Previous Work                                                                   Page 23

work that could perform these operations. Since the CTKO’s abstracted tools to a
higher conceptual level, Cadweld tasks could request tool volunteers by class. Thus
while a Ulysses Script would explicitly declare the circuit simulator Spice as an avail-
able knowledge source, a Cadweld task object would issue a “simulate circuit” post
to the blackboard and all CTKO’s or other task objects whose control bodies match
the post would have the opportunity to volunteer for execution. Should more than
one CTKO have responded, the calling task arbitrated by sorting volunteers by frame
body attributes such as “computing-effort” or “robustness”.

While Cadweld employed a blackboard architecture because of its demonstrated suc-
cess in Ulysses, the control requirements of the two systems were very different.
Since Ulysses’s goal was design automation, it needed an expert system or equivalent
weak method to provide automatic inferencing. Cadweld, on the other hand, set the
objective of improved designer interaction that greatly reduced the requirements for
automatic decision making. Because Cadweld’s control mechanism is not driven by
the current design state and design goals, it does not function as a blackboard in the
sense of Hearsay-II or Ulysses and might be better viewed as object-oriented message

Cadweld explicitly ignored any data modeling. Specifically, in creating a CTKO, Cad-
weld assumed that all information needed to control tool invocation could be mod-
eled independent of the content of data files. Unfortunately, in many instances,
important control information is contained in data files. For example, a circuit simu-
lator such as Spice may be capable of performing D.C., transient, or frequency
domain analysis of a circuit according to declarations stated in the simulator input
file. Similarly, data-independent tool arbitration will only be valid in very limited
cases; even attributes such as “robustness” are highly dependent upon tool input

While the object-oriented approach to CAD tool control employed in Cadweld
allowed competing tools to be used interchangeably, there is no systematic method
for integrating tools with different data formats. Because there is no data model for
the design itself, the design or an application program must be able to comprehend
the design at the file level. As a result, tool-oriented systems such as Cadweld ulti-
mately suffer the same problem as data-oriented systems: the mismatch between data
and tool modeling forces tasks to be represented at an overall low level of abstraction.
Previous Work                                                                                Page 24

As we will show in this dissertation, in order to provide for more flexible tool integra-
tion and control, data and tool modeling must be considered simultaneously.

2.4 Recent Efforts in Design Methodology Management
The third and current phase of framework development represents a shift in empha-
sis from CAD tools and data back to the design process itself, revisiting issues that
were raised by some of the early design environments. Services provided by this lat-
est wave of systems are sometimes grouped under the category “design methodol-
ogy management,” and address issues such as which CAD tools (and other design
methods) and design data are used, how they are used, by whom, and in what order
[33]. At present, there are no CAD systems widely in use that claim to provide broad
design methodology management support, and the aims and goals of such systems
are still very much a topic of research1. One factor that distinguishes this most recent
wave of design systems from the early design environments, however, is that there is
a trend away from systems that attempt to centralize design process control and
towards systems that aid a designer or team of designers in coordinating design

While early knowledge-based design environments such as ADAM [44] and Ulysses
[16] sought to hide the design process control structure from the user, recent design
methodology management systems have typically tried to make the control structure
readily accessible to designers. The most popular approach to representing CAD pro-
cesses has been through graph-based methods that capture a design flow. In general,
these flow graphs model a sequence of transfers between tools and data. Various
types of graphs have been used, including bipartite flowcharts [51], hierarchical net-
works [2] [7] [21] [34], and Petri nets [8] [19] [41].

In making the control structure accessible to designers, these recent flow-based sys-
tems have several practical advantages over their predecessors. First of all, designers
have a greater awareness of which operations the system is able to perform, and are
less likely to be surprised by unexpected behavior. Secondly, it is generally easier to

1. In the Odyssey CAD Framework, design methodology management, as defined above, is split
between the task level (Hercules) and the design problem level (Minerva). This partitioning is not just
a matter of convenience, but rather reflects a particular philosophy: that the management of tool inde-
pendent CAD tasks and the decomposition of design problems are separate (though related) issues.
Previous Work                                                                   Page 25

add new operations. This was observed to be a problem with Ulysses in particular,
where the effort required to modify a script or change the rule base was much more
difficult than running a tool without the framework. A third advantage of presenting
flows to the designer is that it provides a simple mechanism for tracking the progress
of a design task. Finally, since flows link design data with tools, they make it possible
to browse design data with respect to activities performed, as well as to simplify the
implementation of backtracking and redo operations. These features have been incor-
porated into several of the aformentioned systems, as well as into Hercules.

In this Section, we will examine a few of the recent flow-based systems that most help
clarify the approach taken by Hercules. In particular, we will consider two nascent
trends: the increased importance of modeling and storing design “metadata,” or
information about a design, and the development and usage of formal models for
describing the configuration of a CAD system.

2.4.1 NELSIS
Researchers at the Delft University of Technology in The Netherlands were the first to
clearly define the role of design metadata—high level information about the structure
and status of a design—in a CAD framework. As stated in their paper, “Meta Data
Management in the NELSIS CAD Framework” at the 1990 Design Automation Con-

“The crucial role of CAD frameworks in the area of tool integration has often been
emphasized. . . . However, more is to be earned than just having a common reposi-
tory for design data. By organizing the design information in a way that relates to the
designer’s perception and by keeping track of the evolution of the design, the frame-
work becomes a system-wide facility that helps the designer to control his design
activities. The net result is a gain in design productivity, because the designer can
concentrate on his main task, electronic design [61].”

NELSIS uses the Object Type Oriented Data (OTO-D) model [61] to construct a
schema for organizing design metadata as well as design data itself. One of the cen-
tral components of the NELSIS framework is a metadata management module that
understands the OTO-D model. Framework services are built on top of this module
that include support for design transactions and versioning. The authors of [61] also
discuss the possibility for a design methodology manager that may be “configured
Previous Work                                                                 Page 26

with knowledge about the available tools and their dependencies.” A paper pub-
lished the following year describes design flow management in NELSIS [7], which
bears a strong relationship to the work done at Philips that is discussed in the next

2.4.2 van den Hamer and Treffers: “Data Flow Based Architecture”
One of the main issues in flow-based design management is deciding which data to
assign to flows. The Data Flow Based Architecture [34] by van den Hamer and Tref-
fers of Philips Research Labs was the first work to suggest that a design derivation
history based on flows may be sufficient for organizing design data without the need
for additional constructs. The Philips approach to integrating multi-tool design envi-
ronments is based upon constructing a data flow model for tools and “methodolo-
gies” in the design environment and storing this model in a database. Like NELSIS,
van den Hamer and Treffers use the OTO-D [61] model to define their schema for
design metadata. This same model that formally describes the domain-specific con-
figuration of the design system is also used as the means for organizing and accessing
design data, hence bridging the gap between design process and design data man-
agement. As a result of storing flow definitions and and design meta-data in a com-
mon database, the system is easily able to process queries such as “find the
simulations that were performed for this netlist [34].”

The Philips information architecture is described in terms of three layers which are
related, but not identical to, the levels of abstraction in Odyssey. These layers also
have analogs with the cell/port model that is commonly used for describing electri-
cal networks. The first layer in the Philips model describes tools and other functional
units using flowtypes, where each flowtype can have an arbitrary number of input
and output pins. Fig. 2 illustrates an example flowtype for a CompareNetlists func-
tion that corresponds to a simple design tool. A flowtype is thus analogous to an

                           Net1      Compare
                                     Netlists         Difs

                    FIGURE 2. Example Flowtype (from [34])

encapsulated tool at the resource level in Odyssey.
Previous Work                                                                              Page 27

In the second layer of this model, flowtypes are instantiated as flows, which may in
turn be connected to create flowmaps, as shown in Fig. 3.

                                 Layout                  Netlist

        Generate                                                                Compare
         Netlist                                                                Netlists


     FIGURE 3. Example flow map consisting of five interconnected flows (from [34])

The third and final layer in the Philips model deals with handling the metadata gen-
erated when flows are executed. A run represents a single execution of a flow. Design
representations correspond to the individual units of data that are generated at a sin-
gle output pin during a given run. Together, runs and representations capture much
the same information that is stored in the task database in Hercules: which data
objects were used and created by which tools.

While the Philips approach and Hercules provide many of the same services, there
are significant differences in the user’s view of the system, in the modeling of tools,
and in the way that metadata is stored. As will be discussed in Chapter 5, flow repre-
sentations in Hercules are transient: they are derived from the task schema as needed
and destroyed when a design activity is complete. By contrast, flows in the Philips
approach form a central part of the persistent characterization of a design system.

A further difference between the two systems stems from the fact that flowtypes in
the Philips architecture are defined around particular tools.1 As we will show,
because of the parallel treatment of tools and data in the task schema, Hercules offers
a high degree of flexibility in assigning tools to task, uniformity in the user interface,
and the ability to accomodate tasks that create tools during the design process.

1. The Philips authors, however, are currently pursuing the concept of “pin-compatible” flowtypes.
Previous Work                                                                   Page 28

Interestingly, both the Philips and NELSIS papers use the terms “flow” and “method-
ology” almost interchangeably, at least to the extent of stating that a flow-based
model can be constructed for design methodologies. Odyssey makes no such state-
ments, and we believe that the difference is deeper than a choice of terminology. In
our view, protracted tool sequences can rarely be specified in advance during a cre-
ative design process. In our limited experience with Hercules as a CAD system, we
have observed that designers prefer to approach designs a step at a time, examining
results before continuing with the design process. While construction rules embodied
in a task schema in Hercules tell a designer how to create a given object, they do not
constrain him or her to create objects in any fixed sequence. In the Philips and NEL-
SIS systems, users begin a design activity by choosing a flow, in Hercules, users select
a goal design object.

In a broader sense, however, the similarities between Hercules and the Philips and
NELSIS systems are more important than their differences. By recognizing the poten-
tial of semantic models for representing design metadata, these systems mark a sig-
nificant departure from earlier systems, and may well lead to more advanced design
process management support in the future.

2.4.3 Chiueh and Katz: “History Model”
Chiueh and Katz of the University of California at Berkeley have also developed a
history management system [21] that is conceptually similar to the Philips flow-
based approach. The system has been implemented on top of the OCT [36] database.
The Berkeley system uses task templates as building blocks for constructing hierarchi-
cally nested task flows. Like flowtypes in the Philips system, task templates are hard-
wired to specific tools, in that an encapsulated tool is a primitive task template.

In this system, tasks are always invoked within the context of a design activity, a cohe-
sive unit that associates operations with data. The Berkeley history model uses activ-
ity threads to maintain a record of which tasks have been performed. While van den
Hamer and Treffers used language-based queries into the design derivation history
to identify data object, Chiueh and Katz use the notion of moving an activity cursor to
roll back to a previous design point. For example, if a design implemented a logic cir-
cuit using standard cells and then wished to reimplement the same circuit using a
PLA, he or she could reposition the cursor to the appropriate point along the stan-
dard cell thread, and then create a new activity branch using a “create PLA” task.
Previous Work                                                                    Page 29

Although the user interface of this system is not described in [21], this notion of a cur-
sor should lend itself well to a graphical representation. As we will discuss in Chap-
ter 5, the Hercules user interface employs a form-based, graphical query system that
combines the flexibility of the Philips language-based system with the potential ease
of use offered by activity threads.

2.4.4 Vov
Vov [19], by Casotto at the University of California at Berkeley, is a design system
that attempts to non-intrusively capture the actions performed by a designer and
make this record available for reuse. Vov starts with the assumption that design sys-
tems are so complex that a proper characterization of tool and data types is intracta-
ble. Rather than encapsulating tools according to a functional blueprint that
anticipates the context in which tools are used, Vov considers all tools and their
behaviors to be unique. Tool encapsulation or integration into Vov involves simply
binding tools with agents that produce markers stating that a given tool has been
invoked, along with markers for its input and output data. These markers are stored
in the form of a Petri net. By tracing paths through the Petri net, designers may view
the history of tool invocations that led up to a given design object, and edit this
sequence in order to produce new objects.

While the overhead required for tool integration in Vov is small, the semanatic con-
tent of design metadata captured by the system is low. This ultimately limits the
extent of design support services that Vov can provide. In terms of the Odyssey three-
level partitioning of framework services, Vov captures and manipulates the design
history only at the component level. While novices can benefit from the experience of
advanced designers by examining and re-executing their traces, no attempt is made
to generalize these activities beyond the sequence of tool invocations. The informa-
tion shared is thus purely operational, and is limited to particular tools.

The issues raised by Vov regarding the difficulties of characterizing tools and their
behaviors are real, yet rather than abandoning efforts to provide high-level design
support, standardization bottlenecks should be confronted. Hercules raises the level
of abstraction from tools and data to tool independent CAD tasks. As we will show, a
task schema is an explicit attempt to capture knowledge about tasks as tool indepen-
dent design functions, what their dependencies are, and how design objects in gen-
eral are to be created.
CHAPTER 3                 The Task Schema

3.1 Information Modeling and Task Management
As discussed in Chapter 1, one of the main goals of the Odyssey CAD Framework
has been to identify and provide domain-independent design management services,
along with modeling languages for capturing knowledge about a given domain. At
the task level, a domain is characterized through the definition of a task schema. In
this chapter, we will discuss the essential features of a task schema and demonstrate
its role in organizing design objects at the task level.

In general, a data schema may be defined as a structural model that specifies an orga-
nization for a collection of data objects. It accomplishes this by defining the different
types of objects in the organization as well as the structural rules that express the gen-
eral relationships between objects. A collection of objects that has been organized
according to a data schema is a database. For example, a database that stores informa-
tion for airline reservations may include types such as passengers, flights, and air-
ports. Structural rules would include statements such as one passenger can be
booked on n flights, each flight carries m passengers, and each flight has exactly one
airport as its final destination. A data schema is defined using a data modeling lan-
guage, or simply, data model. Some data models currently in use include the entity-
relationship model[20] and the EXPRESS language [29] and the OTO-D [61] model. It
The Task Schema                                                                 Page 31

may be observed that a data model itself may be described as a data schema in a
higher order data modeling language.

While in general, a good data schema should come naturally, it does not necessarily
come easily. As van den Hamer points out [34], data schemata are condensed specifi-
cations, and at least with current database technology, changes to a data schema are
as painful as changes to any other specifications. For this reason, a data schema
should be carefully designed and verified before it is put into use. While a data
schema constrains the information that can be entered into a database, the kinds of
services that a database system can provide derives from these very constraints. For
example, while a database system built upon the airline schema above may not store
a passenger’s favorite city, the schema does make it easy for a ticket agent to process
complex queries such as finding the final destination for a given passenger.

As difficult as it is to design a schema for a database, the problem of designing a com-
prehensive schema for a CAD framework is worse, in that a framework must manage
not only design data, but also the design process. Odyssey attempts to make this
problem more tractable by partitioning design services into levels of abstraction,
where each level can have its own schema, and the interfaces between them are clean.
To specify information at the task level, we have introduced a task dependency model
that can be used to design a task schema for a given CAD domain. A task schema is
similar to a data schema, in that it provides a sufficient specification for automatically
configuring a task database that stores the derivation history for a design or group of
designs in progress. It is more than a data schema, however, as it also specifies the
construction rules by which tool and data resources can be combined to create
instances of other resources. Thus, a task schema not only defines mechanisms for
storing and browsing the results of tasks, but also supports designers in formulating
and executing tasks. In a task schema, classes of tool and data objects are represented
as entities, and the dependencies between them, as relationships. The task depen-
dency model, which is analogous to a data model for a data schema, is actually itself
a schema that specifies the rules for creating a valid task schema. We employ a meta-
model, also consisting of entities and relationships, for describing the task depen-
dency model.

We begin the remainder of this chapter with an example of a complex task from the
domain of circuit optimization that will serve to highlight some of the features
needed in the design derivation model and task schema. Next we continue with the
The Task Schema                                                                 Page 32

incremental development of the task derivation model, illustrating each feature of the
model with an example task schema, as well as a partial task database that has been
built upon the schema. We conclude with a summary of the task derivation model.

3.2 Motivation for the Model—A Complex Task
Although manufacturing-based design techniques such as circuit optimization have
existed for over twenty-five years, they still have not gained popular acceptance
among designers. One reason for this lack of use is the difficulty of integrating these
methods with common design practice, because of the complexity of tool and data
management involved.

To carry out integrated circuit (IC) fabrication process or circuit optimization, design-
ers are faced with making a number of choices. The first major choice is the optimiza-
tion method. This decision is complicated by the fact that there are many options
available where the advantages of one approach over another depend upon factors
such as the circuit size and type, e.g. analog or digital. Once the decision is made
about the optimization method, other choices must be made. For example, a macro-
modeling based optimization method requires decisions concerning experimental
plan generation, variable screening and regression, as well as which simulator to use.

The designer must also deal with many issues concerning the management of tools
and data. One tool/data management issue is the difficulty of versioning with
respect to the optimization task itself. For example, for IC fabrication process optimi-
zation task, there might exist an initial version, a tuned version and a final optimized
version of process inputs. Response surfaces or macromodels introduce complica-
tions that arise from the fact that a macromodel is created during a task as a piece of
data, and may later be compiled and run as a tool. Furthermore, a macromodel is a
single entity that can alternately be regarded as a tool or data: a tool when used in
place of a simulator, and data when its coefficients are used to determine a gradient
for optimization. Finally, entire tasks may have multiple runs with small modifica-
tions. For example, circuits may often need to be optimized numerous times for dif-
ferent conditions, such as delay requirements or multiple fabrication processes.

As we have shown, yield optimization tasks encompass many steps, present many
options at each step, entail complex relationships between tool and data objects, and
require that tools and data must be shared between designers. Given this scenario, it
The Task Schema                                                                 Page 33

is not surprising that few designers to date have embraced optimization techniques
for regular usage. The Odyssey CAD Framework can aid in this process by support-
ing such data and tool management issues.

In order to integrate tasks of this complexity into a CAD Framework, it is first neces-
sary to have a formal representation that specifies the tools, data, and the actions to
be performed. An important factor that must be considered is that the representation
of tasks should be independent of the specific tools that are used in executing those
tasks. Secondly, as in the case with macromodels, tools are sometimes created and
installed as part of the design process. Thirdly, it may be observed that actual design
methodologies rarely follow the uninterrupted batch sequences that are modeled by
flows; in practice, designers tend to execute tasks incrementally, checking the results
after each stage, and often backtracking to change either the data or methods used
before proceeding. Finally, the various tasks performed during yield optimization are
themselves interrelated.

3.3 The Task Derivation Model and the Task Schema

3.3.1 Task Entities
Computer-aided design activities typically involve the manipulation of a wide vari-
ety of objects. As we have illustrated above, for representing information at the task
level, tools as well as data must be considered design objects. As a first step towards
developing the task derivation model, it is useful to organize sets of conceptually
similar objects into classes. Thus in a system for the design of VLSI circuits, possible
classes would include the set of all netlists, the set of all device model parameters,
and the set of all circuit simulators. In a task schema, we refer to these sets as entity
types and elements of these sets as entity instances. In Fig. 4, a container paradigm is
used to illustrate the relationship between entity types and entity instances. Entity
types are shown as boxes and the instances of those types are shown as spheres
above the boxes.

In type theory [3], the Axiom of Specification or the Comprehension Axiom states that
instances of a type may be defined as all those objects that possess a certain set of
properties. For entity types in the task schema, we can partition these properties into
two categories: temporal and definitive. The first category, temporal properties, are
used to annotate entity instances with general pertinent information at the time that
The Task Schema                                                                  Page 34


            adapts               fall          nominal
                                time            cmos

                              circuit                              inverter
            hspice                               cmos
                               perf             low vt

           circuit                          device model
         simulator          fabrics          parameters            op-amp

                         fab process                                 netlist

                           FIGURE 4. Entity types and instances.

an instance is created. Examples of temporal properties would be the date and time
when an instance was created, the designer who created it, and some designer com-
ments. While the set of temporal properties are in general common to all entity types
in a schema, definitive properties are those attributes particular to each entity type that
define its unique nature. Definitive properties are used to describe tools as well as
data, and form the basis for linking the task level and resource level in Odyssey.

The goals of resource management, as supported by the Cyclops Resource Manager,
are to shield the designer from the syntactic details of CAD tool execution, as well as
to provide a common means for accessing design information, regardless of the par-
ticular CAD tool used for producing those results. By providing a uniform approach
to tool and data encapsulation, resource management effectively reduces the band-
width of information required at the task level. The approaches to resource manage-
ment and task management in Odyssey are similar, in that both methodologies
provide information models that allow framework developers to customize schemata
to meet their needs. While the Hercules information model for tasks employs entities
and relationships, the Cyclops model for tool and data encapsulation is based on
The Task Schema                                                                          Page 35

frames of slot-value pairs [24]. Through the use of frames, Cyclops can provide Her-
cules with generalized representations of the definitive properties of entities.

As an example, consider the problem of representing netlists. A netlist is a symbolic
description of a circuit that specifies the interconnection between electrical devices,
and hence serves as input to a wide variety of CAD tools. Although the syntax for
describing a netlist varies from tool to tool, the semantic content essentially remains
the same. If a schema is defined that captures the semantic content of a netlist, indi-
vidual tool encapsulations can translate the schema to syntactically correct input for
that tool. For example, in one design system built with Hercules and Cyclops, the
netlist schema was based upon the CAD Framework Initiative “five box” model [18].
Fig. 5 shows the CFI object model for a netlist and the corresponding frame represen-
           Lib                     Cell      contains                      Port

                      describes           contains              connects          describes
                                                        Net     connects

                                  CellInst                             PortInst

                      frame Cell {
                         presentsPort: list-of Port;
                         containsNet: list-of Net;
                         containsCellInst: list-of CellInst;
                         describesCellInst: list-of CellInst;

                      frame Net {
                         connectsPort: list-of Port;
                         connectsPortInst: list-of PortInst;

                      . . .

                  FIGURE 5. Frame-based representation of a netlist.

The most important decision when encapsulating a tool is to determine how to sepa-
rate its behavior from its input and output requirements in a manner such that it can
The Task Schema                                                                      Page 36

be classified as an entity. This leads to a view of tools as strongly typed functions, and
implies that tools should be considered in the context of how they are to be used in
design before they are encapsulated. In the following section, we will show how rules
embodied in the task schema are used to specify the functional encapsulation of

3.3.2 Construction Rules and Tool Encapsulation
In a task schema, all design objects are represented by entities, whether they are tools
or data. Design activity thus corresponds to the creation and manipulation of
instances of entity types. Furthermore, we assume that instances of all entity types
may be created by applying construction rules that define how entities are to be com-
bined to create instances of other entities. We have found, as Dewilde also notes in
[27], that these rules may be expressed as mathematical functions. Let e, f, and
d 1, d 2, …, d n be variables of different entity types in a task schema S. The expression
e ← f ( d 1, d 2, …, d n ) is interpreted as meaning that an instance of entity type e is con-
structed by applying an instance of entity type f as a function to an n-tuple of
instances of entities of types d 1, d 2, …, d n . For example, we may define an instance of
a circuit performance as being created by applying an instance of a circuit simulator
to instances of a netlist, device model parameters, and stimuli. This construction rule
may be written as:

      circuit-performance ← circuit-simulator ( netlist , device-model , stimuli )    (EQ 1)

Construction rules in the task schema specify how tools are to be encapsulated as
functions at the resource level. In (EQ 1), we have not only declared a construction
rule for the entity type circuit-performance, but have also defined a circuit-simulator as
a function that maps the tuple of types (netlist, device-model, stimuli) to the type circuit-
performance. By separating the resource level from the task level, the Odyssey model
provides a very flexible approach to tool utilization. Because encapsulated tools are
themselves represented as instances of entities, we can readily substitute different
tools with competing implementations into the same construction rule. Fig. 6 illus-
trates the form of a typical tool encapsulation in Odyssey for the circuit simulator
HSpice. Since tool encapsulations are represented by functions, this encapsulation
must produce syntactically correct input for the tool HSpice, and return output in the
form of a circuit-performance. As a whole, the diagram in Fig. 6 may be regarded as an
instance of a circuit-simulator, as defined by the construction rule in (EQ 1).
The Task Schema                                                                 Page 37

                    netlist          parameters            stimuli

                          Read input data from resources
                      Create syntactically correct HSpice input


                                Parse HSpice output
                                Write data to resource


                        FIGURE 6. Tool encapsulation in Odyssey.

Earlier, we stated that design activity consists of manipulating and creating entity
instances, through the application of construction rules expressed as functions.
Because construction rules are defined only in terms of entities, however, some mech-
anism is needed to provide the task management system with access to the outside
world, thereby allowing instances of a given entity type to be directly installed or
imported into the system. A special function, called the null constructor, is defined for
this purpose, and is implicitly assumed to be an entity in any task schema. The null
constructor is denoted by the symbol ∅. Thus if b is an entity in task schema S, the
construction rule b ← ∅ means that an instance of b can be imported into the system
without the need of executing a tool. Rules of this form thus provide a formal means
for representing such common activities as installing tools or importing a cell library
into the task management system.

3.3.3 Tasks
While a single construction rule specifies how to create an instance of a single entity
type, in general, design activity may be organized into sequences of construction rule
applications. Given the definition of the null constructor, we may now formally
define the concept of a task as a substitutional chaining of construction rules that may
be resolved to a single entity type. Note that tasks are defined in terms of entity types,
not entity instances. The implication of this is that tasks are generic design functions,
independent of specific tools or data. For example, suppose that A, B, …, F are entity
The Task Schema                                                                  Page 38

types in a task schema S, and A ← B ( C, D ) and D ← E ( F ) are construction rules in
S. By the definition above, A ← B ( C, E ( F ) ) represents a task, as do the two construc-
tion rules from which this statement is composed. By definition, A, C, D, and F are
tasks as well, although no execution is required to evaluate them. If B has a null con-
structor B ← ∅ , then the installation of an instance of B is also a task. In general, the
term “task” alone will be used hereafter to denote tasks that require execution. Tasks
that are based either on no constructor (e.g. A) or on a null constructor are called
degenerate tasks.

A task with entity instances (tool and data resources) bound to it is called an execut-
able task. Further detail on the binding of tools and data to tasks and on task execution
in Hercules is given in Chapter 5. A more theoretical treatment of functions as typed
objects, with parallel examples drawn from other computer languages, is provided in
Appendix A. The reader is also referred to [32], [3], and [22] for further discussion on
the representation of functions.

3.3.4 Dependency Relationships and the Task Schema Diagram
As defined earlier, temporal and definitive properties describe the attributes of enti-
ties. These properties, however, give only an incomplete image of a design in
progress. In particular, since designs are realized through the execution of tasks, we
should also track which instances were involved in these tasks. For example, con-
sider the construction rule for a circuit-performance and the functional encapsulation
of a circuit-simulator defined by (EQ 1). In examining a particular instance of a circuit-
performance, a designer may wish to know not only when and by whom the instance
was created, but also which circuit-simulator, netlist, device-model, and stimuli were
used to create that instance. Furthermore, a designer may also want to find all of the
circuit-performances that were created for a given netlist. In order to record the assign-
ment of instances to tasks, construction rules in the task schema are expressed by
dependency relationships. Like entities, dependency relationships can be instantiated
and stored as part of the design history.

Two types of dependency relationships are needed in order to express construction
rules in the task schema. The first type of relationship is a function dependency, which
expresses the connection between the entity that is created by the rule and the con-
structor function. Data dependencies relate the parameters of that function to the cre-
ated entity. Both types of relationships may be modeled by the ordered pair
The Task Schema                                                                          Page 39

(TARGET-ENTITY, SOURCE-ENTITY), where a target entity refers to the entity that is
created by a construction rule, and a source entity refers to either the constructor func-
tion or one of its parameters. A more precise definition of dependency relationships
may be given by adding cardinality to the model. For example, each instance of a cir-
cuit-performance that is created by an application of the construction rule in (EQ 1)
depends upon exactly one instance each of a circuit-simulator, netlist, device-model-
parameters, and stimuli. On the other hand, a single instance of any one of these
sources may be used in creating any number of instances of a circuit-performance. In
order to include cardinality in the definition, dependency relationships may be
expressed using an object model patterned as explained in [20], that is illustrated in
Fig. 7. Using this notation, n instances of a given target entity type may depend upon

                                    n       dependency          1
                    target-entity           relationship            source-entity


                                    n   circuit-performance /   1
           circuit-performance             circuit-simulator         circuit-simulator


                                    n   circuit-performance /   1
           circuit-performance                   netlist             netlist


  FIGURE 7. Object model for dependency relationships (after [20]). (a) General form, (b)
  Function dependency, (c) Data dependency.

a single instance of a given source entity type. Just as a task schema may contain
many different entity types, it may also contain many different dependency relation-
ship types of the form shown in Fig. 7 (a), each of which can be instantiated and
stored in the task database. Fig. 7 (b) and Fig. 7 (c) illustrate two of the relationship
types needed to capture the construction rule in (EQ 1).
The Task Schema                                                                                Page 40

Since all the dependency relationships needed to describe a set of construction rules
are binary and 1:n in cardinality, we may employ a shorthand notation to draw a dia-
gram of a task schema. In a task schema diagram, entities are drawn as boxes and
relationships are drawn as arrows emanating from the target entity of a construction
rule to each of its source entities1. Arrows labeled with an f denote the function in the
rule (function dependency), while arrows labeled with a d denote the parameters of
that function (data dependencies). Thus, the construction rule of (EQ 1) may be
expressed by the task schema diagram shown in Fig. 8. In a verbal description of a


                                     f                              d
                                            d          d

                       circuit           netlist      device-model           stimuli
                     simulator                         parameters

            FIGURE 8. Construction rule expressed as task schema diagram subgraph.

task schema diagram, relationships are pronounced either “depends on function,” or
“depends on data.” Null constructors are also left out of the task schema diagram, the
types that they create appearing as leaf nodes.

Instances of relationships provide the specific dependencies that exist between entity
instances. Fig. 9 illustrates a portion of a design that has been instantiated according
to the task schema in Fig. 8. In this example, the circuit-performance “rise time” was
created with the circuit-simulator “hspice” and stimuli “falling step”. Similarly, the cir-
cuit-performance “fall time” was created with “adapts” and “rising step”.

 In general, a task schema for a given domain is developed by defining the task enti-
ties for that domain, determining construction rules for each entity in terms of other
entities, and expressing these rules with f and d relationships. As an example sup-
pose that a task schema S has a set of entity types E = { A, B, …, J } , with construc-
tion rules:

1. In retrospect, the arrows should probably point in the opposite direction, from the source to the tar-
get. We have left them as they are to avoid conflict with our already published works, [11] and [13].
The Task Schema                                                                 Page 41

                                 A ← B ( C, D )
                                   B ← E ( F)
                                   C ← G ( C)
                                                                                 (EQ 2)
                                  D ← H ( I, J )
                         E←∅         F←∅           G←∅
                          H←∅         I←∅          J←∅

The task schema diagram for S is shown in Fig. 10.

3.3.5 Representation of Alternative Construction Rules
In some cases, instances of a given entity type may be created by more than one dis-
tinct construction rule. As an example, consider the creation of netlists in the domain
of integrated circuit design. One way of creating a netlist is by synthesizing it from a
behavioral description of the circuit. An alternative approach is to extract a netlist
from the geometrical description of the circuit layout. In terms of the system of con-
structors in (EQ 2), an analogous situation can be modeled by adding an alternative
constructor for type D, D ← K ( L ) , where K and L are entities with null constructors


                     hspice                                    step

                     adapts               circuit              step

                    circuit                                    stimuli

                          FIGURE 9. Relationship instances.
The Task Schema                                                                   Page 42

                                        f               d

                            B                   C   d           D
                                            f               f
                       f        d                                       d

                   E                F       G       H           I           J

                           FIGURE 10. Simple Task Schema Diagram

added to the set E. To capture the semantics of such alternative constructors in the
task schema, we may define two new entities, D' and D'' , that are alternative entity
types for a base entity type D, each corresponding to one of the two alternative con-
struction rules for D. If p is a function that returns the definitive, historical, and pro-
tective properties of the type to which an entity refers, then entity U is a legal
alternative for entity V iff p ( V ) ⊆ p ( U ) .

Like dependencies, alternatives may be modeled in a task schema by relationships
that can be instantiated. An alternative relationship consists of the ordered pair (BASE-
ENTITY, SIMPLE-ENTITY), whose cardinality is 1:1. Fig. 11 illustrates the instantia-
tion of a task schema involving the base entity netlist and its two alternatives, synthe-
sized-netlist and extracted-netlist. By resolving the alternative relationship instances, a
circuit-performance may depend on either subtype of netlist.

Instances of base entities exist for purely referential purposes. In practice, base enti-
ties have no temporal or definitive properties of their own, but rather represent the
aggregation of the properties of their alternatives. In the implementation of a task
database, base entities may not actually need to be instantiated; referential integrity
may be maintained instead by data access conventions. For this reason, base entities
are sometimes referred to as virtual entities.

As a shorthand notation for representing alternatives in a task schema diagram, a
higraph [35], rather than a simple graph is used. Higraphs are hybrid constructs that
combine the modeling capabilities of simple graphs and Euler/Venn diagrams. In the
task schema diagram, alternatives for entities will be drawn as non-overlapping
boxes, within the region of the base entity. A task schema thus contains entities of two
The Task Schema                                                                                      Page 43

                                                                                          base entity



        performance                                    netlist

                                synthesized                                          extracted
                                  netlist                                             netlist

                      FIGURE 11. Instantiation of alternative relationships

types: (simple) entities of type ε, and base entities of type β. Fig. 12 shows the task
schema diagram for the system of constructors in (EQ 2), with the addition of a new
constructor for D, D ← K ( L ) .

                                 f                 d
                  B                        C
                                                                         D           D”
              f                        f                         D’
                                                       f             d           f               d
          E                 F         G
                                                   H             I           J        K          L

       FIGURE 12. Task schema of Fig. 10, modified to show alternative construction
       rules for D.

3.4 Summary of Task Schema and Task Derivation Models
As discussed in Section 3.1, the task derivation model is a language for designing
task schemata. A task schema, in turn, is a model that defines (and constrains) the
objects and operations that are used to produce designs in a given domain. In this
The Task Schema                                                                       Page 44

respect, the task derivation model may be termed a “modeling language language”
as discussed in [63]. Fig. 13 illustrates the correspondence between the task deriva-
tion model, a task schema, and a collection of design objects in the domain modeled
by the task schema. As shown, the task derivation model may be used to instantiate

     Derivation                                                       Domain-Specific
                                        Task                          Design Objects
      Model         instantiation      Schema

  FIGURE 13. Task derivation model, task schema, and domain-specific design objects.

several task schemata, while each task schema provides the rules for instantiating a
collection of domain-specific design objects.

The rules for developing a task schema from the task derivation model are different
from the rules for instantiating a design subject to a task schema that were presented
in the previous sections. The rules for defining a legal task schema according to the
task derivation model are given below:

      A task schema S = ( E, B, A, F, D ) consists of

      1. a set of type-ε (simple) entities E, that includes the null entity,
      2. a set of type-β base entities B,
      3. a set of alternative relationships A, expressed as ordered pairs, where
         A ⊆ B × E,
      4. a set of function relationships (or function dependencies) F, expressed as
         ordered pairs, where F ⊆ E × [ E ∪ B ] , and
      5. a set of data relationships (or data dependencies) D, expressed as ordered
         pairs, where D ⊆ E × ( E ∪ B ) .

A legal task schema is formed by instantiating the task derivation model shown in
Fig. 14. Here, the model has been extended to include temporal and definitive prop-
erties (resources). The cardinalities placed on relationships may be summarized as

      1. A simple entity type can be an alternative for at most one base entity type.
      2. Every simple entity type is the target of exactly one function dependency
         type, whose source may be either a simple entity or base entity type.
The Task Schema                                                                           Page 45

       3. A simple entity type may be either the target or source of any number of
          data dependency types.

                                                1              1

                                  has target                   has source
   alternative                             1                   1
  relationship                                                                      temporal
       type                                                             has         properties
                 1                          1       (simple)
          n                                          entity        1            1
         1                                                         1            1
                     has alternatives
      base       1                      n                              defines       resource
     entity                                1                   1
                                  has target                   has source
                                                n              n
                                        n          data
                     has source                 dependency

                      FIGURE 14. Task derivation model for a task schema.

3.5 Persistent Storage of the Design Derivation History
Once a task schema has been constructed according to the rules of the task derivation
model, it may then be used to configure a database to store the design derivation his-
tory for a design in progress. The task derivation model places few restrictions on the
type of database that is to be used for storing the design history. In fact, the initial
prototype of Hercules was written in Lisp [59] and simply used lists to store instances
of entities and relationships, while later versions written in C++ [60] employed first a
relational database [39] and later an object-oriented database [53].

In this section, we will illustrate the configuration and management of a task data-
base using the relational model. This example will serve to illustrate the algorithmic
The Task Schema                                                                Page 46

nature by which a task schema may be transformed to a database architecture, and
will also indicate some of the strengths and limitations of the schema-based approach
to task management with respect to schema evolution.

3.5.1 Mapping a Task Schema to the Relational Model
In the relational database model, entities are described in terms of tuples of proper-
ties or relations that are commonly represented as tables. Each column of a relational
table corresponds to a single property of an entity, while each row in a table corre-
sponds to a unique instance of that entity type. For example, suppose that an entity
type employee is defined by the tuple of properties (ID num, first name, last name),
where ID num is an integer that is assigned to each employee, and first name and
last name are each strings. A relational table that contains five instances of employees
is shown in Fig. 15 (a). Similarly, we may define a department as having the two
properties dept num and function. An example relational table that contains three
departments is shown in Fig. 15 (b).

                                      (a) Relation: employee

                           id num         first name         last name
                           1001       John                Smith
                           1002       William             Mager
                           1003       Mary                Jones
                           1004       John                Doe
                           1005       Zoe                 Canine

                                     (b) Relation: department

                                    dept num          function
                                    710         engineering
                                    720         marketing
                                    730         manufacturing

                             FIGURE 15. Relational tables.

A key for a relational table is defined as a column or combination of columns that
may be used to uniquely identify each instance (row) in the table. In Fig. 15 (a), ID
num may serve as a key for employee since no two employees have the same ID
num, but first name may not.
The Task Schema                                                                      Page 47

Relationships between entities may be expressed in several possible ways using the
relational model, depending upon the cardinality of the relationship. For example,
suppose that we wish to express the relationship that any one employee may be a
member of several different departments. Because a single entry in a relational table
cannot contain more than one value, the relationship between employee and depart-
ment must be expressed by creating a new table, which we call employee-depart-
ment, that is shown in Fig. 16. The columns of this new table are defined in terms of
the keys of each of the two entities participating in the relationship. From the table
employee-department we see that employee 1002 (William Mager) is a member of
two departments, “engineering” and “manufacturing”, while each other employee is
a member of only one department. If, on the other hand, each employee were limited
to being a member of only one department, it would not be necessary to define a new
table to contain the relationships between employees and departments. Instead, a col-
umn department could be added to the table employee, as shown in Fig. 17. The car-
dinality of such a relationship is 1:n, meaning that each employee participates in
exactly one relationship with a department, while a single department may partici-
pate in n such relationships with different employees.

                                      Relation: employee-department

                                         employee     department
                                         1001         720
                                         1002         710
                                         1002         730
                                         1003         710
                                         1004         730
                                         1005         720

  FIGURE 16. “Relationship” relational table. Employee 1002 is a member of two departments.

                                          (a) Relation: employee

                       id num    first name            last name       department
                       1001     John                Smith          720
                       1002     William             Mager          710
                       1003     Mary                Jones          710
                       1004     John                Doe            730
                       1005     Zoe                 Canine         720

FIGURE 17. Table expanded to contain a 1:n relationship. Employee 1002 is a member of only one
The Task Schema                                                                                                     Page 48

The first step in constructing a task database from a task schema is to define a table
for each entity. All entities have the temporal properties designer, timestamp, and
comments, so these are defined as columns for each of the tables. Another column,
ID, is defined to serve as a key for each table. Since the definitive properties of enti-
ties are not defined at the task level, but rather using resources, we define a column
for each table called resource, that is denoted by an integer that serves as a pointer to
a unique resource1. As discussed in Section 3.3.4, dependency relationships in the
task database are 1:n, since each instance of a given target entity type must depend on
unique instances of each of its source entity types. As a result, dependency relation-
ships may be expressed in a relational task database by adding columns to each table
that reflect the entities upon which the entity of the table depends. Fig. 18 shows a set
of tables for a relational task database that have been defined according to the task
schema in Fig. 8 and contain the entity and relationship instances shown in the “ball
and stick” drawing of Fig. 9.

                                                Relation: circuit performance

                                                                                circuit                  model
   ID    designer    timestamp                comments          resource      simulator    stimuli     parameters   netlist
   301   jbb        07-25-91 10:45          rise time           1529535       101          202         317          478
   302   cobourn    07-25-91 11:15          fall time           1529627       102          201         323          421

                                                  Relation: circuit simulator

                           ID      designer         timestamp          comments           resource
                           101     marquet        04-15-91 23:04     hspice               9871463
                           102     sutton         05-04-91 08:34     adapts               9871475

                                                        Relation: stimuli

                      ID         designer       timestamp           comments         resource        ...
                     201        director      06-20-91 10:27     rising step         8001200         ...
                     202        jacome        06-28-91 15:50     falling step        8001243         ...

                                FIGURE 18. Relational tables for task database.

1. Because of the complex structure of resource level information, it is not easily represented by the
relational model, which permits only simple numeric and character data types. As discussed in
Section 3.3.1, the Cyclops resource manager uses a frame database.
The Task Schema                                                                  Page 49

One limitation of relational databases is that they lack the ability to process queries
regarding the structure of a database itself. Thus, while a convention may be estab-
lished that the function and data dependencies of a given entity are represented as
columns of a table, it is not possible to ascertain construction rules for creating new
entity instances through this convention alone. In the relational database version of
Hercules, this problem was solved by making an image of the task schema which
effectively serves as a data dictionary for the task database available along with the
task database itself. The fact that an image of the task schema is kept available in Her-
cules is also used to provide a mechanism for representing base entities and their
alternatives. Since the alternatives of base entities are simple entities, they are repre-
sented by tables as described above. No tables are needed, however, for the base enti-
ties themselves. In order to find an “instance” of a base entity, Hercules simply
searches the tables for each of the alternatives as contained in the task schema.

A task schema may be described declaratively, as shown in the example schema
description file in Fig. 19. In a schema description file, simple entities are first
declared using the keyword ENTITY, and base entities using the additional keyword
BASE. Each entity is declared with a label, a name, and a textual description of that
entity that is used by the help facility in Hercules (see Chapter 5). Once the entities
have been defined, alternative relationships are expressed using the ALTERNATIVE
OF keywords, and function and data dependencies using the DEPENDS ON FUNC-
TION and DEPENDS ON DATA keywords. Upon the creation of a new task data-
base, the relational version of Hercules read the schema description file and created
empty tables according to the rules described above. Should the schema description
file have violated the task derivation model presented in Fig. 14, the Hercules data-
base compiler would have issued an error.

3.5.2 Strengths and Limitation of a Schema-Based Task Database
As discussed above, one of the greatest strengths of a task schema is its ability to
serve as a “blueprint” for automatically configuring a task database. Another advan-
tage is that a task schema also lends itself to formulating compact, yet highly-struc-
tured queries into the design derivation history. For example, suppose that A and B
are two entity types (represented by tables) having sets of instances a i and b j (corre-
sponding to rows in tables) where i = { 1, 2, …, n } and j = { 1, 2, …, m } . If B is a
dependency of A (either function or data), then a query to “find the set of all
The Task Schema                                                             Page 50

      BASE ENTITY device_params
      “device model parameters”
      “Set of device model parameters (based on Spice level 2 model)”;

      ENTITY simulated_params
      “simulated device model parameters”
      “A set of device model parameters created by a process simulator”;

      ENTITY macroed_params
      “macromodeled device model parameters”
      “A set of device model parameters created with a macromodel of the
      fabrication process”;

      simulated_params ALTERNATIVE OF device_params;
      macroed_params ALTERNATIVE OF device_params;
      ENTITY process_simulator
      “fabrication process simulator”
      “A tool that creates a set of device model parameters from a
      fabrication process specification”;

      ENTITY process_inputs
      “fabrication process inputs”
      “Set of fabrication process inputs: times, temperatures, doses, etc.
      for each process step”;

      ENTITY macromodel
      “fabrication process macromodel”
      “A response surface that models a fabrication process, may be used in
      place of a process simulator for a restricted range of process
      inputs, for fast evaluation.”;

      simulated_params DEPENDS ON FUNCTION process_simulator;
      simulated_params DEPENDS ON DATA process_inputs;

      macroed_params DEPENDS ON FUNCTION macromodel;
      macroed_params DEPENDS ON DATA process_inputs;

                      FIGURE 19. Example schema description file

instances of A such that each depends on an instance of B that was created by
designer jbb” may be expressed in the relational query language SQL [39] as follows:
      select ID
      from A
      where A.B in
         select ID
         from B
         where B.designer = “jbb”

Note that queries on any entity type may be expressed according to this format. Fur-
ther details on task database queries in Hercules may be found in Chapter 5.
The Task Schema                                                                    Page 51

A third advantage of the schema-based approach to task management is that new
instances of either tools or data may be easily added to the task database, and hence
incorporated into the design derivation history. New data instances are recognized at
the task level by simply adding a new row to a table that contains the temporal prop-
erties of the instance, a pointer to its resource, and the ID’s of the entity instances that
were used in creating it. This is a very small amount of design metadata as compared
to the actual design data contained in the resource. Hence, even if resources must be
deleted to conserve memory storage space, history information may be retained eco-
nomically in the task database to facilitate recreation of a resource, if necessary. Fur-
thermore, tools are handled in the same manner as data; as long as a new tool is
encapsulated according to an existing construction rule, tool integration at the task
level merely entails adding a new row to an existing table.

Limitations in the use of a task schema begin to arise when we consider the evolution
of a schema over time. Adding new entities or construction rules to a task schema
poses no significant problems, since this involves only adding new tables to the task
database and does not affect existing data. The only consideration is that the task
schema and the database data dictionary must be kept in correspondence. More seri-
ous problems occur if construction rules are changed or if dependency relationships
are otherwise removed or rerouted. The reason for this is that existing data instances
become invalidated, and must be tagged or updated to reflect the changes in the
schema. Given current commercially-available relational and object-oriented data-
base technology, all persistent data must be externally processed to ensure that no
information is lost. Ongoing database research, however, is investigating the general
problem of schema evolution in the presence of persistent data, and we intend to
make use of these results as they become available.
CHAPTER 4                  Designing a Design

4.1 Bottom-Up / Top-Down Approach
The design of a task schema is a creative process, and aside from the constraints
imposed by the task derivation model, there are no hard restrictions that limit the
ways in which the model can be applied. Nevertheless, there are several “rules of
thumb” that may be observed to guide system developers in the creation of a task

The first step in designing a task schema is to determine the entity types needed to
fully characterize the design domain. Since entity types correspond to containers in
the task database, they should be selected to mark important decision points in the
design process for the given domain. From the viewpoint of browsing the design der-
ivation history, instances of entities, along with corresponding instances of relation-
ships, serve to show the results of these decisions. From the viewpoint of composing
and executing tasks, entity instances form the set of available options in satisfying
these decisions.

As an example, consider the task of simulating the transient (time domain) behavior
of an electrical circuit. In the circuit design process, transient simulation is used to
determine the time that the outputs of a circuit take to respond to a set of stimuli
applied to its inputs. The circuit itself is typically represented as a network of electri-
Designing a Design System                                                        Page 53

cal devices, or a netlist. While the netlist and stimuli are critical in determining the
performance of the circuit, they are not the only factors. Also important are the elec-
trical properties of the individual devices that make up the netlist. These result from
the fabrication process through which the circuit was produced, and may be summa-
rized as a set of device model parameters.

This view of circuit simulation is by no means novel; in fact, descriptions of a netlist,
stimuli, and device model prarameters form part of the input to nearly all commer-
cial circuit simulators. By declaring these objects as entities in a task schema, how-
ever, the designer is afforded services far beyond those that are provided by a
simulator alone. The difference lies in the ability to manage circuit simulation tasks
within the context of a design process. In order to verify the performance of a circuit,
designers typically simulate a netlist with a variety of different stimuli, e.g., wave-
forms with different rise and fall times or voltage levels. Furthermore, a circuit may
be simulated with several sets of device model parameters that reflect the variability
in the fabrication process. The designer may also change the netlist itself between
simulations in response to unacceptable results. Since the input to a circuit simulator
usually consists of all of the input types semantically flattened into a single file, it is
difficult for designers to ensure that all necessary steps have been taken in verifying
the performance of a circuit. Also complicating the design process, a designer may
choose to employ several different simulators, perhaps trading off efficiency for accu-
racy as a design nears its final stages. By defining transient-response, transient-simula-
tor, netlist, device-model-parameters, and stimuli as entities, instances of each of these
types and the connections between them become part of the design derivation his-
tory. The resulting task schema is shown in Fig. 20.


                                f                           d
                                       d        d

                 transient          netlist    device-model          stimuli
                 simulator                      parameters

                 FIGURE 20. Task schema for transient circuit simulation.
Designing a Design System                                                       Page 54

The previous example illustrates that the design of a task schema is not strictly “top
down” or “bottom up”, but involves what Booch[6] terms “round-trip gestalt
design”. While a task schema defines the functional encapsulation of CAD tools,
existing tools may also serve a a starting point for determining the entities in a task
schema. This is especially important if multiple CAD tools are to be encapsulated as
instances of the same entity type, since the encapsulation, along with its parameters,
must reflect a generalization of the properties of each of the instances.

4.2 Multiple Encapsulation of Tools
Increasingly, the ability of companies to produce competitive, state-of-the-art designs
depends upon the use of highly specialized CAD tools. With the advent of new tech-
nologies, more efficient algorithms and detailed models are rapidly being developed
to meet the needs of designers. The schema-based approach to task management
readily accomodates the integration of specialized, fine-grain tools, because their
properties are well-defined.

Since truly open CAD frameworks have yet to appear on the market, however, tool
developers often compensate for the lack of design process support by producing
composite tools that house several functions under one roof. In other cases, compos-
ite tools arise from the fact that several algorithms can be efficiently designed to work
with the same data structures, such as d.c. and steady-state a.c. circuit simulation.
While composite coarse-grain tools may provide added convenience to users working
directly at the component level, they in general provide a challenge to CAD system
integrators because of the difficulty in encapsulating their disparate functionalities.

Rather than attempting to capture all the functionality in a single encapsulation, an
alternative approach to integrating coarse-grain tools is through multiple encapsula-
tions. Multiple encapsulation of tools has several advantages. First, it allows system
integrators to incrementally add functionality to a CAD system. For example, if the
design process in a given domain only calls for the transient analysis of circuits, there
is no need to encapsulate a circuit simulator such that it produces other functions,
such as determining the poles and zeros of a circuit. A second advantage is that when
several of a tool’s functions are needed for a given design domain, multiple encapsu-
lations allow a monolithic tool to appear at the task level as several fine-grain tools,
permitting a more detailed classification. As an illustration, a single circuit simulator
Designing a Design System                                                               Page 55

such as HSPICE may be encapsulated twice according to the following construction

        transient-response ← transient-simulator ( netlist , device-model , stimuli )

              poles-and-zeros ← pole-zero-simulator ( netlist , device-model ) .

The first encapsulation of HSPICE would invoke the simulator with control com-
mands set to perform a transient simulation only. This enables the simulator to be
classified with other special purpose transient simulators such as ADAPTS. The sec-
ond encapsulation would configure HSPICE to function as a pole-zero simulator, and
could be classified along with special purpose tools such as AWEsim[55]

4.3 Representing Task Scenarios

4.3.1 Inspection
An important feature that a design system must provide is to allow users to view the
definitive (resource level) properties of entities. Odyssey provides two approaches to
this. The first approach is to view the contents of frames directly via the Cyclops user
interface server [24]. The second approach is to model both inspection tools and their
output as entity types, and include the inspection activity as part of the task schema.

Their are two distinct advantages to modeling the inspection of design data within a
task schema, rather than treating it as a separate service. The first advantage is that
for some entity types, there may be several tools available for viewing their associ-
ated resources. A simple example is viewing the results of a transient simulation.
Two ways of viewing the transient response of a circuit are tabular and graphical.
Furthermore, different users of a design system may have different preferences for
different plotting packages, and by defining an entity type such as transient-plotter,
several plotting tools can be encapsulated and installed into the system. Fig. 21
shows a task schema for a typical inspection activity, using the transient-plot example.
While instances of a transient-plotter may be based upon generic plotting tools, such
as XGraph or ACE, they do more than simply invoke the tool. Since the tools are spe-
cifically encapsulated as transient-plotters, the encapsulation code is responsible for
importing the frame-based description of a transient-response and creating syntacti-
cally correct input for the encapsulated tool. The encapsulations can thus be used to
customize the appearance of plots as the tools permit, with legends, titles, etc. Addi-
Designing a Design System                                                             Page 56


                                 f                       d

                          transient                    transient
                           plotter                     response

           FIGURE 21. Task schema for inspecting results of a transient simulation.

tional encapsulations of the same plotting tool may be installed as instances of other
inspection entity types.

The second advantage of modeling inspection tasks in the task schema is that the
resulting view of the data becomes instantiated in the design history. This can save
designers from having to regenerate plots. Furthermore, if the resource associated
with a transient-plot contained a reference to, say, a PostScript file, it can be made
available for insertion into a document.

4.3.2 Verification
In Section 4.1, it was shown how a task schema can be constructed that supports the
flexible substitution of instances of each of the different input types into a simulation
task. By augmenting the simulation task schema with a few additional entities and
relationships, it is possible to record that simulation results have been formally vali-
dated against a set of specifications. Fig. 22 illustrates an example task schema for the
verification of a transient-response.

The definitive properties of transient-specification instances record constraints on tran-
sient-responces, such as upper and lower bounds on circuit delays. A verification-tool
compares the response to the specifications and indicates whether or not the specifi-
cations are met. In implementation, such a tool may either do this automatically, or
may simply display both sets of data and allow the user to decide. The results of the
verification, which may be simply a Boolean value, are stored as a verified-transient-
Designing a Design System                                                         Page 57


                                f               d           d

                 verification             transient                  transient
                     tool                response                 specifications

                 FIGURE 22. Task schema for verifying simulation results.

As is the case with other task schemata, the verification schema shown in Fig. 22 pro-
vides a mechanism for marking salient decision points in the design process. By stor-
ing verified responses as entity instances, the task database records when and by
whom a given verification was performed, as well as indicating which specifications
were used when there are several instances available. Conversely, if a query of the
task database reveals that no instances of verified responses exist that depend upon a
given set of specifications, the designer or design manager knows that the circuit per-
formance has not been verified.

4.3.3 Editing Tasks and Versioning
In general, editors are functions that take instances of a given entity type as input,
and produce a changed version of that same type as output. For example, a netlist-edi-
tor may be encapsulated according to the following construction rule:

                         netlist ← netlist-editor ( netlist ) .                    (EQ 3)

In a task schema diagram, editing tasks are characterized as having a data depen-
dency whose source and target are of the same entity type, as shown in Fig. 22. A
problem with this representation is that no clear means is shown for creating an orig-
inal instance of a netlist; the construction rule expressed by (EQ 3) implies that some
existing instance of a netlist must serve as a basis for creating a new instance. One
way of breaking this dependency cycle is to make the parameter in (EQ 3)—or the
loop in Fig. 22—optional. This approach to modeling editors is presented in [34].
Another approach is to explicitly add a construction rule to the task schema of the
Designing a Design System                                                            Page 58

                                               netlist         d



                          FIGURE 23. Task schema for netlist editing.

                             netlist ← netlist-editor ( ) .                           (EQ 4)

The resulting task schema is shown in Fig. 24. Note that the data dependency whose


                                  new                    derived

                                          f                f


          FIGURE 24. Use of alternative construction rule to break editing cycles.

target is derived netlist points to the base entity type netlist, meaning that instances of
either netlist subtype may be used as parameters of derived netlist. Also note that since
two different function dependencies have netlist-editor as their source, resulting from
the fact that netlist-editor serves as a function in two separate construction rules, a sin-
gle encapsulation of a netlist-editor must be capable of accepting either zero or one
parameter as an argument.

Editing tasks are closely associated with the concept of versions, as discussed in [43].
By keeping the identities of all instances of entities and dependency relationships
separate in the task database, and by not allowing destructive modification of
instances, a task schema such as the one in Fig. 24 will naturally support version
maintainance in the task database. Fig. 25 (a) illustrates a portion of a task database
that has been structured according to the schema in Fig. 24, while Fig. 25 (b) shows a
Designing a Design System                                                                  Page 59



                                                     created                         created
                                n2                   with e1                         with e2

            e2                                                 n2                   n4

            e1                netlist                          n3



      FIGURE 25. Representation of versioning: (a) in task database, (b) as version tree

more traditional version tree view of the derivation of netlist instances. In this exam-
ple, netlist instances n2 and n4 were created as new versions of n1, while n3 was cre-
ated as a new version of n2. This information is captured in both the task database
and the version tree. The semantics of the version tree, however, do not naturally cap-
ture the fact that two different netlist-editors, e1 and e2, were used in creating the var-
ious netlist instances. Because a task schema captures the relationships between tool
and data objects, this fact is easily represented in the task database.

The notion of using different tools to create new versions of objects can be extended
to using editors to change objects that were created by alternative methods. For
example, a designer may wish to use a manual layout editor to create a new version
of a layout that modifies a layout generated by automatic placement and routing
tools. Fig. 24 shows a task schema that models this activity.
Designing a Design System                                                          Page 60


                              d                                         d
                netlist               synthesized       edited

                                         f                 f

                               place and            netlist
                               route tool           editor

          FIGURE 26. Task schema for manually editing synthesized layouts.

4.3.4 Consistency between Design Facets
A popular approach to organizing integrated circuit design databases is to model a
design as a hierarchy of cells, where each cell has several different views or facets [36].
Fig. 27 illustrates three possible views of an inverter cell. In the logic view, an inverter

                                        in inverter out

          in          out                in          out

           logic view                    transistor view          physical layout view

                          FIGURE 27. Three views of an inverter cell.

is described simply as a Boolean function whose behavior may be represented as a
truth table. In the transistor view, the inverter is described as a network of electrical
devices; in this case its behavior is described as time-varying voltages and currents.
The physical layout view of the inverter decribes the inverter as a set of photolitho-
Designing a Design System                                                          Page 61

graphic masks that characterizes the geometry of the circuit as it would be laid out on
a chip.

In the cell and facet model, the interfaces of each facet of a cell remain fixed, but the
contents vary from facet to facet. One of the problems associated with maintaining a
cell and facet database is guaranteeing that the contents of the facets of cells are
mutually consistent. An approach to maintaining consistency between views of a cell
is to realize that these views do not exist in isolation, but are actually related artifacts
that are created as part of a particular design process. In [27], Dewilde discusses the
transformational approach to design, in which a synthesis activity consists of mapping
a behavioral description of an object to a structure, that is in turn composed of lower
level behaviors. Fig. 28 illustrates the transformational approach.


                                                                 Algorithmic Expert

                      Verify           Structure Of

                                       Lower Level

            FIGURE 28. The transformational approach to design (from [27]).

Task schemata may be defined that model the transformational approach to design.
In such a task schema, entities are used to represent the artifacts that are created at
the various levels, while the mappings between levels are expressed as construction
rules. As an example, consider mapping a transistor-level representation of a circuit
to a physical layout. In this example, the entity types netlist and layout are used to
represent the transistor level and physical level views of a circuit, respectively. The
definitive properties of each of these entity types comprise the description languages
for expressing behaviors at each of these two levels. In Fig. 28, there are two different
mappings between levels that are of interest: synthesis of a structure by an algorithmic
expert, and verification that the lower level behaviors of a structure are consistent with
Designing a Design System                                                            Page 62

the original high-level behavioral description. For the case of netlists and layouts, syn-
thesis may be performed by several alternative methods, such as by using automatic
placement and routing tools, or by manually using a layout editor, as was shown in
Fig. 24. Verification in this case may be performed by a circuit-extractor, a tool that
analyzes a layout and produces a netlist. Fig. 29 shows a task schema that expresses
construction rules for these two mappings.


              netlist   f       edited         extracted       f       circuit
              editor                            netlist

                                     d                 d

                              automatic            edited
                               layout              layout

                                 f                      f
                              placement            layout
                             and routing           editor

FIGURE 29. Task schema for mapping between transistor-level and physical layout views of a

The task schema based approach to configuring a database to store views of a circuit
is fundamentally different from the cell and facet based approach, in that the differ-
ent views are represented as instances in the design derivation history. We believe
that the use of a task schema for describing this situation has several advantages.
First of all, a task schema not only declares the views, as entity types, but also
declares the policies, in the form of construction rules, by which instances are created.
External mechanisms for expressing policies are thus not needed. A second advan-
tage is that a task database stores a full accounting of the means by which instances
were created, not simply the existence of the instances. This can play a significant role
towards guaranteeing the consistency of a design. For example, rather than supply-
ing the layout or transistor-level views of a cell, a task database supports more pow-
erful queries such as “find the layout that was synthesized for a given netlist by a
Designing a Design System                                                       Page 63

given placement and routing package,” or “find the netlist that was extracted from
this layout.” As was discussed in Section 4.3.2, a positive response to these queries
finds the results of a particular design action, while a negative response indicates that
a needed action was not performed.

While a task schema is a powerful tool for organizing information regarding the der-
ivation of different views of a design, it does not capture the configuration of cells
that composes a complex structure. In the Odyssey CAD Framework, this configura-
tion is represented by a hierarchy of design domains at the design process level [9].

4.3.5 Tools Created during Design Process
An advantage of treating both tools and data as entities in a task schema is that we
can readily model situations where tools themselves are created during the design
process. One example of such a tool is the switch-level simulator COSMOS [15],
which is compiled for a given netlist and then executed for different stimuli. A sec-
ond example is building and using a macromodel [46] for a fabrication process. Macro-
models are regression models constructed to emulate the behavior of a
mathematically complex system in a readily evaluated form, and can replace a simu-
lator for a restricted range of input. Fig. 30 shows a task schema subgraph for the con-
struction and use of a macromodel.

                                          device model
                                      f                 d

                             fab process          fab process
                             macromodel             inputs

                             f               d

                    macromodel            macromodel
                     compiler             coefficients

         FIGURE 30. Task schema for macromodel construction and utilization.

A macromodel is constructed by applying a macromodel compiler to a set of macro-
model coefficients. Once compiled, the macromodel may then be used as a tool to cre-
ate a set of device model parameters.
Designing a Design System                                                                               Page 64

4.4 Representing Distributed Access to Tasks
In many organizations, design responsibilities are distributed amongst a group of
designers. In order to support distributed and concurrent design activities, entities in
a task schema may be annotated with the names of designers or groups who have
access to those entities. Fig. 31 illustrates a sample task schema for the domain of
integrated circuit design. The activities supported by this task schema include netlist

   R: C, M                                                                 Legend
   W: A
                            R: C, M                   R: read access            C    circuit designer
      circuit               W: C                      W: write access           L    layout designer
    simulator                                                                   F    fabrication engineer
                                stimuli                                         A    system administrator
                                                                                M    manager
   R: C, M
   W: C                                                                    R: C, L, A, M
                                                                           W: A
       circuit                             netlist
                        d                                                    circuit
    performance                                                    f
                                    R: C, L, M R: C, L, M                   extractor
                                    W: C       W: C, L

                                     edited        extracted                          layout
  R: C, F, M                         netlist        netlist
  W: F              d                                                  d
                                                                               R: C, L, M R: C, L, M
   device model                 f                                              W: L       W: L
                                          d                        d
    parameters              netlist                R: L, M             d         auto       edited
                            editor                 W: L                         layout      layout
                            R: C, A, M
                                                   placement                                                d
                            W: A
        f           d                                                            f                  f
                                               f               d
    fab               fab                                                       router         layout
  process           process                                                                    editor
                                      placement          placement             R: L, A, M
 simulator          inputs               tool            constraints           W: A            R: L, A, M
                                                                                               W: A
 R: F, A, M     R: F, M
                                      R: L, A, M        R: L, M
 W: A           W: F
                                      W: A              W: L

 FIGURE 31. Example task schema for integrated circuit design, annotated with read and write
 access for design team members.

editing, layout synthesis, and circuit and fabrication process simulation. In this exam-
ple, we consider a design staff that consists of five members: a circuit designer, a lay-
out designer, a fabrication engineer, a system administrator, and a manager. As
shown in Fig. 31, the various tasks in the integrated circuit design process may be
Designing a Design System                                                      Page 65

assigned to members of the team by restricting read and write access to members.
Note that only the system administrator has the permission to install tools into the
system, and only the manager has read access to all entities. This gives the manager
the ability to track the overall progress of projects. For example, the manager may
formulate queries into the task database to determine the dates, times, and names of
designers that created any object, and compare this against a schedule.

Protection on entities may also be changed to facilitate special projects. For example,
in order to determine if a high-performance circuit fails to meet specifications
because of fluctuations in the fabrication process, a “task force” may be organized
that has read and write access to all entities in that path.
CHAPTER 5                 The Hercules CAD
                          Task Management

5.1 Introduction
Qualitatively, a task is a tool-independent design function, such as “extract a netlist
from a layout and simulate its performance.” As discussed in Chapter 3, in terms of a
task schema, a task is a composition of construction rules having a single entity as its
goal. While a task schema is a static representation of the feasible activities supported
by a framework, tasks are dynamic, in the sense that designers may execute them in
whatever order they wish in order to solve a given design problem. In this chapter,
we will focus on support for composing, executing, and browsing the results of tasks
through a prototype task management system, called Hercules.

Because they represent designer activities rather than rules, the representation of tasks
in Hercules is different from, although related to, a task schema and the task deriva-
tion model. A special data structure, called the task tree, serves as temporary data
storage during task execution and browsing activities. As we will show, because this
same data structure can be used to prepare tasks for execution, as well as to formulate
and return the results of queries into the task database, Hercules affords the designer
a high degree of flexibility in performing design activities. A visualization of the task
tree is the central feature of the Hercules user interface.
The Hercules CAD Task Management System                                            Page 67

In the Hercules CAD Task Management system, a task tree serves as a medium of
communication between a designer and the design system, both for preparing tasks
for execution, as well as for browsing the results of tasks. The role of a task tree in a
task management system may be illustrated through a simple analogy with a hypo-
thetical airline system. In this airline, agents must not only book and facilitate flights
for passengers, but must also be able to reproduce the travel itinerary for all trips that
each passenger has taken. In this illustration, if a task schema is compared to a map
of air routes that contains the set of all possible connections between cities (entities), a
task corresponds to a trip, and a task tree is analogous to a ticket. First of all, the air-
line would not stock a collection of preprinted tickets for all feasible trips, since the
number of possible combinations of cities would render this unmanageable. Rather,
in order to book a trip for a passenger, an agent would draw up a ticket containing
one or more flights that follow routes from the map. Similarly, even a relatively small
task schema holds the potential for representing a very large number of tasks, espe-
cially when one considers that construction rules may be chained together to form
complex tasks. Rather than storing all possible tasks as scripts of flows, a more eco-
nomical approach is adopted in Hercules that allows designers to derive task trees
from the task schema as needed, guiding them through the creation of entity
instances, subject to the constraints embodied by construction rules. As actual flight
activities are managed by a division of the airline that is separate from reservation
and bookings, so is CAD tool invocation handled by the Cyclops Resource Manager
in Odyssey.

Having discussed the analogies between booking flights and task execution, we turn
to the second responsibility of our hypothetical airline ticket agents, namely, the need
to trace passenger travel. In a task management system, this corresponds to the abil-
ity to browse the design derivation history. One approach that the airline could take
is to keep copies of all tickets that have been issued. There are several problems, how-
ever, with this approach. First of all, a passenger may for some reason miss a flight, or
end a trip at a city other than the final destination on the ticket. In terms of task exe-
cution, this corresponds to a task either unexpectedly or intentionally terminated
before its goal. A second difficulty is that a passenger may not have clear travel plans
before embarking on a trip, and rather than buying a single round-trip ticket, may
choose instead to purchase a series of shorter tickets. This situation is similar to bot-
tom-up design. Both of these common exceptions severely complicate an agent’s abil-
ity to piece together the travel activities of a given passenger.
The Hercules CAD Task Management System                                          Page 68

An alternative to saving copies of tickets for tracking passenger travel is to record the
arrival of each passenger at each city, along with the previous point of departure.
This is role of the task database in Hercules—to store instances of entity types along
with pointers to the tools and data that were used in creating them. Like tickets in the
airline, the useful life of a task tree ends when a design activity is completed. In fact,
if the airline maintained a database of passenger arrivals by city, records of individ-
ual travel activity could be produced in a format that looks exactly like a ticket. Fur-
thermore, if a second passenger requested a ticket for a trip that duplicated the the
travel activities of another passenger over a given period of time, this could easily be
generated. As such, a task tree may be regarded as a template for specifying both exe-
cution and browsing activities. This flexibility is the motivation for the central role of
the task tree in the Hercules user interface.

For the remainder of this chapter, we proceed with a description of the task tree data
structure, and the fundamental operations that it supports. Next the Hercules graph-
ical user interface is discussed, and example execution and browsing activities with
the interface are presented.

5.2 The Task Tree

5.2.1 Structure
While a task schema may contain cycles, the task tree data structure is a directed, acy-
clic graph. The nodes in a task tree are called entity templates. Each entity template
refers to an entity in the task schema and serves as a placeholder for a working set of
instances of that entity from the task database. The edges in a task tree correspond to
function and data dependencies in the task schema. A single node in the task tree,
called the root or goal, has no edges incident upon it, while each other node has a sin-
gle edge incident upon it.

Figures 32 (c) and 32 (d) show two task trees that have been derived from the task
schema in Fig. 32 (a) and refer to the task database in Fig. 32 (b). The choice of which
instances are to be included in the working set of an entity template depends upon
the design activity at hand, but in general, they are selected according to constraints
on their temporal properties, or by the relationships in which they are involved. The
task tree in Fig. 32 (c) has a template for entity Z as its root, and is one level deep,
meaning that only the dependencies of Z, namely X and Y, are included in the tree.
The Hercules CAD Task Management System                                                    Page 69

                     Z                                                     z2
             f              d                                   y2                    x2

            Y                X                                  y1         Z          x1
                     f                      d
                                                                Y        w1            X


                    (a)                                                 (b)

      cobourn                                            sutton
      03-20-92                                           09-16-91
      instance y2                                        instance w1
                          instance z2                                           jacome
                              03-20-92                                          04-15-92
                              instance z1                                       instance x3

           X                                             02-29-92
                                                         instance x2

                    (c)                                                 (d)

FIGURE 32. Relationship between (a) task schema, (b) task database, and (c),(d) task trees

The working set for entity template X is empty, while the working set of entity tem-
plate Y contains a reference to the the single instance y2. The working set for entity
template Z consists of references to the two instances, z1 and z2. This is the set of all
instances of Z that have dependencies upon y2. Fig. 32 (d) shows how a cycle in the
task schema is expanded as a task tree. The goal of this tree refers to an entity of type
X, and its working set is the single instance x3. Since entity type X has two dependen-
cies in the task schema, W and X, both of these also appear as dependencies in the
task tree. The working sets of the templates for W and X consist of the two instances
that were used in creating x3, namely w1 and x2.

5.2.2 Operations
Design activities in Hercules, both execution and browsing, may be formed from a set
of basic operations on a task tree. These operations may be roughly divided into four
The Hercules CAD Task Management System                                        Page 70

groups: those that manipulate the extent of the task tree, those that manipulate the
working sets of a single entity template, those that manipulate working sets through
relationships to other entity templates, and those that create or destroy instances in
the task database. Following is a summary of this set of basic operations. Operations on the Extent of the Task Tree

Expand (n)

      n is an entity template.


      n is a terminal node in the task tree, and does not refer to a base entity type in
      the task schema.

Action Performed:

      New entity templates are created, corresponding to each of the dependencies
      to which n refers, and linked to n via corrsponding relationships.


       n is an entity template.


      n is a non-terminal node in the task tree.

Action Performed:

      All successor nodes of n, and the dependency relationships incident upon
      them, are deleted from the task tree.

Specialize(b, a)

      b is an entity template, a is an entity.


      n refers to a base entity type and thus a terminal node in the task tree; a is an
      alternative of that entity.
The Hercules CAD Task Management System                                              Page 71

Action Performed:

       b is deleted from the task tree and replaced by a new template that refers to a.

Generalize(a, b)

        a is an entity template, b is an entity.


       a refers to an entity that is an alternative of a base entity; b is that base entity.

Action Performed:

       a is deleted from the task tree and replaced by a new template that refers to b. Operations on Working Sets Involving a Single Entity
Elements of the working sets of entity templates are chosen from the task database
via the Select operation. Select operates in much the same manner as the “select”
statement in the SQL database query language, and may be performed according to a
variety of constraints. The simplest forms of the Select operation are when the con-
straints apply to a single entity type, as in the following three cases: selection with no
constraints, direct selection of instances, and constraints on temporal properties.

Select (n)

       n is an entity template

Action Performed:

       All instances of the entity type referred to by n in the task database are
       included in the working set of n.

Select (n, subset)

       n is an entity template

       subset: directly specifies one or more elements of the working set of n

Action Performed:
The Hercules CAD Task Management System                                          Page 72

       The working set of n is selected as the instances contained in subset. In prac-
       tice, this is performed interactively to allow a user or client to pick the ele-
       ments of the working set.

Select (n, temporal-constraints)

       temporal-constraints: specify limits on the temporal properties of elements of
       the working set of n, e.g. beginning and ending dates for the timestamp, user
       ID restrictions, or keywords contained in the comments.

Action Performed:

       The working set of n is selected according to the temporal-constraints.

Aside from Select in the forms stated above, another operation that may be applied
to an entity template is a test to determine the cardinality of its working set:


       n is an entity template

Action Performed:

       If the working set of n contains exactly one element, return that element; else
       return nil. This operation is primarily used to check the preconditions for exe-
       cuting a task, as will be discussed in Section Operations on Working Sets Using Dependency Relationships
A more complicated form of the Select operation allows clients of Hercules to trace
paths along instances of dependency relationships in the task database. This is the
chief mechanism for browsing the design derivation history.

Select (n, dependency-constraints)

       n is an entity template

       dependency-constraints: restrict the working set of n to those elements that
       depend upon a pre-specified set of instances. In practice, these dependencies
The Hercules CAD Task Management System                                            Page 73

       are represented within the task tree data structure itself as the working sets of
       the dependencies (both function and data) of n.

Action Performed:

       Given a task tree of depth one, select the set of all instances of the entity type
       of the root such that the dependencies of each instance is in working sets of
       each of the leaf nodes. An example of the usage of dependency constraints
       was shown in Fig. 32 (c), where the working set of the entity template for Z
       consisted of the set of all instances of Z that have dependencies upon y2.

Dependency constraints may also be applied recursively. This allows users to find the
set of all instances in the working set of the root node of a task tree several levels deep
that depend upon the working sets of the leaf nodes. Selection with dependency con-
straints provides a general means for formulating forward-chaining queries into the
design derivation history. Hercules also provides a mechanism for processing back-
ward-chaining queries that finds the specific tool and data instances that were used in
creating a given instances. Backward-chaining queries are expressed by the History
operation, which is described below.

History (n)


       n is a leaf node in a task tree

       The working set of n contains a single element. ( Unique (n) )

Action Performed:

       If n refers to a base-type entity, Specialize it to the type of the single element in
       its working set.

       Expand n to add its dependency entity templates to the task tree.

       For each of the dependency templates of n, Select the instance on which the
       element in the working set of n depends.

Fig. 32 (d) may be viewed as the result of a backward-chaining query. In this exam-
ple, the working sets of the templates for W and X consist of the two instances that
were used in creating x3, namely w1 and x2.
The Hercules CAD Task Management System                                                          Page 74 Operations that Create or Destroy Instances in the Task
In the previous two sections, we focused upon operations that are used to browse the
task database. In this section, we consider the operations that create of destroy
instances. These are the three operations Run, Install, and Delete.

The Run operation executes a task and stores the result in the task database. Before
the Run operation can be invoked, a task tree must be prepared for execution. To pre-
pare a task for execution, the designer begins by deriving a task tree from the task
schema that covers the scope of the intended task. This is accomplished by first
selecting the goal of the task and then recursively Expanding the task tree according
to the task schema until the desired input is reached. For example, given the task
“extract a netlist from a layout and simulate its performance” and the task schema in
Fig. 33, an appropriate task tree is formed by first selecting circuit-performance as the

     simulator             stimuli

           f         d                                                circuit
                                                             f       extractor
       circuit                          netlist
                                  edited    extracted
           d                      netlist    netlist
   device model             f                                                    layout
                                       d             d
    parameters            netlist
                                                                 d        auto       edited
                          editor             placement                   layout      layout
       f         d
    fab            fab                  f                d
  process        process                                                  f                  f
 simulator       inputs
                                placement         placement             router            layout
                                   tool           constraints                             editor

               FIGURE 33. Example task schema for integrated circuit design.

goal of the task, expanding this node to add its dependencies to the tree, and then
expanding netlist as an extracted-netlist. The resulting task tree is shown in Fig. 34.

Once the task tree is fully expanded, the next step is to bind tools and input data to
the task, by assigning unique instances to each of the leaf nodes of the tree, using the
The Hercules CAD Task Management System                                         Page 75




                     layout                                        circuit


              FIGURE 34. 2-level task tree extracted from schema in Fig. 33

Select operation. Given the above procedure for preparing a task for execution, the
Run operation may be defined as follows:

Run (task-tree)


       The working sets of each leaf node of the task tree must contain a Unique

Action Performed:

       Each non-leaf node of the task tree is visited in a post-order traversal. At each
       node, Hercules generates an execution order for Cyclops, which is composed
       from the dependencies of that node. The structure of an execution order is sim-
       ilar to an s-expression in the language Lisp [59]. The tool and data resources
       associated with with each of the dependencies are presented as a list, with the
       function dependence (tool) occuring first in the list. Cyclops then evaluates
       this list and creates a new instance containing the result, using the tool encap-
       sulation mechanism discussed in Chapter 3. As each new instance is created, it
       is stored, along with its dependencies, in the task database.
The Hercules CAD Task Management System                                         Page 76

As discussed in Chapter 3, entities in the task schema may have null constructors that
allow entity instances to be directly installed or imported into the task database, such
as data from an existing library or CAD tools. This functionality is supported by the
Install operation in Hercules.

Install (n, i)

       n is an entity template; i is an entity instance.



Action Performed:

       Instance i is inserted directly into the task database. No dependency relation-
       ship instances are created. No tools are executed.

Finally, in the model presented, all task evaluations create new entity instances with
no destructive modification of existing instances allowed. In order to remove obso-
lete instances from the task database, a Delete operation is provided.

Delete (n, s)

       n is an entity template; s is a subset of the working set of n.



Action Performed:

       Remove the elements in s from the task database along with the dependency
       relationships of which they are the target. A warning is issued before perma-
       nent deletion occurs.

5.3 The Hercules Graphical User Interface

5.3.1 Organization
The Hercules graphical user interface was originally designed with the goal of illus-
trating the dynamic effects of the operations described above on the task tree. As
The Hercules CAD Task Management System                                           Page 77

such, a visualization of the task tree was made the central feature of the user inter-
face. Nevertheless, while the user interface was intended to serve as a showcase for
the inner workings of Hercules, experience has shown that it is also efficient means of
interaction with the user. In this section, we describe the three main windows of the
Hercules user interface: the task window, the instance browser window, and the help
facility. The Task Window
The task window, shown in Fig. 35, is the top-level window in the Hercules user
interface. The central portion of the task window contains a view of the active task

       Exit                          Clear                           New Task

               layout                                              circuit
                            Expand                              performance
                            Browsedevice model


                          FIGURE 35. Hercules task window.

tree, in this example extracted from the task schema in Fig. 33. Entity templates are
represented by boxes containing the name of the entity. If an entity is either a base
entity or an alternative of a base entity, then the icon for its template has a double bor-
der, as is the case for extracted netlist and layout. The various menus and buttons in the
task window give users access to the operations that manipulate the extent of the the
task tree, discussed in Section, as well as the Run operation, which is repre-
sented by a single button. By clicking on an entity template icon, the user pops up a
The Hercules CAD Task Management System                                          Page 78

menu that provides several options. The first item in the popup menu is an extent
manipulation operation. This is either Expand, Unexpand, or Specialize, depending
upon whether the template is a leaf node, non-leaf node, or is of a base entity type,
respectively. The second item in the popup menu, Browse, opens an instance browser
window for that entity type, while the third item, Help, invokes the help facility. The Instance Browser Window
An instance browser window for a given entity type may be opened by selecting the
Browse option from the entity template icon popup menu, as shown in Fig. 35.
Fig. 36 illustrates an instance browser for device model parameters. Controls in this win-

                    Instance Browser: device model parameters
            Keywords        cmos

            Date Limits     From:        7-25-1991      To:    7-26-1991

            User Limits

            Use Dependencies

            Browse/Select           History          Install        Delete

       jbb        25-Jul-1991    14:12     nominal twin tub cmos
       director   25-Jul-1991    15:25     twin tub cmos low vt
       cobourn    26-Jul-1991    10:32     nominal n-well cmos
       jacome     26-Jul-1991    11:43     n-well cmos high vt low kp


                       FIGURE 36. Hercules instance browser window.

dow provide user access to the operations on entity template working sets, as dis-
cussed in Sections through An instance browser window is composed
of three sections, from top to bottom: a set of attribute filters, control buttons, and the
working set viewer/selector. The Select control button is used to request a query into
the task database. The results of this query appear in the working set viewer. Con-
straints may be applied to the Select operation by checking one or more of the filters.
The Hercules CAD Task Management System                                         Page 79

The first three filters, “Keywords,” “Date Limits,” and “User Limits” specify con-
straints on the temporal properties of entity instances during the query. Fig. 36 shows
how the working set for device model parameters can be filtered to include only those
instances created between July 25, 1991, and July 27, 1991, and whose comments con-
tain the keyword “cmos.” The fourth filter, “Use Dependencies,” directs Hercules to
limit the working set to only those instances that have dependencies upon instances
in the working sets of the children of the current template. We note that these filters
may be applied in any combination to formulate complex queries.

One or more instances of the working set may also be selected directly, either by dou-
ble-clicking on an item in the working set viewer, or by highlighting items with the
mouse button depressed and the pressing the Select button. If the working set con-
sists of a single item, the History button becomes enabled. When the History button
is pressed, Hercules Expands the task tree to include the dependencies of the current
template, and pre-Selects their working sets to include only the instances that were
used in creating the target instance.

The two remaining control buttons, Install and Delete, are used to add or remove
instances to or from the task database. When the Install button is pressed, Hercules
opens a form window (not shown) that prompts the user for information about the
instances that is to be stored. It is by this mechanism that CAD tools or data libraries
are integrated into Hercules. Pressing the Delete button pops up a warning message
before permanently removing highlighted items from the task database. The Help Facility
While the task window allows users to view particular tasks that have been extracted
from the task schema, the Hercules Help Facility provides information about the task
schema itself. The Help Facility can be entered in one of two ways, either from an
entity template popup menu, of by pressing New Task in the task window menu bar.
In the latter approach, Hercules opens an entity browser window, not shown, that
gives an exhaustive listing of all the entities in the task schema, and provides a means
of indexing into the Help Facility. Rather than presenting the task schema graphically,
the Help Facility gives a hypertext view of the schema. An example help window is
shown in Fig. 37 for the entity type edited netlist.
The Hercules CAD Task Management System                                         Page 80

                                   Help: edited netlist
                 A netlist that has been created by manual editing.
                 Internal representation is based on CFI 5 box scalar
                 netlist model.

                 Subtype of:
                 Depends on function:
                 netlist editor
                 Depends on data:
                 Used in creating:
                 circuit performance
                 edited netlist

                               Close               New Task

                           FIGURE 37. Hercules help window.

A help window consists of three sections: a description, task schema hypertext links,
and control buttons. The first portion of a help window, the description, is used to
give general information about an entity type, its resource level representation, etc.
The task schema hypertext links serve two purposes in the help facility. First, they list
the relationships incident upon, and emanating from, a given entity. Second, they
provide a means for navigating through the task schema. Each of the entity names
shown in boldface are buttons that open a help window for the corresponding entity.

The New Task control button is used to specify the root or goal for a new task tree. Its
effect is to insert an entity template icon into the task window. New Task is only
enabled if the task window has been cleared. The Close button exits the Help Facility.

An important feature of the Help Facility is that it relies completely upon information
contained in the task schema; no external information is necessary. In this respect,
Hercules is self-documenting.
                                                                                Page 81

5.3.2 User Interaction
In the next sections, we will illustrate the use of the Hercules graphical user interface
in performing task execution and browsing activities. The first example is preparing
and running a simple task. Next, we will show how a backward-chaining query with
the History operation may be used to construct a new task that is a modification of an
existing prototype. Finally, we will present a forward-chaining query and the use of
the “Use dependencies” filter. Each of the examples is based upon the task schema
shown in Fig. 33. Running a Task
In this example, we illustrate the use of the Hercules graphical user interface in per-
forming the task, “extract a netlist from a layout and simulate its performance.”

 Since Hercules employs a goal
                                      Exit            Clear                New Task
based approach to task defini-
tion, we begin by selecting the                          Run
goal of the task, which in this
case is circuit performance.
When New Task is pressed,                           Entity Browser
Hercules opens an entity                      auto layout
browser that gives an exhaus-                 circuit extractor
tive listing of all entities in the           circuit performance
task schema. Here, the user                   circuit simulator
                                              device model parameters
picks circuit performance as the
goal. Note that the user may
                                                 OK            Help
also enter the help facility at
this point.

After the user selects the goal
                                      Exit            Clear                New Task
of the task from the entity
browser, an icon for circuit per-                        Run
formance appears in the task
window. The next step is to
Expand the task tree, using the                 Expand
command in the popup menu,                      Browse
to include the dependencies for                 Help
circuit performance in the task.                        circuit
                                                                                                        Page 82

Here, the dependencies for cir-
cuit performance have been           Exit                          Clear                           New Task
added to the task tree. The                                              Run
double border on netlist indi-
cates that we must specialize                                         circuit
this entity template before it                                      simulator
can be expanded. When Spe-                                Specialize
cialize is selected from the                              Browse     netlist
popup menu, a specialization                              Help
menu appears. In this case,                                                                   performance
                                             General: netlist     device model
extracted netlist is chosen as the                                 parameters
specialization.                              edited netlist

                                             extracted netlist        stimuli

With the task tree fully
                                     Exit                          Clear                           New Task
expanded to cover the scope of
the task, we now use the                                                 Run
instance browser to assign
unique instances to each of the                                       circuit
leaf nodes. This may be done                                        simulator
in any order, and we choose to               circuit
pick a layout first.                                                 extracted
                                             layout                                              circuit
                                                 Expand           device model
                                                 Browse            parameters

Keyword and timestamp limits
have been applied to filter the                            Instance Browser: layout
instances in the layout working         Keywords         cmos
set. “cmos inverter” is selected.
                                        Date Limits From:          7-25-1991        To:    7-26-1991
                                        User Limits

                                        Use Dependencies

                                        Browse/Select            History        Install       Delete

                                     jbb         25-Jul-1991     14:12     cmos inverter
                                     director    25-Jul-1991     15:25     cmos nand gate
                                     cobourn     26-Jul-1991     10:32     cmos alu
                                     jacome      26-Jul-1991     11:43     cmos 4 bit shift register

                                                                                                        Page 83

Because both tools and data are
modeled by entity types,                             Instance Browser: circuit simulator
browsing and selection of tools           Keywords
is the same as for data.
                                          Date Limits From:                        To:
                                          User Limits

                                          Use Dependencies

                                      Browse/Select             History         Install     Delete

                                    jlk         01-Jun-1991 23:35         Metasoftware HSpice
                                    zoe         02-Jun-1991 12:15         CMU AWEsim
                                    jbb         18-Jul-1991 20:30         CMU Adapts


Once the leaf nodes of the task
                                    Exit                           Clear                         New Task
tree have been uniquely
selected, the task is run by sim-                                      Run
ply pressing the Run button.
The task is executed via a pos-                                       circuit
torder traversal, first creating                                     simulator
an extracted netlist, then creat-           circuit                                         Comment
ing a circuit performance. As                                       extracted                  circuit
                                                                     netlist                performance
each new instance is created,                                                                   circuit
                                            layout                                         inverter delay
Hercules prompts the user for                                                               performance
                                                                  device model
a comment to be associated                                         parameters                Continue
with that instance. After a com-
ment is entered for circuit per-                                                                Stop
formance, execution of this task                                     stimuli
is complete.
                                                                                                  Page 84 The History Operation and the Use of Prototypes
Because the same task tree data structure is used for both browsing and execution,
Hercules allows the designer to intermix these activities, with powerful results. One
such result is the ability to easily form new tasks that are based on existing proto-
types. Suppose a designer wants to re-run a circuit simulation, changing only the
device model. In this example, we will show how the History operator may be
applied to the result of the previous task in order to help specify a new task.

To perform this task, the
                                    Exit                        Clear                        New Task
designer first chooses circuit-
performance as the root of a task                                   Run
tree. Instead of expanding a
tree, as was done in the previ-
ous example, the user browses
through existing instances to
select a prototype.                                       Help

The user selects the instance of
circuit-performance    “inverter                 Instance Browser: circuit performance
delay” that was just created in           Keywords
the previous example to serve
as the prototype. Next, the His-          Date Limits From:                     To:
tory operator is applied to this          User Limits
instance to expand the task
tree, preselecting the instances          Use Dependencies
used in creating “inverter                Browse/Select       History        Install     Delete
delay” into the working sets
for each of the dependencies of     jbb         23-Jun-1992 13:01       inverter delay
circuit performance.

                                                                                                       Page 85

At this point, the working set
for device model parameters con-    Exit                            Clear                         New Task
tains the unique instance that                                         Run
was used in creating the circuit
performance “inverter delay.”                             circuit
This instance may be viewed                             simulator
by opening the browser.
                                               Expand                            performance
                                                    device model


The browser indicates that
“nominal twin tub cmos” was                   Instance Browser: device model parameters
the instance used in createing            Keywords
the circuit performance “inverter
delay.”                                   Date Limits From:                       To:
                                          User Limits

                                          Use Dependencies

                                          Browse/Select         History        Install     Delete

                                    jbb         25-Jul-1991 14:12         nominal twin tub cmos


The designer may now change
the working set for device model              Instance Browser: device model parameters
parameters to a new instance, in          Keywords      cmos
this case “twin tub cmos low
vt.”                                      Date Limits From:                       To:
                                          User Limits

                                          Use Dependencies

                                          Browse/Select         History        Install     Delete

                                    jbb      25-Jul-1991 14:12            nominal twin tub cmos
                                    director 25-Jul-1991 15:25            twin tub cmos low vt
                                    cobourn 26-Jul-1991 10:32             twin tub cmos high vt

                                                                                                  Page 86

Finally, the user re-executes the
task by pressing the Run but-        Exit                        Clear                       New Task
ton in the task window. The                                         Run
comment “inverter delay 2” is
given to the new instance that                         circuit
is created.                                          simulator
                                                      netlist              performance
                                                                          inverter delay 2
                                                 device model
                                                  parameters                 Continue


Hercules thus fully supports the use of prototypes as discussed in [19], with the level
of abstraction raised from the component level to the task level. We note that the
intermixing of browsing and execution also provides a convenient means for back-
tracking, as designers can readily locate a previous state in the design derivation his-
tory. Forward-Chaining Query
In this final example, we will illustrate how the Hercules user interface is used to con-
struct a forward-chaining query into the design history. In particular, we consider
finding the set of all circuit performances that were simulated for the “cmos inverter”

To begin this query, the user
                                     Exit                        Clear                       New Task
first creates a task tree whose
goal is circuit performance and is                                  Run
expanded once through netlist.
Next, the user opens the netlist                     simulator
browser to select an instance to            Expand
server as the object of the                 Browse    netlist
query.                                      Help
                                                 device model

                                                                                                      Page 87

Here, the user selects the
“cmos inverter” netlist.                                  Instance Browser: netlist
                                          Keywords      cmos

                                          Date Limits From:                        To:
                                          User Limits

                                          Use Dependencies

                                          Browse/Select         History         Install      Delete

                                    jbb         16-Aug-1991     15:12     cmos inverter
                                    director    17-Aug-1991     16:25     cmos nand gate
                                    cobourn     18-Aug-1991     10:12     cmos alu
                                    jacome      19-Aug-1991     14:43     cmos 4 bit shift register


Next, the user opens an
instance browser for circuit per-                Instance Browser: circuit performance
formance. When the Use                    Keywords
Dependencies filter is applied
and the Browse/Select button              Date Limits From:                        To:
is pressed, the two perfor-               User Limits
mances that were simulated for
the “cmos inverter” netlist               Use Dependencies
appear in the working set.                Browse/Select         History         Install      Delete

                                    jbb         23-Jun-1992 13:01         inverter delay
                                    jbb         23-Jun-1992 18:15         inverter delay 2

CHAPTER 6                 Conclusions

A CAD framework may be characterized as a design system that provides a collec-
tion of domain-independent services, along with mechanisms for modeling the infor-
mation specific to a given domain. As we have discussed, domain-specific
information can be more easily modeled by separating framework services into
clearly defined levels of abstraction. The Odyssey CAD Framework employs four
levels of abstraction: the component level, the resource level, the task level, and the
design problem level.

In this thesis, we have defined the services and models used at the task level of
abstraction, where tasks are tool-independent design functions. Task management
services include support for the development and execution of task flows, support
for capturing and browsing a persistent record of the design derivation history, and
support for user interaction. A new information model, called a task schema, has been
introduced to characterize domain-specific knowledge at the task level that repre-
sents the dependencies between classes of tool and data objects. We have shown that
if tool encapsulation is based upon a task schema, the benefits of task management
services can be provided at a very low marginal cost beyond the efforts required for
encapsulation at a purely syntactic level.

The Hercules CAD Task Management System effectively demonstrates the schema-
based approach to task management and provides the services listed above. During

Conclusions                                                                   Page 89

an interactive session with Hercules, users operate on a task tree, whose structure is
defined by the rules embodied by the task schema. A single task tree can be used for
both preparing tasks for execution, as well as for formulating queries into the task
database. This affords designers a high degree of flexibility in controlling design

The main contribution of this work is demonstrating that a model that specifies the
configuration of a CAD system as relationships between different tool and data types
can also serve as an efficient means for structuring information about the history of
designs in progress. In other words, CAD system integration and design methodol-
ogy management, which have historically been considered separate issues, should in
fact be closely related. As we have shown, a task schema is a single representation
that supports both of these issues.

From a system integration viewpoint, we have shown that CAD tools can be effec-
tively encapsulated as functions that map a tuple of input types to a single output
type. By allowing the output type of an encapsulated tool to itself be an encapsulated
tool, we can handle particularly complex tasks, such as the construction and usage of
macromodels, that create tools as part of the design process.

From the viewpoint of design methodology management, we have shown that a task
database that captures the relationships between instances tool and data types is a
semantically much more powerful representation than traditional version trees.
While version trees capture dependency relationships between data objects alone, a
task database records the tools that were used in creating data objects as well. In
effect, a task database stores sufficient information to indicate how design objects
were created.

Finally, we conclude that a task schema composed of tool and data entity types and
the function and data dependency relationships between them is an effective means
for representing the configuration of a design system. As discussed in Chapter 3, we
recognize that schema-based approaches to data modeling in general have their limi-
tations, most notably the difficulty in changing a schema once persistent data has
been created. Nevertheless, the discipline imposed by a task schema is the substance
upon which task management services such as automatic task execution and design
history browsing facilities are based. Furthermore, we have shown that stable task
schemata can be developed for several application domains, including integrated cir-

Conclusions                                                                   Page 90

cuit and fabrication process simulation and optimization, that support not only the
creation of new data but also the installation of new tools with out requiring changes
to the task schema.

As database and operating system technologies evolve, we expect the form and the
role of a task schema in a CAD framework to change. Nevertheless, we believe that
the schema-based approach to CAD task management presented here is a significant
step towards developing CAD systems that not only integrate CAD tools, but also
help manage the design process.

CHAPTER 7                 Future Work

7.1 Adding Hierarchy to the Task Schema
As the scope of a design domain increases, the number of entity and dependency
relationship types in a task schema could grow to the point of being unmanageable
with the current browsing and help facilities. To address this issue, we propose add-
ing hierarchy to the task derivation model.

Any attempt to add hierarchy to a task schema should account for the fact the task
derivation model is not only flat structurally, but also semantically. The need to clas-
sify tasks within a task schema becomes especially important if Hercules is to be suc-
cessfully integrated with Minerva in Odyssey. One possible approach to forming a
hierarchical classification of tasks in a task schema is to identify patterns associated
with different design objectives such as inspection, verification, synthesis, and opti-
mization. Examples of such patterns were presented in Chapter 4. With such a classi-
fication system in place, Hercules clients would have the option of defining a task
tree either by goal object, or by action and parameters.

7.2 Distributed Task Execution
In nearly all design houses today, networked workstations have taken precedence
over large mainframes or single-user systems as the preferred computing environ-
Future Work                                                                        Page 92

ment. In its current implementation, Hercules supports concurrent access to both the
task schema and the task database through a client-server paradigm. Furthermore,
the Cyclops execution manager allows designers to invoke CAD tools on remote
machines across a computing network. Nevertheless, Hercules fails to take full
advantage of the computing advantages that a network can afford in terms of distrib-
uted processing. At present, Hercules executes tasks in a purely sequential manner,
performing a post-order traversal of the task tree until the goal node is reached. By
taking a more intelligent look at task execution, Hercules should be able to evenly
distribute tool invocation across a network.

The task tree data structure is particularly well-suited for exploiting distributed pro-
cessing. In executing a task tree, the only true requirement is that all child nodes must
be processed before their parents. A simple approach to distribution is to recursively
divide a task tree into disjoint subtrees, process each of the subtrees on a different
machine, and combine the results. Along with with this, algorithms should be devel-
oped to ensure adequate load balancing.

It has been stated that many of the services currently provided by frameworks should
ultimately be incorporated into operating systems [64]. We feel that distributed task
execution is a prime candidate for such a move.

7.3 Development of Applications
To date, we have developed demonstration task schemata for a variety of domains,
including integrated circuit and fabrication process simulation and optimization. In
the near future, we plan to extend the schema-based applications that have been
developed for Hercules to include a full suite of tools for analog design. The purpose
of this project is two-fold. First it will continue to exercise and test the capabilities of
Hercules and the task derivation model. Second it will result in a platform for further
research in circuit design.
APPENDIX A                Representation of
                          Tools and Data

The logic of considering both encapsulated tools and data as resources is analogous
to the handling of files in the Unix operating system—some files have an “execut-
able” attribute, some files don’t. Unlike executable files in Unix, however, our
approach to task management requires that tools are modeled as strongly typed func-
tions that expect certain entities as input and produce certain entities as output.
Because of the role that formally defined functions play in the task schema, we will
use the notation of set theory, type theory, and its extension to typed lambda calculus
to describe the modeling of the definitive properties of entities. From this basis, we
will develop an object model for entities that defines their relationship to resources.

A.1 Classification with Types
In set theory, the Axiom of Specification, or the Comprehension Axiom states that for
every set A and to every condition P(x), there corresponds a set B whose elements are
exactly those elements x of A for which P(x) holds. This may also be expressed sym-
bolically as:

                           B = { x ∈ A| P ( x ) ≡ T }                           (EQ 5)
                                                                                  Page 94

where T denotes the value “true”. Thus, if A is the set of all objects in a design system
and P(x) is a predicate that tests whether or not a given object x is a netlist, then
B ⊆ A is the set of all netlists.

In type theory, any set or property can be represented by a function that maps ele-
ments to the values “true” or “false”. Let V β denote a variable of type β and U αβ
denote a function that maps variables of type β to variables of type α, where the sub-
scripts are referred to as type symbols. If “o” is the type symbol denoting truth values,
then U oβ is a function that maps variables of type β to “true” or “false”. The Compre-
hension Axiom for type theory states that

                             ∃U oβ ∀V β [ U oβ V β ≡ A o ] ,                        (EQ 6)

where A o is any (well-formed) formula that evaluates to a truth value. In other
words, the Comprehension Axiom asserts the existence of some function U oβ that
indicates whether or not an element is of a certain type β.

One result of the Comprehension Axiom is that instances of a given type may be
defined as all those objects that possess a certain set of properties. This is the view of
types that has been adopted by many representation languages, including most com-
puter languages. The Comprehension Axiom itself can also be used to define accessor
functions that return the values of these properties. Using the notation presented

                             ∃u αβ ∀v β [ u αβ v β ≡ A α ] ,                        (EQ 7)

asserts the existence of functions u αβ that map instances of type β to instances of type
α. Thus, if instances of type β are defined has having properties or attributes of types
α 1, α 2, …, α n , the functions u α β, u α β, …, u α β may be used to access the values of
                                    1      2         3
these attributes.

EXAMPLE 8. Representing a Simple MOS Transistor Device Model

       Suppose that a simple MOS (metal-oxide-semiconductor) transistor model is
       defined as having the attributes threshold voltage (vt) and transconductance
       (k), each of which are in turn of type real. In the computer language C++, the
       class (type) “MOST” representing this model can be defined by the statement:
       class MOST {
                                                                               Page 95

          float vt;
          float k;
          MOST(float x, float y)          {vt=x; k=y;}
          float get_vt()                  {return vt;}
          float get_k()                   {return k;}

       This statement declares class “MOST” as having the two attributes vt and k, a
       constructor function “MOST(float, float)”, and accessor functions correspond-
       ing to each of the two attributes. The program fragment
       MOST d(0.2, 1.0e5);
       float a = d.get_vt();
       float b = d.get_k();
       creates an instance “d” of class “MOST” with vt = 0.2 and k = 1.0 × 10 , and
       assigns the values of the threshold voltage and transconductance of “d” to the
       real-valued variables “a” and “b”, respectively, using the appropriate accessor
       functions. The same notion of a MOS device could also be expressed by
       Cobourn’s frame model, as implemented in the Cyclops Resource Manage-
       ment System:
       frame most {
          real vt;
          real k;

       Written in the language of the Cyclops Frame Manager, the program fragment
       below implements the same functionality as the C++ example, using the
       assignment function “setReal”, and the accessor “getReal”:
       CID d;           // CID is the type of a Cyclops object ID
       double a,b;

       create(“most”, &d);
       setReal(d, “vt”, 0.2);
       setReal(d, “k”, 1e5);

       getReal(d, “vt”, &a);
       getReal(d, “k”, &b);

A.2 Functions as Typed Objects
To this point, we have focused upon how types may be defined in terms of a collec-
tion of attributes, and how functions can be used to either ascertain the type of an
object or to access the value of one of its attributes. Thus we have been concerned pri-
                                                                                        Page 96

marily with monadic functions that take a single argument of a specified type. A more
general view of functions is supported by considering the type composed of ordered
sequences of objects of other types, called tuples. An n-tuple is represented symboli-
cally by the expression ( x 1 , x 2 , …, x n ) , where α 1, α 2, …, α n are the types of vari-
                                α1 α2            αn
        1 2          n
ables x , x , …, x , respectively. An n-tuple can also be regarded as the type of a cross
product           of         sets,           ( x 1, x 2, …, x n ) = X 1 × X 2 × … × X n ,  where
x 1 ∈ X 1, x 2 ∈ X 2, …, x n ∈ X n . If τ is the type of an n-tuple, then f ατ is a function that
maps a parameter list of objects, where the list itself is of type τ, to an object of type α.
One example of such a function was already encountered in Example 8, for the C++
constructor MOST(float x, float y), that maps the real-valued variables “x” and “y” to
an instance of class “MOST”.

In general, one can define constructors for any type α that has as its parameters a
tuple of type τ. Such constructors, however, are not necessarily unique, since a vari-
ety of algorithms could be applied to achieve the desired result. For example, con-
sider the problem of sorting a list of names into alphabetical order. Let β denote the
type of a list of names in random order, and α denote the type of a list of names in
sorted order. f ατ , where τ in this case is the 1-tuple ( x β ) , is thus a function that sorts
a list. There are many possible ways of implementing f ατ , such as insertion sort, bub-
ble sort, and quick sort. Furthermore, the choice of the proper approach depends
upon several factors, not least of which is the predicted efficiency of the sorting algo-
rithm. Because f ατ can itself have multiple instances that can be described by a finite
set of properties, it is appropriate to classify functions, as well as data, as typed objects.

A formulation of type theory, known as typed lambda calculus and developed by
Alonzo Church in the 1940’s, provides a means for describing functions in terms of
their implementation. This theory introduces an abstraction operator, λ, where
 [ λv β A α ] denotes the function whose value on a parameter set v of type β is A α ,
where v β may be free in A α . Written in terms of λ, the Comprehension Axiom of
(EQ 7) becomes

                              ∀v β [ [ λv β A α ] v β = A α ] .                          (EQ 9)

EXAMPLE 10. Using λ to Define Functions

       Let β be the type of a natural number. [ λn β [ n 2 + 2n β + 1 ] ] defines the func-
       tion that returns n 2 + 2n + 1 for any natural number n. Thus
        [ λn [ n 2 + 2n + 1 ] ] 5 = 36 .
                                                                                            Page 97

        [ λn β [ [ n β + 1 ] 2 ] ] is equivalent to [ λn β [ n 2 + 2n β + 1 ] ] , but they are not the
       same function.

       Similarly, if β is the type of a list in random order and α is the type of a list in
       sorted order, [ λv β [ quicksort in terms of v β ] ] x β = a list that is a sorted version
       of x β .

Since functions themselves can be classified as types, it should be possible to define
constructors for functions. At first glance, this property of functions may seem to
have little bearing in a CAD environment, where functions are based upon CAD
tools. As we will show later, however, the ability to create functions as part of a
design process greatly expands the flexibility of a design system, enabling activities
that would otherwise be awkward to support.

The prevalence of functions that create functions is easier to see if we momentarily
suspend the notion of evaluating functions on a computer. A simple example is the
differentiation operator, /x, where f/x is the partial derivative of f with respect to x.
The differentiation operator can thus be regarded as a function that takes a function
as an argument and returns another function. Certain interpreted computer lan-
guages, such as Lisp, readily accomodate the concept of creating functions at runt-
ime, and other languages can achieve this behavior if one program is allowed to
compile another program. In the context of a design system, any time a program is
compiled as part of the design process, it can be modeled as a function with a con-

EXAMPLE 11. Symbolic Differentiation in Lisp

       The computer language Lisp is a particularly good vehicle for illustrating con-
       cepts in the representation of functions because of its close syntactic ties to the
       predicate calculus. Lisp expressions are constructed as lists of symbols, placed
       between parentheses, where the first element in the list is interpreted as a
       function. Thus the expression (+ 3 2) evaluates to 5.

       Lisp uses the symbol lambda in much the same manner as the abstraction oper-
       ator in λ-calculus to define unnamed functions. The polynomial 3x 2 + 2x + 1
       may be represented in Lisp by the expression:
       (lambda (x) (+ (* 3 (expt x 2)) (* 2 x) 1))
                                                                      Page 98

This function can be evaluated for x = 5 by the expression:
(funcall ‘(lambda (x) (+ (* 3 (expt x 2)) (* 2 x) 1)) 5)

→ 86

A function diffpoly can be written that lexically analyzes the lambda-expres-
sion representation of a polynomial and returns another lambda-expression
that represents its derivative. diffpoly is thus a function of the form f αα ,
where α is the type of a polynomial.
(diffpoly ‘(lambda (x) (+ (* 3 (expt x 2)) (* 2 x) 1)))

→ (lambda (x) (+ (* 6 x) 2))

Finally, both taking the derivative and evaluating the result at x = 5 can be
accomplished by a single expression:
(funcall (diffpoly ‘(lambda (x) (+ (* 3 (expt x 2)) (* 2 x) 1))) 5)

→ 32

[1]   C.Alexander. Notes on the Synthesis of Form. Harvard University Press, 1964.

[2]   W. Allen, D. Rosenthal, and K.Fiduk. “Distributed Methodology Management
      for Design-in-the-Large.” In Proceedings of the IEEE International Conference on
      Computer-Aided Design, IEEE, 1990, pages 346-349.

[3]   P.B. Andrews. An Introduction to Mathematical Logic and Type Theory: To Truth
      through Proof. Academic Press, Inc., 1986.

[4]   ANSI. “Interim Report from the Study Group on Database Management Sys-
      tems,” Bulletin of SIGMOD, 7(2), 1973.

[5]   P. Bingley and P. van der Wolf. “A Design Platform for the NELSIS CAD Frame-
      work.” In Proceedings of the 27th ACM/IEEE Design Automation Conference, ACM
      Press, 1990, pages 146-149.

[6]   G. Booch. Object Oriented Design with Applications. Benjamin/Cummings Pub-
      lishing Co., Inc., 1991.

[7]   K.O. ten Bosch, P. Bingley, and P. van der Wolf. “Design flow Management in
      the NELSIS CAD Framework.” In Proceedings of the 28th ACM/IEEE Design Auto-
      mation Conference, ACM Press, 1991.
                                                                             Page 100

[8]   F. Bretschneider, C. Kopf, H. Lagger, A. Hsu, and E. Wei. “Knowledge Based
      Design Flow Management.” In Proceedings of the IEEE International Conference on
      Computer-Aided Design, IEEE, 1990, pages 350-353.

[9]   J. B. Brockman, T.F. Cobourn, M. Jacome, and S.W. Director. “The Odyssey CAD
      Framework.” In IEEE DATC Newsletter on Design Automation, IEEE, Spring 1992.

[10] J.B. Brockman and S.W. Director. “Predictive Subset Testing: Optimizing IC
     Parametric Performance Testing for Quality, Cost, and Yield,” IEEE Transactions
     on Semiconductor Manufacturing, 2(3):104-113, August 1989.

[11] J.B. Brockman and S.W. Director. “The Conceptual Schema: A New Basis for
     CAD Framework Organization.” In Techcon ‘90-Extended Abstract Volume, Semi-
     conductor Research Corporation, 1990, pages 35-38.

[12] J.B. Brockman and S.W. Director. “A Macromodeling Approach to Process Sim-
     ulator Tuning.” In Proceedings of the Workshop on Numerical Modeling of Processes
     and Devices for Integrated Circuits: NUPAD III, IEEE, 1990, pages 17-18.

[13] J.B. Brockman and S.W. Director. “The Hercules CAD Task Management Sys-
     tem.” In Proceedings of the IEEE International Conference on Computer-Aided
     Design, IEEE, 1991, pages 254-257.

[14] H. Brown, C. Tong, and G. Foyster. “Palladio: An Exploratory Environment for
     Circuit Design,” Computer Magazine, 16:41-56, December 1983.

[15] R.E. Bryant, D. Beatty, K. Brace, K. Cho, and T. Sheffler. “COSMOS: A Compiled
     Simulator for MOS Circuits.” In Proceedings of the 24th ACM/IEEE Design Auto-
     mation Conference, ACM Press, 1987, pages 9-16.

[16] M. Bushnell and S.W. Director. “Automated Design Tool Execution in the
     Ulysses Design Environment,” IEEE Transactions on Computer-Aided Design,
     8(3):279-287, March 1989.

[17] CAD Framework Initiative. “CAD Framework Users, Goals, Objectives, and
     Requirements,” Technical report, Architecture Technical Subcommittee:
     Requirements Task Group, Version 1.4, February 1990. Preliminary Working
                                                                            Page 101

[18] CAD Framework Initiative. “Scalar Netlist Specifications”

[19] A. Casotto, R. Newton, and A. Sangiovanni-Vincentelli. “Design Management
     based on Design Traces.” In Proceedings of the 27th ACM/IEEE Design Automation
     Conference, ACM Press, 1990.

[20] P. Chen. “The Entity-Relationship Model-Toward a Unified View of Data,”
     ACM Transactions on Database Systems, 1(1):9-36, March 1976.

[21] T. Chiueh and R. Katz. “A History Model for Managing The VLSI Design Pro-
     cess.” In Proceedings of the IEEE International Conference on Computer-Aided
     Design, IEEE, 1990, pages 50-52.

[22] A. Church. The Calculi of Lambda-Conversion. Princeton University Press, 1941.

[23] G. Clark and R. Zippel. “SCHEMA—An Architecture for Knowledge-Based
     CAD.” In Proceedings of the IEEE International Conference on Computer-Aided
     Design, IEEE, 1985, pages 358-361.

[24] T.F. Cobourn and S.W. Director. “An Improved Methodology for CAD Tool Inte-
     gration.” Submitted for review.

[25] J. Daniell and S.W. Director. “An Object Oriented Approach to CAD Tool Con-
     trol,” IEEE Transactions on Computer-Aided Design, 10(6):698-713, June 1991.

[26] A.M. Dewey and S.W. Director. “Yoda: A Framework for the Conceptual Design
     of VLSI Systems.” In Proceedings of the 26th ACM/IEEE Design Automation Confer-
     ence, ACM Press, 1989, pages 380-383.

[27] P. Dewilde. “Design vs. Standards: The Cases.” In Proceedings of the Second IFIP
     WG 10.2 Workshop on Electronic Design Automation Frameworks, Edited by F. J.
     Rammig and R. Waxman, Elsevier Science Publishers, 1991, pages 37-55.

[28] L.D. Erman, F. Hayes-Roth, V.R. Lesser, and D.R. Reddy. “The Hearsay-II
     Speech Understanding System: Integrating Knowledge to Resolve Uncertainty,”
     Computing Surveys, 12(2), June 1980.

[29] Express modeling language.
                                                                             Page 102

[30] P. Feldman and S.W. Director. “Accurate and Efficient Evaluation of Circuit
     Yield and Yield Gradients.” In Proceedings of the IEEE International Conference on
     Computer-Aided Design, IEEE, 1990, pages 120-123.

[31] S.I. Feldman. “Make-A Program for Maintaining Computer Programs,” Soft-
     ware-Practice and Experience, 9(4):98-106, 1979.

[32] A.J. Gadient. “A Framework for Knowledge Source Based VLSI Synthesis,”
     Technical Report CMUCAD-89-36, Carnegie Mellon University, May 1989. Mas-
     ter’s Project Report.

[33] M. Guiney, S. Kleinfeldt, J. Miller, and M. Yeung. “Design Methodology
     Manangement.” Advance copy of paper invited to appear in Proceedings of the

[34] P. van den Hamer and M.A. Treffers. “A Data Flow Based Architecture for CAD
     Frameworks.” In Proceedings of the International Conference on Computer-Aided
     Design, IEEE, 1990, pages 482-485.

[35] D. Harel. “On Visual Formalisms,” Communications of the ACM, 31(5):514-530,
     May 1988.

[36] D. Harrison, P. Moore, R. Spickelmier, and A. Newton. “Data Management and
     Graphics Editing in the Berkeley Design Environment.” In Proceedings of the
     IEEE International Conference on Computer-Aided Design, IEEE, 1986.

[37] D. Harrison, A. Newton, R. Spickelmier, and T. Barnes. “Electronic CAD Frame-
     works,” Proceedings of the IEEE, 78(2):393-417, February 1990.

[38] Homer. The Odyssey. P.F Collier and Son, 1969. Translated by S.H. Butcher and
     A. Lang.

[39] Informix Software, Inc. Informix-SQL Version 2.10.00B, 1987.

[40] M. Jacome and S.W. Director. “Design Process Management for CAD Frame-
     works,” In Proceedings of the 29th ACM/IEEE Design Automation Conference, ACM
     Press, 1992.

[41] A. Di Janni. “A Monitor for Complex CAD Systems,” In Proceedings of the 23rd
     ACM/IEEE Design Automation Conference, ACM Press, 1986, pages 145-151.
                                                                              Page 103

[42] D. Johannsen. “Bristle Blocks: A Silicon Compiler,” In Proceedings of the 16th
     ACM/IEEE Design Automation Conference, ACM Press, 1979, pages 310-313.

[43] R. Katz “Towards a Unified Framework for Version Modeling.” Technical
     Report, University of California Berkeley, Computer Science Division, no.
     UCB/CSD 88/484.

[44] D.W. Knapp and A.C. Parker. “A Design Utility Manager: The ADAM Planning
     Engine.” In Proceedings of the 23rd ACM/IEEE Design Automation Conference,
     ACM Press, 1986, pages 48-54.

[45] N. Kraft. “Embedded Tool Encapsulation.” In Proceedings of the Second IFIP WG
     10.2 Workshop on Electronic Design Automation Frameworks, Edited by F. J. Ram-
     mig and R. Waxman, Elsevier Science Publishers, 1991, pages 9-20.

[46] K.K. Low and S.W. Director. “An Efficient Macromodeling Approach for Statis-
     tical IC Process Design.” In Proceedings of IEEE International Conference on Com-
     puter-Aided Design, IEEE, 1988, pages 16-19.

[47] K.K. Low and S.W. Director. “A New Methodology for the Design Centering of
     the IC Fabrication Process,” IEEE Transactions on Computer-Aided Design,
     10(7):895-903, July 1991.

[48] A. Margaris. First Order Mathematical Logic. Dover Publications, Inc., 1990.

[49] C. Mead and L. Conway. Introduction to VLSI Systems. Addison-Wesley Publish-
     ing Company, Inc., 1980.

[50] Meta-Software Inc. HSPICE User’s Manual, H9001. 1990.

[51] T. Miyazaki, T. Hoshino, and M. Endo. “A CAD Process Scheduling Technique.”
     In Proceedings of the IEEE International Conference on Computer-Aided Design,
     IEEE, 1990, pages 354-357.

[52] S.R. Nassif, A.J. Strojwas, and S.W. Director. “FABRICS II: A Statistically Based
     IC Fabrication Process Simulator,” IEEE Transactions on Computer-Aided Design,
     3(1):40-46, January 1984.

[53] Objectivity, Inc. Objectivity/DB. Menlo Park, CA, 1991.
                                                                             Page 104

[54] L.A. O’Neill, C.G. Savolaine, T.J. Thompson, J.M Franke, R.A. Friedenson, E.D.
     Walsh, P.H. McDonald, J.B. Breiland, and D.S. Evans. “Designer’s Workbench—
     Efficient and Economical Design Aids.” In Proceedings of the 16th ACM/IEEE
     Design Automation Conference, ACM Press, 1979, pages 185-199.

[55] L.T. Pillage and R.A. Rohrer. “Asymptotic Waveform Evaluation for Timing
     Analysis.” IEEE Transactions on Computer-Aided Design, 4(9):352-366, April 1990.

[56] E. Siepmann, G. Zimmerman. “An Object-Oriented Database Model for the
     VLSI Design System PLAYOUT”, In Proceedings of the 26th ACM/IEEE Design
     Automation Conference, ACM Press, 1989, pages 814-817.

[57] D.P. Siewiorek, D. Giuse, W.P. Birmingham, M. Hirsch, V. Rao, and G. York.
     “DEMETER Project: Phase 1 (1984),” Technical Report CMUCAD-84-35, Carn-
     egie Mellon University, July 1984.

[58] J.M. Siskind, J.R. Southard, and K.W. Crouch. “Generating Custom High Perfor-
     mance VLSI Designs from Succinct Algorithmic Descriptions,” in Proceedings of
     the Conference on Advanced Research in VLSI,” Massachusetts Institute of Technol-
     ogy, 1982, pages 28-40.

[59] G.L. Steele. Common Lisp. Digital Press, 1984.

[60] B. Stroustrup. The C++ Programming Language. Addison-Wesley Publishing Co.,

[61] P. van der Wolf and T.G.R van Leuken. “Object Type Oriented Data Modeling
     for VLSI Data Management.” In Proceedings of the 25th ACM/IEEE Design Auto-
     mation Conference, ACM Press, 1988, pages 351–356.

[62] P. van der Wolf, G.W. Sloof, P. Bingley, and P. Dewilde. “Meta Data Management
     in the NELSIS CAD Framework.” In Proceedings of the 27th ACM/IEEE Design
     Automation Conference, ACM Press, 1990, pages 142–145.

[63] A. Westerberg, et. al. “nDim”.

[64] W. Wolf. “In search of simpler software integration,” Spectrum, page 31, January
                                                                              Page 105

[65] W. Wolf, J. Newkirk, R. Matthews, and R. Dutton. “Dumbo, A Schematic-to-
     Layout Compiler, “ in Proceedings of the Third Cal. Tech. Conference on VLSI,” Cal-
     ifornia Institute of Technology, 1983, pages 379-394.

To top