batabase

JUNE 1982
VOL.5
NO.2
quarterly
a
bulletin
of the IEEE
computer society
technical
committee
batabase
Engineering
Contents
Engine~ring
Data
Management
Project
within the IPAD
Activities
2
HR. Johnson and D.L. Berr,hardt
Using
Retational Database
a
Circuit
System
for
10
Design
A. Haskin and R. Lone
Performance of Database
in VLSI
Systems
A. Beetem, J.
Management
15
Design
Milton, and G. Wiederhold
Using a Relational Database Management
System for Computer Aided Design Data
21
A. Guttman and M. Stonebraker
DAVID:
Design
integrated
R.H. Katz
Aids to VLSI
Databases
using
29
Associate Editors,
Chairperson, Technical Committee
on
Database
Database
Engineering
Engineering
Batory
Prof. Jane Liu
Prof. Don
Digital Computer Laboratory
University of Illinois
Dept.
Urbana, III. 61801
University
(217) 333-0135
Gainesville, Florida 32611
of
Computer
and
Information Sciences
of Florida
(904) 392-5241
Prof. Alan Hevner
College of Business and Management
University of Maryland
College Park, Maryland 20742
Editor-in-Chief,
Database
(301)
454-6258
Engineering
Dr. Won Kim
Dr. David Reiner
IBM Research
Sperry
K55-282
100 North Road
5600 Cottle Road
Sudbury,
San Jose, Calif. 95193
Research Center
Mass. 01776
(617) 369-4000 x353
(408) 256-1507
Randy Katz
Dept. of Computer Science
University of Wisconsin
Prof.
Madison, Wisconsin 53706
(608)
262-0664
in contributions
Database
Opinions expressed
of the IEEE
vidual author rather than the official
Engineering Bulletin is a quarterly publication
Computer Society Technical Committee on
Database Engineering. Its scope of interest includes: data
structures and models, access strategies, access control
techniques, database architecture, database machines,
intelligent front ends, mass storage for very large data
bases, distributed database systems and techniques,
database software design and implementation, database
utilities, database security and related areas.
Contribution to the Bulletin is hereby solicited. News
items, letters, technical papers, book reviews, meeting
previews, summaries,
case
studies, etc., should be sent
to the Editor. All letters to the Editor will be considered for
publication unless accompanied by
trary. Technical papers
are
a
request
unrefereed.
to the
con
are
those of the indi
position of the TC on
Computer Society, or
Database Engineering, the IEEE
organizations with which the author
Membership
may be affiliated.
Engineering Technical Commit
Computer Society members, student
in Database
tee is open to IEEE
members, and associate members. (Application form in
this
issue.)
from
Letter
This
the
tional
to
the
of
issue
is
Newsletter
Engineering
how
Data
database
design
Database
Editor
Guest
environment. We
in Academia and
have
of
reports
to
current
research
Industry: Boeing
Computer
groups
Research at San Jose, Stanford University, U.C.
I.B.M.
and the University of Wisconsin—Madison.
five
The
papers fall into
their
design
describe
requirements,
The
papers
design data
from
from
the
three
viewpoint
I.B.M.
and
The
categories.
and
environment
of
the
Wisconsin
group
data
its
CAD
come
systems
built
to
very
from
Services,
Berkeley,
from
Boeing
management
applications builder.
describe
The
by database
being
people.
from
Stanford
and
address
Berkeley,
papers,
whether conventional database systems can provide
formance
for
CAD
applications.
Interestingly
groups
devoted
Management, i.e.,
Design
apply tradi
the
to
new
applications area of
system techniques
of
topic
the
the
to
support
two
remaining
the question of
adequate
per
enough, the two
conclusions!
different
these
is
two
by
immediately struck
constructed
hierarchically
design
“complex
objects (e.g., “composite objects”,
objects”,
“ragged
relations”,
hierarchy”), and the pervasive need to keep
“design
“reasonable.”
costs
accessing
reading
In
themes:
common
All
of
these
are
just
into
database
them.
papers
beginning
system
data
research as
Design
database
reports,
for
support
to
are
one
snapshots
structures.
management
we
enter
the
of
We
works—in—progress.
how
and
problems
they map
of
We are far
from solving all
is beccming an important area of
understand
the
mid—1980s.
Yours
truly,
J~1
Randy H.
Madison,
1
in
Data
Engineering
Management
Activities
Within the
IPAD
Project
H. R. 3ohnson
D. L. Bernhardt
Boeing Computer Services
Seattle, Washington
ABSTRACT
In
this paper
summarize
we
the
research and
management systems by the IPAD project
1.0
the
at
development in engineering
Boeing Company.
data
base
Introduction
1976 NASA awarded the Boeing Company a contract to develop IPAD (Integrated
Programs for Aerospace-Vehicle Design). The specific goal of IPAD was to increase
productivity in the United States aerospace industry through the application of
computers to manage engineering data. The contract included a requirement for Boeing
to form an Industrial Technical Advisory Board (ITAB) to guide the development of IPAD
Members of ITAB represent major manufacturing (aerospace and other) and
i]
computer companies. NASA, Boeing, and ITAB have worked together since that time to
analyze engineering design methodologies; to establish requirements for integrated,
computer based systems for managing engineering data, and develop software to
Results have included development of the RIM and IPIP
demonstrate these concepts.
In
.
data
base
management
communication.
comprehensive
2.0
and
systems
network
a
facility
IPAD documentation and software is in the
discussion of IPAD
Requirements
for
objectives
Engineering
Data
and
for
public
intertask
mu1ti-~st
domain.
ee2] for
a
products.
Management
Early in the IPAD contract, the engineering design process was analyzed and a
This
requirements for engineering data management were identified.
The following briefly summarizes these requirements.
documented
number of
work was
n3 4].
,
Some of the more obvious requirements included:
scientific data types for both scatar and non-scalar
FORTRAN interface; support for
selection
elements in matricies; support for
a
(large matricies) attributes;
projection of data with respect to specific
defining and manipulating geometry data and interfacing
graphic display systems.
and
this with
design drafting
and
Multiple levels and styles of data description are required to provide for differing data
requirements and for data independence to support a variety of users in a dynamic
environment. Specifically, the network and relational data models are required.
‘This
work is funded under NASA contract NASI-14700.
2Correspondence
Boeing Company,
may be addressed to the IPAD Program Management
P. 0. Box 24346, Seattle, WA 98124, M/S 73-03
2
Office,
The
dividing a data base into logical partitions, each containing data
A logical partition, referred to in the following as a
an engineering task.
include
“data set”, may
tuples/records from one or more relations/record types. A
relation/record type may span data sets. Facilities must be provided to restrict access
Support
is
required
for
associated with
to data sets.
This meta-data may
user description of data sets.
include information such as sources, uses, time of creation, and the quality of data in the
data set. The data manager must support user access to this meta-data.
The data manager must also support
required to support the iterative nature of the design process.
provide for efficient access to versioned data sets while
manager
minimizing physical redundancy across versions. Comparative analysis of versions of a
data set should be supported, along with facilities for tracking the history of change to a
particular design.
Versioning
The
of data sets is
data
must
supported to release (approve or sign off) a data set and to insure
changed once released. New versions may be created and modified to
design changes.
A mechanism must be
that it cannot be
record
Long
term archival of
data sets must be
supported by the data manager. Archived data
Data describing archived data sets must be
sets must be available upon user demand.
available for online perusal.
The data manager must support interactive retrieval and
and ad hoc queries.
update
to
support interactive
design
The data manager must support distributed processing in a loosely coupled network of
heterogeneous machines so that data may be communicated between geographically
dispersed divisions of the same firm as well as firms which have received subcontracts
for portions of the design work. The data set is one natural unit of transfer within the
network.
A uniform interface to system facilities should be
of the system and communication with other
provided
to facilitate
learning
and
use
users.
To support the total CAD/CAM environment, the data manager must also provide
support to manufacturing in the traditional sense in terms of providing support for shop
scheduling,
accounting
material
requirements planning, inventory
control of finished
goods,
and the
function. It must also provide for the generation of machine tapes to aid in
the transfer of the design which exists in the data base to the tools which will machine
the parts of the
designed product.
See
5]
for
a
more
complete description
of
these
requirements.
Finally,
the
data
This should include
manager
must
triggering
on
provide capabilities
user
meta-data
so
to
support project management.
that the creation of data sets may be
scheduled and progress monitored by the system.
3.0
The RIM Data Base
Management System
The RIM (Relational Information Managment) data base management system was
developed on the IPAD project to explore relational data base concepts prior to the
development of IPIP. RIM has been enhanced by the University of Washington and The
3
Boeing Company
in
cooperation
with ITAB and the IPAD
Project.
A RIM data base may be accessed in read mode by multiple
base is restricted to single user, when it is opened for update.
RIM supports a single level of data definition.
Schema definition may be entered and modified
Rules
Relations
users.
are
Access to the data
organized
interactively through
a
into schemas.
menu
relationships within and between relations may be declared.
constraints, although the user may turn rule checking off and on.
data
on
used
as
RIM
provides several
scientific support
also supports a tolerance
approximation of equality.
It
types.
specified
interface.
can be
Rules
capabilities with its matrix, vector, and real data
capability which supports qualification by user-
algebra-level (including join) and calculus-level (excluding join) data
through an interactive interface, along with facilities for
manipulation
RIM supports the calculus-level data manipulation commands
retrieved
data.
formatting
RIM
offers both
commands
for FORTRAN programs via subroutine calls.
RIM
is
written
available
on
primarily
several hosts:
RIM have been
many of these
FORTRAN
supplied to
organizations.
The IPIP Data Base Management
4.0
The
66, but will compile in FORTRAN 77. It
CDC, UNIVAC, VAX, and PRIME. More than 130 copies
universities and corporations. RIM is used on a daily basis
in
IPIP
(IPAD
Information
time
over
manage engineering
IPIP supports multiple data models,
user access
which
may
through
interfaces in
a
distributed environment.
supported. Composite objects called structures,
multiple tuples from multiple relations, may be declared and
Scientific data types and arrays
of
base management system is intended to
CAD and CAM environments. To this end,
levels of schemas, and concurrent, multiple
data
multiple
through multiple application
consist
in
System
Processor)
data
is
of
are
manipulated as entities to manage geometry and other scientific data. Data may be
partitioned logically into data sets to support concurrent access, versioning, releasing,
a general description of IPIP.
and archival procedures. See
6]for
developed a general purpose network facility for intertask communication in a
IPAD network has been
The
hetergeneous distributed processing environment.
of
ISO
with
accordance
in
layered protocol. Access to IPIP
specifications
implemented
for
network.
See
a general description of the
this
data
via
is
and IPIP-managed
7]
written
network
the
are
IPIP
and
network facility.
primarily in Pascal.
IPAD has
1PJP is in
early stages
of release and
consequently
example, the latest version of IPIP supports
not versioning, releasing, or archival; and
some
is
in
an
evolutionary
state.
For
locking aspects of data sets, but
facilities for the declaration and
of the
initial
integration testing. Application interfaces are limited
to FORTAN programs. IPIP proper, its schema compilers, and CDC and DEC FORTRAN
precompilers execute on CDC CYBER series machines operating under the NOS
operating system. DEC VAX 11 FORTRAN programs against the CYBER-resident data
manipulation
of structures
are
in
base may be submitted via the IPAD network from a VAX 11/780 (operating under the
VMS operating system) and then executed on the VAX, DML commands being forwarded
to the CYBER for execution and results being returned via the network to the VAX.
4
Application
Currently,
4.1
programs
IPIP is
Compliance
submit
and
executing only
in
receive
a test
data
in
native
environment at the
machine
Boeing
representation.
IPAD site.
With Standards
objective of IPIP has been compatibility with specifications for data
manipulation languages which seem to be leading to a standard. It was
felt that this approach would take advantage of previous work and tested constructs,
would facilitate migration between standard compliant systems and IPIP, and should
facilitate incorporation of IPIP extensions into standards.
Given the work of CODASYL and ANSI committees and the relationships between these
committees, and given the engineering requirement for a FORTRAN interface, the IPIP
Logical Schema Language (LSL) was based upon a subset of the 1978 CODASYL DDL 8]
and the IPIP Data Manipulation Language (DML) was based on a subset of the 1978
Extensions and departures from these specifications
CODASYL FORTRAN DML 9]
Some of these are discussed in the following sections.
were made in some instances.
One
major
definition and
.
4.2
Integration
of User Interfaces and
Capabilities
Integration has been a major objective of IPIP: integration of user interfaces and
A single Logical Schema Language (LSL) and Data
integration of capabilities.
Manipulation Language (DML) supports both the relational and network data models and
applications, be they interactive or written in one of several programming languages.
The LSL is used at both the
conceptual and external levels of data definition
Internal Schema Language (ISL) resembles the LSL as nearly as possible.
features such as the structure-defined composite objects for geometry are
with other data mangement
.
The
Scientific
integrated
capabilities.
Most aspects of data definition and data
data
ioJ
manipulation
are
invariant
are
or
very similar
models, application environments, and logical and physical descriptions.
The
DATA MODEL clause in the LSL determines which data model specific constructs (e.g.,
CODASYL set or relational foreign key) may be used in a particular schema. Relational
across
The HOST
corresponding network constructs.
specifies which host language rules must be used
in a particular schema to name relations and attributes and to specify data types.
(Alternate, host-independent names may be specified for readibility.) An application
treats both a simple object and a structure-defined composite object in the same way
(i.e., as a relation/record).
model specific constructs resemble
LANGUAGE clause in the LSL and ISL
The
advantages
of
this
integration
are
several:
less
language
to
learn
for
users
of
multiple data definition and/or data manipulation environments; uniformity of semantics
across environments; access to common data at any level of logical schema through any
IPIP-supported data model or application environment; support for the shop where just
one data model and/or application environment is desired; availability of capabilities
traditionally ascribed to one environment in other environments; commonality in
implementation supporting multiple environments.
Data Architecture
~
4.3
By data architecture we mean the framework for configuring data
manipulation. Data definition for IPIP is organized into schemas,
together to provide data independence and various views of data.
commands appear in application programs and interactive sessions.
5
definition and data
which
Data
may
be tied
manipulation
There
three types of IPIP schemas: internal, logical, and mapping. The IPIP internal
to the internal schema of the ANSI DBSG
10] and the storage
of the CODASYL DDLC
IPIP logical schemas correspond to ANSI
are
schema
corresponds
schema
s]
.
The
conceptual and external schemas and also to CODASYL schemas and subschemas.
IPIP mapping schema is used for mapping between schemas of the other two types.
IPIP data base is described
by
logical schemas mapped
application program or session may
An
levels of
Logical
schemas
to
arrangement
can
be
provide
single level of internal schemas and one or more
underlying logical and/or internal schemas. An
be formulated against logical schemas at any level.
a
to
configured
for
in
the
centralized
comprehensive, base—level logical (conceptual)
ANSI
definition
and
of
CODASYL tree structure
data base
a
through a
schema.
configurations of logical schemas can be coupled by mapping one logical
multiple logical schemas or by invoking multiple logical schemas in a single
application program or session. This provides for decentralized definition of a data base
This coupling capability may be used for a variety
or of a federation of data asesll].
of purposes ranging from integration of existing data bases with minimal change to data
definition, to decentralization of data administration over multiple clusters of shared
and/or private data.
Multiple
tree
schema to
The
to vary the depth of logical schemas supports control of data independence
data cluster. The ability to couple logical schemas horizontally supports control
independence of data and data administration across data clusters -additional
over
of
ability
a
independence. Data independence is enhanced in both cases by
mapping schemas, since change often involves only interschema mappings.
dimensions of
JPIP
provides
for
the
use
pre-runtime binding of programs and logical schemas. Programs
regardless of whether underlying schemas have been bound.
of
may
be bound at runtime
Together, the richness of the IPIP data architecture along with IPIP binding options
permits tradeoffs between degrees of data independence and the overhead of creating,
maintaining, and referencing data description.
4.4
The
Support
for
Multiple Data Models
IPIP LSL and DML support both the relational and network data models.
These
languages were based on subsets of the 1978 CODASYL DDL and FORTRAN DML
Included were those CODASYL constructs supporting sets for which
specifications.
relationships are determined by states (value or null) of corresponding attributes in
Constructs specific to other set selection criteria were excluded.
owner and members.
Inclusion of some constructs (e.g., for set ordering and for multiple member types) was
deferred for
one reason or
another.
and RETENTION clauses which specify constraints on
members with/from owners were retained and extended
with respect to the handling of null attributes and dovetailed with an IPIP extension
(MEMBERSHIP clause), which provides for member records to be put into ownerless
‘potential’ set occurrences and to be associated automatically by IPIP with an owner
when it is created as well as providing for the CODASYL option where owner must exist
whenever member does (referential integrity in relational terminology). IPIP extensions
include explicit clauses governing IPIP propagation (both from owner to member and
The
CODASYL
INSERTION
association/disassociation
of
6
owner)
member to
of record deletion.
system propagation
bidirectional
For
The CODASYL SOURCE clause which
owner to member was extended to
of item state from
provides
provide
for
for
propagation.
support of the relational data model, a FOREIGN KEY clause was
using syntax which retained the relational flavor of the concept, but
Clauses were included to specify insertion, retention, and
syntax.
direct
more
included in the LSL
paralleled set
membership options in terms of item states. Propagation of record (tuple)
item state may be specified relative to foreign keys as well as to sets.
deletion and
provides for operations relative to foreign keys (by name) paralleling
CODASYL operations relative to sets. A WHERE phrase was incorporated into the IPIP
FIND, FETCH, MODIFY, and DELETE commands to support specification of more
general conditions for calculus-level operations. Relation name in a DML command may
be qualified by a cursor name to support program definition of multiple relations,
concurrently, over a single schema-defined relation.
The
IPIP DML
included in the LSL to govern which data model dependent
foreign key, or both) may be used in a particular schema.
A DATA MODEL clause
(i.e.,
constructs
set,
was
treated as synonyms in IPIP languages, and may be used
A DOMAIN clause, which was
model specified.
interchangeably regardless
included in the LSL and ISL to provide for user-declaration of data types, may be used
with either data model. And it is intended that in future releases of IPIP that regardless
of data model specified, DML commands across relations (records) may be expressed
either in the CODASYL style of referencing schema-declared relationships (e.g., FETCH
‘RELATION’ and ‘RECORD’
are
of
data
items of A, items of B VIA (name of) schema-declared set or foreign key relating A and
is the criteria defining that relationship) or in the relational
B; where
in-line
of
style
specification of relationship criteria (e.g., FETCH items of A, items of B
a1=b1,
WHERE
a1=b1,
The unified
an=bn
...
...
a~=b~).
approach
in
fully
4.5
Other Scientific
Currently, attributes
arrays.
this time.
join
is not available at this time.
support for the network and relational data models is described
6, 12].
more
or
to
The full relational
Capabilities
of IPIP relations may be integer, real, character, or boolean scalars
projection on individual elements of an array is not supported at
Selection and
capabilities for data set partitions of a data base are supported. A data set is
implicitly on first user access. Data set intersections with relations are the
Access by data set is supported by IPIP indexing
units of locking data for read/update.
(B-tree). IPIP indexing and address conversion structures have been designed to support
access to versions of data sets while minimizing physical redundancy of data across
versions.
Data sets may be used in specifying data to be processed by a prototype
for
facility
transferring data between IPIP and RIM data bases.
Initial
declared
supported to manage geometry and other
a logical schema to consist of tuples from a
network
of
relations
related
tree or
as
by foreign keys. A structure may also be defiiied
in terms of records and sets. A relation/record in one logical schema may be mapped to
Such a relation/record is said to be structure-defined. A
a structure in another schema.
is
(retrieval
and update) as an entity through operations on a
structure
manipulated
Composite objects
scientific data.
called
structures
are
A structure is defined in
7
structure-defined relation; the
A
user accesses
commands used
structure-defined data at the
on
non-structure defined records.
entity (e.g., surface,
curve,
segment)
level.
command may result in IPIP processing of multiple underlying tuples as
schema-declared constraints and propagated actions for relations and
single user
specified by
foreign keys within
A
when
same
the
user
On store, IPIP will generate values for unique keys
will sequence retrieved data according to schema
the structures-defined record.
User productivity is
the structure.
does
not.
IPIP
specification for inclusion in
enhanced through support of entities which are natural to his application. Data integrity
is enhanced through definition of structure processing in the schema, as opposed to
complicated command sequences being embedded in numerous applications.
5.0
Distributed Processing
Some initial capabilities for distributed processing are in place. This includes the IPAD
network and the VAX interface to CYBER data bases (see Section 4.5). The ability to
loosely couple IPIP data bases (see Section 4.3) has extensive potential for distributed
data management.
A prototype facility is available for transferring data between IPIP and RIM data bases
One area for further investigation here is the use of IPIP
on a copy and replace basis.
and RIM in tandem to manage global and local data bases; data sets being copied to RIM
for local
locks
on
use.
Questions
arise
as
to the
implications
data sets which span program executions.
8
for
versioning
of data sets
and/or
REFERENCES
i]
W. E. Swanson.
2]
R. E. Miller.
“Industry Involvement in IPAD Through the Industry Technical
Advisory Board”, Proceedings of IPAD National Symposium, NASA Conference
Publication 2143 September 1980, pages 21-26.
“IPAD Products and
IPAD National
pages 219—234.
3]
D. D.
Symposium,
Implications
for the Future”,
NASA Conference Publication
Meyer. “Reference Design Process”, IPAD
Proceedings
of
2143 September 1980,
Document
D6-IPAD-70010-D
March 1977.
4]
3. W. Southall.
“Integrated
D6-IPAD-70012-D
5]
T. R.
Data
Fisher, E.
Information
Processing Requirements”,
IPAD Document
June 1977.
G. McKenna, D. D.
Management Requirements”,
Meyer,
and 3. E. Schweitzer.
IPAD Document
“Manufacturing
D6-IPAD-70038-D December
1981.
6]
D. L. Comfort, H. R.
7]
F. M. Ives, D. M. Kirkwood, and 3. G. Tanner. “Executive and Communication
Service to Support the IPAD Environment”, Proceedings of IPAD National
Johnson, and D. D. Shull.
“An
System”, Proceedings of IPAD National Symposium,
2143 pages 145-178, September 1980.
Engineering
Data
Management
NASA Conference Publication
Symposium, NASA Conference Publication 2143 September 1980, pages 95-144~.
8]
9]
10]
ii]
12]
13]
CODASYL Data
January 1978.
Description Language Committee.
CODASYL COBOL Committee.
A.
Kiug
Report
“Journal of
“Journal of
Development”,
Development”,
October 1978.
Tsichritzis, Editors. “The ANSI/X3/SPARC DBMS Framework”,
the Study Group on Data Base Management Systems AFIPS Press, 1977.
and D.
of
Heimbigner and D. McLeod. “A Federated Architecture for Data Base
Systems”, Proceedings of the National Computer Conference 1980, pages
D.
283-289.
Larson, and 3. D. Lawrence. “Network and Relational Data
Modeling in a Common Data Base Architecture Environment”, Sperry Univac
Research Report TMAOO72O, Roseville MN. March 1979.
H. R.
Johnson, 3.
A.
Herron, 3. E. Schweitzer, and E. R. Warkentine. “An Approach
for Management of Geometry Data”, Proceedings of IPAD National Symposium,
NASA Conference Publication 2143 September 1980, pages 179-202.
R. P.
Dube,
G. 3.
9
Using
a
Relational Database System for Circuit
Design
Roger Haskin
Raymond Lone
Research
IBM
5600
San
The
revolution
threaten
The
to
make
circuit
in
Cottle Road
Jose
95193
technology poses problems that
design automation systems obsolete.
fabrication
conventional
many
CA
complexity of modern computer systems increases both the
of data to be managed and the number of designers accessing the
Also, the long turnaround time necessary to correct chip design
requires extensive simulation to be done prior to circuit fabri
size
amount
data.
errors
and
Data
cation.
network
necessary
specification
remain consistent
as
to
(i.e.
the
the
parts
simulation
and
must
wires),
and
be
correlated
this
difficulty of adapting the usually ad-hoc data management
existing design systems to handle larger designs has
in
interest
employing modern database technology on their
of
while many
However,
tive
for
manage
use
in
data
facili
created
behalf.
modern database systems make them attrac
environment, the fact that they were intended to
features
design
a
business
the
design evolves.
The
ties
to
correlation must
of
compromise
their
ability
to
be
integrated
into
a
design system.
At
1])
IBM
to
San
Jose
improve
2].
described in
in the process of modifying System R
are
we
Some of this work is
ability to handle design data.
briefly, the extensions we are making include:
Research,
its
Complex Objects are a facility that allows the user to declare and to
specify structural relationships among semantically related data. Fig. 1
shows
a
logic block).
complex object for a simplified ‘module’ (e.g.
Complex objects are implemented by defining three new column types. The
I’IODULES.tiID, PARTS.PID, FUNCTIONS.FID, and SIGNALS.SID columns are all of
The PARTS.MID, SIGNALS.I’IID, FUNCTIONS.PID, AND
the new type IDENTIFIER.
all
of
PINS.FID
are
type COMP_OF, denoting that the tuples in these
hierarchical
descendents
of
relations
are
(i.e.
of)
components
higher-level objects (e.g. a pin belongs to a function residing on a part
is
PINS.SID
of
of
a
module).
type REF. which is used to express
The complex object mechanism allows parti
non-hierarchical references.
the
relations
(e.g.
object
PARTS,
containing
components
tioning
FUNCTIONS, etc.), and expressing the connectivity among elements of the
partitions (e.g. saying which gates are wired to which). Fig. 2 shows a
small
example fragment of a logic diagram expressed in this schema.
Entries in the MID, PID, FID, and SID columns are shown as integers, but
are
(machine id, timestamp).
really system generated unique values
Complex objects retain the use of value matching to define the partitions
and connections, and also retains the relational query language to perform
data manipulation (although see the comment below).
However, by defining
the object structure to the system,
it is possible to provide enhanced
performance and integrity checking.
10
MODULES
MID~
MODULE
1
NAME
PARTS
PID~’1ID~
PART NAME
SIGNALS
LSID~
SIGNAL NAME
]
FUNCTI ONS
rFIDIPID~
FUNCTION
NAME
1
PINS
LFID~PIN
PIN
Fig.
1
-
NAME
~SID~I/Q~
Complex Object
Conversational Transactions.
be
highly
and
A
is
database
transaction
inconsistent.
is
defined
b.
the
design
Logic Designs
database
is
likely
to
the
period during which the
System
designed for transactions that
complete quickly (i.e. fractions of a second),
R
only a few records,
inputs that are known
address two problems of standard
a.
of
Gedanken
This poses problems for the transaction management
control facilities of System R (as it would for most other
access
and
Use
for
interactive.
concurrency
systems).
Schema
have
in
to
span
was
advance.
transaction
Conversational
transactions
management:
Changes made by a transaction can be backed out (e.g. due to system
Backout is intolerable when the transaction spans an incon
crashes).
sistency due to a long series of interactively entered changes.
It is standard practice to suspend (block) a transaction attempting to
locked object until the lock is acquired (i.e.
a
rather than
access
informing the transaction and letting it decide what do). Interactive
users would undoubtedly find such suspensions bothersome.
applications, the programts data access patterns map
In these situations,
complex objects.
complex objects are a
more
appropriate lock granularity than relations or tuples. The heart of
conversational
the
mechanism
transaction
is
a
facility for acquiring
locks on entire complex objects, thus including them in the lock graph
Conversational
locks
2,3]).
persist past end of transaction until
An attempt to acquire a conversational
explicitly re1eased by the user.
lock on an already locked object returns an error rather than suspending
In
most
well
interactive
onto
the transaction.
Database-Data
many
done
base
Structure
Interface.
To
achieve
adequate performance,
(e.g. display management, simulation) will probably be
using memory-resident data structures.
Perhaps the overriding data
issue
is
how
fast
these
structures
can be built from data
performance
functions
11
SID~
L~1
FID
FID
PID
117
23
81
23
59
71
PIN
FUNCTION
NA?IE
SID
I/O
117
3
Yl
21
0
81
4
A2
21
I
59
2
CK
21
I
in
2
-
database.
the
STROBE
2inp. NAND
2inp. NAND
D FF w/ P,Clr
PIN NA?IE
Fig.
SIGNAL NAI’IE
Complex Object Fragment
The
overhead
of
the
for
a
Signal
Path
record-at-a-time
SQL
interface
systems)
high to allow adequate performance.
We are therefore providing an object-oriented interface to allow a data
from the data in one complex object or a set of
structure
to be built
addition
In
to
creating a data structure from complex objects,
objects.
this interface will provide language constructs to initialize elements in
the structures that do not contain data from the database, and will auto
matically translate structural interrelationships defined in the complex
object into pointers in the data structure.
(shared by
most
is
other
Storing Non-Coded Data.
In
too
common
with
most
business-oriented data
R has
only rudimentary facilities for handling
management systems, System
the non-coded data necessary to many phases of the design process (e.g.
simulation checkpoint data, circuit mask patterns).
System R’s facili
ties for managing non-coded data are being modified to greatly improve
performance on updates, to support data items of essentially unlimited
length (2+ Gb), and to manage data stored outside of System R (e.g. in
VSAM
datasets).
Preliminary Results
A
will
description of these extensions is available in 2], and
However, experience with the design gained
repeated here.
implementation effort have led us to several interesting obser
detailed
not
during
be
the
vations.
Our
tuple
original intent was to implement complex objects by giving each
the object a unique identifier, and handling structural naviga
in
12
(e.g. retrieving all tuples in a relation belonging to a given
object) using joins. This is, of course, the way a user would implement
This proved unsatisfactory
such objects on top of a relational system.
for three reasons:
the space overhead of storing identifiers in tuples of
large objects, the time overhead of performing a join (or at least
consulting an index) to follow a reference, and the fact that duplicating
an object would have
required a network copy, generating new identifiers
therefore implemented intra-object
and resolving references to them.
we
the ‘object map’
The object
called
access
paths using a special table,
the
for
each
in
root
tuple occupy
tuple
object (the
map contains an entry
The
ing the first entry), each entry holding the tuple’s address (TID).
tioii
.
user
they
that
thinks
contain
links
(to
an
at
duplicating
COMPOF
index
two
most
the
and
into
tuples
REF
the
object
I/O’s)
and
columns contain
and
in fact
speeds following logical
copying an object by merely
the
the new tuples are
as
map
map.
enables
rebuilding
identifiers, but
This
created.
interesting question involves the suitability of the relation
Consider the
query language for performing queries on complex objects.
all modules
wish
select
in
1.
to
shown
we
Further, suppose
object
Fig.
than
This would
is
connected
ten
where
to
an
more
inputs.
output pin
the
following SQL query:
require
Another
al
SELECT
UNIQUE MODULE NAME
,PARTS ,FUNCTIONS ,PINS P1
FROM
MODULES
WHERE
MODULES.MID
=
PARTS.PID
FUNCTIONS.PID
=
FUNCTIONS.FID
=
PINS.FID
<
only
is
AND
AND
=
FROM
PINS
WHERE
P2.10
P2
this
query
‘I’
=
P2.SID
Not
AND
‘0’ AND
(SELECT COUNT (UNIQUE PNID)
PINS.IO
10
PARTS.MID
=
AND
Pl.SID);
clumsy,
requiring explicit coding
of
the
joins
necessary for navigating from the pins to the modules containing them, but
they do not even map well into the access path that will be used since, as
above, the root tuple is known to be the first entry in the
It therefore appeared desirable to provide improved facili
object map.
ties for maneuvering in complex objects, for example:
mentioned
FROM
UNIQUE MODULE NAME
MODULES,PINS P1
WHERE
MODULE.NID
SELECT
PINS.IO
10
<
=
=
‘0’
ROOT
OF(PINID) AND
AND
(SELECT
example schema and queries are rather contrived, we are in
investigating using the extended System R to manage data
process
for a large internal design system.
Preliminary estimates show that in
addition to the added integrity offered by complex objects, the perform
ance will be dramatically better than it would be for a comparable schema
Although
the
the
of
13
using INTEGER
object map.
columns
and
rather
joins
than
IDENTIFIER,
and
etc.
the
Summary
We believe the System R extensions described here overcome many of
problems conventional database systems have in managing design data.
particular,
1.
2.
By defining the structure of objects to the
performance, structural integrity, and ease
ming can be. achieved.
Complex objects
In
improvements in
applications program
system,
of
appropriate unit of locking in many cases
tuples.
Object locks were used to implement
conversational transactions, which greatly improve the ability of the
system to be used interactively.
than
3.
the
are
are
relations
Providing the
large objects
a
more
or
ability
to
sets
of
build
program data structures directly from
objects, and allowing non-coded data to be
stored and retrieved efficiently and in synchronization with the tran
saction and recovery mechanism enhance the performance and utility of
the database system for many common design operations.
or
References
1.
Astrahan,
M.
N.,
Management,’
ACM
1976,
2.
et.
‘System
al.,
Transactions
on
R:
Relational
Database
Approach
Systems, Vol. 1
Database
to
No.
2,
June
pp 97-137.
Haskin,
R.
al Database
L., Lone, R. A.,
System,’
Proc.
‘On Extending the Functions
1982 ACM-SIGMOD Intl.
Conf.
on
of
a
Relation
Management
of
Data, June 1982.
3.
Gray, J. N., Lone, R. A., Putzolu, G. R., and Traiger, I. L., ‘Granu
larity of Locks and Degrees of Consistency in a Shared Data Base,’ in
Modelling in Data Base Management Systems (G. H. Nijssen, ed.), North
Holland, 1976.
14
PERFORMANCE OF DATABASE MANAGEMENT SYSTEMS IN VLSI DESIGN
Anne Beetem
Jack Milton
Gio Wiederhold
I.
Introduction.
VLSI custom
need
design involves the manipulation of large
invest 4 to 30
to
man
years for
methodologies infeasible Sch79].
The
microprocessor design makes single-designer oriented
The effort to communicate concepts and data among multiple
design specialists probably contributes significantly
certain to grow
volumes of diverse interrelated data.
to the
design cost, and the volume of data is
refinements in fabrication methods allow increases in component count and
as
heterogeneity. Because database technology has dealt with both the management of large volumes
of data and problems caused by concurrency of data
effective handling of VLSI design data through the
advantages
attendant
of
flexibility,
ease
of
access
use
Ful8O], Mal8O]),
of database management systems with their
provisions for
use,
investigate the
we
protection,
increased
data
independence, and concurrency control, for example.
There
VLSI
are
several key issues which must be addressed if databases
There
design.
seems
to be Iitt~e
are
to become effective tools in
disagreement that design systems should exploit hierarchy
Additionally, it is of critical importance that the system allow for
Kat82].
methodologies
so
that
1) changes
variety of design
a
be reflected both up and down the
at any level can
design
hierarchy, and 2) different representations of the design (e.g. sticks, layout geometry, circuits, gate
logic)
are
allowed.
representations
more or
less
elements at lower levels of
change emanating
at
the
Ultimately,
a
system
should
automatically e82],Kat82]).
design
higher levels,
maintain
Explicit storage for
must be avoided in order to
because excessive
equivalence
between
these
all attributes of all
permit effective management of
replication of lower level elements vitiates the
benefits of hierarchical design methods, and because explicit storage at the gate instance level
creates excessive
storage demands. To avoid these demands the database system
must be able to
fetch actually instantiated data, compute potential, non-instantiated data using stored algorithms,
“infer”
certain
parameters of the design
Moreover, in order
acceptable
that the
to the
to
make the
move
from
relationships between elements (See Ko81]).
away from
design engineering professionals,
degradation of performance relative
or
specialized design files
to database
systems
the performance of the system has to be such
to that of
gained.
15
specialized files is proportional
to the benefits
II. Current Work.
The main objective of
knowledgeably,
work is to determine whether commercial database systems, used
our
perform adequately.
can
The initial set of experiments has revolved around DEC’s DBMS-20,
published CODASYL database definition DBT71].
order to
In
schema.
database
obtain
correct
We spent
and
a
a
system based
major initial effort
to
the
on
design the
high performance operation from
current
commercial systems it is essential that the semantics of the application be modelled carefully before
attempting
we are
to map them into
as
problems
are
similar,
to model the VLSI
believe that the results
we
importantly, by using
More
existing specialized design files
Due to availability of data and programs,
WEM79].
using data from conventional circuit board design
many of the
well.
database schema
a
this data,
and programs
we were
on
the
same
Language vC79])
is
a
transistors). The SDL compiler produces
contains the
we
timer),
r12
a
binary file from
chose the PDP-1 1 processor,
description:
(register files),
The CODASYL schema
advantage of the network
the DBMS-20 database.
and
equivalent database representation.
SDL
the control.
a
if
was
cpu
as
are
design written
in the
the specialized control subject, via
vC77],
levels in the hierarchical
and
as
logical description of each component described
the SPRINT database
purposes,
an
described in terms of gates, gates
are
process
comparisons with
(Structural Design
straightforward hierarchical description language (e.g. registers
flip-flops, flip-flops
in terms of
design
data.
used
were
Since
process.
to the VLSI
able to make benchmark
We first demonstrated the replacement of design files by
Specialized design files of circuit information
applicable
are
design
described in SDL
a
described
are
described in terms of
in SDL.
binary file
The
design which is then loaded into
“hardwired” schema.
SL79].
There
are
For test
eight different
(central processing unit), reg (registers), rf 1 (priority arbiter
(flip flops), gate (gates),
trans
(transistors) and bottom (primitives).
modelled closely to the SPRINT schema except for revisions to take
The binary file
structure.
The initial
loading of
produced by the SDL compiler
example took SPRINT
the PDP-11
required about four minutes for DBMS-20, which
we
find
was
about
loaded into
one
minute
acceptable.
Reading from the Database
The next experiment tested the time i~ takes to both read from and write into the database.
macroexpander program Pay8O]
component from
a
was
The
database.
used which first reads the logical description of
user
then specifies the levels to be expanded.
requests that the program expand all levels down
logical description of
the
producing
the
to
a
simulator
~rogram.
high level
Thus, if the
user
transistor, the resulting output will be the
original component described totally
description could be the input
the first step in
to the
a
A
in terms of transistors.
This form of
Also, in the VLSI environment, this could be
layout diagram.
The macroexpander program needs to do very many random read operations,
component that is being expanded is large and described
of expanding the PDP.1 1 and its ALU:
16
at
a
high level.
The
especially
following
are
if the
the results
SPRINT
ALIJ
time
10
CPU
PDP-11
10
time
21s
33s
30
45
time.
66
115
time
120
190
CPU
These results show less than
a
Records
DBMS-20
factor of two
in
degradation
Words
read
read
1514
7754
5925
28501
performance of
This is
the DBMS-20.
an
acceptable trade-off for the increased flexibility and generality of CODASYL and disputes the original
theories that there would be at least
order of
an
magnitude difference
performance.
in
Writing iat~ the Database
To test writing into the database
acceptable both
in
an
absolute
application of VLSI design,
modified
so
component, it
the
stores
new
makes
user
a
is
representation
some
were
seconds.
changes
can
corresponding
this level (the MUX and the
an
was
design system does
not
the times would
be
that
hoping
In order to simulate
In this mode, after the program
a
were
In
description.
original description
at
a
was
tested
the ALU
are
on one
the
given le~’eI, and
were
design
stores
use
when
of the registers, the ALU.
the 40181 and the 40182. When these
total read time of 17.4 seconds and
times for the 40182
XOR)
internal
a
total write time of 41.3
a
Two other pieces at
8.78 and 8.82 seconds.
also expanded, and the ALU
was
expanded again with the
in the database. The total read time
was
48.0 seconds,
We consider that the DBMS-20 implementation showed
203.0 seconds.
acceptable performance.
Signalling Changes
At
this
stage,
we
ui
resource to
all
the Database
explored implementation of data management facilities
specialized design files.
A
strong motivation for using
design participants and
design environment. To
database is that it
provides the data
becomes the communication medium in
so
carry this function
a
provided by
not
effectively the database system has
to be
a
down between different hierarchical levels, and
sideways
between different
as a
future VLSI
augmented with
communication paths. These paths may ultimately be oriented in any combination of directions
or
real
a
expands
choose the appropriate internal description to
expanded versions of these lower level pieces
and the total write time
to the
description of
expanded, the 40181 gave
The
tests
another
as
expanded. This scenario
Two of the parts in the upper level
pieces
the SPRINT
given device within the database, the macroexpander program
this version in the database, the program
higher level component
as
considered how the database would handle instantiations.
we
that it could write back into the database.
atmosphere, if the
a
control,
and relative to the retrieval times.
sense
To exercise the representation of
was
a
proceeded with the DBMS-20
We
have this capability.
do not have
we
representations
-
-
up
of
a
given design.
The downward direction is supported
by
the hierarchical
17
design
process, but in
practice design
changes also flow upwards,
and other
as
instances at
oriented needs.
performance
direction, which relates detail
a
lower level
are
We hence have
to more abstract
modified to satisfy layout, timing, fanout
in the
developed communication
specifications. The creation
or
upward
modification of lower
level instances has to be bound to the appropriate higher level elements. We implement this task by
signalling scheme. Multiple
element may be defined by
structures at
an
higher hierarchical levels
The
signal of the change
level to which the
signal
the system provides
a
creates
was
a
exception flag
an
functional component and
at the
higher
a
warning
component,
One approach to the
level parts that
that
change
a
a
or a new
has been made.
method to find the
signalling problem would be
owners
upper level components.
flagging
Ill.
parameterization of
This is
that component.
use
At
structures.
a
a
a
a
the
at that
library description.
later time, when the
level, the introduction of
going into further
new
a
component keep track of the upper
costly and rigid approach. Alternatively,
a
design level,
appropriate action could then be
library description.
to have each
indirectly and implemented
Without
An
an
simple example is
directed is accessed by the specialist responsible at that
taken; for example, verification of continued correctness
version of
Wie77]:
association of several higher level entities
element that is defined from the expansion of
an
may become involved because
a
“height first” algorithm
detail
(See Wie82]),
we
to
developed
we
signal by flagging
indicate
some
sample
times:
Dealing
Level
ALU
reg
0.13s
MUX,XOR
gate
0.9
INV
trans
7.1
TN
bottom
21.0
with
Partially Instantiated Levels.
We have written
element.
elements
This
are
Time
Piece
procedures which
will obtain all
dependent instances
requires that first all actually instantiated elements
an
a
lower level of
some
retrieved, and then all other
using the macroexpander. Actual instantiations
obtained by expansion
be stored whenever
are
at
are
required
to
element contains data not derivable from the expansion. This is typically true
for elements at the extremes of
an
otherwise regular structure.
transistors, the connection configuration,
or some
layout detail
For such elements the
may have to be
driving
specified.
IV. Conclusions and Future Work.
The initial approach continues to
seem
promising:
DBMS-20 allowed
us
to
implement both initial
designs and modifications relatively quickly and easily. Coupled with the fact that performance has
not been
badly affected, this has allowed
experiments
to
obtain the
us
to
experiment productively.
We expect to
use
these
knowledge needed for eventually designing versatile and complete
database systems for VLSI design. Our immediate goals and activities
1.) The database description needs
to be
expanded
18
to deal with the
are
the
following:
signalling procedures. We
are
expansions using the
involved in using
2.) We plan
a
same
incorporate multiple representations and other desirable
to
reloaded data and
timing
tests to reaffirm
the passage of information
using procedures.
design),
our
we
plan
information in order to handle different representations of the
schema is
4.)
We
designed
to facilitate this
in the process of
to test the
same
design
in
“sideways” passage of
a
unified
The
manner.
investigation.
acquiring
relational database management systems and wish to do
experiments with those systems.
similar
5.)
are
theory that the overhead
development of systems for maintaining equivalence between representations (for
instance the logical and layout aspects of
new
our
commercial database is not prohibitive.
investigate
to
With the
3.)
Be81J
the schema further
developing
We would like to develop further ways to manage
queries
that access
partially instantiated,
computable and/or retrievable elements.
References
Be81]
Approach to Communication in VLSI Design: Part II The
Schema”, Stanford University, Department of Computer Science, Internal Report,
Beetem, Anne:
New
“A Database
-
1981.
Be82]
Beetem, John: “Structured Design of Electronic Systems Using Isomorphic Multiple
Representations”, Stanford University, Electrical Engineering Department, PhD Thesis,
January
1982.
DBTG(71): Report of the CODASYL Database Task Group, available from ACM, NY
lAG, Amsterdam, April 1971.
DBT71]
Fu180]
Fulton, Robert E.:
and Aeronautics,
“National Meeting to Review IPAD Status and Goals”, Astronautics
July/August
1980.
Kat82]
Katz, Randy H.: “A Database Approach tor Managing VLSI Design Data”,
Design Automation Conference Proceedings, June 1982.
Kó81]
Koenig, Wolfgang and Raymond
Mallmann, Felix P.:
System”,
“Storage of VLSI Physical Designs
Laboratory, unpublished report, 1981.
“The Management of Engineering
The Seventeenth
Design
The Nineteenth
A. Lone:
Relational Database’, IBM Research
Ma180]
or
Changes Using
Automation Conference
Proceedings,
the
in
a
Primus
pp. 348-366,
June 1980.
Pay8O]
Payne,
-
Thomas:
Pascal
Engineering Department,
macroexpander program, Stanford University,
(Computer Systems Laboratory), CIS, 1980.
Electrical
CSL
Sch79]
Scheffer, Lou:
SL79]
Slutz, Eric: SDL description of DEC PDP-1 1, Stanford University, CSL, CIS, 1979.
“Database Considerations for VLSI Design”, Design Automation at
Stanford, ed. W. vanCleemput, Stanford CSL Technical Report No. 178, 1979.
19
vC77]
vanCleemput, W., T.C. Bennett, J.A. Hupp, and K.R. Stevens: “SPRINT:
System for Printed Circuit Board Design”, Proc. IEEE Computer Society
Software and Applications Conf., pp. 113-119, November 1977.
vC79]
vanCleemput, W.: SDL: A Structural Design Language for Computer
Digital Systems, Stanford CSL Technical Report No. 136, 1979.
WEM79]
Wiederhold,
Gio and Ramez El-Masri:
An Interactive
mt.
Computer
Aided
Design of
“The Structural Model for Database Design”;
Proceedings of the International Conference on Entity- Relationships Approach
Systems Analysis and Design, pp. 247-267, December 1979.
Wie77]
Wiederhold, Gio: Database Design, McGraw-Hill, 1977.
Wie82]
Wiederhold,
Gio,
Anne
Communication in VLSI
Beetem
and
Design”,
IEEE
Garrett
Integrated Circuits, April 1982.
20
Short:
Transactions
Database Approach to
Computer Aided Design of
“A
on
to
USING
RELATIONAL
A
.?OR
DATABASE
COMPUTER
AIDED
MANAGEMENT
DATA
SYSTEM
DESIGN
Antonin Guttman
Michael Stonebraker
University of California
Berkeley
1.
Introduction
There
relational
has
been
interest
considerable
to
data
systems
manage
database
in
for
using
computer
been
have
concerns
However,
design (CAD) systems.
database
have
been
that
designed
systems generally
expressed
In
well
for other uses and might not be
suited
CAD.
to
that
too
there
relational
DBMS’s
is
are
concern
addition,
The purpose of this paper is to report our experience
slow.
with implementing a CAD application in a relational DBMS and
comparing its performance with a non—database CAD package.
aided
In
Section
2
the database
schema
that
was
structure of the special purpose CAD
Then in Section
indicate
the
we
3
package.
experiments
and
Section
the
results.
contains a
4
performed
give
discussion of the
results.
Section
indicates
5
Lastly,
where a relational DBMS was found to be inadequate as
areas
a
support tool for CAD applications.
used
2.
The
Database
discuss
we
describe
and
the
Schema
The application package benchmarked was KIC, a graphics
editor
for integrated circuit designs developed at Berkeley
2]. A KIC database consists of a collection of circuit
“cells”.
Each
cell
contain mask geometry and subcell
can
A complete circuit design expands into a
references.
tree,
with
single
a
for
subcells,
associated
stores
a
Our
five
main
the
with
circuit
cell
at
non—root
each node
in
virtual
INGRES schema
relations:
the
root
and
nodes.
in the
tree.
memory
on
reflects
the
21
other
cells, used as
be
can
geometry
KIC
During editing
VAX 11/780 computer.
Mask
a
above
structure
and
has
cell
master
cell
ref
box
( author,
(
(
(
wire
In
the
to
given
designed
assigned
The
and
Master
each
to
the
cell
ref
if
references
For
master
cell
to
it.
example,
Id,
width
polygon id,
use,
cell
the
ref
id
defined)
Id,
tll—t32)
xl,
~ ~
vertnum
relation,
name
author
the
is
a
cell.
cell within
relation
the
Id,
yl, y~)
x2,
wire
use,
(
polygon
cell
child,
xl,
use,
master
is
is
the
textual
name
person who
number
identification
unique
It
used
is
for
unambiguous
the database.
of
name
describes
cell
x,
subcell
contains
“cpu”
the
references.
“register” as a
which
in
tuple
part, then the cell ref relation contains a
identifier
is
of
the
is
the
and
child
“Cpu”
parent
identifier of “register”.
Tll
X
2
a
are
3
t32
through
matrix specifying the location, orientation and scale of the
subcell with respect to the parent.
This representation
of
transform
is the one generally used in computer
a
spatial
graphics 3].
The
box
relation
describes
mask
Owner
is
identifier of the cell of which the box is a part.
metal or diffusion
Xl
specifies the mask layer; e.g.
x2
the x—coordinates of the left and right sides of
are
box while ~ and ~ are the y—coordinates
of
the
top
Use
and
the
rectangles.
the
and
bottom.
A
“wire”
is
a
connected
path of
the
describes
wire
relation
coordinates of its centerline
id
is
and
use
“polygon”
is
width.
Wire
Owner
wire.
A
vertices.
relation.
vertex
X
y
the
and
orders
3.
Experiment
The
(xl,
y~,
mean
the
Each
in
tuple
segment, giving the
x2,
~) and its
identifier
same
as
for
for
the
a
box
particular
relation.
solid
with
of
number
shape
any
stored in each tuple of the polygon
the coordinates of
the
and
are
vertex,
vertices (tuples) within one polygon.
One
vertnum
line
unique
a
lines.
one
a
is
data we used circuit cells from two design
GORDA
is a prototype layout for a
Berkeley.
switched capacitor filter 5], and decO—i
of
is a part
the
RISC
VLSI
The
6,7].
computer
design descriptions were
For
our
projects
at
translated
database.
test
from
KIC
files
and
22
loaded
into
the
INGRES
We
three
programmed
and
measured
operations
compared to KIC performing
the
C
and
written
were
programs
in
CAD
retrieval
representative
of
test programs
our
speed
the same
test
The
operations.
made
calls
to
INGRES
the
DBMS
L4].
retrieval
The
first
geometry
program
geometry data associated with a given circuit
This is
cell, not including geometry belonging to subcells.
the first step in most CAD editing sessions.
~p—leve1
retrieved
the
retrieval
Geometry
with
tree
The
second
expansion
for
all cells referenced in a
geometry
cells
fully expanded design tree.
Geometry for lower level
transformed to its proper position relative to the root
was
cell.
This operation produces a plot of an entire design.
retrieved
program
Retrieval
top—level
middle of
circuit.
a
The
~
location
that
geometry
cell.
a
tables
This
The
fell
third
within
a
operation would
be
below
show
the
retrieved
program
small area in the
used
results
to
of
“window”
the
tests.
Tuples refers to the number of tuples representing
Geometry
INGRES
the
database
each
geometry retrieved from
during
CPU
Time and Elapsed Time were reported by the
operation.
operating system. The msec/Tuple figures are time divided by
the
number
of
INGRES tuples.
The Relative Time rows give
the
slowdown
factor
of
test
our
programs
relative
Circuit
GORDA
Geometry Tuples
592
to
KIC.
—
CPU
CPU
Seconds
msec/Tuple
Relative
CPU
KIC
INGRES
7.5
24.0
13
Time
41
1
~
—
—
Elapsed
Seconds
7.5
Elapsed msec/Tuple
Relative
13
Elapsed Time
Pest
1:
41
~
1
Top Level Retrieval
23
69
5.5
Circuit
Ge ometry
GORDA
12,7T9
Tuples
—
KIC
INGRES
—
Seconds
CPU
128.3
msec/Tuple
CP U
Rel ative
CPU
El apsed
10
Time
Seconds
Elap sed msec/Tuple
Relat lye
Test
2:
1
3.5
128.3
649
Retrieval
1
with
Tree
Circuit
G eometry
35
10
Time
Elapsed
443.5
CPU
C PU
5.1
448
Window
87
Seconds
.75
msec/Tuple
Re lative
1
decO—i
Tuples
in
51
Expansion
KIC
Geom etries
]
CPU
9
TIme
INGRES
85
14.5
171
1
20
.75
33
—
E lapsed
Ela psed
Rela tive
Seconds
msec/Tuple
9
388
Elapsed Time
1
45
Test
3:
Retrieval
24
by Location
4.
Discussion
Results
of
In
in
CPU
Tests 1
and 2, the factor of three increase
for INGRES can be attributed primarily to the fact that
INGRES is a general—purpose DBMS
KIC
includes
while
only
DBMS
used in place of
functions
that
it
requires.
Any
time
purpose code will show some decrease in performance.
cost must be balanced against the advantages of using a
special
This
DBMS,
of
simplification
e.g.
independence, etc.
data
software,
application
The elapsed time measurements show a larger performance
This is mainly because
about a factor of five.
difference,
KIC
data
INGRES geometry data is disk resident.
geometry
resides
actually
KIC
quickly
has
no
virtual memory, and since the tests were run
KIC’s
data
machine with ample main
memory,
in real memory.
in
dedicated
has
bin
spatial
a
and
for
window
the
must
allows
that
structure
in
isolate
geometry
such access method
Test
perform
on
a
was
it
to
INGRES
3.
sequential
a
search.
The
features
new
narrow
the
manage
a
virtual
memory
next
the
in
suggested
performance
section
may
changing INGRES to
database would dramatically
improve
gap.
In
addition,
performance.
5.
New
Peatures
During
that
our
should
be
applications.
5.1.
identified
we
added to a relational DBMS to
We discuss them in turn.
four
experimentation
features
facilitate
CAD
Ragged relations
It
would
been
have
convenient
for
field
a
in
relation
a
to
In our database, for
repeat a variable number of times.
data
store
for
to
a
example, this would have allowed us
of
“boxes”
the
cell master relation,
in
varying number
instead of in a
The
cell master
box
relation.
separate
relation could have been defined by
cell
master
( id,
defined
where
fields
wire,
the
“&(...)“
notation
describing a
and
polygon
coalesced
with
the
This revised
understand.
In
box
is
cell
cell
name,
author,
&(use, xl, x2, ~, ~fl.
means
that
repeated,
reference
master
the
group
for each
once
relations
relation
schema might be more
it
would
addition,
25
in
a
five
The
could
be
similar
natural
speed
of
box.
for
a
access
way.
user
to
to
the
geometry for
in one tuple
particular cell,
a
rather
since
distributed
than
the
would
geometry
across
three
be
relations.
We
this
extension
under
the
name
“ragged
propose
relations”.
One way to support ragged relations would be to
first provide ordered relations, which has been suggested by
Stonebraker
nest,
so
relation.
A
and
that
a
We
of
and
then
relation
a
allow
could
be
relations
an
to
ordered
idea.
this
investigating
are
database
8,11],
others
field
with
ragged relations or nested relations is
and reflects the hierarchical
form,
that
the
just
language
provides
standard
relational
data
manipulation
operations must be
with
relations
or
augmented before it can be used
ragged
nested
relations.
We
such
are
an
investigating
augmentation.
in
not
first
normal
nature of the data.
A
5.2.
Transitive
Our
second
could
which
Closure
test
nest
required to
was
program
of
range of
retrieve
r
is
t
is
~
This is an
number of times.
not
transitive
and
does
closure
INGRES query.
We have extended the
cell
facilitate
to
such
tasks.
ref
tree
into tree
(
where
or
subcells
variable
a
a
operation similar to
to
a
single
correspond
syntax of QUEL with a * operator
For example:
range
expand
r.child)
=
ROOT
r.parent
t.cell
r.parent
=
=
the
tree
Here the tuple variable t ranges
over
relation,
which
is the result of the query.
The retrieve adds tuples
the
to tree and is
new
over
(with t
repeated
ranging
tuples)
until~ there
Some
database
in
possible
system 13].
are
5.3.
Access
are
~ spatial
Many CAD programs,
data
design
be
test would have run
classified according
by approximate
We
INGRES
new
location
like
third
faster
in
system
of
spatial
“bins”,
bin
mechanism
according
much
to
a
test
program, need to
spatial location.
INGRES if data could
our
to
its
i.e.
location.
are
considering adding
as
an
two—dimensional
additions.
closure
transitive
operations involving
ORACLE
and
the
in
12]
Query—By--Example
retrieve
This
no
extension
array
of
a
of the
bins is
spatial
secondary
26
defined
facility.
A
grid.
index
by
a
to
A
bin
inaex
is
file containing, for each bin, pointers to all
a
in
Geometries
objects that might overlap that bin.
a
particular area can be found quickly by looking in the index
under the appropriate bins.
For example, a bin index
could
be defined by:
the
index
box
on
is
boxbins
~(i~i,x2) through max(xl,x2) ~
min(~j,~) through max(~,~) ~
This
The
define
5.4.
bin
index
mm—max
the
set
Unique
is
based
expressions
of
bins
it
on
a
grid of 10
the size
specify
could overlap.
10
io5.
X
10
of
each
squares.
box and
identifiers
Codd and others 9,10] have suggested the usefulness of
identifiers
for
database
unique
objects.
They should be
and
handled
generated automatically by the database system
In our application we were
as
a
internally
special type.
forced to manage
identifiers
our
for
own
unique
cells,
wires, etc.
6.
Conclusions
INGRES
performs typical computer aided design retrieval
than
slower
considerably
special
purpose
We have suggested a number of
enhancements
that
programs.
could
be
made
to
relational database system that would
a
to
for
improve performance and make the system easier
use
CAD
We are continuing to look for additional
applications.
mechanisms along the same lines.
operations
7.
Acknowledgements
This
2/82
8.
1]
and
work was sponsored by NSF grant
ECS—8007683—Wong—
by AFOSH grant 78—3596--Stonebraker/Wong—6/82.
References
Held,
G.D.,
Relational
Vol.
2]
3]
44,
M.R.
Stonebraker
Data
Base
AFIPS
Keller, K.
Circuits
Press,
and
“INGRES:
A
E.Wong
Proc AFIPS 1975 NCC,
System,”
Montvale, N.J.
A
Editor
Kic,
Graphics
Masters
Thesis,
Dept.
and
Computer
Science,
Engineering
California, Berkeley,
CA.
Newman,
R.F.
W.M.
Interactive
and
Computer
June
for
Integrated
of
Electrical
of
University
1981.
Sproull
“Principles
Graphics,”
McGraw—Hill,
1979.
27
of
N.Y.
4]
6.2
Reference
‘I~GRES
Version
al.
Woodfill, J. et
Research
Electronics
Memo No. UCB/ERL M79/43,
Manual,1’
CA.
of
California,
Berkeley,
Laboratory, University
July 1979.
5]
The
cell
circuit
switched
GORDA
capacitor
Instruction
International
1981,
7]
made
Reduced
A
“RISC
I:
Sequin
Proc
Eighth
Computer,”
Architecture
Nay
Symposium on Computer
D.A.
Patterson,
a
Labs,
Electronics Research
Berkeley, CA.
6]
of
a
prototype
layout
at
Guinea
Jesus
by
of
California,
University
is
filter
C.H.
and
Set
VLSI
443—457.
pp.
to
“A RISCy Approach
Fitzpatrick, D.T. et al.
VLSI
Design Fourth Quarter (October 1981), pp.
Architecture
in
News
(Also appears
Computer
VLSI,”
14—20.
March
1982.)
8]
Stonebraker,
Relation
M.
J.
and
Brouser,”
University
Electronics
California,
of
1981.
December
CA.
Berkeley,
Sophisticated
A
UCB/ERL M81/94,
No.
Memo
Laboratory,
Research
“TIMBER:
Kalash
9]
“Extending the Database Relational Model to
Codd, E.F.
Transactions on Database
ACM
More
Meaning,”
Capture
December
No.
Vol.
1979, pp. 397—434.
4,
4,
Systems
10]
Lone,
Applications,”
Research
IBM
for
Design
RJ3176
(38928)
Database
in
“Issues
R.A.
Report
7/10/81.
ii]
Lone,
R.A.,
Relational
Zloof,
N.
Transitive
(Revised)
13]
“ORACLE
A
and J.L. Becerril “GSYSR:
IBM
for
Interface
Graphics,”
Casajuana,
Database
Report RJ2511
Research
12]
R.
“Query—By—Example:
Closure,”
IBM
Operations
Report
Research
on
the
RC
5526
(#24020) 10/29/76
SQL Language
Relational
(32941) 4/24/79.
Software
—
Reference
Incorporated,
28
Guide,”
October
Copyright
1980.
by
DAVID:
for
Aids
Design
Randy
Integrated Databases
using
VLSI
Katz
H.
Sciences
Department
Computer
University of Wisconsin-Madison
Madison, WI 53706
Abstract
1.
research
briefly describe on—going
We
database
of
applying
ways
computer—aided design data.
Wisconsin
management of
into
of
at the University
technology for the
Introduction
Modern
ments
database
EDP
satisfy
the
require
applications.
These
have
had
either
little
data)
or
evolved
have
systems
traditional
of
touch
to
a
(read
report
(short duration,
touch most of database) orientation. Database research has
only,
recently been directed towards the needs of the design automation
design systems have a tremendous need
Computer—aided
community.
the
those
unlike
facilities
by
for data management
required
transaction
canonical
Some
debit—credit
transaction
of
described
these
are
GRAY78].
here.
data
design
A
management
construction of a
support
system
of
hierarchical
wide
the
use
to
mirror
spread
object,
For
a
microprocessor consists of
example,
methodologies.
trol
and
part
data
a
and
a
register file;
ple representations,
path part;
forth.
so
design
design
hierarchical
the
must
consists
latter
the
Further,
a
design
of
a
in
exists
con
ALU
an
and
multi
representations
example, a VLSI circuit
by
system.
functional
design can simultaneously exist as a block diagram, a
stick
a
transistor
diagram, a logic
a
network,
description,
the
must
The
and
mask
a
manage
system
layout EMEAD8OI.
diagram,
of a design, as it progresses from release to release.
evolution
must
the
system
complex,
Finally, since design objects are so
simultaneous
designers.
support multiple
2.
The
equivalence
the
across
For
Library Paradigm
major
A
the
enforced
be
should
and
complaint
of
the
community is
automation
design
database
relational
systems
real—time design applications (see GUTT82]). We
unrealistic to expect a database system
perhaps
state—of—the—art
perform updates
data
extract
period
of
the
usage
A
time,
to
from
and
a
design.
the
A
system,
return
it
realistic
more
when
are
too
feel
that
slow
for
it
is
that
interactively
to
is
approach
over
a
long
memory
update
it
in
done.
We
call
to
this
model
of
Library Paradigm
design
database
resembles
a
hierarchically
structured
a
serves
“electronic
reposi
filing cabinet,”
ALU
an
tory of a design information. A subpart of design (e.g.,
is
of
of
the
Path
of
the
a Microprocessor)
ALU
Data
slice
concurrent
that
no
checked—out for design activity in such a way
and
29
as
centralized
is
designer
contain
on
any of its
mechanism is based
working
it.
The
subparts,
on
nor
on
parts
any
hierarchical
locks
that
with
intentions. Designers can work in parallel as long as they are in
the
parallel subtrees of
When
a
design
hierarchy
KATZ82a]
design part is successfully checked out, the data associated with
.
it
is
loaded
into
virtual
pulated directly by
data
memory
structures,
which
are
mani
the
applications program. The data structures
are
back
into
the
When
database.
periodically
checkpointed
the
through,
design
subpart is returned to the database (i.e.,
the locks are released). The system must
enforce
now
integrity
constraints
the
hierarchy and across equivalent representa
up
tions (e.g., has a
cell
its
now
of
box”
outgrown
“bounding
has
a
geometries?,
representation been invalidated by a design
change?).
the
updating the database directly, we avoid much of
entering and leaving a database system. Applications
is
programs have more knowledge about the design data and how it
to
be
manipulated, and thus provide special purpose data struc
its representation. The database system still
tures for
provides
the
sharable, centralized data repository, as well as a standard
By
not
overhead
of
interface
for
3.
Schema
for
choose
data
access.
Design
Data
Management
tables.
design with three types of
primitive and composite design
cell. Associated with
cell—id
is
cell~s
the
a
unique
name,
and
other
control information. The composition table
designer,
encodes the design hierarchy by
how
more
describing
primitive
cells
and
oriented
within
are
placed
higher—level composite
cells. Finally, the representation tables describe how
primitive
such
transistors
as
or
objects,
geometries, are placed within
cells. The details of the representation, as well as the encoding
of
orientations
and
placements, are determined by the programs
that use the representation. For
mask
are
example,
geometries
boxes assigned to specific layers and placed on a
as
represented
Cartesian grid.
We
The
4.
cell
Work
to
table
at
represent
describes
a
each
Wisconsin
just begun to undertake a research program in design
Currently underway is an effort to implement a
low—level database system based on System—R~s
The
RSS.
system,
called
WiSS
is being designed and
(Wisconsin
Storage
System)
Professor
David
DeWitt
and
a
implemented in conjunction with
group of students led by Tobin Lehman and Richard Simkin. It pro
vides facilities for sequential
B—tree
files,
indexes,
binary
links
(also implemented wih B—tree structures)
long records, and
file level versions.
We are using the system as a research vehi—
cle for a number of experimental projects in database management.
We
data
have
management.
,
,
30
are
The
the
than
a
features of
latter two.
single page.
data,
such
in
the
design
is
the
same
location
at
that
We
WiSS
most
Long
records
They
relevent
random
as
files.
access
record
and
that
and releases.
old versions of
the
ful
data
keep
of
legal
Since
it
is
It
for
Alternatives
possible to seek to any
of
data
any length
should
system
the
support
design environment,
on—line
versions,
it
is
use
for
reference.
Further,
requirements, old released versions cannot be
is not feasible to keep all versions on—line,
provide facilities for
encoding
differentially
are
hypothetical
designs,
must
system
mechanisms
longer
non—traditional
handle
read/write
to
In
the
management
much
are
text and rasterized
images, that frequently arise
environment.
Our model of access for long
records
strongly believe
because
which
as
within the
location.
destroyed.
data
design
to
those
to
meant
are
alternatives,
to
are
archive
old
and
restore,
on—line
and
versions.
and are implemented as
hypothetical databases STON8O, STON81]. System generated
surro
used to identify records across versions. An implemen
are
gates
tation
of
is
gates
differential
described
in
files
based
KATZ82b]
on
B—tree
indexes
surro
over
addition, we have been inves
tigating how optical digital disk technology can be used for ver
sion management
(similar work appears in SVOB81]).
5.
In
.
Work
Future
WiSS
is
for
the
essentially an access method with some features use
environment.
We
intend to build DAVID, a
design
will
DAVID
design management system, on top of it.
con
keep
sistent a design~s multiple representations and design hierarchy.
It has been structured to keep small that part of the system that
is
to VLSI design.
It should be possible to use DAVID
specific
for other design domains, as long as
the
are
objects
designed
hierarchically.
ful
We
also
are
“server”
base
Again,
Design
paradigm
a
parts
“on—reserve”
“held”
6.
examining
within
for
a
are
a
the
local
role
of
network
related
to
a
checked out and
a
centralized
of
designer
design
data
workstations.
library
later
appropriate.
appears
returned. They can be put
(read ible, but not
updatable).
designer if already checked out
They
to
can
someone
also
be
else.
Conclusions
The
needs
for
design automation community has real
design
facilities, many of which are not currently supported
for
data
by state—of—the—art database systems. A fruitful area
base
research
will
be
to
how
database systems can be
study
extended to fit into this new environment, providing
the
needed
with a reasonable (and hopefully small) additional
functionality
management
overhead.
31
7.
References
GRAY78]
Gray,
“Notes
J.,
Systems
Graham,
Seegmuller,
GUTT82]
G.
Guttman,
A.,
Database
on
Operating
—-
M.
R.
Operating
Advanced
An
eds.,
Course
Springer—Verlag,
in
Systems,”
R.
Bayer,
N.Y.,
R.
M.
1978.
Relational
a
“Using
Computer Aided Design Data,”
Stonebraker,
Database
Management System for
Database
Engineering Newsletter,
this
issue.
for
VLSI
KATZ82a] Katz, R. H., “A Database
Approach
Managing
Data,” 19th Design Automation Conference, Las Vegas,
Design
(June 1982).
NV,
KATZ82b]
for
Structures
Lehman, “Storage
Alternatives,”
Working Paper in progress,
Katz,
sions
R.
and
H.,
T.
Ver
(Mar.
1982).
MEAD9O]
Mead,
C.,
Conway,
L.
Introduction
Addison—Wesley, Reading, MA.,
STON8O]
to
VLSI
Systems
1980.
Stonebraker,
Knowledge
tem,” Proc.
M.
K.
R.,
Keller,
“Embedding
Expert
Hypothetical Data Bases into a Data Base Sys
ACM SIGMOD Conference, Santa
Monica,
CA,
(May
and
1980).
STON81]
Stonebraker,
ACM
Proc.
SVOB81]
for
SIGMOD
Svobodova,
a
as
Views,”
“Hypothetical Databases
Ann
Conference,
Arbor, MI, (May 1981).
M.
L.,
Distributed
Operating
Systems
R.,
“A
Reliable
Object—Oriented
Repository
Computer System,” Proc. 8th Symposium on
Pacific
Principles,
CA,
Grove,
(Dec.
1981).
32
ANNOUNCING
The 3rd
SPONSORED BY
International
Conference
~1jEEE COMPUTER S0CIE~Y
on
THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, INC
DISTRI BUTED
COMPUTING
SYSTEMS
in
Cooperation with
Processing
Society of Japan (IPSJ)
Information
Institut National de
et en
Miami/Ft. Lauderdale, Florida
en lnformatique
Automatique (INRIA)
Recherche
October 18-22, 1982
•
SCOPE
The scope of this conference encompasses the technical aspects of specifying, designing, implementing, and
evaluating distributed computing systems. In such systems, there is a multiplicity of interconnected processing
resources able to cooperate under system-wide control on a single problem, often with minimal reliance on
centralized procedures, data, or hardware. The location of computing resources may span the spectrum from
physical adjacency to geographical dispersion. The topics of interest include the following aspects of distributed
computing systems:
El
El
El
El
El
SYSTEM AND HARDWARE ARCHITECTURE,
INCLUDING SIMD
DECENTRALIZED CONTROL, EXECUTIVES,
AND OPERATING SYSTEMS
DISTRIBUTED DATABASES
LI
LOGICAL AND PHYSICAL
INTERCONNECTION NETWORKS
SOFTWARE ENGINEERING AND
PROGRAMMING LANGUAGES
El
The conference will include technical
General Chairman
H. J.
Siegel
Purdue Univ.
School of EE
West Lafayette, IN 47907
Program Chairman
Carl G. Davis
Ballistic Missile
Defense Advanced
Technology Center
Tutorial Chairman
K. H. Kim
Univ. of South Florida
Exhibits Chairman
Edith W. Martin
Deputy Undersec. of Def. (Res. &
Adv. Tech.), Pentagon, Rm 3E 114
Washington, D.C. 20301
Standing Committee Chairman
Charles R. Vick
Auburn Univ.
Awards Chairman
T. Y. Feng
Ohio State Univ.
Treasurer
Duncan H. Lawrie
Univ. Illinois~ Urbana
Local Arrangements
H. Troy Nagle, Jr.
Auburn Univ.
Publications Chairman
Ben Wah
Purdue Univ.
Professional Societies Liaison
S. Diane Smith
Univ. Wisc. Madison
Publicity Chairman
Bill Buckles
Univ. Texas Arlington
SURVIVABILITY, RELIABILITY,
AND FAULT
TOLERANCE
El
SPECIFICATION, VERIFICATION,
AND
VALIDATION
El
DESIGN METHODOLOGIES
VLSI-BASED SYSTEMS
El
El
ANALYSIS, MODELING, AND MEASUREMENT
El
APPLICATIONS, INCLUDING SIMULATION
COMPUTER COMMUNICATION
presentations, panel discussions,
tutorials & exhibits.
TUTORIALS
Complementing the Conference there will be two full days set aside for
tutorials. The following have been tentatively selected:
“Pragmatic View of Distributed Processing,” by Ken Thurber
“Microcomputer Networks,” by Harvey Freeman
“Fault-Tolerant Computing,” by Vic Nelson and Bill Carroll
“Decentralized Control,” by Bob Larson, Paul McEntire and John O’Reiley
PROGRAM COMMITTEE
John Musa
(Bell Labs)
Chong Nam (Systems
Control, Inc.)
c. V.
Ramamoorlhy
(UC/Berkeley(
Azriel Rosenfeld
Lana Kartashev
(U. Maryland)
(U. Nebraska)
Jack Lipovski (U. TexasAustin)
Mike Liu (Ohio State U.)
Chairpeople
Kerrter, Austria
C. M. Woodside, Canada
Paul Pearson, England
Gerard Le Lann, France
Herbert Weber, Germany
Helmut
Steve Smollar (Schlum
berger-Doll Research
Joe Urban (U. Soulh
western
La.)
CONFERENCE LOCATION
Mariagiovanna Sami, Italy
Hideo Aiso, Japan
Diplomat
J. Wilmink, Netherlands
R. C. 1. Lee, Taiwan
airport at Miami. Beachfront
with tennis, golf, swimming,
Leah J.
Siegel,
Florida
by
Hotel in
near
shopping,
U.S.A.
Additional Program Committee Members will be chosen
• — —
Bhargava
(U. Pittsburgh).
Doug DeGroot (IBM)
Clarence Giese (Dept.
of Army AIRMICS)
Bob Heath (U. Kentucky(
Vic Nelson (Auburn U.)
Peter Ng (U. MissOuri(
Dan Siewiorek (CarnegieMellon U.)
Harold Stone (U. Mass.)
Ken Thurber (Architecture
Tech. Corp.)
Larry Wiftie (SUNY/Buff.)
Ken Batcher (Goodyear)
Mapping Agency)
International Associate
Bharat
(Systems
Development Corp.)
Bill McDonald
Bob Arnold (Honeywell)
Geneva Belford (U. Ill.)
Bill Carroll (U. Texas-Arlington)
Glenn Cox (General
Research Corp.)
Barry Gilbert (Mayo Clinic)
J. C. Huang (U. of Houston)
Robert Keller (U. Utah)
Annette Krygiel (Defense
the International Associate
Hollywood,
the international
and
resort
boating.
Chairpeople.
_._ ___________ — — na__a
If you wish to receive
a
copy of the Advance
Program for the Third International Conference on Distributed
to: Harry Hayman, IEEE Computer Society, 1109 Spring
Computing Systems, clip and mail this coupon
Street, Suite 201, Silver Spring, MD 20910.
.
NAME
EMPLOYER
______________________________
______________________________
STREET
.
__________________________________
CITY
STATE
__________________________________
COUNTRY
ZIP
_____________
______________
______________
_____________