698 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. IO, NO.

6, JUNE 1991
An Object Oriented Approach to CAD Tool Control
J ames Daniell, Member, IEEE, and Stephen W. Director, Fellow, IEEE
Abstract-As VLSI design frameworks evolve, a distributed
control mechanism for CAD tools has become a central re-
search issue. In this paper, we present an object oriented tool
integration methodology that treats the fools as objects. This
approach simplifies CAD tool control within a design frame-
work, making the framework more general, easier to use, and
more capable of supporting a large population of CAD tools.
I . INTRODUCTION
ODAYS VLSI design specialist must be able to use
T a large number of VLSI CAD tools in order to create
larger and more complex VLSI designs. To date, the de-
velopers of most CAD tools have focused on creating
more robust, efficient, and powerful programs rather than
making them easier to integrate into the overall design
cycle. Even though newer VLSI CAD tools often have
graphical user interfaces that make them easier to interact
with individually, these graphics still do not help the VLSI
designer to envision the state of both the design and that
of the overall design process. VLSI designers need a way
to both consistently interact with the individual tools as
well as to manage the design process from a single point
of view.
The first attempt to address this problem was through
the creation of tightly integrated suites of CAD tools that
were each designed to work together. Such collections of
tools are referred to as design environments. While design
environments do address the need for design process con-
sistency, they are unable to help the VLSI designer ad-
dress the real world problems associated with a large pop-
ulation of heterogeneous CAD tools that were neither
designed to work together nor capable of interacting with
newer, foreign tools. To further address heterogeneous
interoperability , a new generation of design systems,
called design frameworks, are being created.
VLSI design frameworks are open, loosely coupled
systems constructed to allow numerous tools to share data
and resources without having to be explicitly designed to
work together. Most research in the area of design frame-
works has focused on design data management and user
interfaces. However, as the design process becomes more
Manuscript received April 17, 1990. This work was supported by the
Semiconductor Research Corporation under Grant SRC88-DC-068, by the
UNISYS Corporation, and by the National Science Foundation under Grant
CDR-8522616. This paper was recommended by Editor M. R. Lightner.
J. Daniell was with Research and Development, Software AG, Reson,
VA. He is now with AT&T Unix Systems Laboratory, Summit, NJ 07901.
S. W. Director is with the Department of Electrical and Computer En-
gineering, Camegie Mellon University, Pittsburgh, PA 15213.
IEEE Log Number 9042634.
automated, the designer spends less time directly manip-
ulating design data and more time managing CAD tools
that manipulate the design data. This results in the need
for extensions to standard user interfaces to include
graphical and textual information that can be used to ma-
nipulate CAD tools and, in effect, provide a user interface
to the design process management system. Overall, de-
sign data manipulation shifts more towards the CAD tools
and away from direct designer intervention.
This paper discusses one such design framework
testbed, named Cadweld, that extends previous work [3]
and forms the basis for a new way to model and imple-
ment a distributed control mechanism for a large popula-
tion of heterogeneous CAD tools. Specifically, Cadweld
simplifies designer interaction with individual CAD tools
as well as allowing arbitrary CAD tools to be easily added
or deleted from the design framework. This approach is
fundamentally different than many other design frame-
work initiatives that are more concerned with providing a
distributed and general data model and tools to support
this model 191, [ 1 11, [ 11. While we recognize the need for
such models and tools, we believe that the issue of CAD
tool control is central to overcoming many of the prob-
lems that have plagued previous design environments. The
core of our approach is modeling CAD tools as first-class
abstract data types within a design framework. Specifi-
cally, each tool is represented as an object oriented entity
with associated specialized functions which leads to a
more general and open control mechanism within the de-
sign framework. While Cadweld has not been designed to
address other (and complimentary) research issues in CAD
data modeling, it none the less serves as a useful vehicle
to validate the proposed approach to CAD tool control.
As Cadweld directly extends the unique work of the
ULY SSES design framework, the next section summa-
rizes the ULYSSES systems strengths and weaknesses.
Subsequent sections review the overall contributions of
the Cadweld project, the organization of the Cadweld im-
- -
plementation, and present -an illustrative example.
nally , the conclusion discusses the contributions of
Cadweld research.
11. ULYSSES-AN EARLY FRAMEWORK
The ULYSSES [3], [4] VLSI design framework
Fi-
the
ad-
dressed the fundamental issues surrounding heteroge-
neous CAD tool integration at both the data and control
levels. The issues addressed included the ability to incor-
porate arbitrary CAD tools into a framework; automatic
0278-0070/91/0600-0698$01 .OO 0 1991 IEEE
DANIELL AND DIRECTOR: APPROACH TO CAD TOOL CONTROL 699
execution of a design task that may, in turn, require the
execution of multiple CAD tools; support of a design cap-
ture mechanism; and the handling of data translation be-
tween dissimilar CAD tools. ULYSSES employed a
blackboard-based architecture, similar to that of HEAR-
SAY-I1 [12], to handle interaction between CAD tools and
to distribute design information. The blackboard was in
essence a global data space through which cooperating
processes communicated with each other. Various goals
and intermediate results were stored on the blackboard.
This information caused the execution of CAD tools, gen-
eration of new internal data, or modification of informa-
tion that already existed on the blackboard. Control of the
blackboard was explicitly maintained by the Scheduler
[3]. The Schedulers job was to examine all pending op-
erations and decide in which order they should be exe-
cuted. The Scheduler used many criterion to arbitrate be-
tween CAD tools; such criteria included job priority,
whether the task required human interaction, and the
available computer resources.
Design activities are encoded in scripts that are
compiled to automatically execute the CAD tools needed
to carry out a design task. More specifically, a script is a
high level representation of a design task that contains
information about the CAD tool execution sequence, the
reasons for each step in the sequence, and how the output
of one tool could be used as the input to another tool. In
order to develop a script, a designer had to have a com-
plete and detailed knowledge of ULYSSES and the CAD
tool suite and its operation. However, once a complex
CAD tool task is encoded in a script by an expert de-
signer, a novice designer could then employ the script with
little or no knowledge of how it is developed. The script
is compiled by the Scripts Compiler [3] that created a set
of expert system rules that could, in turn, activate tools
or interact with the blackboard.
ULYSSES demonstrated that the blackboard architec-
ture is an effective means for automatic execution of ap-
propriate CAD tools to meet a specified set of require-
ments. Furthermore, the Scripts Language [3] (and its
associated compiler) produced a mechanism that under-
stood CAD tool sequencing and a format to explicitly
represent CAD tool interaction. Since ULYSSES had the
ability to arbitrate between competing CAD tools, the
scripts writer could partially decompose the problem by
formulating a large design task in terms of a set of smaller
scripts. ULYSSES would then properly sequence the run-
time requests and actions.
Unfortunately, the script mechanism for control has
limitations. Although scripts could generally be used to
describe design tasks, they concentrated too much infor-
mation about the individual tools and the environment
within the script. This made the script mechanism cum-
bersome and difficult to maintain. In particular, since
scripts made explicit reference to CAD tools, it required
that existing scripts be rewritten as new CAD tools were
introduced into the environment.
A second limitation with the script mechanism is that
scripts require the designer to fully specify the design task
in advance. This is not always possible because design
often involves dynamic modification of plans as the de-
sign progresses. Therefore, the information needed for a
given design task is not always known a priori. For ex-
ample, the actual writer of a script may know that a par-
ticular type of tool (e.g., a circuit simulator) will be re-
quired for a given task but may not know which particular
tool (e.g., SPICE) will be used at runtime.
ULYSSES managed a large number of design details
and complex design interdependencies. It automatically
maintained consistency throughout the design represen-
tation and could re-invoke CAD tools if a change was
made. This allowed ULYSSES to handle feedback in the
design loop, allowed CAD tools to interact through dif-
ferent views of the design, and allowed for tedious detail
management to be handled semi-automatically.
Experience with ULYSSES showed that when infor-
mation about CAD tools and the design task are intermin-
gled, the ability to write and maintain scripts is made dif-
ficult. There needs to be a formal separation of knowledge
concerning CAD tool operation and knowledge needed to
perform a design task. Furthermore, specific knowledge
of how a CAD tool operates should be as far removed
from the user view of the system as possible. This implies
that some intermediate form must be used to interface
CAD tools which transparently handles the details of the
CAD tool operation but still allows high level access to
the CAD tools functionality.
In this paper we introduce a new approach to CAD tool
control that simplifies the way a designer interacts with a
set of CAD tools as well as allowing arbitrary CAD tools
to be easily added or deleted from the design framework.
This approach is fundamentally different than many other
design framework initiatives that are more concerned with
providing a distributed and general data model and tools
to support this model [9], [ 111, [ 13. While we recognize
the need for such models and tools, we believe that the
issue of CAD tool control is central to overcoming many
of the problems that have plagued previous design envi-
ronments. The core of our approach is a new way of mod-
eling the CAD tools within a design framework. Specifi-
cally, each tool is represented as an abstract object so that
the design framework can manage it at a very high level.
As we shall see, this leads to a more general and open
control mechanism within the design framework.
111. A NEW APPROACH TO CAD TOOL CONTROL
Based on the experience we gained with ULYSSES, we
feel that a distributed and open control mechanism can be
effectively used to drive the design process while not re-
stricting how the designer interacts with the tools. Since
there now exists a larger population of CAD tools as well
as better data models to support them, we can shift our
focus away from data modeling issues and more towards
the manner in which the designer and the CAD tools in-
teract. In short, we can build a design framework that em-
ploys a new view of CAD tool control.
IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. IO, NO. 6, JUNE 1991 700
In order to build a usable design framework, it must
include a control mechanism that supports the following
features.
A domain independent representation of control di-
rectives that is required to perform work in the design
framework (i.e., a control language).
A way to automatically map from control directives
to actual tool invocation. This implies that the end result
of any control directive is the eventual running of a tool
in a transparent manner (i.e., high level requests such as
make a PLA will eventually result in CAD tools being
invoked that creates the desired PLA) .
Support of a hierarchical organization of control that
allows different parts of the design framework to initiate
control directives.
The control mechanism must support opportunistic
as well as deterministic control flow. Opportunistic op-
eration (e.g., selecting a tool dynamically during the de-
sign process) is essential if the design framework is to
handle a large, changing population of CAD tools and
still function without modification.
The ability to detect errors or failure to complete a
control directive so that the framework can exhibit robust
operation in spite of the imperfect CAD tools and design
data.
The ability to backtrack, allowing the design frame-
work to move to an earlier state in the control flow. With-
out this feature, the framework would not be able to it-
erate, handle complex errors, or be able to explore the
design space in a breadth-first manner.
The ability to resolve between multiple control paths
and possibly traverse these paths simultaneously. This is
essential if the framework is to support groups of tools
that compete for the same role in the design cycle.
4.1. The Blackboard Model
The ULYSSES system demonstrated that a blackboard
model (see Fig. 1) meets all of the above criteria. In this
model, control directives take the form of posts to the
blackboard. These posts ultimately result in a tool being
selected and then invoked. Any blackboard agent (i.e., a
software module that interacts with the blackboard) may
post to the blackboard allowing each agent to initiate con-
trol flow. Because the blackboard is inherently event
driven, it allows the design process to be opportunistic
rather than procedural in nature. Error handling can be
achieved through error reporting to the blackboard (i.e.,
a post that contains error information). Either specialized
error handling or normal blackboard agents then use this
error information to determine the correct course of ac-
tion. Backtracking (discussed in the following) is not ex-
plicitly handled via the blackboard but by the initiator of
a post. Finally, resolution between different alternatives
is handled in a distributed manner, which is significantly
different than the approach taken in ULYSSES.
To create a more general and open control mechanism,
we have modified the ULYSSES blackboard model to in-
clude a volunteer mechanism in which posts to the black-
Designer
t-
f
Fig. I . A simplified view of the blackboard
board are implicit bids much like a contract-net scheme
[7], [15]. Agents that wish to respond to a post are col-
lected and passed back to the initiator of the post. The
post initiator makes control decisions by either sorting or
pruning the list of volunteers to select a single agent to be
activated. This approach implies that control decisions are
ultimately made by the designer or by higher level agents,
termed CAD tusks (or tasks), that perform multiple design
steps automatically (we more fully describe tasks later).
The individual control decision (such as the best tool to
invoke to perform a simulation step) is performed by the
task (or designer) that originally posted the request for an
action to take place. This allows the task (or designer) to
base the decision within the smaller context of the design
step that the task (or designer) is currently trying to per-
form. This is much different than systems, such as ULYS-
SES, that employ a central scheduling mechanism to con-
trol a body of self-activating blackboard agents. The major
problem with self-activating agents is that posts to the
blackboard may result in immediate and undesirable ac-
tion being taken by an agent. Therefore, all posts to the
blackboard must be monitored and their implications must
be apparent in order to keep the design framework per-
forming useful work. The scheduler must be both domain
specific (i.e., it must know about the type of design being
undertaken) and centralized so that all control decisions
are examined by the scheduler. Cadweld, however, nei-
ther uses nor requires a scheduler.
With this mechanism, the blackboard becomes a con-
duit that matches the needs of the designer with the abil-
ities of the CAD tools ut a high level. Since existing CAD
tools were not designed to interact with the blackboard in
the manner described above, an intermediate form must
be created that bridges the gap between the CAD tool and
the blackboard. We term this new form the CAD tool ob-
ject (CTO) (described in the following). The CTO be-
comes more than just a place holder for the tool within
the blackboard scheme; it becomes an essential element
in our scheme to make the control mechanism more open
and general. If we wish to stop using a centralized sched-
uler, the blackboard can only play a limited role in deter-
mining which tools are to be used and in what manner.
This is only possible because of the contract-net protocol
and the fact that the CTOs can accurately inform the de-
DANIELL AND DIRECTOR: APPROACH TO CAD TOOL CONTROL 70 1
signer or task as to the CAD tools abilities and attributes.
In effect, the posting task need not be concerned with low
level invocation details. This allows the designer or task
to direct control from within the appropriate context for
a given design decision where the scheduling makes more
sense.
If we are to adopt this view of CAD tools as objects,
we must adapt our view of the framework to support ge-
neric CAD objects (consisting of CTOs and CAD tasks).
One of the more onerous problems with distributed
control procedures is the manner in which backtracking is
handled. A backtracking capability is essential in a design
framework in which error recovery, design optimization,
an iterative, or recursive design styles are to be handled.
The design framework must be able to track the control
flow so that if the need for backtracking arises, previous
design information can be restored. By using the volun-
teer mechanism (rather than self-activating blackboard
agents), the context of the control flow is maintained by
the designer or task that initiated the post. We, therefore,
require a design log mechanism to save context data as
well as a file version server to protect files that are
changed. The design log contains all context dependent
information that was active when each control decision
was made. When the designer wishes to backtrack through
the control sequence, the design log is used to restore con-
text information.
4.2. The CAD Tool Object (CTO)
At the heart of our new view of an open control mech-
anism for a CAD design framework is the CTO. The CTO
has six basic parts as summarized in Table I . We discuss
each of these parts in more detail in the following.
4.2.1. The Frame Body: The frame body, which char-
acterizes the most discernible attributes of a CAD tool, is
structured as an attribute pair, termed a slot, and a value.
The semantics of the slot are determined by the CAD tool
hierarchy and the values are determined by the type of
tool the tool object describes. A typical frame body con-
sists of the following.
I ) Information necessary to invoke the tool, such as
the host machine the tool resides on, the path name, and
usage caveats.
2) Information that describes the tools abilities, in rel-
ative terms, that is used to judge the tool in comparison
to other tools.
3) Information that describes the tool to a designer as
well as the location of on-line help and example files.
4) Information about the type of data the tool requires.
The frame body represents generally declarative infor-
mation about the tool. The slot values contained in the
frame body are used by utilities to correctly control the
tool in the design process. A short example of a frame
body is shown in Fig. 2. This is a partial view of the
frame body of the VLSI process simulation tool FABRIC-
SII. Note that much of the information concerns how the
tool is to be invoked and how to compute its arguments
in context.
user-name: FabricsII
system-name : fabrics
host: maxwell
path: /usr/eecad/bin
ram-path: /usr/eecad/man
input-type: process
output-type: spin
user-interface-type: tty
arg-type: standard
interactive: no
computing-effort: 90
priority: 10
arg-list: (a list of argument bodies)
Fig. 2. Partial view of the FABRICS11 frame body.
TABLE I
THE PARTS OF THE CTO
Declarative information about the tool
How the tool is controlled (i.e., what it can
Models of each command line argument that is
Hidden computer resources the tool requires
Runtime pointers to files the tool either reads
Models of how handle different errors
Frame Body
Control Body
Argument Body
Exrernal Dependencies
File Bodies
volunteer to do)
used to invoke the tool
or creates
Error Handlers
encountered in using the tool
The HOST, PATH, and SYSTEM-NAME slots are
used to determine where the CAD tool binary resides
while the ARG-TYPE, ARG-COMPRESSION, and
ARG-LIST, and USER-INTERFACE-TYPE are used to
determine how to invoke the tool. The ARG-TYPE is used
to determine if the tool receives arguments on the UNIX
command line or if the tool has piped input/output or a
mixture of both. The USER-INTERFACE-TYPE allows
the framework to determine if a special window (or win-
dows) are needed to be created for the tools user inter-
face. In cases where a tool is interactive, the INTER-
ACTIVE slot informs the framework that the tool may
override the user interface and use its own interface. Slots
such as COMPUTING-EFFORT and PRIORITY are used
to rank the tools abilities as selection criteria. Slots such
as these are important in that they rate the tools past and
anticipated performance in the design process. Finally,
the ARG-LIST slot contains a description of how to model
each of the CAD tools arguments. The ARG-LIST con-
tains a list of argument bodies, of which one is shown in
Fig. 3. Each argument body has information on whether
it is a switch, if the argument is flagged, where it goes on
the argument line (PRECEDENCE), and how to compute
the value (CONSTRUCTOR). The CONSTRUCTOR is
list of functions which are called to determine the value
of an argument. It is through the CONSTRUCTOR that
the CTO accesses values in the design space.
702 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. I O, NO. 6, JUNE 1991
class: input
name: "fabrics input file"
value: "half -micron.process"
default: "nmos. dat .process"
saitchp: no
precedence: 1
constructor: (select-by-design-type "process")
Fig. 3. Partial view of the FABRICS11 input argument body
Using this CTO, the designer may run the tool by caus-
ing a post to be placed on the VLSI backboard that re-
quests the tool to be invoked. The FABRICS11 CTO then
interprets the request and begins to determine its argu-
ments. If an argument cannot be determined (such as the
input file illustrated in Fig. 3) then the designer is quer-
ied. Throughout the session, the designer can request help
on the individual slots. I f, in the course of determining
input files, the designer requests help, the framework at-
tempts to construct an example file from which to work.
Determining the correct values for a CTO's frame body
is handled in several ways including:
allowing the framework to use default values as de-
termined by the CAD tool hierarchy;
using values from similar, existing tools (i.e., pro-
gram by example);
using on-line help facilities to determine the individ-
ual slot semantics and determine an appropriate value.
Of special use are slots that are used to rate a tool's
abilities in relative terms to other tools already in the
framework. In these cases, care must be taken to ensure
that the standards adhered to by other tools are followed.
Erroneous or imprecise descriptions of the tool's abilities
will lead to the tool being used (or not used) i n the wrong
part of the design process.
Cadweld attempts to make frame body creation as pain-
less as possible by providing high level utilities to create,
copy, and edit the tool objects. As the size of the design
framework increases, frame body creation becomes easier
as a large number of examples become available to draw
upon.
4.2.2. The Control Body: The control body consists
of a set of activation patterns to which the tool (or task)
object can respond. It is through the control body that the
CTO is activated in response to posts on the blackboard
from the designer and other tools. In effect, it allows a
tool to volunteer for a proposed design step. The control
body ultimately is the mechanism through which the tool's
abilities are first brought to the attention of either the de-
signer while the information in the frame body is used to
decide if and how the tool is to be used.
The information contained in the control body is a do-
main dependent representation of the CAD tool's (or
task's) role in the design process. It describes how the
tool object is to be used in the type of design to be un-
dertaken using the design framework. The control body
does not guarantee that the tool or task can complete the
design step it may bid for, but does indicate that it is gen-
erally capable of handling a design step. Final determi-
nation of a tool's relative abilities or appropriateness is
handled through tool queries by both the designer and task
objects. For example, the appropriateness of an interac-
tive tool that cannot use the current grdphics display is
negated by its inability to use the current hardware. In this
situation, it is advisable to have the tool "bid" on black-
board posts that are generally within its design capabili-
ties. The choice of not using the tool will be left to the
designer or task that initiated the post. This allows the
designer or task to pursue an alternate computer platform
that has the necessary hardware support.
Since the control body is used only to act as pattern for
which the tool object may volunteer, the control language
need not be overly expressive. It must only grossly cate-
gorize the role a CAD tool can play in the design process
and it is left to the designer (or task) to then interrogate
the tools or tasks which respond to a post. Recall that
CTO's do not initiate posts but only respond to them.
Communication between CTO's !is only accomplished
through task or designer interactioh with the blackboard.
The creation of the control body is an interactive pro-
cess that usually involves the use of the design method-
ology planner to help envision how the tool will interact
and compete with existing tools in the framework. If we
wish to add a new tool to the framework, we must deter-
mine the role it will play in the overall design process.
We must then examine the existing tool and task objects
to determine how this design role may be expressed in the
context of the control bodies of the existing tools. Since
this process may involve a great deal of time if attempted
manually, we use the planner to summarize the existing
control bodies and use this information to guide the con-
struction of a new control body. Over time, the aggregate
of the control bodies becomes the control language and
grammar used to express control directives in the design
framework. It should be noted that this process is inher-
ently evolutionary and allows the design framework to
adapt to different design cycles without modification of
the control mechanism or existing control bodies.
4. 2. 3. Argument Bodies: The argument body is a one-
to-one mapping between the command line arguments
used to invoke a tool and a model to represent what these
arguments do for the CAD tool. Argument bodies are ob-
jects and are derived from a relatively small hierarchy.
The arguments are broken down into two general classes,
those that are normally determined only once for a tool,
referred to as static arguments, and those that may change
from one tool invocation to another, referred to as dy-
namic arguments. Static arguments fall into five sub-
classes.
1) Operating system dependencies that may restrict
how the tool is run.
2) Technology files that assign design specific tech-
nology constraints.
3) Internal limits that the tool may have (such as length
DANIELL AND DIRECTOR: APPROACH TO CAD TOOL CONTROL 703
of a field name or how many iterations the tool may cycle
through).
4) Control flow switches that change internal control
flow within the tools procedures.
5 ) Optimization switches that are used to set internal
grading criterion.
These arguments tend to have set and forget values
that do not change often when the tool is invoked. Dy-
namic arguments, on the other hand, are usually re-eval-
uated each time the tool is invoked. In general, the dy-
namic arguments all point to different files that the tool
will either read or write while running. Note that the Val-
ues of the argument bodies for files (i.e., the file name)
is always determined by the version server (described in
the previous section) so as to avoid damage to the design
database.
4.2.4. External Dependencies: One of the more ex-
asperating problems in learning and using new CAD tools
is understanding the side effects of using a tool. For ex-
ample, tools often create hidden files, depend on un-
known files or directories, and, in the case of UNIX shells,
may require shell variables. When a tool depends on such
hidden information, we say it has an external dependency.
External dependencies must be modeled so as to control
and track the effects of using a particular tool. The need
for these mechanisms becomes particularly important as
tools become less frequently used. In these cases, even
the expert tool user may forget about a hidden side effect
of invoking a tool. By capturing these dependencies up-
front, we maintain a more complete and permanent record
of how the tool operates and avoid possible unforeseen
errors. Within Cadweld, four classes of external depen-
dencies are currently recognized.
File Dependencies-Often a tool will either auto-
matically search for an input file or will automatically cre-
ate an output file. From a versioning and maintenance
standpoint, these files must be tracked.
Directory Dependencies-Tools often search for files
in a particular directory or create output in a target direc-
tory. As in the case of files, we must track this behavior
as well.
Shell Variable Dependencies-As the popularity of
UNIX increases, so too has the use of UNIX shell vari-
ables as a means for passing information to a tool. Cad-
weld allows a tool object to check to see if a shell variable
is bound, if the value is the anticipated one, and, if nec-
essary, to temporarily change the value of a shell vari-
able.
Usage Caveats-Many tools require simple usage
caveats such as banner messages that inform the designer
of a potential problem or source of help should a problem
arise. The usage caveat is a declarative body of generally
useful information that is supplied to the user the first time
the tool is used in the current design session.
4.2.5. File Bodies: File bodies are used to model all
files a CAD tool will either read or create. It is used to
keep track of copies of a file, record creation and modi-
fication date, and to maintain information about how the
file is currently being used. It is through the file bodies
that the design framework can keep track of how the
CTOs are accessing the design space. A file body in-
cludes the following information:
name-the full pathname of the file;
description-a short description of why this file is
being accessed;
type-indicates if the file is a symbolic pointer or a
socket;
access-indicates how the file is to be accessed (i.e.,
READ, WRITE, or IO which implies both);
original-indicates this is a copy of another file and
keeps track of the name of the original that was used to
create this file;
owner-the owner of the file (i.e., a CTO or the de-
signer) ;
created-the date and time of when the file was cre-
ated;
modiJied-the date and time of when the file was last
modified;
archive name-the name of this file if it is archived
into a permanent archival director;
permanent-a Boolean flag to determine whether this
file should be kept in the design framework archive or
whether to flush it from the design space when the design
session is complete. The default is TRUE.
4. 2. 6. Error Handlers: In order to allow the CTOs to
handle error reporting and response in a consistent man-
ner, a set of standard error handlers have been provided.
These include the following.
Nonzero exit status; within the UNIX domain, it is
standard protocol to return a zero if the program com-
pletes successfully and a program dependent nonzero
value if an error occurs.
Process status; if the CAD tool process becomes
blocked, destroyed, or requires excessive computational
resources (i.e., an infinite loop or request for more mem-
ory that cannot be satisfied), an error handler can be in-
voked.
Error output; programs may output error messages
either in their normal output or in a special error log. If
these messages are discovered, an error is flagged.
In order to use one of these handlers, the framework
administrator specifies the type of handler to be attached
and the function to be invoked if the type of error is en-
countered. The error handler then becomes the conduit
through which the error is reported as well as responded
to. One of the advantages of this approach is that generic
error handlers may be used as well as tool specific error
handlers. Error reporting happens in two ways: through a
reporting mechanism field in each error handler or through
warnings and breaks generated by Cadweld when no error
handler is present. For example, suppose we wish to print
out a warning when a particular CAD tool exits with a
value of - 1, this indicates that the tool failed to find the
input file passed to it in the command line. We attach a
nonzero exit handler with a value set to - 1 and an error
704 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. IO, NO. 6, JUNE 1991
handler such as:
e r r o r - c l a s s : n o n z e r o - e x i t
d e s c r i p t i o n : " S i g n a l s a F i l e Not f
F ound. Warni ngl r -
exi t - number : -1
e r r o r - f u n c t i o n : ( o u t p u t " F i Le Not
F ound" 1
r epor ti ng- mec hani s m: warn.
4.3. Coupling the Blackboard with CTO's
We have described a new abstract type (CTO) that must
be created in order for existing CAD tools to interact with
the blackboard. Furthermore, using a volunteer mecha-
nism results in a blackboard model that is more general
and less capable of being used to automatically invoke
Fig. 4. The general blackboard architecture.
CAD tools. This places the added burden on the CTO to
be responsible for modeling how the tool is invoked and
correctly representing its abilities to the rest of the design
framework. In order to make the CTO sufficiently ex-
pressive, it should be based on a strongly typed, object
oriented approach. The tools must be treated as objects in
their own right, capable of being modeled and manipu-
lated. To achieve this, we employ a CAD Object Man-
ager, or simply referred to as the Manager. The Manager
is a group of utilities that Cadweld uses to create, manip-
ulate, and maintain the CAD objects in the framework.
The CTO is a declarative record of the CAD tool it
represents and the Manager makes use of the information
contained in the CTO to correctly represent the CAD
tool's ability and status to the rest of the design frame-
work. It is the Manager that functionally bridges the gap
between very high level coarse grained control directives,
such as start or stop a tool, and the low level particulars
of running and tracking an actual computer program.
By adding the CAD Object Manager to the volunteer-
based blackboard, we have simplified interaction with the
design framework. No central scheduler is required and
posts to the blackboard do not result in immediate acti-
vation of blackboard agents (e.g., CAD tools). This ar-
rangement allows for the construction of another type of
object that initiates posts to the blackboard termed the
CAD Task. The CAD Task is roughly isomorphic to a
ULYSSES script but is superior in two ways. First, it can
rely on the CTO's and Manager to handle low level par-
ticulars of invoking a tool so that it need only use high
level directives (such as start, stop, etc.) and not be con-
cerned with low level details. Second, the CAD task does
not (and should not) contain explicit reference to partic-
ular CAD tools (i.e., invoke a certain tool) but, instead,
uses the volunteer mechanism to query the design frame-
work for the existence of tools and tasks that can perform
a particular design step. Thus CAD Tasks are inherently
opportunistic and flexible enough to allow tools and tasks
to be added or deleted from the framework.
V. THE CADWELD DESIGN FRAMEWORK
In order to investigate the characteristics and perfor-
mance of the control mechanism described in the previous
section, we have developed the Cadweld design frame-
work. In this section, we review the overall architecture
of this framework. Cadweld is implemented as a loose
collection of modules, as illustrated in Fig. 4, allowing
us to easily add or delete modules as new and improved
subsystems become available. In particular, user inter-
faces, interprocessor communication packages, and da-
tabases can be easily changed or replaced.
5. 1. The CAD Object Manager
The CAD Object Manager creates, manipulates, and
maintains CTO's and has been designed to support inter-
action with the underlying CAD tool representations by
both the designer and the CAD Framework administrator.
The major role of the Manager in Cadweld is as follows.
Object Creation-The Manager provides a high level
operation for object creation that includes the ability to
create objects from scratch as well as incrementally build
them from copies of other objects.
Object Maintenance-The Manager provides high
level utilities to store, edit, and inspect the CTO's. In
particular, these functions are as free of programming de-
tail as possible so as to minimize knowledge of underlying
representations.
Object Graphical Representation-The Manager
creates graphical views of the objects that are displayed
by the user interface. The Manager, not the user interface,
is responsible for assigning graphical properties to the ac-
tive graphical representation (such as color or bitmap) and
for interpreting all semantics associated with graphical
events reported by the user interface (such as selecting an
object's run button).
Designer / Object Interaction-The Manager pro-
vides a buffer between the tool's information require-
ments and the designer. This includes providing facilities
to generate information for the tool automatically (if pos-
sible) and allowing the tool object to interact with other
parts of the design framework.
Interaction Among Objects-The Manager provides
a conduit between cooperating objects such that the two
objects do not have explicit references to each other. This
type of dynamic interaction is essential in cases where we
wish to allow design processes to be independent of the
CAD tool suite. Such interaction implies that tool objects
DANIELL AND DIRECTOR: APPROACH TO CAD TOOL CONTROL 705
(by definition) cannot have explicit references to other ob-
jects. In such cases, we perform generic design steps that
are then mapped to specific tool objects and communica-
tion links are established. Such forms of communication
include:
1) sharing files via pointers (i.e., name passing);
2) sharing or sending of blackboard posts;
3) passing of constraints via the constraint space.
Overall, the Manager (in conjunction with the black-
board) attempts to match the perceived needs of the de-
signer with the abilities of the CAD tools resident (see the
subsection on the design methodology planner in the fol-
lowing). As was noted in Section 11, tools are invoked in
a two step process. This has resulted in two types of in-
formation that are used for control. The first is the control
body that is used to allow CTOs (described more fully in
the next section) to bid on blackboard posts. The second
is theframe body that is used to represent the CAD tools
ability and status. The Manager provides mechanisms to
operate on both forms of information so as to make con-
trol decisions. In the object oriented view, these mecha-
nisms are term methods which are specialized procedures
and functions that recognize the class of the arguments
passed. Within Cadweld, we generally refer to these
methods (which may be a function or a procedure) as util-
ities.
5.2. The User Interface
One of the desirable features of a design framework is
that it have a unified and consistent user interface. Un-
fortunately, most existing CAD tools either run in batch
mode or have their own unique user interface. Cadweld
does not attempt to override the user interface of inter-
active tools but provides an icon driven system from which
to control the tools. The Cadweld User Interface (Fig. 5 )
is a mouse driven window-based application with menus
for command selection and icons to represent CTOs,
CAD tasks, and utilities. The icons are active images in
that they employ pop-up buttons to define the operations
that are supported for that object.
To simplify the design of both the graphical icons as
well as the CTOs, the CAD Object Manager and the user
interface are run as separate UNIX processes as illustrated
in Fig. 6. This requires creating two way communication
where the user interface sends requests for information
and action to the Manager and the Manager constructs
views of the tools and data that the user interface can
then display. At present, the Cadweld user interface sup-
ports the following views.
I ) The Toolbox View-A view of the tools as a collec-
tion of icons that are grouped according to the way in
which the designer would use the tool in the design pro-
cess. This is visible in the upper left of Fig. 5 .
2) The Hierarchy View-A view of the various classes
of tools and how each tool fits into the CAD tool class
hierarchy. This view is particularly important for under-
standing the interrelationships of the objects within Cad-
weld.
3) The Control View-A view of the current control
flow (i.e., the tool invocation sequence). This is repre-
sented as a direct graph and is visible in the right of Fig.
5 .
4) The Data View-A view of the data flow through the
design session showing the files that have been created by
each tool as illustrated in the lower left of Fig. 5 .
The purpose of each view is to give the designer some
insight into how tools interact (via control or data views),
how tools are inter-related (via the hierarchy view), and
a simple way to view all tools, tasks, and utilities (the
toolbox view). The control and data views are particularly
useful during the design process. The control view allows
the designer to examine a graphical record of tool invo-
cations that have caused other tools to be activated. In
effect, a design control precedence graph is constructed
that allows the designer to see which tools are active,
which tools are cooperating with each other, and which
tools have completed their execution.
We believe that the user interface to a design frame-
work should be as domain independent as possible. This
is only possible if the underlying semantics of the graph-
ical representation the designer works with is handled by
the Manager and not the user interface application. It is
desirable to let the user interface be a graphical tool that
performs two functions: displays information provided to
it by the CAD Object Manager (or possibly the design
database) and posts on the blackboard semantic-free rep-
resentations of designer interaction with the user inter-
face. In effect, the user interface is concerned only with
the syntax of the graphical interaction. These semantic-
free representations (e.g., the designer has selected a data
file icon) are then left to the remainder of the framework
to interpret (e.g., use the selected file as input to a tool).
By constructing the user interface to operate in this man-
ner, we can avoid cases where the built-in functionality
of the user interface creates a closed, inflexible way of
dealing with the design framework.
5.3. Representing Design Data
The design data has been the central focal point of most
design environments and continues to be a major area of
interest in the construction of more general design frame-
works. While no framework would be complete without
a mechanism to efficiently handle the design data, at pre-
sent Cadweld does not require a full scale data represen-
tation scheme in order to test our CAD tool control mech-
anism. However, the need for a full design data subsystem
is apparent and does play a role in the operation of the
design framework. In particular, it is essential to be able
to determine if sufficient translation capabilities exist to
create the necessary input files for a tool. The worst-case
scenario requires the designer to learn the syntax or se-
mantics of an input file format even when the possibility
of automatic translation (or database extraction) exists.
As we noted in the review of the database approach, no
single design representation is sufficiently general to han-
dle all types of design data. Given this situation, numer-
ous standards have been created that address some aspect
706 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. 10. NO. 6, JUNE 1991
C.dwmld h Ma Ct h l e F m t d - RsluN 1.0
i Yr t anVi w5 0.t. 1
UYS derlgn-uptve
Fig. 5. The Cadweld user interface.
To Be Oisplaye-d
Fig. 6 . The managerher interface co-processes
of the data representation issue. This has resulted in a ple-
thora of data formats that were generally based on the pre-
vailing data representation scheme at the time the CAD
tool was designed. At present, we are forced to deal with
dozens of file types, incompatible semantics, and poorly
defined interfaces. This results in spotty coverage of de-
sign representations across different tools. For example,
two synthesis tools may share an input format but each
may have differing output formats. In cases where the two
output formats cannot be cross translated, we may be
forced to abandon one design representation in favor of
the other. Such events must be anticipated by the design
framework and brought to the attention of the designer.
We deal with the design representation at three levels.
The first is the database representation. It is at this level
that all forms of the design are realized. The second is the
design space which includes information about design al-
ternatives. This is a set of relations and constraints about
the different aspects of the design database. The third is
the version space wherein the relations between the tools
and the design data are maintained. It is at this level that
the data to tool interactions and constraints are main-
tained. We consider each of these levels individually.
5.3.1. CAD Data Management: The CAD database
refers to not only the central database facility but also to
all files and artifacts produced through the invocation of
the CAD tools. In fact, the CAD database may include
more than one database within its domain (e.g., OCT [ 111
or EDA tools [I O]). One of the larger problems for VLSI,
and system design in general, has been the numerous stan-
dards that have arose to meet the varying needs of the
CAD tools. This has resulted in multitude of CAD tools
and translators that use varying, and often imprecise,
communication schemes that are typified by the many file
types in a typical CAD design system. We believe that it
is impossible to adhere to a narrow or rigid data standard
given the current generation of CAD tools. However, it
is important that we ultimately use our experience gained
in the construction of design frameworks to propose future
standards that may support a wide range of CAD tools.
While Cadweld is not explicitly designed to work with
a single database, it does have the ability to verify data
completeness and correctness. This ability is achieved
through typing and modeling of the files the tools use and
create. To the extent that the tools adhere to a syntactic
and semantic standard within a file type, we can deter-
mine the state and validity of a design in progress. What
is not supported is the ability to a priori ensure data avail-
ability since we do not support a specific database. This
inability implies that we can use a database only if the
CAD tools themselves were designed to take advantage
of a database (as in the case of the OCT tools) or if trans-
lators exist that can map from some external representa-
tion to that of the database. The next best alternative is to
provide file transformation utilities (as in ULYSSES) that
can handle a general class of translations. In general, we
are forced to maintain our design data in numerous com-
puter files and to rely on versioning (described in the fol-
DANIELL AND DIRECTOR: APPROACH TO CAD TOOL CONTROL 707
TABLE I1
TYPES OF I NFORMATI ON IN THE DESIGN SPACE
Design Al teri i uri ves Information about the various design paths
pursued and which parts of the design
represent which tradeoffs
A list of the current design goals and their
relation to the design data.
The set of constraints imposed on any point
in the design space
Design Goals
Dcsi gt i Constraints
Information that describes the status of the
designer who is using the system.
lowing) and typing of files to maintain the integrity of the
design database.
5.3.2. The Design Space: The design space is meta-
level information that models the interdependencies and
alternatives within the design database. The design space,
as defined, was introduced by ULYSSES [3] and contin-
ues to be a useful concept for a design framework. The
design space (summarized in Table 11) contains a wide
variety of information that can be used by both the de-
signer and higher level tools (such as tasks or the planner,
described below).
A focal point of the ULYSSES formulation of the de-
sign space is the concept of the design point. The design
point is a single form or realization of the design in prog-
ress. The design space is populated with design points
that represent the parallel and competing design alterna-
tives that the designer has elected to pursue. Switching
between design points is used to focus the design frame-
work on the new design point. The concept of design
space exploration and enumeration is not unique to Cad-
weld but is a powerful mechanism that should be included
in a design framework.
5. 3. 3. The Version Server: A major requirement of a
design framework is that it track design dependencies and
automatically protect the design from irreversible
changes. Much of this is accomplished through design
versioning and the ability to restore a design to a previous
state. To achieve this, Cadweld makes extensive use of a
version server to provide a layer between the tools and the
design data. Since Cadweld does not have a central da-
tabase, tools are free to create and manipulate files that
represent the design. In order to track and protect the de-
sign data, Cadweld requires the CAD Object Manager to
explicitly make requests for file access so that the version
server may be allowed to either create, rename, or delete
files without interference from the tools. It is crucial that
all design data a CAD tool will touch be modeled in the
CAD tool object and that the version server be allowed
full access to the design files in the design database. The
version server, therefore, tracks not only requests for file
access but also which tools requested access to the file so
that tool-to-file dependencies may be traced as well. Note
that this is functionally isomorphic to the EDA Design
Manager [lo] and is designed to handle calls not only to
the local file system, but also calls to remote file systems
as well (via the UNIX BSD 4.3 RFS service).
5.4. The Design Methodology Planner
One of the problems with building a design framework
that supports many tool and data formats, is that the de-
signer may become overwhelmed with a large number of
tools. In an effort to assist the designer with selection
among a preponderance of alternatives, a design meth-
odologyplanner (or planner) has been designed, but is not
yet completed, for Cadweld. When completed, the plan-
ner will assist the designer with the correct selection of
CAD tools as well as provide information as to the trade-
offs different CAD tools represent. Unlike other planners
[8], [13], the Cadweld planner focuses on the tools rather
than design specific decisions (such as design style). It
provides the designer with information about tool avail-
ability, tool capabilities, existence Of tool communication
problems, and a high level mechanism to match the de-
signers needs with the abilities of the tools.
The planner will operate in two modes: plan building
and plan execution. Plan building is the process of spec-
ifying what the designer is trying to achieve and the en-
capsulation of this information in a permanent design task.
Plan execution is the actual invocation of these design
steps by the planner for the designer. Each of these two
modes require the planner to provide the designer with
critical feedback as to the viability and progress of a plan
as it is built or executed. The need for this feedback di-
rectly results from the fact that the design framework al-
lows CAD tools to be added or deleted on the fly. Because
of these changes, existing plans (encoded in a task) may
begin design steps that the designer wishes to alter, per-
haps to take advantage of new tools. Since the selection
and execution of a tool within a planning context may be
complex, the designer requires the planner to make plan
building as simple as possible. Therefore, both plan
building and execution should make use of the planner to
help match the needs of the designer with the abilities of
the resident CAD tasks and CAD tools. It should be noted
that using the planner is not required and that general pur-
pose tasks are generally encoded to be tool independent.
5.5. Summary of the Cadweld Design Framework
We have outlined the major components of the Cad-
weld design framework. It differs significantly from de-
sign environments in that its components are loosely cou-
pled. The blackboard is used as the basic medium through
which the various modules interact and we have described
the function of these modules. Cadweld employs a stand-
alone user interface that runs as a separate process and is
domain independent. The framework uses the CAD Ob-
ject Manager to assign information for the user interface
to display and it interprets the designers actions as re-
ported by the user interface. The CAD Object Manager is
an integral part of this framework in that it provides pow-
erful utilities for use with CAD objects. Cadweld sup-
ports the concept of a CAD database as well as a design
space and version server that tracks the interaction be-
tween the CAD tools and the design data. The design
708 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. 10, NO. 6. J UNE 1991
methodology planner will assist the designer during inter-
action with the CAD Object Manager and a large number
of CTOs. What should be clear is that we have not de-
signed the framework to specifically address a class of
CAD problems. The control mechanism is open and is
based on a volunteer protocol. The designer asks for tools
to perform a task and is returned a list of possibilities.
This list of possible tools may then be sorted and a target
tool selected and activated. We contend that this approach
allows one to develop a design framework that is capable
of handling many more tools (i.e., more than 100) than
we previously considered possible in a design system.
VI. AN EXAMPLE SESSION
In order to demonstrate how Cadweld functions over-
all, we present an annotated example of a particular task
in operation. The highlights of this example are:
designer interaction with a high level task as well as
the planner and backtracking mechanism within the
CAD Object Manager;
task-to-task and task-to-tool interaction;
sorting and the use of error handlers to detect tool
Since the primary vehicle for interaction with the de-
signer is through the graphical user interface, we must
describe what the designer does textually. The format we
will use for this example is as follows:
D i r e c t o u t p u t f r om Cadwel d w i l l appear l i k e
t h i s
failures from the RUN facility.
while description of graphical events will appear like
this
and comments will appear like this.
The task we will illustrate, called the Lassie task, is
based on the LASSIE data-path synthesis tool [ 161and is
designed to automatically create a data path for a partially
specified design. The Lassie task should not be confused
with the LASSIE CAD tool that does significantly more
than this task. The Lassie task uses a design that consists
only of logical components and their required connections
and creates a VLSI chip with the appropriate interconnec-
tions completed. To achieve this, the Lassie task needs a
design specified in the DIF [ 5] language from which to
start. It then determines the structural binding between
logical components and actual physical realizations. Las-
sie then attempts a global place and route to determine
where the parts of the design should be placed in the final
chip. Once this is done, the actual wires are added to the
design specification and the chip is transformed into its
final representation (in this case, CI F). This design pro-
cess is illustrated in Fig. 7.
The following task example assumes that we have al-
ready created a logical design and that the design is in the
current design point. In this case, an ALL (allocated hard-
ware) description exists in for the digital filter i n the file
jilt. all.
[ u n i x l % c adwel d
One Dimensional
Blndlno Detall Routlng 1
L
Fig. 7. The Lassie task design process
The Cadweld system files are loaded.
> ( c adwel d)
I n i t i a l i z i n g t h e Cadwel d Des i gn F ramework
. . .
C hangi ng t h e c u r r e n t d i r e c t o r y t o / u s r /
d a n i e l l / wo r k i n g - d i r
VLS I B l ac kbo ar d C r eated and I n i t i a l i z e d
Us er I n t e r f a c e A c t i v a t e d .
At this point the user interface co-process is created.
Des i gn Space I n i t i a l i z e d .
Cad T o o l I n t e r f a c e A c t i v a t e d .
N e t l i n k s I n t e r f a c e A c t i v a t e d .
At this point the Cadweld netserver co-process is created.
I n i t i a l i z a t i o n C ompl ete.
E n t e r i n g Top L e ve l Command-Loop . . .
The designer activates the lassie icon and selects lassie
run button.
The user interface now reports to the Manager that the
designer has selected the RUN button on the Lassie
Task. This is reported as a post to the blackboard.
A c t i v a t i n g T o o l i n Res pons e t o P os t:
(RUNTOOL L AS S I E ) .
The Lassie icon changes to reverse video.
This actual change in graphical color is achieved by
the Manager explicitly sending the user interface process
a message to SELECT (i.e., change to reverse video)
the Lassie icon in all open views. From this point on, an
asterisk denotes output that comes directly from the Las-
sie task.
* S ear c hi ng f o r t a r g e t D I F d e s i g n i n d e s i g n
p o i n t .
Lassie searches the design point s constraint space f or a
design file that is of the type DIF.
* F a i l e d t o f i n d D I F de s i gn. L ooki ng f o r
* har dwar e d e s c r i p t i o n s .
o t h e r r e c o g n i z a b l e
* F ound a 1 l o c a t e d har dwar e f i l e
* S ear c hi ng f o r D I F t r a n s l a t i o n .
( f i l t . a l 1 ) .
DANIELL AND DIRECTOR: APPROACH TO CAD TOOL CONTROL 709
Now that Lassie has found a design description, it re-
mains to be seen i f t hef i l e can be successfully used. To
do this, Lassie places a post on the blackboard f or an
object that can help with this translation.
1 Too 1 has Responded, i t i s : "Sb i nd"
* B e gi nni ng S t r u c t u r a l B i n d i n g . . .
R U n n i n g S b i nd . . .
S bi nd c ompl ete.
S ear c hi ng T o o l s f o r P os t: (TRANSLATE
: S OUR C E ALL : T AR GE T DI F )
1 T o o l has Responded, i t i s : "Saw-
E x t r a c t o r .
Lassie has found a volunteer that claims it can build the
required DIF representation from the ALL (allocated
hardware) $le. Lassie now invokes the volunteer with a
constraint that it use the newfile Ifilt.al1). The volunteer,
Saw-Extractor, is another task and the output it generates
will be marked with a double asterisk.
R unni ng S A W- E X T R A C T OR . . .
** A t t e mpt i ng t o f i n d e x t r a c t i o n f i l e . . .
** e x t r a c t i o n f i l e f ound, s t a r t i n g
e x t r a c t i o n .
* S t r u c t u r a l B i n d i n g C ompl ete
* S howi ng T r a ns f o r ma t i o ns o c c ur r e d:
Lassie outputs a list of modules changed in thefilt design.
S ear c hi ng T o o l s f o r P os t: (PLACEMENT
GLOBAL)
6 T o o l s have Responded, t h e y a r e :
"A s a no ' I ,
" T i mberWo I f M C " ,
" T i mbe r Wo l f S C " ,
"T i mbe r W o 1 f S C - 4" ,
"PUPPY I
" V P N R "
* S o r t i n g t o o l s by:
Saw-Extractor creates a command >le that represents the * r o bus t ne s s
spec@c commands necessary to inform SAW to create a
DIF representation. The Saw-Extractor then determinis-
tically invokes SAW with the command file in the con-
straint space to be used for input to the SAW tool.
* di mens i o n = 1
* c e l l l i b r a r y =act o r mag o r d i f .
Lassie now must sort the tools, trying to obtain the most
robust tool that can handle one-dimensional placement
and use a compatible cell library.
R unni ng S ys tem A r c h i t e c t ' s Workbench . . .
**S ys t e m A r c h i t e c t ' s Workbench V1.3 **
**Wor kbenc h s t r u c t u r e s b u i l t i n v i r t u a l
memory **
Removi ng t h e f o l l o wi n g v o l u n t e e r s :
"T i mbe r Wo 1 f MC " ,
"T i mbe r W o 1 f S C - 4 " ,
I ' V P N R " .
Three of the volunteers were unable to either place in one
dimension or use the type of cell library described. At this
point, the volunteer list is, in order, (TIMBERWOLFSC,
ASANO, PUPPY). We now begin the process of invoking
the RUN facility to attempt a global placement.
F > h
E nt e r har dwar e f i l e name ==> f i l t - a l l
P a r s i ng har dwar e f i l e and b u i l d i n g
s t r u c t u r e s . . .
**Har dwar e s t r u c t u r e s b u i l t i n c o r e **
F > P O - d i f i 1t . o c t
........................................
F > mapf - f i f i I t
A> q u i t
Workbench) c r e a t e d a d i r e c t o r y ( f i 1 t . o c t )
whi c h i s n o t c u r r e n t l y p r o t e c t e d
Saw c ompl ete.
** e x t r a c t i o n c ompl ete, i n f i l e
f i l t - Da t a P a t h . d i f .
S aw- E xtr ac tor c ompl ete.
,), ... Warni ng: T o o l ( S ys tem A r c h i t e c t ' s
Both Saw-Extractor and Saw report back as successful so
Lassie now begins the second phase of determining what
parts of the logical design belong to which cells in the
cell library.
S ear c hi ng T ool s f o r P os t: ( B I N D S T R UC T UR E )
* B e gi nni ng P l acement . . .
R unni ng T i mberWol f S C . . .
C A V E A T E NC OUNT E R E D:
) ) , ... C hec ki ng f o r t r a n s l a t i o n
T i mberWol f S C i n d i c a t e s an e s t i ma t e d C P U
us age o f 2 hour s .
C o nt i nue ( Y o r N) ? N
T i mberWol f S C c o mpl et es u n s u c c e s s f u ~~y .
* P l acement t o o l appear s t o have f a i l e d .
* G e t t i n g n e x t v o l u n t e e r . . .
;;; C hec ki ng f o r t r a n s l a t i o n
R unni ng Asano . . .
;;; Warni ng: Asano E r r o r Handl er I nvoked.
Asano i n d i c a t e s a t r a c k c ount o f I O , i s t h i s
a c c e pt a bl e ?
( I f n o t , Asano e x i t s wi t h an e r r o r s t a t u s )
( Y o r N) N
Asano c o mpl et es u n s u c c e s s f u l l y .
710 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. 10, NO. 6. JUNE 1991
* P l acement t o o l appear s t o have f a i l e d . S t ep S i z e ? 1
* G e t t i n g n e x t v o l u n t e e r . . .
;;; C hec ki ng f o r t r a n s l a t i o n
S ear c hi ng f o r "S bi nd" o u t p u t t o "P uppy"
i n p u t t r a n s l a t o r
,,, ... Warni ng: A ut o mat i c T r a n s l a t i o n F a i l e d
* r e que s t f o r a ut o ma t i c t r a n s l a t i o n f a i l e d
S ear c hi ng T o o l s f o r P o s t : (TRANSLATE
:SOURCE D I F :TARGET OCT)
1 T o o l has Res ponded, i t i s : "DI F - to- OCT"
R unni ng DI F - to- OCT . . .
DI F - to- OCT c ompl ete.
B e gi nni ng t o s ear c h De s i gn L og . . .
S tep: P l a nne r A c t i v a t e d
A c t i o n: ?
Thes e a r e a v a i l a b l e a c t i o n s f o r t h e
B ac kt r a c k e r :
f : f o r wa r d f r o mt h i s p o i n t
b: c o n t i n u e b a c k t r a c k i n g by s t e p s i z e
b <s tep>: b a c k t r a c k by s t e p v a l u e
<r e t >: c o n t i n u e b a c k t r a c k i n g
? o r h e 1 p : t h i s h e l p message
a: a b o r t b a c k t r a c k i n g
s : show f o r wa r d s t e ps pendi ng
The backtracking mechanism, as it currently exists, is
cumbersome. The designer will typically backtrack
through numerous design points by either varying the step
size to be backtracked or, in future work, may go back to
a specijic point using a graphical tool.
R unni ng P uppy . . .
;;; Warni ng: P uppy E r r o r Handl er I nvo ked.
** Unabl e t o F i n d S pecs . P uppy w i 1 1 e x i t
u n s u c c e s s f u l l y .
P uppy c o mpl et es u n s u c c e s s f u l l y .
* P l acement t o o l appear s t o have f a i l e d .
* G e t t i n g n e x t v o l u n t e e r . . .
* N o more v o l u n t e e r s f ound.
* L a s s i e w i l l e x i t u n s u c c e s s f u l l y .
L a s s i e c o mpl et es u n s u c c e s s f u l l y .
The designer is now faced with a decision to either back-
track into the Lassie task or look f or another design tool.
In this case the designer calls the design methodology
planner in an attempt to find an alternative solution.
The designer selects the "activate" button on the
planner icon and the planner interface appears.
...
,,, P l a nne r I n i t i a l i z e d
A c t i o n : b
S tep: RUN LAS S I E
A c t i o n: b
S tep: DO-WHILE-VOLUNTEERS
A c t i o n: b
V o l unt e e r L i s t R e s t o r e d t o : (PUPPY)
S tep: IF-VOLUNTEER-OK
A c t i o n: b
S tep: ACTIVATE-VOLUNTEER
A c t i o n: b
S tep: I F-VQI UNTEERS
A c t i o n : b
S avi ng o l d v o l u n t e e r l i s t t o c hec k f o r
V o l unt e e r s .
V o l unt e e r L i s t R es t o r ed t o : (DI F - to- OCT)
S tep: ACTIVATE-VOLUNTEER
PLANNER ACTI VATED
I f you r e - a c t i v a t e t h e P l anner , o l d p l a n s
may be l o s t .
What i s yo ur p o s t ? s y n t h e s i z e d a t a p a t h A c t i o n : b
S ear c hi ng T o o l s f o r P o s t : (SYNTHESI ZE A c t i o n: b
DATAPATH)
S tep: PERFORM-AUTOMATIC-TRANSLATION
V o l unt e e r L i s t R es t o r ed t o : (ASANO PUPPY)
2 T o o l s have Res ponded, t h e y a r e :
"Magi c", S tep: ACTIVATE-VOLUNTEER
"L as s i e" A c t i o n: f
... ,,, ... C hec ki ng f o r t r a n s l a t i o n
,,, P l a nne r Has e x i t e d .
R unni ng Asano . . .
. . . ,,, Warni ng: Asano E r r o r Handl er I nvo ked.
Asano i n d i c a t e s a t r a c k c o unt o f I O , i s t h i s
a c c e pt a bl e ?
The designer now decides to attempt to backtrack into the
Lassie task and recover the design created by Asano. This
is done activating the Manager icon and selecting the
"backtrack" button.
B a c k t r a c k i n g commenci ng . . .
Do you want t o s e t t h e b a c k t r a c k i n g s t e p
s i z e ( Y o r N)? Y
( I f no t , Asano e x i t s wi t h an e r r o r s t a t u s )
( Y o r N ) Y
Asano c ompl ete.
DANIELL AND DIRECTOR: APPROACH TO CAD TOOL CONTROL
* G l o ba l P l acement C ompl ete
A c t i o n: s
711
TABLE 111
FI NAL SPECIFICATION OF THE FI LT CHIP
CREATED USING LASSI E
The f o l l o wi n g a r e t h e pendi ng f o r wa r d
s teps :
F I N I S H T A S K
A C T I V A T E PLANNER
A c t i o n: f
* S howi ng Modul es , C l as s es , and A t t r i b u t e s
Lassie outputs a long list of information concerning the
results of the global placement.
* B egi nni ng L ayout G e ne r a t i o n . . .
S ear c hi ng T o o l s f o r P o s t : (ROUTE)
1 T ool has Responded, i t i s : tf L ayout' t
R unni ng L ayout . . .
Specification Value
Cells 870
Nets 614
Pins 1396
Transistors 6525 (estimated)
TABLE IV
LIBRARIES CADWELD USES
Basic Library Language Application
~~
PCL Lisp CAD Object Manager
Xtobj C Cadweld User Interface
Mx C Cadweld Object Editor
NETLinks C Cadweld Netserver
VII. CADWELD IMPLEMENTATION
p a r s i n g a l o ng . . .
get- tabl e- s i z e r e a d f r om f i l e :
aux . d i f . f i l t
p a r s i n g c ompl eted'
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
number o f e r r o r de t e c t e d: 0, p a r s i n g
c ompl eted.
D I F d a t a bas e i s r eady f o r a c c e s s i ng
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The current implementation of Cadweld makes use of
several extensive programming libraries as summarized in
Table I V. Early in the design of Cadweld, we decided to
partition the implementation into separate modules. As we
are using a multiple process architecture, we were free to
implement each module in any desired language. This al-
lowed us to develop the graphical, window-based appli-
cations and an interprocessor communication layer on top
of these existing libraries. The primary implementation
The LAYOUToutputs a long list of diagnostic information
here.
L ayout c ompl ete.
* L ayout G e ne r a t i o n C ompl ete
* F i n a l de s i gn i n f i l t . c i f
L a s s i e c ompl ete.
A c t i o n: s
The f o l l o wi n g a r e t h e pendi ng f o r wa r d
s teps :
A c t i o n: a
A C T I V A T E PLANNER
B a c kt r a c ke r e x i t e d . Res umi ng a t c u r r e n t
p o i n t .
At this point, the final representation is of the FILT
design found in the file jilt. cif and the overall character-
istics are summarized in Table 111. The designer may now
wish to examine the finished design (via a layout editor
such as MAGIC) or plot the results on paper using a plot-
ting program such as CPLOT.
This example session has given a brief overview of how
the designer interacts with Cadweld. It should be noted
that while this example highlights many of the features
found in Cadweld, the inherently graphical nature of the
framework is difficult to capture in a simple trace such as
this.
language of Cadweld is Lucid Common LISP [14] with
Xerox Portable Common Loops [2] (PCL) included. The
choice of an interpreted language rather than a compiled
language (such as C) was motivated by the requirement
that the design framework be inherently open ended. By
using LISP, we were able to rapidly develop and explore
the different aspects of Cadweld. The use of PCL, a pub-
lic domain object oriented programming environment for
LISP, gave us a class system and inheritance mechanism
to represent the CAD Tool Hierarchy and CAD objects
within Cadweld.
Xtobj [ 171 is a graphics library that allows for arbitrary
combination of active icons, groupings of icons, and
graphs of icons. One feature of the Xtobj library is that it
allows the assignment of graphical properties (such as
color, labels, location on the screen, etc.) to be handled
dynamically. This allows the user interface to display in-
formation that is created dynamically by the Manager.
Mx [6] is another graphics library that primarily han-
dles textual information in several formats that include:
lists, forms, menus, and editable fields. The Cadweld Ob-
ject Editor has its own user interface application that was
constructed using Mx. This allows the designer or frame-
work administrator to view and edit the CTO's in a more
pleasing graphical format that does not require the under-
standing of the lower level representational format.
NETLinks [ 181 is a packet switching communication
package that allows Cadweld to communicate between a
wide variety of different computers and UNIX operating
systems. The Cadweld Netserver is an application, writ-
712 IEEE TRANSACTIONS ON COMPUTER-AIDED DESIGN, VOL. IO, NO. 6, JUNE 1991
7.18%
17.63%
Fig. 8. Overall Cadweld system breakdown.
MI=
DBCIamtIw
Admlnlatratlve
J
UI suppotl
Object Manager
0 1000 2000 3000 4000
Fig. 9. Lines of Lisp and PCL code.
ten in C, that is a layer on top of NETLinks to support
the concepts of RUN, STOP, SUSPEND, RESUME, or
AWAIT as applied to a remote job.
The usefulness of Cadweld is due, in large part, to the
overall expressiveness and generality of its graphical pre-
sentation and interprocessor communication. We were
able to save a great deal of time and energy by using ex-
isting software libraries.
The bulk of the implementation is written in LISP and
PCL. The overall distribution of code is shown in Fig. 8
and actual statistics are shown in Fig. 9. The CAD Object
Manager includes the lisp code for the argument modeler,
version server, and lower level object manipulation. The
code labeled U1 Support includes all utilities necessary
to create graphical information for the user interface to
display as well as utilities to interpret information that is
generated by the user interface. The administrative code
handles the overall software organization of Cadweld such
as file interdependencies, global variables, and commu-
nication protocols between the various modules in the
framework. The declarative code consists of definitions
for the CAD Tool Hierarchy, other internal classes to
Cadweld, and the bidirectional functions.
VIII. CONCLUSIONS
When we began to build Cadweld, we were faced with
several challenging problems. Among these problems, we
focused on the requirement that the framework have an
open and flexible control mechanism. We knew, from our
experience gained with ULYSSES, that a design frame-
work designed to use existing CAD tools faces many dif-
ferent and, often contradictory, control and data represen-
tational needs. Given an abundance of tools, data formats,
evidence that the control problem (i.e., selecting the best
tool or task at any given point in the design process) is
extremely onerous and not generally solvable through the
use of a centralized scheduler. By focusing on the control
problem and less on the data representation problems, we
discovered that much of the control problem can be sep-
arated from the data requirements of the framework.
From ULYSSES, we adopted the use of a blackboard
mechanism as a means of centrally gathering the control
information. Unlike ULYSSES, we extended the black-
board to include a completely decentralized architecture
and decentralized activation mechanism. While the black-
board allowed a group of blackboard agents to exchange
information and control directives, we did not want to use
a centralized scheduler but, instead, required the CTOs
and CAD tasks to be self-contained, modular, and easily
controlled. This approach allowed the designer and tasks
to use the blackboard as a means of finding potential tools
(or tasks) and then to rely on the tools (or tasks) to have
sufficient self-knowledge to be controllable from a very
high level. In order to provide this type of self-knowl-
edge, we employed object oriented programming tech-
niques. In effect, we had to create an abstract type that
represented the CAD tool, CAD task, and a set of spe-
cialized utilities to manage these abstract types. As a re-
sult, more than one half of the Cadweld design frame-
works underlying code is either declarative information
about tools as an abstract type or specialized utilities
within the CAD Object Manager.
We can summarize the contributions of this research to
include the following points:
1) a new view of control based on the volunteer pro-
tocol coupled with the blackboard;
2) the ability to organize and control many more tools
than before;
3) a separation of generic software control issues from
domain specific control issues. The designer and the
tasks do not need to be concerned with the lower
level programming details associated with using a
CAD tool;
4) a general view of design that is not constrained to a
limited part of the design cycle. Since the volunteer
mechanism contains no implicit assumptions as to
the semantics of the contents, it should be useful for
most types of routine design that employ a large
number of CAD tools;
5) the ability to assist the novice designer in learning
to use CAD tools as well as more sophisticated de-
signers in learning to master new tools;
6) an inherently modular and opportunistic framework
architecture. We have made the chore of maintain-
ing the framework much easier. The framework ad-
ministrator can add or delete CTOs and tasks with
minimal regard for the impact of these actions.
and hardware requirements, we were forced to examine
only the most general approaches to bringing the tools
into a single framework. ULYSSES also provided us with
The above list indicates that we have added to the body
of knowledge concerning design frameworks and their
construction. However, it does not indicate how the de-
DANIELL AND DIRECTOR: APPROACH TO CAD TOOL CONTROL 713
signer is better off than before Cadweld could be used.
We should begin by stating that Cadweld is but a part of
a larger whole. We eventually wish to allow the designer
more powerful ways to create and manipulate the design
data, better tools to support the design cycle, and more
efficient ways to explore the design space. In the interim,
Cadweld provides many features that are crucial in the
creation of a design framework, which may be summa-
rized as follows.
The designer may draw from a large population of
existing CAD tools as represented by Cadweld.
The CAD tools may be invoked across a distributing
computing environment transparently.
The tools are represented at a conceptually high level
allowing the framework to be more easily main-
tained. In particular, adding or deleting tools is much
more straightforward.
Each CTO describes the tool it represents such that
the designer can determine the existence and use of
tool by querying the CTO for information.
The control flow is inherently open, incremental, and
accessible. The designer has much more feedback as
to how the framework is operating and what options
are available.
CAD tasks allow the design process to be partially
automated in such a way that the designer may in-
tempt the flow, redirect the control sequence, and
backtrack to a previous design point.
While Cadweld is not a general design framework, it
has allowed us to develop and test a new approach to CAD
tool control. We believe that this approach, based on the
object oriented programming scheme, will be the basis for
a new and more powerful generation of design frame-
works.
REFERENCES
[ 11 EDIF Specification: EDI F electronic design interchange format,
Version 2.0.0, Tech. Rep., Electronic Industries Association, 1987.
[2] D. Bobrow, L. DeMichiel, R. Gabriel, S. Keene, G. Kiczales, and
D. Moon, Common Lisp object system specification, X3j 13
Working Paper, Xerox Corp., 1988.
[3] M. Bushnell, ULYSSES-An expert-system based VLSI design en-
vironment, Ph.D. dissertation, Elect. Comput. Eng. Carnegie Mel-
Ion Univ., Dep., 1986.
[4] M. Bushnell and S. W. Director, ULYSSES-A knowledge based
VLSI design environment, Int. J . AIEng. , vol. 2, no. 1, J an. 1987.
[5] M. Bushnell, D. Geiger, J . Kim, D. LaPotin, S. Nassif, J. Nestor,
J. Rajan, A. Strojwas, and H. Walker, DI F: The CMU-DA inter-
mediate form, Res. Rep. no. cmucad-83-11, SRC-CMU Center for
Computer-Aided Design, J uly 1983.
T. Cobourn, Mx Users Manual, Tech. Rep., SRC-CMU Re-
search Center for CAD, 1989.
K. S. Decker, Distributed problem solving techniques: A survey,
IEEE Trans. Syst. Cyber. Man, vol. SMC-17, SeptJ Oct. 1987.
A. Dewey, A knowledge-based approach to VLSI system plan-
ning, Ph.D. dissertation, SRC-CMU Center for Computer-Aided
Design, Dep. Elect. Comput. Eng., Camegie Mellon Univ., Apr.
1987.
A. Dewey and A. Gadient, VHDL motivation, IEEE Design Test
Comput., vol. 3 , Apr. 1986.
K. Goldman and T. Stout, A design automation environment, VLSI
Syst. Design, J une 1988.
D. Harrison, P. Moore, R. Spickelmier, and A. Newton, Data man-
agement and graphics editing in the Berkeley design environment,
in Proc. ICCAD-86, Apr. 1986.
F. Hayes-Roth, D. J . Mostow, and M. S. Fox, Understanding Speech
in the HEARSAY-I1 System.
D. Knapp, A planning model of the design process, Ph.D. disser-
tation, Univ. Southern California, Dec. 1986.
Lucid common Lisp users guide for the Vax, Users Man., Lucid,
Inc., 1986.
R. G. Smith, The contract net protocol: High level communication
and control in a distributed problem solver, IEEE Trans. Comput.,
vol. C-29, Dec. 1980.
M. Trick and S. W. Director, LASSIE: Structure to layout for be-
havioral synthesis tools, in Proc. 26th DAC, 1989.
N. Vidovic, D. Siewiorek, D. Vrsalovic, and 2. Segall, Towards a
consistant view of the design tools and process in distributed problem
solving environments, in Proc. 22nd Hawaii Int. Con$ on System
Sciences, J an. 1989.
D. Vrsalovic, 2. 2. Segall, and D. P. Siewiorek, NETLinks: In-
terprocess(or) communication infrastructure for distributed environ-
ments, Working Paper, Dep. Comput. Sci., Camegie Mellon Univ.,
Nov. 1987
Carl Hansen Verlag, 1978.
James Daniell (M90) received the B.S.E. and
M.S.C.S. degrees concurrently from the Univer-
sity of Connecticut in Dec. 1985 and the Ph.D.
degree in electrical and computer engineering from
Camegie Mellon University in 1989.
From 1989 to 1991, he worked Software AG, a
German software vendor, designing large scale,
heterogenous business applications. Currently, he
is the Head of the Market Strategies Department,
AT&T Unix Systems Laboratory, Summit, NJ . He
also teaches at American University as an Adjunct
Professor of Computer Science. His current interests are in the area of
CAD, distributed problem solving, and large scale network applications.
Dr. Daniell is a member of Tau Beta Pi, Phi Kappa Phi, ACM, and
AAAI.
Stephen W. Director (S65-M75-F78) for a photograph and biography,
please see page 183 of the February 1991 issue of this TRANSACTI ONS