design process planning and management for cad … f. jacome carnegie mellon university pittsburgh,...

CARNEGIE MELLON UNIVERSITY

Design Process Planning and Management for CAD Frameworks*

A DISSERTATIONSUBMITTED TO THE GRADUATE SCHOOL

IN PARTIAL FULFILLMENT OF THE REQUIREMENTS

for the degree of

DOCTOR OF PHILOSOPHYin

Electrical and Computer Engineering

by

Margarida F. Jacome

Carnegie Mellon UniversityPittsburgh, Pennsylvania

September, 1993

* This work has been supported by the Engineering Design Research Center, an NSF Engineering Research Cen-ter.

Page ii

Abstract

This research addresses the realization of a new abstraction level for CAD Frameworks, the

problem level, aimed at supporting design process planning and management services in CAD

Frameworks. This objective has been achieved trough the development of a formal theory of

design for describing design processes; the development of a paradigm for design process

planning and management that properly accommodates all real world agents and resources

cooperating in the design activity; the development of a domain independent, and heuristically

and epistemologically adequate general representation of the design space based on the pro-

posed design formal theory, and in the proposed design process planning and management

paradigm; and finally in the modelling of design processes as a problem solving activity

developed in a design space defined by the previous design space representation. A design

process planning and management system, called Minerva, that realizes the problem level in

CAD Frameworks was implemented.

Page iii

Acknowledgments

There are many people who have helped make this dissertation a reality. First, I am very grate-

ful to my advisor, Steve Director, for his guidance, encouragement and willingness to explore

new ideas. Steve was always a source of insightful advice and I learned immensely from him.

I doubt I could find another advisor anywhere with whom I could maintain a better working

relationship.

I would like to thank my other thesis committee members, Chris Hendrickson, Rob Rutenbar

and Herb Simon. Herb Simon followed my work closely, discussed my ideas, provided many

insightful comments and suggestions, and opened my research interests to a variety of chal-

lenging topics and issues. I am thankful that I had the opportunity to get to know and to learn

with such a fascinating and complete person as Herb Simon. Chris Hendrickson also followed

my work closely and was a tremendous source of advice and encouragement. Chris was

always probing the boundaries of my research, leading me to focus on the relevant issues, and

helped me to clarify some of my claims in this research. Rob Rutenbar carefully reviewed this

dissertation and provided me with very useful feedback on my work.

Page iv

I would especially like to thank IBM, particularly Dan Cotrell, for their interest in this

research from its very initial phase. Their intellectual support added to my motivation and

helped me during the more difficult and challenging moments of this research.

Back in Portugal, I would like to thank IST and INESC, particularly Luis Vidigal, for their

continuous support throughout these years.

A very special thanks goes to Peter Feldmann and Tony Leal for many exciting technical dis-

cussions during my first years as a graduate student in CMU. I was really fortunate in having

them as colleagues and friends. A special thanks is also due to Terence Chang and Juan Carlos

Lopez. Terence implemented the User Interface I designed for Minerva. Juan Carlos helped

me with the code of Minerva’s message parser and also helped me a great deal by executing

various Minerva’s design plans using the OCT tools.

I would also like to thank my office-mate, Kannan Krishna, for his helpful comments and sug-

gestions on this thesis, and also for many refreshing discussions on philosophy, music and

poetry. I also would like to thank my two closest colleagues in the CAD Framework’s research

group in CMU, Jay Brockmann and Tom Cobourn, for many interesting conversations.

Besides the friends I already mentioned, many others contributed to make this years of gradu-

ate school an enjoyable experience. I would specially like to mention Roxana Feldmann, Joao

Costeira, Carlos Bispo, Ana Pereira, Marquet Anderson, Samir Naik, Becky Lott, Peter Sut-

ton, and Jennifer Braun.

A very special thanks goes to my family, and particularly to my parents, Maria Teresa and

Luis, for their guidance, encouragement, and for their unconditional love and support. And of

course my biggest thanks goes to my husband, Eduardo, for his love, endless patience, and for

making me a more complete person and my life a more meaningful one.

Page v

Dedication

This dissertation is dedicated to my mother, Maria Teresa.

1

Table of Contents

CHAPTER 1 Introduction 31.1 Research Contributions 7

1.2 Outline of Dissertation 8

CHAPTER 2 Characterization of the Design Space 92.1 Controlling design complexity by adequately formulating and structuring design

problems 11

2.2 Generation and test design operators. Design plans. 14

2.3 Control knowledge 15

2.4 Example: Digital VLSI Design Space 15

CHAPTER 3 A Paradigm for Design Process Planning andManagement 17

3.1 Introduction 17

3.2 Predictability and Knowledge Completeness in Design 17

3.3 Coordinating the Design Activity 19

3.4 A Paradigm for Design Process Planning and Management 22

CHAPTER 4 A Formal Theory of Design 274.1 Introduction 27

4.2 Design Hierarchy 284.2.1 Design Objects and Properties 284.2.2 The Syntax of the Design Hierarchy 314.2.3 The Semantics of the Design Hierarchy 364.2.4 Deriving a Design Hierarchy for a Design Discipline 38

4.3 A Taxonomy of Abstract Specifications 444.3.1 Realization-driven design processes 474.3.2 Behavior-driven design processes 484.3.3 Defining Functional and Structural Design Object Decomposition 504.3.4 Taxonomy of abstract specifications 554.3.5 Models and Behavioral Descriptions 614.3.6 Example 62

4.4 Design Processes 634.4.1 Consistency Constraints 634.4.2 Constraint reasoning 654.4.3 A high-level view of design processes 674.4.4 Representing design processes and projects 71

4.5 Discussion of the applicability of the proposed theory of design 84

2

4.6 The Y-Chart 85

4.7 Closing Comments 88

CHAPTER 5 Design Space Representation 895.1 Introduction 89

5.2 Knowledge level structure of a design space 905.2.1 Defining Design Hierarchy. 905.2.2 Design Objective Templates 955.2.3 Knowledge Structures for defining Abstract Specifications and Abstract Consistency

Constraints 106

5.3 Representing Design Processes 1115.3.1 Design Domain Instances and Facet Instances 1125.3.2 Organization of Design Domain and Facet Instances in a Design Process 1135.3.3 Active Design Objectives or Objective Instances 1145.3.4 Organization of Objective Instances in a Design Process 1155.3.5 Property Instances and Active Consistency Constraints 1165.3.6 Organization of Design Issues Instances in a Design Process 1175.3.7 Canonical Properties, Requirement Instances and, Consistency Constraints 1185.3.8 Organization of Canonical Properties, Requirements and Consistency Constraint Instances

in a Design Process 119

5.4 Relating All Organizations in the Design Process: sn and S+ 120

5.5 Discussing Some Snapshots of Design Processes 1215.5.1 Transformational Synthesis 1225.5.2 Structural or Functional Decomposition 1235.5.3 Recomposition 1245.5.4 Built in Primitive Actions 126

5.6 Design History 127

5.7 Conclusions 128

CHAPTER 6 Minerva 1296.1 Minerva Prototype 129

6.2 Integration Issues 150

6.3 Evaluation Issues 152

CHAPTER 7 Conclusions and Future Work 1577.1 Main Contributions 157

7.2 Future Work 1577.2.1 Continuity Issues 1577.2.2 New Topics in CAD Frameworks 158

APPENDIX A An operator’s scenario for VLSI digital circuits 161

3

CHAPTER 1 Introduction

In the early days of CAD, the primary goal of the CAD researcher was to develop CADtools for addressing each possible synthesis, analysis and optimization design problem andto enhance problem-solving capabilities of existing CAD tools. During this time, very littleattention was given to the environment in which CAD tools were to be used. Thus, designersoften spent considerable time learning tool specific languages for representing input andoutput data and command languages for controlling tools. Since each tool typically used itsown language for representing data, executing different tools in the same piece of datawould typically require cumbersome and error prone data translations.

With the increasing complexity of designs, as well as with the significant increase in thenumber of tools involved in the design process, the need for creating sensibledesign envi-ronmentsbecame clear. Designers were wasting far too much time in tool “impedance”adjustments, as well as showing some resistance to constantly learning the usage of newtools. This marked the beginning of a new CAD discipline, which has become known asCAD Frameworks.

The original goal of those working in the area of CAD Frameworks discipline was verystraightforward and pragmatic: to develop CAD environments which would provide design-ers with services aimed at making the set of CAD resources used in their design activity,including CAD tools, libraries, and databases,convenientto use. CAD Framework technol-ogy would also provide an adequate platform for integrating diverse CAD resources in theseCAD environments. To achieve this original goal, current CAD Frameworks typically pro-vide CAD resources, particularly CAD Tools, with anencapsulation which implements a“standard” interface of the specific resource to the framework. Such encapsulations basi-cally represent the tool input and output data and also the tool control command language interms of an intermediate (tool-independent) format. By doing so, the specifics of each par-ticular resource are “hidden” in the encapsulation. Tools can now directly communicatetowards the framework. At this point, recognizing the importance of creating adequatedesign environments, the industry created the CAD Framework Initiative (CFI), [1] aimed atdeveloping industry guidelines and standards for CAD Frameworks.

After having conceived and developed such fundamental services, and again motivated bythe increasing complexity of design processes, more ambitious goals started being pursuedby researchers in the CAD Framework community. Indeed, the set of “resource oriented”basic services provided by CAD Frameworks had become significantly insufficient to dealwith the emerging challenges of design, such asconcurrent design, where several designers,sometimes in physically distant locations, work simultaneously on different parts of thesame design problem. The main goal of the CAD Framework researchers changed then from

Introduction

4

“making resources convenient to use” to attempting to“actively assist designers during thedesign process”.

The first main outcome of this new phase in CAD Frameworks research was the introduc-tion of the concept ofCAD tasks. CAD Tasks implementabstractions of design functionsoractivities, in the sense that they relate together the tools and data needed to execute a givendesign function. CAD Tasks can, thus, be viewed as the operatorsof a design environment.

In most cases, CAD tasks have been defined in terms of the tools that will be used to executethem. On the other hand, some frameworks [2][3] exploit the more abstract view ofresources provided by the encapsulation and, thus, define CAD tasks independently of theparticular tools that may be used for the task execution. We refer to the first approach as“early binding” and the second approach as “late binding”. Decoupling of CAD Tasks fromCAD tools, ultimately supported by the encapsulations, allows a very convenient and finalabstract separation between the changeable and arbitrary world of CAD resources and theworld perceived by the designer that is based on “CAD Tasks”.1

In order to deal with the problem of maintaining data consistency throughout design pro-cesses, most state-of-the-art CAD Frameworks provide data versioning services. Someframeworks go further and provide design history services, which record interdependenciesamong pieces of data and tools used to generate these pieces of data during task executions[4] [5]. In both cases a browsing mechanism allows the designer to inspect data objectsbased on filters such as “give me all data objects associated with this particular data entity,generated by executing this particular CAD task.” Filters, such as keywords and date, arealso allowed. Such “history” records are basically aimed at helping the designer in selectingadequate pieces of design data during design processes.

Finally, most state-of-the-art CAD frameworks also allow composition of CAD tasks interms ofdesign flows. Design flows may be thought of as a directed graphs in which thenodes are CAD tasks and the arrows define the flow of action.2 Some implementations allowsophisticated control mechanisms such as decision points with branching and conditionalloops.[7]

1. Note that the notion of CAD Task with late binding leads to the need for encapsulating not onlytools, but actual data as well. Encapsulating data means representing it in a intermediate format.By doing so, all resources (data and tools) available to the framework can be syntactically definedin a consistent way.

2. Some “flows” are built differently, for instance, by having a complex and extensive depen-dency graph, and by allowing designers to “instantiate” for execution just the particular sub-graphof this graph needed for accomplishing a specific task. [6] This constitutes a variant of the generalmethod for defining a flow.

5

In summary, the services provided by state-of-the-art CAD frameworks include: (1) user-friendly operators (CAD Tasks) andmacro-operators (design flows), aimed at assisting theexecution of design activities; (2)databases, to store the data resulting from such activities;(3) and browsing mechanisms on these databases, using more or less sophisticated filtermechanisms, in order to help the designer to select the pieces of data to be assigned to thenext CAD Task and, thus, proceed with the design process.

In short, current state-of-the-art CAD Frameworks areexecutive systems able to executedesign plans, i.e., partially ordered sequences of CAD Tasks. Odyssey, a general purposeCAD Framework [2] under development in CMU, provides most of the functionality previ-ously described, constituting one of most well structured executive systems developed sofar. The executive component of the Odyssey CAD Framework is made up of the Cyclopsresource manager [8], which is responsible for encapsulating tools and data, and the Her-cules task manager, [4] which is responsible for executing CAD Tasks and design flows, andfor implementing the design history browsing mechanisms. IFDF, [3] another general pur-pose CAD framework under development at CMU, also implements CAD tasks and designflows. IFDF was first applied to the facility development process. Note that the designationof “problem-oriented approach” used by the IFDF authors was basically chosen so as toclearly distinguish this approach from the so called “activity view” of traditional methodsused to represent facility development design processes, such as CPM.1

The functionality achieved by recently developed CAD Frameworks is certainly a signifi-cant achievement compared to the direct usage of tools in the early days. However, we findthe frequently made claims that design flows constitute “the” needed support for design pro-cess management to be questionable. It is important to note that in such design flowapproaches designers are the ones ultimately responsible for properly planning and manag-ing the design process. Nothing in these CAD Frameworks really prevents designers from,say, executing a design flow with a non-updated piece of data. Furthermore, nothing in theseCAD Frameworks prevents designers from backtracking improperly, by choosing wrong,incompatible data objects. Moreover, nothing in these CAD Frameworks prevents designersfrom making design decisions that are inconsistent with each other. The reason for this situ-ation is that there is no high level, conceptual, notion of consistency in the “design processmodel,” or even the very basic notion of “current state” of the design process. What exists isa predefined set of CAD tasks that should be executed in a given order. A final, though webelieve quite decisive, argument demonstrating the inadequacy of flow-based approachesfor representing design processes is their acknowledged failure in modeling and properly

1. It is important to note that, in IFDF, tasks and problems are equivalent concepts. Accordingly,in IFDF, problem decomposition is defined as being the set of tasks that have to be achieved tosolve the overall problem. A specific task hierarchy is supposed to reside in the system, explicitlydescribing a number of possible decompositions of the facility development process. Each ofthese decompositions constitutes anhardcoded task hierarchy. Note that this definition of “prob-lem decomposition” is totally equivalent to the traditional definition of a design flow.

Introduction

6

dealing with design hierarchy, due to their inherently “flat” nature.1 So, the above severeand fundamental limitations on the ability of state-if-the-art CAD Frameworks to providedesign process planning and management services clearly indicate that the concept of adesign process goes far beyond the concept of a design flow.

Let us use an analogy to better illustrate our point. Let us suppose Luis is in a given city, sayLisbon, at location A. And let us also suppose Luis wants to travel from location A (hishotel) to location B. We have two forms of attacking this problem. The first solution is toprovide Luis with a list of instructions, of the type:

1.From location A, move straight, about 500 feet. As soon as you see a red schoolbuilding on your left, turn immediately right. If the particular road is closed go to 10.

2. Keep moving straight. On the third light, turn left. If the particular road is closed goto 20.

3. etc.

A different strategy would be to provide Luis with a map of Lisbon, which sets the context,and teach him how to navigate using a map, in other words supply him with control knowl-edge.

It is a fact that Luis may reach his final destination using any of the two above strategies.Yet, there are fundamental differences between them. In the first case, Luis does not knowwhere he is, during the whole trip, since he does not have any idea of the layout of the cityhe is travelling in. He is just ‘blindly’ following instructions. So, if any event not predictedin his particular set of instructions occurs, Luis will have no means to ‘improvise’ a differentroute. In the second case, Luis can just re-plan a different itinerary, using his map and hisability to navigate using a map. An even more interesting difference between both strategiescan be observed if, during the following day, Luis needs to go, still from location A, hishotel, to location D, a different place from the previous day. In the first case, Luis needs anew set of instructions. Note that even if both sets of instructions have similar parts, Luishas no means to know it up front. In the second case, Luis is ready to go! Finally, let usassume Luis travels to a different city. If he is using the second strategy, the only thing hereally needs in order to be able to travel to any location in the new city is a map of the city,since he already knows how to navigate using maps. In the first case, though, he will need toask for lists of directions, again, and again, and again.

Design flows are similar to lists of directions, or navigation actions. What we propose is todevelop a framework that can navigate using a given map, i.e., using knowledge about aspecific design discipline.

1. Design hierarchy is generated, for instance, when a given design object is decomposed into aset of sub-objects or components.

Research Contributions

7

In this work we characterize and describe the design process as a problem solving activitythat takes place in a well definedproblem space. A problem space is a knowledge levelabstraction containing:

• mechanisms for symbolically representing, and keeping track of, initial, intermediate,and finalproblem states; and

• mechanisms for defining and representing general categories of problems, in terms ofthe concepts and of the control knowledge employed in their solution processes, aswell as the operators used during the problem solving process to properly modify thesymbol structures which describe the problem situation.

We call a problem space defined for a design problem adesign space and a problem state ina design space is called adesign state. The design state includes, among other things, thedesign problem specification, i.e., the set of properties that should be verified by the designobject; and the design data, i.e., the set of all design object representations developed so farin the design process.1

1.1 Research Contributions

The objective of our research is to develop design process planning and management facili-ties that can be used by CAD Frameworks. As will be seen below, this objective has beenachieved through the:

1. development of a formal theory of design for describing design processes. This theoryis general enough for describing a variety of design processes from distinct design dis-ciplines, not only the VLSI circuit design process;

2. development of a paradigm for design process planning and management that properlyaccommodates all real world design agents2 and resources cooperating in the designactivity;

1. This is just a sub-set of the elements represented in the design state. In Chapter 4 we formallydefine design space and design state.

2. Design agents are active entities capable of making decisions that directly or indirectly impactthe current design state.

Introduction

8

3. development of adomain independent1 andheuristically and epistemologically ade-quate2 general representation of the design space based on our formal theory of designand on our design process planning and management paradigm;

4. modeling of design processes as a problem solving activity taking place in the previ-ous design space;

5. realization of a new abstraction layer for general purpose CAD Frameworks, called theproblem level, that supports design process planning and management services, basedon our model of the design activity.

Since our contribution is applicable to design processes in general,3 in what follows, when-ever possible we will give examples of several design disciplines, such as VLSI digitaldesign, VLSI analog design, automobile design, and constructions design.

1.2 Outline of Dissertation

In the next chapter we discuss some of the important characteristics of the design spaces thatare implicitly defined by human designers while performing design. In Chapter 3 wedescribe our paradigm for design process planning and management. In Chapter 4 wedevelop a formal theory of design for describing design processes. In Chapter 5, a knowl-edge level and data level structure of a design space is proposed that properly expresses thedesign theory in the context of the proposed design process planning and management para-digm. Chapter 6 discusses Minerva, a design process planning and management system, tobe integrated in general purpose CAD Frameworks, that directly implements the proposedknowledge and data level structures of a design space. Finally, Chapter 7 presents conclu-sions and future work.

1. A domain independent representation is one that does not contain embedded or hardcodeddomain dependant knowledge but, rather, allows for inclusion of such knowledge for each con-text.

2. meaning to derive a design space representation rich enough (epistemology adequacy) thatmany interesting domains could be properly represented, but this goal was always measuredagainst the ability to deal with representations efficiently (heuristic adequacy).

3. We will discuss the conditions of applicability of our work in Chapter 4.

9

CHAPTER 2 Characterization of theDesign Space

One of our fundamental research goals is to develop a general model of the designspace. This chapter discusses some of the important characteristics of design spaces thatare implicitly defined by human designers while performing design. We also introducesome basic concepts and terminology from the problem solving discipline.

Solving a design problem can generally be viewed as a search in a very large space forobjects which satisfy a set of constraints. Each point in this space reflects a possible can-didate solution to the design problem that realizes a particular trade-off between designcharacteristics or metrics.1 We refer to this space as thesolution space. The total compu-tational effort for generating a solution and evaluating it can be extremely large, and,therefore, searching the entire solution space for the best design is impractical. Further-more, the huge number of design decisions that typically have to be made during thedesign processes and the complex interdependencies that can be found among some ofthese decisions make design a very complex problem-solving activity.

During the design process,2 complexity is typically controlled by making use ofheuris-tic knowledge, or justheuristics. Heuristics are simplified criteria, methods, principles,or simply rules of thumb, that may be derived from first principles or may simply resultfrom intensive experience in dealing with similar problems.[9] Two broad categories ofheuristic knowledge are typically used in design, as it will be explained next.

The first type of heuristic knowledge is used for derivingconvenient problem formula-tions for a given design discipline. It is well known that properly formulating and repre-senting problems is key to any efficient problem-solving process. So, to better deal withdesign complexity, designers typically employ heuristic-based methods for adequatelyformulating and structuring design problems. Let us briefly illustrate the advantages of aconvenient heuristic-based problem formulation, using as example the VLSI digital cir-cuits discipline. Note that the very concept of a digital circuit with its two valued inputsand outputs, is itself heuristic in nature, since it only holds for certain specific condi-tions. Yet, the inherent simplicity and the adequacy of this representation allows designproblems of huge dimensions to be very straightforwardly addressed in the discipline.3

Section 2.1 discusses in some more detail the main techniques typically used for deriv-

1. For the disciplines of VLSI analog and digital design, examples of such metrics are area andpower consumption.

2. As in many other problem-solving domains.

Characterization of the Design Space

10

ing convenient formulation and structuring for design problems for a broad variety ofdesign disciplines.

After employing adequate heuristic-based problem formulations, designers then controlcomplexity during the problem solving process through the use of a second type of heu-ristic knowledge, which in this case is aimed at efficiently pruning the solution space,thus making the process of search for candidate solutions practical. This class of heuris-tic knowledge is often calledconceptual design knowledge. Examples of conceptualdesign knowledge, for the VLSI digital domain of problems are: understanding thespeed-area trade-off between ripple-carry, carry-save, and lookahead adder, or knowingthat unbuffered dynamic latches are particularly susceptible to induced switching noiseon their output.

Dewey [10] addresses in some detail the key role played by conceptual design knowl-edge in VLSI digital design processes and proposes a general methodology for organiz-ing and using conceptual design knowledge during VLSI digital design processes. In thedomain of VLSI analog design, [11] proposes the use of predefined circuit topologies fortargeting specific regions of the solution space, referring to this conceptual designknowledge as “style selection knowledge”.

The design process ends when a plausible design solution is found that satisfies all of thedesign criteria or specifications of satisfactory performance.1 Note that the goal ofdesign is not necessarily to find a design object that, besides satisfying an established setof criteria, also possesses qualities unmatched by any other design object in the space ofcandidate solutions, but instead is to discover anyqualified object with as little searcheffort as possible. This means that the designer’s goal is not to find theoptimal designsolution but to find asatisficing solution.[12]

The remainder of this chapter is organized as follows. After discussing general tech-niques used for formulating and structuring design problems, we will discuss the opera-tors typically contained in design spaces. We then discuss the role of control knowledgein design processes and introduce a definition for design methodology. We conclude bypresenting an example of real world design space. In Chapter 4 we will propose aDesign Theory that formally defines all concepts informally introduced and discussed inthis section.

3. A possible metric for problem complexity in the VLSI design general discipline is the totalnumber of transistors.

1. Notice that traditional engineering methods make much more use of inequalities than of max-ima and minima. So called “figures of merit” permit comparison among solutions in terms of“better” and “worse” but seldom provide a judgement of “best”. [12]

Controlling design complexity by adequately formulating and structuring design

11

2.1 Controlling design complexity by adequately formulating and structuringdesign problems

A very general and powerful method for increasing search efficiency and decreasingdesign complexity isproblem decomposition, in which the original problem is reformu-lated in terms of an arbitrary number of less complex sub-problems. In other words, theproblem space in which the original design problem was formulated is decomposed intoa number of smaller sub-problem spaces, each of which corresponds to a sub-problem.This is sometimes called in the literature as the “divide-to-conquer” strategy. It is impor-tant to note that design problems are generally of the nearly decomposable type, [12]meaning that it may not be possible to completely ignore the interrelations among thesub-problems.

Two types of problem decomposition are employed in design. One type occurs when acomplex design activity associated with a given design object is decomposed intosmaller sub-activities associated with the exact same design object. A trivial example ofthis type of decomposition is when a designer decides to undertake the complex and glo-bal design activity in terms of the less complex synthesis, verification and optimizationsub-activities.

A more elaborate and extremely effective version of this type of decomposition is towork at different levels of abstraction with the fully detailed problem space representedin terms of a hierarchy of abstraction spacesin which successive finer levels of detailare introduced [13]. An abstraction space is a simplified representation of the fullydetailed problem space, where unimportant details are ignored.

By considering details only when a solution in the higher level space gives strong evi-dence of being plausible, a heuristic search process investigates a greatly reduced por-tion of the solutions space. Heuristics for pruning the solution space are typicallydeveloped for each of these abstraction levels. Deriving good heuristics for the higherlevels of abstraction of design is absolutely crucial, since great effort can be wasted indeveloping solutions that have no chance of ever meeting the performance requirementsdue to poorly made high level decisions. Accordingly, design is indeed frequentlydefined in the literature as an incremental translation/transformation process from a highlevel abstract description of a given design object into a lower level description of thesame object. By higher level description, we mean a description that hides some level ofdetail from the designer and not just a textual equivalent of the lower level description.Figure 1 illustrates the unidimensionaldesign hierarchy that might be created by decom-posing a given design problem into an ordered set of sub-problems, one defined for eachof the abstraction levels defined for the discipline.


12

A second type of problem decomposition occurs when the original system to bedesigned is itself decomposed into subsystems, in which each subsystem performs a par-ticular sub-function of the overall function. For example, the design of a datapath, in thedomain of VLSI design, is typically decomposed into the design of an arithmetic andlogic unit, registers, multiplexers, and a control unit. Also, the design of an automobileis typically decomposed into the design of the body, the chassis, the engine, and thetransmission. We will call this type of problem decomposition asdesign object decom-position.

Since there is always some form of interrelation among possible sub-components, vari-ous decomposition or “cut” criteria can potentially be used. However, in some domains,such as automobile design, effective decompositors are known, and little search needs tobe conducted at the level of selecting adequate problem decompositions. In other words,even if several automobile components need substantial modifications due to majortechnological changes, the basic decomposition may not change. In order to be effective,the decomposition process needs two kinds of additional information: how the con-straints on the original problem are to be translated into constraints on each of the sub-problems and how to recompose the design objects that result from the solution of eachof the subproblems into the final design object.

Repeated applications of decomposition knowledge also produce design hierarchies. Forinstance, a specific design hierarchy may be generated by decomposing a system into aset of components, and recursively decomposing these components into sub-compo-nents, until all resulting sub-components are small enough to manipulate. The two basicprinciples on which a well-structured hierarchy is founded aremodularity andlocality.Modularity requires that well-defined and unambiguous functional interfaces betweensub-components be kept throughout the abstraction levels. Locality implies that the

Abs

trac

tion

Object1.level1

Object1.level2

Object1.level3

FIGURE 1 Hierarchy of Abstract Design Representations

Abstraction level 1

Abstraction level 2

Abstraction level 3

Controlling design complexity by adequately formulating and structuring design

13

details outside a component are not important during the design of the interior of thesub-component.

FIGURE 2 Hierarchy of design sub-components

Obj1.SubObj2.lev

Obj1.SubObj3.lev

Obj1.SubObj4.lev

Obj3.SubObj5.lev

Obj3.SubObj6.levObj1.lev

FIGURE 3 Two-dimensional Design Hierarchy

Abs

trac

tion

Obj1.SubObj2.l1

Obj1.SubObj3.l1

Obj1.SubObj4.l1

Obj3.SubObj5.l1

Obj3.SubObj6.l1Obj1.l1

Obj1.SubObj2.l2

Obj1.SubObj3.l2

Obj1.SubObj4.l2

Obj3.SubObj5.l2



14

Figure 2 illustrates the unidimensional design hierarchy that might be created by apply-ing design object decomposition knowledge during a design process. Figure 3 illustratesthe generaltwo-dimensional design hierarchy that might be created during a design pro-cess, due to the use of abstraction and of design object decomposition knowledge,together.

Pre-compiled knowledge may be available prior to the start of the design process thatgreatly reduces the search in the design space. An extreme example of this is the socalled cell-based VLSI design style, where definitions of circuit elements that have beenpreviously proven to work are compiled in libraries and retrieved for reuse by thedesigners during the design process. Pre-compiled decomposition knowledge can alsobe extremely efficient in controlling search since the total search space becomes signifi-cantly smaller due to the fact that known decompositions represent a solution to a part ofthe problem.

2.2 Generation and test design operators. Design plans. 1

For most design disciplines, the use of the general techniques discussed above allowsthe derivation of adequate general formulation and representation schemes for designproblems and design states, respectively. During the design problem solving processes,the design state is modified until an acceptable solution is found. A problem solvingstep, or adesign step, is a transition between two different design states.

In general, design activity isexploratory andevolutionaryin nature, in the sense that inthe beginning of the design process the designer usually only has a vague idea of thesequence of design steps that need to be taken in order to realize an acceptable solutionto the design problem. Each design step in the design process involves the execution of adesign operator. 2 We will refer to the partially ordered sequence of operators that has tobe executed to realize an acceptable solution to the design problem as thedesign plan.

In a broad sense, the exploratory process of design can be viewed as a cycle ofgenera-tion andtest design steps, [12] respectively implemented by generation and test designoperators.

1. In Chapter 3 we provide formal definitions for design operators and design plans. The defini-tions given in this introductory chapter are only aimed at broadly introducing some basic termi-nology.

2. Design operators implement specific design functions. Note that at this point we are not mak-ing any strong assumption about the implementation nature of such operators. Actually, in realworld design environments, design operators may be implemented, at one extreme, by fully auto-mated CAD tools and, at the other extreme, as pencil-and-paper human designer activities.

Control knowledge

15

Generation operators create new representations for design objects or modify existingones. For instance, a generation operator may transform a register transfer level descrip-tion of a digital circuit into a logic level description of the same circuit, thus creating anew, more detailed, description or representation for the same design object. This is typ-ically called a synthesis step. A generation operator may also modify an existent repre-sentation of a design object, trying to maximize some cost function, yet not increasingthe level of detail of the design object representation. This is typically called an optimi-zation step.

Test operators are aimed at evaluating the consistency and/or correctness of design rep-resentations created by generation steps. For instance, a set of test steps can be per-formed to verify if a given digital circuit meets its specific requirements on functionality,speed and dissipated power.

2.3 Control knowledge

In problem solving, the information used to decide what to do next given a specific prob-lem state is calledcontrol knowledge. Traditionally, in the domain of design problems,control knowledge is characterized in terms ofdesign methodologies. In practical terms,a design methodology is a set of specific methods/procedures or more general directivesthat directly or indirectly enforce control decisions. In particular, design methodologiesare thus aimed at helping designers cope with the complexity of the design problem in asystematic way, by guiding them in deciding what action to perform next, given a spe-cific design state. We will give some examples of design methodologies applied to theVLSI domain of problems in the next section.

Design methodologies may vary significantly from one design environment to another,and even between designers in the same environment, reflecting such conditions as theavailability of CAD resources for the development of different products, or particularpreferences of designers in terms of tactics for attacking specific problems. Designmethodologies may also a priori restrict the solution space. The generality of a designmethodology is inversely proportional to the number of design decisions it enforces. Anexample of such “enforced decisions” is the layout style in the domain of VLSI design.The main reasons why methodologies enforce design decisions is either to make thedesign process more efficient, exactly tailored to the types of products that are expectedto be designed and/or due to limitations in the available design resources.1

2.4 Example: Digital VLSI Design Space

1. e.g., CAD tools


16

The domain of digital design is probably one of the design areas in which concepts suchas abstraction and design object decomposition have most effectively been exploited.Digital microelectronic circuits are designed to operate with two valued, or binary,inputs and outputs. Because these circuits require only two disjoint output voltageranges to function correctly, practical circuits exist that can function reliably over wideranges of voltages, currents, temperatures and process characteristics. A relatively smallnumber of basic digital circuits can be used as building blocks that realize highly com-plex digital systems. Examples of such building blocks are inverters, buffers, NOR,NAND and transmission gates. These building blocks can then be interconnected toform complex circuits such as microprocessors. The reason why abstraction and designobject decomposition have been so successfully exploited in digital design is becausethe principles of modularity and locality are sufficiently guaranteed for the set of digitalbuilding blocks.

The two most common design methodologies adopted by digital designers aretop-downandbottom-up. In a typical bottom-up design methodology the designer starts with basiccomponents (such as gates) and builds a structure (such as a cell) defines its function,and uses it hierarchically to build higher level structures. In a top-down design method-ology the designer may start by specifying a block diagram with the major subcompo-nents of the design. For a computer, these blocks may include processor, memory, input/output, etc. These blocks are usually described textually rather than via a formal lan-guage. Given these blocks, the designer derives the RLT (Register Transfer Level)description for each of the basic components, which consists of program like statementsdescribing the movement or processing of data between storage elements. After that, thedesigner may derive logic diagrams for the blocks described at higher levels. A logicdiagram contains well-defined logic functions, such as NAND gates and latches, whosedigital operation can be accurately described via Boolean logic. For some styles ofdesign, for example, gate array circuits, this is the lowest level of description requiredfrom a designer.

Introduction

17

CHAPTER 3 A Paradigm for DesignProcess Planning andManagement

3.1 Introduction

As discussed in Chapter 1, we proposed to model the design process as a problem solving activ-ity taking place in the context of a well-defined design space. It is important to note that design,and particularly concurrent design, is a distributed activity among a set ofdesign agents. Designagents are active entities capable of making decisions that directly or indirectly impact the cur-rent state of the design. Such design agents may have different roles in the decision-making pro-cess associated with the design activity and contribute in various forms to the evolution of thestate of the design. In order to perform their role, they may also use a wide variety of resources.In short, design agents are the active entities that own and know how to use the elements thatconstitute a design space.

So, in parallel with the characterization of the elements that constitute a generic design space,(viz. knowledge, data and resources) we also need to characterize the different types of designagents that actually use such elements to undertake the design processes. In other words, wealso need to devise a properparadigm for design process planning and management. Such aparadigm should include the characterization of the different types of design agents taking partin the design process, in terms of their roles in the process, and a specification of how they coop-erate.

Before proceeding, in the next section we discuss and clarify two important issues that impactthe development of a paradigm for design process planning and management.

3.2 Predictability and Knowledge Completeness in Design

Most design disciplines suffer fromincomplete knowledge. In other words, most design disci-plines lack well defined, generally applicable, solutions to their specific design problems. Thisleads to the use of heuristic knowledge in design. It is important to note that if any of the

assumptions that typically underly heuristic knowledge do not hold for a specific problem,1 theparticular problem solving method being used will fail. An illustration of this fact is that real

1. This may be difficult to verify up front for most cases.

A Paradigm for Design Process Planning and Management

18

world CAD tools, which implement problem solving operators, frequently fail and/or produceunsatisfactory results. Moreover, there are a large number of CAD tools that are interactive,relying on the designer’s intervention to properly complete a problem solving activity.

Incomplete knowledge coupled with the advances in the state-of-the-art of most design disci-plines and implementation technologies, bring new problems and new difficulties to the designarena, thereby preventing us from attempting to fully automate design unless we are dealingwith a very small design domain. Thus, while developing our design process planning and man-agement paradigm, we will not commit solely to either a full automated or an interactive designapproach. Having identified the currentdecision-making roleof the designer in design pro-cesses, we incorporated it in the paradigm as one specific category of design agents. Note thatthe current function performed by human designers in the design process is, thus, naturally inte-grated into the overall paradigm. In developing a software system that implements this para-digm, if the above design agent is realized by a fully automated software module, we will beimplementing automated design, otherwise, if such an agent is realized by an interactive modulethat interfaces with a human designer, we will be implementing interactive design.

The second issue that impacts the development of a paradigm for design process planning andmanagement is related to understanding the predictability of the design process. Observe that itis unrealistic to expect to be able to produce a fully detailed design plan (i.e., a partially orderedsequence of CAD tasks) during the planning phase of the design process and expect it executesuccessfully if the planning phase has been totally decoupled from the executive phase. In gen-eral, a plan generated in this way would probably be useless after the execution of the first cou-ple of operators, because the design process is far from being totally predictable. In other words,it is not realistic to generate design plans in “open loop,” i.e., with no feedback from the execu-tion space, for solving arbitrarily complex design problems. Note that a successful design planis a partially ordered sequence of CAD tasks that, when executed, generates an acceptable solu-tion to the design problem.

One reason for this lack of predictability is incomplete design knowledge. Another cause of thisnon-predictability is related to the design environment in that the designer often lacks controlover the immediate availability of design operators (i.e., CAD tools) in his own design environ-ment. Moreover, one of the most prominent specific factors leading to the lack of predictabilityin design consists of the designer’s lack of precise knowledge characterizing the specific behav-ior of the particular CAD tools available in his or her design environment. Unfortunately, thisproblem cannot be solved just by enforcing the distribution of proper documentation on CADtools, since sometimes, due to the non-perfect nature of design knowledge, such CAD tools willindeed behave in “unpredictable” ways even for those who developed them!

Finally, CAD tools are typically developed by third parties, targeting a large market of userswith distinct interests, and, therefore, it is simply not realistic to expect that such tools willalways perfectly meet the specific needs of every individual design environment. Note that this

Coordinating the Design Activity

19

last point is more a question of lack of adequate CAD tools for executing “ideal” design plans,than a question of lack of predictability on such CAD Tools.

For these reasons design plan generation must be interleaved with design plan execution duringthe course of design. Moreover, in order to achieve maximum efficiency in the design plan gen-eration and design plan validation phases of the design problem solving process, the nearlydecomposable nature of the design should be properly explored during design plan generation,by generating independent sub-plans associated with sub-problems, and by allowing such plansto be individually executable, thus achieving maximumparallelism in (sub)plan generation andexecution. Since the population of operators is expected to change frequently, no particular con-figuration of operators should be assumed. Moreover, given a specific design problem, weshould be able to generate all of the alternative plans that different designers might considerdesirable.

3.3 Coordinating the Design Activity

Key in the development of a paradigm for design process planning and management, particu-larly when considering concurrent design, is deriving a convenient and general metaphor fordesign agent cooperation and coordination.Such a metaphor is needed for guiding the detaileddevelopment of specific communication and synchronism protocols among design agents.

Before describing possible metaphors for design agent cooperation and coordination, we brieflydiscussdistributedversus centralized problem solving architectures. In a distributed problemsolving architecture design agents are implemented asindependent processing units, or bodies.Such design agents are able to execute their activities inparallel, and in a totally autonomousfashion. On the other hand, in centralized problem solving architectures, design agents are only“virtual” entities in that all design agents are actually implemented as part of the exact sameprocessing body.

Note that centralized problem solving architectures do not preclude the development of highlystructured architectures with a well-defined set of virtual design agents. The idea in such casesis to develop a conceptual organization properly accommodating the different dimensions andrequirements of the problem solving activity being modeled. PLANEX [14], a knowledge basedprocess planner for construction and manufacturing, is an example of an highly effective andsuccessful centralized architecture. Thanks to its carefully designed organization of designagents and resources, PLANEX is able to properly make use of domain-specific knowledge toattain a high level of performance in a narrow domain, performs a clear separation betweendata, knowledge and control, and has incremental growth capability. [14]

However, since all virtual design agents in a centralized architecture are implemented within thesame processing body, the resulting systems have a natural sequential behavior with control

typically realized by means of an agenda.1 This arrangement is incompatible with the need to


20

provide support for aconcurrent design activity. Note that concurrent design implies the exist-ence of autonomous design agents simultaneously cooperating in the design activity. Therefore,our design agents can only be accommodated in adistributed architecture, as independent pro-cessing units executing their activities in parallel.

Let us now discuss the three fundamental metaphors for design agent cooperation and coordina-tion that have been described in the literature: result sharing, task sharing,andplanning. Notethat these three fundamental metaphors for design agent cooperation and coordination can beimplemented either in a distributed architecture or in a centralized architecture. As describedabove, we are basically interested in the distributed “versions” of such metaphors. As will beseen, these metaphors realize different solutions to important problems in a distributed activity,such as:

• formulating, describing, decomposing and allocating problems and synthesizingresults among a group of intelligent and differentiated design agents;

• enabling design agents to communicate and interact;

• ensuring that design agents act coherently in making decisions, accommodating theglobal effects of local decision; and

• synthesizing views and results.

Result sharing is a form of cooperation in which individual design agents assist each other bysharing partial results based on somewhat different perspectives of the overall problem. Controlis typicallydata-driven. Examples of distributed activity systems that implement result sharingmetaphors are HERSAY II [15] and A-TEAMS [16]. Blackboard Architectures [17] constitute avery successful example of a well-structured general problem solving architecture which mayrealize a result sharing metaphor. HERSAY II, for instance, is a blackboard system.

Pure result sharing approaches are potentially suitable for systems that are aimed at solving onespecific class of problems, such as CAD tools implementing specific design functions. In suchcases, a community of design agents may thus cooperate for generating a solution to a particularproblem by applying their different methods to the data generated throughout the differentstages of the solution process. Note that such methods can be complementary or alternative. Apure result sharing metaphor is certainly not appropriate for efficiently dealing with the designactivity, since design is primarily agoal oriented activity. By goal oriented we mean that thestate of the design data by itself does not indicate the course of action to be followed, since dif-

ferent design goals may imply radically different courses of action given the exact same data.1

1. Other control schemes may be implemented, yet this does not change the inherent sequentialbehavior of the resulting system.

1. Note that in the case of specific design operators, the main goal is implicit, and, therefore, onlythe state of the data really matters.

Coordinating the Design Activity

21

The second general metaphor for design agent cooperation and coordination is task sharing. It isa form of cooperation in which individual design agents assist each other by sharing the compu-tational load for the execution of sub-tasks of an overall task. Control in systems that implementtask-sharing isgoal-directed, i.e., the processing done by individual design agents is directedtowards achieving sub-goals of an overall goal.

Thecontract net protocol [18] [19] is one of the most successful communication and coordina-tion protocols deriving from the task sharing metaphor. In the contract net protocol, a specificcollection of nodes, or design agents with processing capabilities, called the contract net, isassumed. Each node in the net may take the role of a manager or of acontractor. A manager isresponsible for monitoring the execution of tasks and for processing the results of their execu-tion. A contractor is responsible for the actual execution of the task. Nodes are not statically tiedto a control hierarchy; they can switch between both roles dynamically.

The contract net protocol is certainly adequate for dealing with strict hierarchical (i.e., parent todescendant, or manager to contractor) design agent cooperation patterns that occur when the

general classes of problems being addressed are of thefully decomposable type,1 or are at leastvery close to it. However, in cases wheredynamic dependencies among problems beingaddressed by sibling managers may exist, as happens during the course of design, the naturallydecoupled nature of this metaphor may fail in efficiently capturing and dynamically dealingwith problem-coupling.

So, in a way, a pure task sharing metaphor, such as the one underlying the contract net protocol,would fail in capturing the integrated dimension of design, since design problems are only ofthe nearly decomposable type. Even with some clever programming, that would somewhat cor-rupt the intrinsic logic of the metaphor, we would anticipate that such an approach would per-form poorly in some specific situations, such as backtracking. Backtracking to a previouslyvisited design state often occurs during the design process, when it becomes clear that a givendesign solution has no chance of ever meeting the specified performance requirements, due topoorly made previous design decisions. Backtracking requires undoing this inappropriate set ofdesign decisions.

Finally, planning can also be used as a basis for dynamically defining the cooperation and coor-dination scheme for a set of design agents involved in a given distributed problem solving pro-cess. However, having design agents independently developing sub-plans for addressing design(sub)problems would exhibit problems similar to the ones described for task sharing. Actually,fully distributed planning, from the point of view of design agent coordination and cooperationissues, constitutes a special case of task sharing.

1. A fully decomposable problem is one that when decomposed generates totally decoupled sub-problems.


22

We have therefore concluded that none of the three “classical” metaphors for design agent coor-dination, taken in their pure form, are directly suited to our needs, and, therefore, we are moti-vated to develop an agent coordination metaphor aimed at properly accommodating thespecifics of the design activity. Such a metaphor, which we call “planning based activityfusion”, is described in the next session, when we introduce and discuss our proposed paradigmfor design process planning and management of design processes.

3.4 A Paradigm for Design Process Planning and Management

It is convenient to categorize the design agents of interest to us as:Design Process Manageragents orDPMs, Designer agentsor DAs, aKnowledge Base Manager agent orKBM, anExec-utive Manager agent orEM, and aDesign Space Manageragent or DSM.

Let us assume a generaldesign environment containing an arbitrary number of designers, work-ing on an arbitrary number of design problems (within the same broad design discipline or in

complementary design disciplines), and sharing the same general purpose CAD Framework.1

Our paradigm organizes a design environment in terms of twologic spaces2: services logicspace andproject logic space. At any given time, an arbitrary number of project logic spacesmay coexist within a given design environment, yet only a single services logic space will existin any design environment. Bellow we describe the role of each of these logic spaces, the role ofeach type of design agent within its logic space, and summarize the communication and coordi-nation protocol maintained between these design agents. The two types of logic spaces are sche-matically shown in Figure 4.

A project logic space contains all alternative design processes, i.e., all design processes beingdeveloped in parallel for the same target design problem in a given design environment; and all‘designers’ concurrently working on these alternative design processes. A project logic space isconstituted by an arbitrary number of DPM type of design agents, by an arbitrary number of DAtype of design agents, and by one DSM type of agent.

1. Note that nothing here precludes a physically distributed design environment across multiplesites.

2. A logic space is an abstraction aggregating a specific set of agents which provide equivalentand/or complementary services aimed at achieving a specific body of functionality, within a spe-cific paradigm.


23

The full representation of the state of eachalternative design process being developed is main-

tained by an individual DPM type of design agent.1 Designer agents, or DA’s, are the “drivers”

of the design process.2 DA type design agents asynchronously ‘connect’ to a previouslyselected DPM residing in the logic space of the target project and request information on the

1. DPM’s can be viewed as Managers in a ‘flat’ Contract Net.

2. Notice that no restrictions are being imposed in the way such ‘Designer’ agents can be imple-mented. DA design agents can be implemented by an interactive program serving as front end to ahuman designer or, on the opposite side of the spectrum, can be implemented by a fully autono-mous (i.e., non interactive) design agent.

DesignProcessManager



SpaceManager

Designer

Designer

Designer

KnowledgeBaseManager

ExecutiveManager

FIGURE 4 A paradigm for design process planning and management

Project Logic SpaceServices Logic Space


24

global state of the related design process. Based on such information, DA agents select a (sub)-problem to focus their attention on, and then they engage in a process of refining and developingthe specification of the selected (sub)problem. The results achieved by DA design agents areimmediately returned by them to the proper coordinator DPM design agent. Such results arethen properly inserted in the current representation of the state of the design.

DPM design agents are always trying to generate executable plans for solving the (sub)prob-lems contained in their representation of the state of the design process. Such problems natu-rally embed the design decisions previously taken by DA type design agents. DPM designagents are also responsible for solving plan generation and plan execution impasses by properly

reformulating the design problems that generated such impasses.1 DA type design agents canalso cooperate in different alternative design processes (owned by different DPM type design

agents) of the same project.2

Finally, the Design Space Manager is the design agent responsible for managing the projectlogic space itself. The DSM is unique to a given project and maintains information such as the“logic addresses” of the DPMs and DAs involved in the project, thus allowing new DAs to con-nect to an existent project or to switch from one DPM to another in the context of the sameproject.

The services logic space is aimed at providing the set of project logic spaces that currently existsin a given design environment with: (1) the general knowledge of the design discipline, or setsof design disciplines, being addressed; and (2) executive services, i.e., actual implementation ofthe design abstract problem solving operators in the context of the particular design discipline(s)being addressed. Note the total design discipline independent flavor of the proposed paradigm.The services logic space contains a single KBM design agent, and a single EM design agent.

The Executive Manager agent is the ‘front end’ to the executive system. DPMs, on their owninitiative, asynchronously connect to the EM design agent, whenever they have (sub)plans to bevalidated or executed, and request the validation or execution of such (sub)plans. Notice that thefact that the EM is unique does not preclude the executive system from executing specific taskswithin its own logic space in a concurrent and thus distributed fashion. Actually, given the dis-tributed nature of the planning process, the capability for concurrent execution of plans should

1. Impasses can be created by lack of resources for executing a given plan, by failure during planexecution, or by direct intervention of a DA type design agent. See Chapter 5 for a detailed dis-cussion of the cooperation and coordination mechanisms of the proposed paradigm for designprocess planning and management.

2. Note the difference between this paradigm and the classical blackboard paradigm. DPM designagents are not just recipients of structured information, since they actively cooperate in the designprocess. Furthermore, DA design agents do not access directly the information characterizing thestate of a given alternative design process (kept by the DPM design agents). Actually, DA agentsonly can see very specific (and simplified) “views” of such an information, specially suited totheir particular design activities. Such views are created by DPM design agents.


25

actually be an implementation requirement for such executive systems.1 As soon as (sub)planvalidation or (sub)plan execution results are produced in the logic space of the executive, theEM connects asynchronously to the proper DPM type design agent and reports these results.

The second design agent in the services logic space is the Knowledge Base design agent. TheKBM contains the definitions characterizing the knowledge component of the design space for agiven design discipline. DPM design agents ‘connect’ asynchronously to the KBM to requestinformation each time new design elements are introduced in the current state of the design pro-cess or each time a plan generation or a plan execution impasse occurs.

In Chapters 4 and 5, respectively, we describe the cooperation and coordination protocols of ourproposed design process planning and management paradigm in detail, and propose an architec-

ture2 for its implementation.

1. Notice the difference between this case and the Contract Net Protocol. In our case, problemdecomposition is only performed by DPM’s. E is a pure executive system. The reason for this isthat DPMs should maintain a complete and fully justified representation of the state of theirdesign processes.

2. i.e., a knowledge and data level organization.


26

Introduction

27

CHAPTER 4 A Formal Theory of Design

4.1 Introduction

In this chapter we propose a formal theory of design. Recently there has been otherefforts directed towards developing such a theory. Most notable among these is the Hier-archical Design Theory, [20] proposed by Siepmann, which we feel is the most signifi-cant contribution to date.

A comparison between our proposed theory of design with that of Siepmann is difficultsince our design theory is wider in scope in that it completely describes the design space,while Siepmann’s theory is only concerned with describing and relating ‘snapshots’ ofdesign data generated during a given design process. Being more specific, his theorydoes not address the issue of formalizing the knowledge-level categories that compre-hend the design space, or attempt to abstract any kind of general characterization on the“design data objects” created during a design process. Yet, Siepmann’s hierarchicaldesign theory was the first to explicitly formalize a set of basic notions in design pro-cesses, that we adopted in our formal theory of design. Hence some of our definitions are

in a sense generalizations of definitions made by Siepmann.1 Beyond this set of general-izations, our formal theory of design addresses a vast body of issues that have no coun-terpart in any other contribution found to date in the design theory literature.

The ultimate objectives of our theory of design are to formally characterize thedesignspace and to formally describe design processes as a problem solving activity that takesplace in this design space. The design space has two components: the design disciplineknowledge component and the design process state component. The design disciplineknowledge component characterizes the different categories of objects being designed inthe context of the discipline, the properties associated with such objects and how theseproperties relate to each other, the general design goals and the design operators whichare meaningful for the specific design discipline(s), etc. The design state component rep-resents the state of a design process in terms of the design data already generated, thedesign data still to be generated, the history of the particular design process, and soforth. Bellow we will describe in more detail each of the sub-components of the designspace, and then formally define the design space itself. We conclude this chapter by dis-cussing the conditions of applicability of our formal theory of design to a design disci-pline.

1. Being more specific our definitions 4, 6, 8, 13, and 14 are generalizations of definitions pro-vided in Siepmann’s theory, in which they do have explicit the notion of “abstract class of designobject”.The abstract class of design object is an abstraction proposed in our design theory forcharacterizing design data objects, as it will be discussed next.

A Formal Theory of Design

28

4.2 Design Hierarchy

As discussed in Section 2.1, hierarchy is used in many ways during design, mainly forcontrolling the overall complexity of the design process. This section is aimed at defin-ing a key component of the design space, i.e., the hierarchy of design objects that can bediscriminated for each specific design discipline.

4.2.1 Design Objects and Properties

Design objects can be characterized by a set of properties. For example, in the case of a

sports automobile1, such properties include weight and color. For the case of digital sig-nal processing blocks, such properties include word length, execution time and layoutarea. In this section we discuss the characterization of design objects of a given designdiscipline in terms of their specific properties.

Definition 1: Design objects2 are characterized by a set of abstract propertiesthat describe their structure and/or behavior. Anabstract class of designobjects isdefined in terms of a set of different design objects each of whichis characterized by the same set of abstract properties.

Definition 2: Given an abstract class of design objects “k”, theabstract

specification for “k”, denoted byPo,k, is the set of abstract properties, or

predicates, or non-closed forms, denoted by , which are necessary and

sufficient for characterizing each design object in the abstract class of design

objects.3

In what follows we will use To,k to denote the set of all possible design objects in anabstract class of design objects “k”. For instance, if the abstract class of objects being

designed is an automobile “a”, To,a denotes the set of all imaginable “a” (or automobile)

design objects. Elements of the set To,a, i.e., specific automobile design objects, are

denoted by .

Definition 3: The general form of anabstract property, denoted bypo,k is

1. Whenever possible, we will try to give examples from different design disciplines in order toshow the generality on our proposed theory of design.2. A design object can be either a physical device or a “process”. For instance, Software Engi-neering is a discipline that “designs” computer programs, which are not “physical artifacts”, butprocesses. We will return to this subject later on.3. The superscript “o” stands for abstract class of design object. It is not an index.

pio k,

tio a,

Design Hierarchy

29

= <t> _has_spec-predicate

where the spec-predicate contains at least two free variables. One of these

variables, denoted by <t>, is of the kind ∈ To,k. The remaining vari-

able(s) in the predicate are aimed at receiving the property value(s).1

For instance, if the abstract class of design objects being designed is an automobile “a”,possible abstract specifications are:

= <t> _has_ _weight_ _equal_to_<val>

= <t> _has_ _color_ _equal_to_<val>

For , <val> is a real variable. For , <val> is a variable of the kind “color”.

If the abstract class of design objects being designed is the adder “ad”, examples ofpredicates are

= <t> _has_ _word-length_ _equal_to_<val>

= <t> _has_ _execution-time_ _less_than_<val>

= <t> _has_ _layout-area_ _less_than_<val>

Definition 4: A specific property or property instance defined for the

abstract class of design objects “k”, and denoted by , is a predicate with

the general form

= <t> _has_spec-statement,

where the only free variable, denoted by <t>, is of the kind ∈ To,k.

Note that: ( )∈ true, false for all ∈To,k.

1. The type of such variables will thus vary from property to property.

pio k,

tio a,

p1o a,

p2o a,

p1o a, p2

o a,

p1o ad,

p2o ad,

p3o ad,

pio k,

pio k,

tio k,

pio k, ti

o k, tio k,


30

Definition 5: We say that derives from , denoted by ↵, if the formula “spec-statement” of can be derived from the for-

mula “spec-predicate” of by assigning values to all free variables of

this last predicate.

Examples of possible property instances for adders are:

= <t> _has_ _word-length_ _equal_to_ 4-bit

= <t> _has_ _execution-time_ _less_than_ 10 ns

= <t> _has_ _layout-area_ _less_than_ 50.000 mµ2

So, for the examples of abstract properties associated with adders, we have

↵

↵

↵

Definition 6: A specification instance or specification, denoted by Po,k, is a

set of specific properties, or predicates |i=1,2,... defined for an abstract

class of design objects “k”.

Definition 7: A specification instance Po,k derives from an abstract specifi-

cation Po,k, denoted by Po,k ↵ Po,k, if and only if

∀ ∈ Po,k. ∃ ∈ Po,k. ↵

This definition is extendable to any partition on the sub-specification Po,k.

Definition 8: denotes the set of all final design objects that satisfy Po,k,

as indicated below

pio k, pq

o k, pio k,

pqo k, pi

o k,

pqo k,

p1o ad,

p2o ad,

p3o ad,

p1o ad, p1

o ad,

p2o ad, p2

o ad,

p3o ad, p3

o ad,

pio k,

pio k, pq

o k, pio k, pq

o k,

TPo k,o k,

Design Hierarchy

31

= ∈ To,k | ∀ ∈ Po,k, ( ) .

In other words, this means that all final design objects in satisfy all property

instances in Po,k. If is the empty set, the design is over-specified, implying that

there is no target system that has all of the specific properties in Po,k.

Making adesign decision, in the process of designing a design object in the abstract

class of design objects “j”, meansderiving a specific property po,j from an abstract prop-

ertypo,j ∈ Po,j, and adding it to Po,j. Each time a specific property is included in Po,j, the

set of possible final design objects that can satisfy Po,j is reduced. In short:

Typically, for each given design discipline, it is possible to design a variety of differentabstract classes of design objects. For instance, for the automobiles design discipline, wemay design sport cars or sedans. What creates the notion of a design discipline, though,is the fact that such different abstract classes of design objects typically share importantproperties. This suggests that it might be convenient to collectively characterize theentire set of abstract classes of design objects that constitute a given design discipline. Inthe next two section we will address this issue.

4.2.2 The Syntax of the Design Hierarchy

In this and in the next section we develop an organization for abstract classes of designobjects that belong to the same design discipline. In this section we discuss the syntacti-cal aspects (i.e., those related with form) of this organization and in Section 4.2.3 we dis-cuss the semantic aspects (i.e., those related with content) of the proposed designhierarchy.

By way of motivation, again consider the design disciplines of VLSI digital circuitdesign, and automobile design. An example of an abstract class of design objects for thediscipline of VLSI digital circuit design is adders. An example of an abstract class ofdesign object for the discipline of automobile design is sedans.

Definition 9: An abstract design hierarchy, denoted∆, is a two dimen-sional structure of ordered sets ofdesign domain private facets, denotedδ.

Design domain private facetsδ are sets of abstract propertiespo that define

TPo k,o k,

tio k, pq

o k, pqo k, ti

o k,

TPo k,o k,

TPo k,o k,

Pk t1,o j, Pk t2,

o j,⊆ TPk t1,

o j,o j, T

Pk t2,o j,

o j,⊆⇒


32

abstract classes of design objects in the overall context of the design disci-pline.

For instance, let us suppose the abstract class of design objects is lowpass filters, fromthe VLSI digital circuit design discipline. The design domain private facet associated

with lowpass filter1 includes abstract properties such as cut-off frequency of the filter,filter gain for the pass band and filter gain for the stop band, and tolerances for the stopband of the filter and for the filter gains.

The general structure of a design hierarchy∆ is illustrated in Figure 5. The verticaldimension of the abstract design hierarchy∆ is referred to as theabstraction dimension.The horizontal dimension is referred to as thespecialization dimension.

The abstraction dimension organizes the abstract design hierarchy∆ into designabstraction layers,and denoted by∆Α,i, where “i” identifies the particular abstraction

layer. The abstraction dimension of∆ defines partitions in the abstract specification ofeach individual abstract class of design objects. We will discuss how these partitions arederived later on in this section.

We impose the restriction on∆ that the organized structure, or topology, for the designdomain private facets in each abstraction layer be a tree. Thus, each abstract design layer∆Α,i is a tree defined by a set of distinct vertices, of typeδi,j, and by a set of distinctedges connecting these vertices calledinheritance sub-paths.

In our notation, we adopt the convention that the first index in the representation of ageneric design domain private facet δi,j designates the abstraction layer∆Α,i to whichthe specific design domain private facet belongs. So, for the example in Figure 5, thehighest level design abstraction layer∆Α,1 is composed of the set of abstract designdomain private facets δ1,1, δ1,2, δ1,3, δ1,4, δ1,5, δ1,6, δ1,7, δ1,8.

In Figure 5, the direction in which the level of abstraction increases is indicated. Weadopt the convention that if j > i, then∆Α,j is less abstract than∆Α,i.The design abstrac-

tion layer that corresponds to the least abstract level of∆ is called theground abstrac-

tion level, or simply theground level, and is represented by∆Α,G. (Note that the leastabstract layer has the most detail associated with it).

1. This example refers to the particular design domain private facet for the low pass filter that isdefined at the transistor level. Abstraction is discussed bellow.

Design Hierarchy

33

We also impose a restriction on∆ for the purpose of relating the topologies of the designdomain facet trees defined for each abstraction level in the design hierarchy. In particu-lar, given a specific tree topology defined for a given abstraction level,∆Α,j, the topol-

ogy of a tree defined for an abstraction level “i”,∆Α,i, where j > i, should be either equal

δ1,1

δ1,2

δ1,3

δ1,6

δ1,7

δ1,8δ1,4

δ2,1

δ2,2

δ2,3

δ2,6

δ2,7

δ2,8

δ2,5

δ2,4

δG,1

δG,2

δG,3

δG,6

δG,7

δG,8

δG,5

δG,4

Specializationδ1,5

∆Α,1

∆Α,2

∆Α, G

Abs

trac

tion

FIGURE 5 Structure of an Abstract design Hierarchy ∆


34

to the topology defined for∆Α,j or should correspond to a sub-tree of the tree associated

with ∆Α,j. Figure 6 shows an acceptable topology for two layers, denoted 1 and 2, wherelayer “1” is more abstract than layer “2”. However, mainly for notational simplicity, wewill assume from now on that the topology of the trees is identical for all abstraction lay-ers, as illustrated in Figure 5.

Note that, in our notation, theroot node of an arbitrary abstraction layer∆Α,i will alwaysbe designated byδi,1, or alternativelyδi,R, where ‘R” stands for root.

Definition 10: The set of all design domain private facets which occupy

identical topological positions1 on each design abstraction layer structure

∆Α,i, defines an abstract design domain denoted by .2

1. In other words, correspond to the same node on the tree.2. In the general case, i.e., when we allow non-identical topologies to be defined for the severalabstraction levels of∆, yet obeying the previously described to sub-tree restriction, this meansbasically that some abstract design domains may not be defined at the higher abstraction levels of∆.

δ1,1

δ1,2

δ1,3δ1,7

δ1,8

δ2,1

δ2,2

δ2,3

δ2,6

δ2,7

δ2,8

δ2,5

δ2,4

δ1,5

∆Α,1

∆Α,2

Abs

trac

tion

FIGURE 6 Topology of abstraction layers.

∆H j,o

Design Hierarchy

35

We adopt the convention that this particular position is defined by the second index in

δi,j. Thus the index “j” identifies a given abstract design domain defined on∆.

For the example in Figure 7, the abstract design domain is composed of the set of

abstract design domain private facets δ1,5, δ2,5,...,δG,5.

∆H j,o

∆H 5,o

δ1,1

δ1,2

δ1,3

δ1,6

δ1,7

δ1,8δ1,4

δ2,1

δ2,2

δ2,3

δ2,6

δ2,7

δ2,8

δ2,5

δ2,4

δG,1

δG,2

δG,3

δG,6

δG,7

δG,8

δG,5

δG,4

Specializationδ1,5

∆οΗ,5

∆Α,1

∆Α,2

∆Α, G

Abs

trac

tion

FIGURE 7 Structure of an Abstract design Hierarchy ∆


36

The abstract design domain , which contains the root design domain private facet

of all design abstraction layers∆Α,i, is designated theroot abstract design domainand

can be alternatively denoted by .

Note that, given a particular abstract design hierarchy∆, each design domain private

facetδi,j only belongs to one design abstraction layer∆Α,i and to one abstract design

domain .

As mentioned above, the structure of each abstraction layer∆Α,i is a tree. Therefore, for

each abstract design domain private facetδi,j in ∆Α,i, there is a unique path fromδi,j tothe root abstract design domain private facet of the layer denoted byδi,1 (or δi,R).

Definition 11: The inheritance path, or specialization path, of an

abstract domain private facet δi,j is the ordered set of the abstract domain pri-vate facets contained in the unique path from the immediate parent ofδi,j inthe tree toδi,R.

So, for the previous example, the abstract domain private facets contained in , the

inheritance path ofδ2,5, are δ2,2, δ2,1, where δ2,2 is the most specialized designdomain private facet in the path andδ2,1 is the most general design domain private facetin the path. In Figure 7, the direction in which the level of specialization increases isindicated.

4.2.3 The Semantics of the Design Hierarchy

This section introduces the semantics associated with defining an abstract design hierar-chy∆ for a specific design discipline and simultaneously discusses the reasons underly-

ing the proposed general organization for∆.

The vertical dimension of the abstract design hierarchy∆ defines partitions on theabstract specifications of abstract classes of design objects. Such partitions are based onthe level of abstraction that is inherent to each abstract property contained in theseabstract specifications. Let us assume an abstract class of design objects “j” defined by

an abstract specificationPo,j. ∆ defines a partition onPo,j, such that an abstract sub-

specification is created for each abstraction level∆Α,i in ∆.

∆H 1,o

∆H R,o

∆H j,o

∆S i,o j,

∆S 2,o 5,

Pio j,

Design Hierarchy

37

Note that, by the definition of partition

∩ = ∅, for

and

Po,j = ∪ ∪ ... ∪

As discussed in Chapter 2, the general idea behind the use of abstraction is to reduce the

complexity of finding a design object that satisfies a given specification instance Po. Thisis done by allowing the designer to start by considering only those properties containedin the more abstract sub-specification. Only when this initial set of properties is meet bythe object under design, the designer moves down in the partitions hierarchy, and con-siders the following, lower level, sub-specification. This process is repeated until theground abstraction level is reached.

The vertical dimension of an abstract design hierarchy∆, on the other hand, serves adual purpose. First of all, it discriminates between different abstract classes of designobjects which may coexist for the design discipline targeted by∆. Examples of differentabstract classes of design objects which can be defined for VLSI digital circuits designare adders and multipliers. Examples of abstract classes of design objects which can bedefined for the discipline of automobile design are sedans and sports cars. As mentionedin Chapter 2, the “divide-to-conquer” strategy, implemented by decomposing the designof a complex object into the design of a set of less complex objects, is extensively usedin design, thus creating the need for properly characterizing abstract specifications forall possible abstract classes of design objects realizable in the discipline.

The vertical dimension, as defined, also allows expression of commonalties among dif-ferent abstract classes of design objects defined for a given design discipline. In otherwords, it allows representation of the concept of specialization (or conversely, generali-zation) by allowing different abstract classes of design objects to share abstract proper-ties. For instance, in the discipline of automobile design, different design abstract classesof design objects, such as sedans and sport cars, share a sub-set of their abstract proper-ties, such as having color, having weight, having an engine, and so forth.

This “specialization versus generalization” concept is crucial in design since it helps tocontrol complexity of design processes by promoting an efficient reuse of previousdesign experience. Note, for instance, that designing any specific type of automobile forthe very first time is considerably more difficult than, say, designing a sedan after havingdesigned a sports car.

Pio j, Pk

o j, i k≠

P1o j, P2

o j, PGo j,


38

Definition 12: An abstract sub-specification for an abstract class of design

objects “j”, Po,j, is complete, denoted by , if and only if it contains all

possible specifications that can characterize any final design object of thespecific abstract class of design objects.

In other words, a complete abstract specification is such that, by adding an arbi-

trary specification to the set, implies that no design object exists that can be described or

represented by any derived Po,j.

Note that in∆, only the abstract design domains defined by the leaf design domain pri-vate facets will correspond to abstract classes of design objects characterized by a com-plete abstract specification.

Definition 13: Two sub-specifications instances and of the same

specification Po,j, where i < k, areabsolutely_consistent if the set of all final

design objects satisfying the less abstract sub-specification is a subset

of all final design objects satisfying the more abstract specification . In

short, for i < k,

_is_absolutely_consistent_( , ) ⇒ .

Definition 14: A Specification Po,j is _is_absolutely_consistent if for any

sub-specification pair and :

if i < k, then _is_absolutely_consistent_( , ).

4.2.4 Deriving a Design Hierarchy for a Design Discipline

Let us now discuss how a specific abstract design hierarchy∆ can be derived given acollection of abstract classes of design objects belonging to a given design discipline.

We start by assuming that our abstract design hierarchy∆, defined for a specific designdiscipline, has a specific set of traditionally accepted design abstraction levels, i.e., weassume up front that∆ is composed of a set of design abstraction layers∆Α,i, i=1,2,...The way in which such abstraction levels are derived is strongly design disciplinedependent and is beyond the scope of this research.

PCo j,

PCo j,

Pio j, Pk

o j,

Pko j,

Pio j,

Pio j, Pk

o j, TPk

o j,o j, T

Pio j,

o j,⊆

Pio j, Pk

o j,

Pio j, Pk

o j,

Design Hierarchy

39

Our objective is thus to derive an adequate tree topology for organizing the designdomain private facets of the abstract classes of design objects defined for the design dis-cipline. We start by selecting any two abstract classes of design objects from the setdefined for the design discipline. For instance, consider a class “n”, defined by the

abstract specification Po,n, and a class “k”, defined by the abstract specificationPo,k.

Note that the configuration of abstraction layers in∆ defines a partition inPo, n and in

Po,k, such that two abstract sub-specifications, and , respectively, are created

for each design abstraction layer∆Α,i.

Now let us consider how the internal tree structure of design domain private facets for ageneric abstraction layer∆Α,i is created, based on the classes of design objects “n” and“k”. Let us also consider how the abstract design domains for each of these objects,

and , and related abstract design domain private facets,δi,n andδi,k, are

derived. Two situations may occur:

Case 1: The abstract class of objects “k” is a generalization of the abstract class ofobjects “n”, or conversely, the abstract class of objects “n” is a specialization of theabstract class of objects “k”. In short,

∀i, .

In other words, all design objects described by a specification instance Po,n are also

described by the specification instance Po,k (which is indeed a subset of Po, n). Said dif-

ferently, all final design objects satisfying Po, n also satisfy Po,k. For instance, abstractclass “n” may be a sedan, while class “k” may designate a generic automobile.

In this case, if our abstract design hierarchy was intended to represent only these twoabstract classes of design objects (“n” and “k”), the abstract sub-specification associatedwith the more general class k would constitute the root design domain private facet. So,for each∆Α,i, we haveδi,k = δi,R.

Notice that, for any root design domain private facet, it is true by construction that

∀i, δi,R = , where “i” denotes the abstraction layer∆Α,i in ∆.

Pio n, Pi

o k,

∆H n,o ∆H k,

o

Pio n, Pi

o k,⊇

Pio k,


40

The second design domain private facet δi,n would then be inserted in the tree structure

of ∆Α,i as a descendent node of the root design domain private facet node, δi,R, as indi-cated below:

and would be defined, for each abstraction level∆Α,i, as follows:

∀i, δi,n = - , where “i” denotes the abstraction layer∆Α,i in ∆.

Note that by deriving the sub-specificationsδi,k and δi,R, we have already uniquely

defined the corresponding and .

Case 2:None of the two abstract classes of design objects (“k” or “n”) is a generaliza-tion of the other, or conversely, none of the two abstract classes of design objects (“k” or“n”) is a specialization of the other. In short,

for ∃i,

For example, the abstract class of design object denoted by “n” can be a sports car, whilethe abstract class of design object denoted by “k” can be a sedan.

δi,R δi,n

Pio n, Pi

o R,

∆H n,o ∆H k,

o

δ1,R δ1,n

δG,R δG,n

δ2,R δ2,n∆ο

Η,n∆οΗ,R

#Pio k, #Pi

o n,≤ Pio k, Pi

o n,⊄

Design Hierarchy

41

In this case, a generalized abstract design object “g” is created as follows,

∀i, δi,g = ∩ , where “i” denotes the abstraction layer∆Α,i in ∆

and the abstract design domain private facets for the abstract classes of design objects“n” and “k” would then be defined as follows, with “i” denoting the abstraction layer∆Α,i in ∆,

∀i, δi,n = - δi,g

∀i, δi,k = - δi,g

This leads to the following structural organization for the generic design abstractionlayer∆Α,i, with δi,g = δi,R

Returning to our example, the artificially created set of “root” design domain privatefacets, which also defines an “artificial” abstract design domain, contains all abstractproperties shared by a sedan (k”) and a sports car (“n”), throughout the abstraction levelsdefined in∆. We may think of this artificial abstract design domain as being the general-ized abstract class of design objects automobile.

As in the previous case, , , and the artificially created , are also fully

defined at this point.

Given these two possible initial cases, let us now discuss how to insert the remainingabstract class of design objects defined for the discipline in the existing design hierarchy.Basically, for each new abstract class of design objects, the goal is to determine the bestinsertion point, or topological position, for the design domain private facets that willcharacterize the particular abstract class of design objects. Such an insertion point isdefined in the generic design domain private facets tree that is commonly defined foreach abstraction layer∆Α,i in ∆. When this insertion point is determined, using themethod described bellow, the content of each new design domain private facetδi,a,

Pio n, Pi

o k,

Pio n,

Pio k,

δi,R

δi,n

δi,k

∆H n,o ∆H k,

o ∆H g,o


42

where “a” denotes the new abstract class of design object being inserted, is derived asfollows:

∀i, δi,n = - , where “i” denotes the abstraction layer∆Α,i in ∆, and

denotes the inheritance path for the particular topological position in the generic tree forthe abstraction level∆Α,i.

General case: Inserting a new abstract class of design objects “a” in an existing designhierarchy∆.

Consider an abstract class of design objects “a”, defined by an abstract specification

Po,a. As in the previous cases,∆ defines a partition onPo,a, such that an abstract sub-

specification is created, for each abstraction level∆Α,i in ∆.

The search in∆ for the insertion point for the private design domain facets of the newabstract class of design objects “a” should start at the highest abstraction layer and grad-ually move down in the direction of the lower abstraction levels in∆.

So, starting at the highest level abstraction in the design hierarchy, denoted by∆Α,1,each path defined from the root abstract design domain facet should be investigated foran insertion point, as indicated in the figure below,

For each of these paths, an alternative insertion point is generated immediately beforethe following specialization-based insertion criteria stops being detected:

Pio a, ∆S i,

o a, ∆S i,o a,

Pio a,

δ1,1

δ1,2

δ1,3

δ1,6

δ1,7

δ1,8

δ1,5

δ1,4

∆Α,1

Design Hierarchy

43

After the investigation for insertion points is concluded in the abstraction layer∆Α,1, weshould move down in the hierarchy, i.e., into the immediately lower level of abstractionin ∆, if it exists.

For all remaining, lower level abstraction layers in∆, being traversed during this pro-cess, each alternative insertion point coming from the upper layers should be investi-gated for consistency. In other words, we need to verify if the insertion criteria is stillverified at the insertion point for the current abstraction level. If it is verified, the alterna-tive insertion point is also signaled as valid in the corresponding path. If not, the pathshould be investigated again, but now moving in the direction of the root private designdomain facet, as indicated below, in order to find a new candidate insertion point, i.e., apoint where the insertion criteria is verified again.

When eventually the ground level (i.e., the lowest level of abstraction in∆) is reached,the remaining alternative insertion point or points, if there are more than one, should beselected on the basis of the degree of specialization, i.e., “the fewer properties kept in thenew private design domain facets, the better.”

In the figure shown below, we illustrate an inconsistent insertion point “A” beingdetected, and thus generating a “back” search for a new insertion point in the corre-sponding path. We also illustrate two consistent insertion points, “B” and “C”, beingdetected, which are kept as alternative insertions to be further investigated in the lowerabstraction layers.

∆S i,o a, Pi

o a,⊇

δi,1

δi,2

δi,3

δi,6

δi,7

δi,8

δi,5

∆Α,i

δi,4

A

B

C


44

4.3 A Taxonomy of Abstract Specifications

This section is aimed at deriving a taxonomy of abstract properties which constitute an

abstract specification,Po, that defines an abstract class of design objects. We start by dis-cussing design processes in general, in order to better put into perspective the semanticsof the abstract properties that may characterize a given abstract class of design objects.

As mentioned is Section 2.2, a design process can be seen as an arbitrarily complexsequence of generation and test design steps. Generation design steps basically consistsof derivation of property values for a given design object, or modification of such valuesattempting to meet a given set of performance requirements, while test steps consists ofverification to determine if a given set of property values meets the set of performancerequirements specified for the design object. Let us now introduce some semantics in thecharacterization of abstract properties that are involved in these different design steps.

A design object can be fundamentally characterized in terms of itsrealization structureand/or itsbehavior.

In simple terms, the realization structure of a given design object is defined by a set ofrealization structure primitives or realization structure primitive building blocks inter-

connected according to a specifictopology.1 In Figure 8, a possible realization structure

for a current source2, represented at transistor level, is shown. The primitive buildingblocks used in the realization structure are the transistors M1 through M4. The topologyis the way such primitive building blocks are interconnected, forming the current sourcedesign object.

Before the design process can commence, realization structure primitive building blocksmust be available for each abstraction level∆A,i of the specific design discipline. Also,the form of the interconnection these primitive building blocks that is required to form agiven topology should be defined, for each abstraction level∆A,i.

Moreover,models must exist for each of these realization structure primitive buildingblocks. Note that primitive building blocks may refer to either an atomic physical

device, or a process,3 yet in both cases they can be seen as black boxes which generate aspecific set of outputs in response to a given stimuli or set of inputs. So, a model is an

1. Non-primitive structural building blocks may also be used, but for simplicity, we delay such apossibility until Section 4.3.2.2. A current source is a specific abstract class of design object defined for the general disciplineof VLSI analog circuits3. In the software engineering design discipline, the design objects are indeed processes, asopposed to physical devices.

A Taxonomy of Abstract Specifications

45

abstraction of a primitive physical device or process that captures and represents therelations between the inputs and the corresponding outputs of the real physical device or

process. In order to develop a suitable model for a primitive (i.e., atomic) system,1 athorough understanding of the system and its operational range is needed. Moreover, asystem may have different models depending on the different operational ranges inwhich it will be used and/or the required accuracy with which we want to reproduce thereal physical process.

Returning to the example shown in Figure 8, models have to be available for the realiza-tion structure primitive building blocks used in the realization structure of the currentsource, i.e., for the transistors M1 through M4. Note that such transistors may be mod-eled differently at high and low frequencies.

Thebehavioral description of a given design object indicates, by means of a set of math-ematical equations or other formalisms, how the object reacts to specific sets of stimuli

or ‘inputs’.2 For example, a possible behavioral description for a low pass filter is

where “A” denotes the filter gain, and "ωp” denotes the cut-off frequency.

The particular type of mathematical equations, or formal languages, used in generatingsuch descriptions must be properly specified for each abstraction level∆A,i of the spe-cific design discipline. Moreover, note that the mathematical equations used for describ-ing the behavior of design objects may also assume many different forms for the exactsame design discipline, at the exact same abstraction level. Examples of such different

1. We use the term system as substitute for “physical device or process”.2. Note that a model is therefore a behavioral description of a realization structure primitivebuilding block. We return to this subject in Section 4.3.5.

FIGURE 8 Realization Structure of a Cascoded Mirror Current Source.

M1 M2

M3 M4

Iin Iout

A =1, ω ωp≤

0, ω ωp>


46

forms are theexternal,or input-output description,and theinternal, or state-variable

description, used at the transistor level of abstraction.1

According to the way a target design object is initially specified, we may define twobroad categories of design processes:realization-driven design processes andbehavior-driven design processes. These categories are described more fully in the next two sec-tions in terms of the following design problems:

Problem 1: Design an active low pass filter that meets a set of performance require-ments;

Problem 2: Design an automobile suspension that meets a set of performance require-ments;

Problem 3: Design a digital processing unit that implements a specific algorithm andmeets a set of performance requirements;

Problem 4: Design an operational amplifier that meets a set of performance require-ments;

Problem 5: Design a water tank with a certain area and profile that meets a set of perfor-mance requirements;

Problem6: Design a dc current source that meets a set of performance requirements.

Note that in all of these design problems, a set of “performance requirements” are speci-fied. Indeed, initial design object specifications not only indicate (with more or less pre-cision) the intended behavior for the object under design, called behavior-driven designprocesses or, alternatively, the specific realization structure for the design object, calledrealization-driven design processes, but also typically contain a specific set of require-ments that must be met by the design object. Examples of such requirements for the dis-ciplines of digital and analog circuit design are area and dissipated power. Note that it ispossible to synthesize, say, two low pass filters with an identical behavioral descriptionyet with very different areas. Another example of a requirement that can be meaningfulto almost all design discipline is the final cost of the design object.

1. For instance, in network analysis, if we are interested in only the terminal properties, we mayuse the impedance transfer function to describe the network; if we want to look to current andvoltage of each branch of the network, then loop analysis or node analysis has to be used to findthe set of differential equations to describe the network. The transfer function may be called theexternal or input-output description of a realization structure, while the set of differential equa-tions that describes the internal as well as the external behavior of a realization structure may becalled the internal or state-variable description of the system.


47

We are now ready to discuss realization-driven design processes and behavior-drivendesign processes.

4.3.1 Realization-driven design processes

For some design problems in some design disciplines, the realization structure of thedesign object being designed is known a priori, or is selected in a very straightforwardfashion during the early phases of the design process. The design processes used to solvesuch design problems are thus calledrealization-driven. This may be the situation withProblems 2, 5 and 6 mentioned above. In these problems, a realization structure for thephysical device to be designed would probably be derived early in the design process.

In realization-driven design processes, once a realization structure is found for the phys-ical device being designed, the next step is to develop, by applying various physical

laws, a set of mathematical equations to describe this realization structure.1 For exam-ple, we may apply Kirchoff’s voltage and current laws to electrical system realizationstructures defined at the circuit level and Newton’s laws to mechanical system realiza-tion structures. Such equations are abehavioral description of the realization structure.

Once a mathematical (or other) description of a realization structure is obtained, the nextstep in the realization-driven design process involvesqualitative and/orquantitativeanalysis. In quantitative analysis we are interested in the responses of the system realiza-tion structure to the application of certain input signals. For example, inProblem 5, wemay be interested in investigating how the tank resists vibration of the ground due to anearthquake. In a qualitative analysis, we are interested in the general properties of the

system realization structure, such as stability.2 If the tank inProblem 5 was constructedon a platform type of support in a region of strong winds, stability would be of concern.During this phase of design, designers evaluate the realization structure, using the corre-sponding realization structure description(s), to determine if it satisfies the specifiedrequirements.

As mentioned above, for some cases it is possible to derive different behavioral descrip-tions for the exact same realization structure. So, different behavioral descriptions maybe used during this analysis process, according to their ability to better give an answer tothe specific analysis problems that are posed.

1. Note that the behavior of each realization structure primitive building block in the particulartopology is specified by the corresponding primitive building block model.2. Controllability and observability are examples of other qualitative properties of devices andsystems realization structures.


48

If the response of the realization structure is found to be unsatisfactory, the realizationstructure has to be improved oroptimized. In some cases, the response of a realizationstructure can be improved just by adjusting some of its parameters (for instance, thedoses of cement in concrete used to build the cylindrical structure of the tank). In othercases, compensators have to be introduced. For instance, lateral steel structures abuttingthe tank. In the worst case, the realization structure itself has to be modified. Notice,though, that if the realization structure is properly chosen, the performance requirementsfor the physical system should correspondingly improve through the introduction ofparameter adjustments and/or compensators. Finally, since most realization-driven

design processes typically work only at the ground level of abstraction,1 i.e., they do notutilize abstractions of the fully detailed level of abstraction, a realization structure withthe proper parameters can be directly mapped onto an actual physical system.

4.3.2 Behavior-driven design processes

In many design processes, in a significant number of design disciplines, a realizationstructure for the design object cannot be specified a priori. Actually, in such cases, oneof the fundamental goals of the design process is the derivation of a proper realizationstructure for the design object. By proper realization structure we mean a realizationstructure that has, at least, the potential for exhibiting the desired behavior. We call thistype of design processesbehavior-driven.

In such cases, the design problem is initially specified in terms of a set of mathematicalequations, or other forms of behavioral description. The designer’s main goal is, thus, toderive a realization structure that can be described by the behavior. Manufacturabilityand reliability issues may also impact such a derivation. Problems 1, 3, and 4, mentionedabove are examples of this category of design processes.

Moreover, in a significant number of behavior-driven design processes, the specifiedbehavioral descriptions (for instance, the set of mathematical equations) represent“ideal” behavior, i.e., a behavior that is known to be impossible to realize with thestructure primitive building blocks defined for the discipline, due to technological oractual physical limitations. In such cases, a set of functional requirements is typicallyalso specified, complementing the information provided by the “ideal” behavior. Thepurpose of these functional requirements is to indicate how much real behavior can devi-ate from ideal behavior. A suitable and realizableapproximate behavioral descriptionmust then be derived. An approximate behavioral description is one which is able tomeet the particular set of functional requirements.

1. The VLSI analog circuit design discipline uses more that one abstraction level, yet producingsometimes realization-driven design processes. For simplicity, we delay the discussion on the useof abstraction levels during the design process to the next section.


49

Deriving such an approximation constitutes a crucial part of the actual design process.For instance, in the case of the low pass filter problem, these requirements will constitutethe so called LowPass Frequency Response Specification. Such specification, besidesindicating a value for the cut off frequency of the high end of the pass band, also indi-cates allowed tolerances: (1) for the stop band of the filter, defining a transition region;and (2) for the maximum deviation between the amplitude of the real filter and theamplitude of the ideal filter. Meeting these requirements actually drives the process ofselecting a convenient general form for the filter algorithm, by specifying whether the

approximate behavioral description will be a polynomial, or a ratio of polynomials,1 andthen the selection of a convenientpolynomial approximation technique for realizing theapproximate behavioral description of the filter (i.e., equiripple, frequency sampling,windowing, beta, butterworth, chebyshev, or elliptic), and the further selection of aproper order for the filter, i.e., for the polynomials of the approximation. So, in the caseof the filter, the approximate behavioral description involves a polynomial approxima-

tion, a filter order,2 and a set of coefficient values.3

Furthermore, frequently the description of the desired behavior of a complex system,and/or the description of a realization structure for a complex system, is made at anabstraction level that is higher than the ground level for the particular design discipline.As discussed earlier, the idea is to control the complexity of the design process. Forinstance, in the VLSI digital circuit design discipline, several levels of abstraction aredefined, including the logic and the circuit levels of abstraction. The circuit level is alower level of abstraction, vis. it is a more detailed level, than the logic level. Note, forinstance, that the behavioral description of a digital system, at the logical level ofabstraction, is a set of boolean equations which is a much simpler representation than theset of non-linear differential equations that describe behavior at circuit level. Similarly,the structure primitive building blocks defined for the logic level, i.e., NAND’s, NOR’sand NOT’s, are significantly less complex than their counterparts defined for the circuitlevel, i.e., transistors, capacitors, and resistors. Moreover, frequently the behavioraldescriptions represented in the highest levels of abstraction rely on non-mathematicaldescription formalisms, such as Register-Transfer Level description languages, or Algo-rithmic Level description languages. Note that the existence of such a hierarchy ofabstraction levels creates the need for properly and consistently transforming realizationstructures and descriptions from one abstraction level to another.

1. Note that a polynomial corresponds to a FIR filter algorithm, while a ratio of polynomials cor-responds to an IIR filter algorithm.2. The filter order corresponds to the order of the polynomial or ration of polynomials used in theapproximation.3. The coefficients of the approximation are the coefficients of the corresponding polynomials.


50

In design, the same behavior can typically be exhibited by many different realizationstructures. So, considering again the behavior-driven category of design processes, oncea potentially realizable behavior is specified, at whatever abstraction level∆Α,i, the nextstep is to find a suitable realization structure that, besides exhibiting the intended behav-ior, can better accomplish all implementation requirements and technological constraintswhich may exist. Examples of implementation requirements for VLSI circuit design arearea and dissipated power. Examples of technological constraints for the same disciplineare the use a particular fabrication technology or the use of a particular layout style.

Analysis and optimization steps are similar for both behavior-driven design processesand realization-driven design processes, and therefore we will not discuss them again.

A design process is concluded when a complete ground level description of a finaldesign object has been generated that exhibits the desired behavior and meets all desired

performance requirements1. It is assumed that a direct mapping can be made from theground level description of the design object that results from the design process into thecorresponding physical device or process.

4.3.3 Defining Functional and Structural Design Object Decomposition

Before presenting the proposed taxonomy of abstract specifications, it is useful to for-mally definestructural and functional design object decomposition, which is used forcontrolling the complexity involved with deriving the realization structure and thebehavioral descriptions, respectively, of a complex design object.

In order to understand the meaning of structural decomposition, we need to describehow a realization structure is defined. A realization structure is defined in terms of aninterconnection (in a topology) of a number of structure building blocks defined at a spe-cific abstraction level∆Α,i. Such building blocks can be either primitive building blocksor non-primitive building blocks. A primitive building block is one that cannot beexpressed in terms of other, simpler, building blocks defined at the same abstractionlevel. In other words, a primitive building block is an atomic building block, in that itcannot be decomposed in terms of less complex building blocks. In defining the realiza-tion structure of a specific design object, each used building block (primitive or non-primitive) can also be seen as the realization structure of a particular design (sub)object.

Definition 15: A realization structure description is referred to as afunda-mental structural decomposition if it only uses realization structure primi-tive building blocks. Otherwise, if the realization structure description uses at

1. The meaning of performance requirements in this context is very broad, and includes behaviorand structure specific requirements.


51

least one realization structure non-primitive building block, it is referred toas anon-fundamental structural decomposition.

For instance, the realization structure of an OPAMP, at the circuit level of abstraction,may be defined in terms of transistors and capacitors, which are among the structureprimitive building blocks of the circuit level of abstraction for the VLSI digital designdiscipline. This realization structure would, thus, constitute a fundamental structuraldecomposition. On the other hand, the realization structure of the exact same OPAMPcan be alternatively represented, at the exact same abstraction level, using non-primitivebuilding blocks, such as current sources, differential amplifier stages, and voltage gainamplifiers, which is a non-fundamental structural decomposition. Note that such struc-ture non-primitive building blocks may themselves be represented in terms of the primi-tives building blocks of the common abstraction level or in terms of other non-primitivebuilding blocks.

Similarly, the behavioral description of a given design object can be specified simplyand directly in terms of the mathematical formalisms and/or behavioral description lan-guages that characterize the particular abstraction level∆Α,i, or, alternatively, a behav-ioral description can be specified in terms of a set ofassumed behavioral(sub)descriptions, defined at the same abstraction level. A behavioral (sub)description issaid to be “assumed” in a particular target behavioral description, if such a sub-descrip-tion is not explicitly represented in the particular behavioral description in terms of themathematical formalisms and/or behavioral description languages that characterize theparticular abstraction level∆Α,i. Each of the assumed behavioral (sub)descriptions can,thus, be seen as a “non-primitive behavioral building block”, for the particular abstrac-tion level.Note that a behavioral (sub)description, i.e., a non primitive behavioral build-ing block, should also correspond to the behavioral description of a particular finaldesign (sub)object.

Definition 16: A behavioral description is referred to as anon-fundamentalfunctional decomposition if is uses at least one “non-primitive behavioral

building block”.1 Otherwise, the behavioral description is referred to as afundamental functional decomposition.

Let us illustrate the concept of a non-fundamental functional decomposition for theVLSI analog circuits design discipline. Let uM, yM, and GM be, respectively, the input,the output, and the impulse-response matrix of a given object, M, under design, and rep-resented at the circuit level of abstraction. Assuming that an external description is beingused, the behavioral description of M is given by:

1. As mentioned above, a non-primitive behavioral building block can also be called an assumedbehavioral (sub)description.


52

Let us now consider two other final design objects, Si|i=1, 2, also defined at the circuit

level of abstraction. The behavioral description of Si would be given by,

,

where ui and yi are the input and the output and Gi is the inpulse-response matrix of sys-tem Si.

If the behavior of M could be replicated by connecting S1 and S2 in parallel, as illus-trated in the figure shown bellow, the impulse matrix of the behavioral description of M

could then be alternatively given by,

,

in which case the behavioral description of M would correspond to a non-fundamentalfunctional decomposition. G1 and G2 are the “non-primitive behavioral buildingblocks” in this last behavioral description of M. Note that the behavior of M would thenbe expressed in terms of the behavior of two other final design objects, S1 and S2,defined at the same abstraction level.

4.3.3.1 A complete example

We start by illustrating the concept of fundamental structural and fundamental func-tional decompositions. Assume we wish to synthesize a digital processing circuit thatrealizes the property instance:

= <t>_has_behavior_ Table_1,

yM t( ) GM t τ,( ) uM τ( ) dτ∞–

t

∫=

yi t( ) Gi t τ,( ) ui τ( ) dτ∞–

t

∫= i 1 2,=

uM

u1

u2

S1

S2

y1

y2

+yM = y1 + y2

GM t τ,( ) G1 t τ,( ) G2 t τ,( )+=

plo p,


53

where “p” denotes the abstract class of deign objects “processing circuits”, and “l”denotes the logic level of abstraction,

Let us also assume that Table 1 is given by:

The above table can be represented by the one of the following boolean equations:

d = = NAND(NOT(a), NOR(b, NOT(c))

or

d = = NAND(NOR(a, b), c)

In the boolean algebra used for describing the behavior of digital circuits, the fundamen-tal statement connectives, or logic operators, are NAND, NOR, and NOT. Therefore, thetwo expressions above are examples of alternative fundamental functional decomposi-tions because they describe the exact same behavior.

Similarly, when deriving a realization structure that exhibits the above behavior, we mayuse the following possible structure primitive building blocks, defined for the logical

Table 1:

a b c d

0 0 0 1

0 0 1 0

0 1 0 1

0 1 1 1

1 0 0 1

1 0 1 1

1 1 0 1

1 1 1 1

a¬ b c¬∨⟨ ⟩¬∧⟨ ⟩¬

a b∨⟨ ⟩¬ c∧⟨ ⟩¬


54

level: NOR2, NOR3, NAND2, NAND3, and NOT.1 So, we may define our realizationstructure using two different fundamental structural decompositions, as shown below:

d = NAND2(NOT(a), NOR2(b, NOT(c))

or

d = NAND2(NOR2(a, b), c).

Note that “NAND2(NOT(a), NOR2(b, NOT(c))” is a possible realization structure forthe behavioral description “NAND(NOT(a), NOR(b, NOT(c))”. “NAND2(NOR2(a, b),c)”, on the other hand, is a possible realization structure for the behavioral description“NAND(NOR(a, b), c)”.

The important point illustrated by this example is that each of the different fundamentaldecompositions (structural and behavioral) will lead to different ground level realizationstructures and, thus, to different product realizations.

Now, let us illustrate non-fundamental decompositions, both functional and structural, insynthesizing the behavior:

d =

Using the primitive behavioral connectives for the logic level of abstraction, we wouldobtain the following primitive functional decomposition

d = NAND(a, NAND(NOT(b), NOT(c))),

corresponding to the following fundamental structural decomposition

d = NAND2(a, NAND2(NOT(b), NOT(c))).

Let us now assume that, in the particular design hierarchy where the design process wastaking place, we had also represented the abstract class of design objects known as

implication,2 denoted by “⇒”. The behavioral description of the abstract class of designobject implication, at the logic level, would be defined as

a ⇒b =

1. The subscript denotes the number of inputs of the primitive building block.2. Implication is the conditional logic operator.

a b c∨⟨ ⟩∧⟨ ⟩¬

a b¬∧⟨ ⟩¬


55

or,

COND(a, b) =

where a is the antecedent and b the consequent of the implication operator.

In this case, we could alternatively have described the intended behavior of our targetsystem using the non-fundamental behavioral decomposition

d = COND(a, NOR(b, c))

and defined a realization structure for the target system1, at the logical level of abstrac-tion, also as a non-fundamental structural decomposition,

d = CONDacdo(a, NOR2(b, c)),

where CONDacdo is a realization structure non-fundamental building block.

We are now ready to derive a taxonomy of abstract specifications that define abstractclasses of design objects.

4.3.4 Taxonomy of abstract specifications

Our proposed taxonomy, summarized in Figure 9, is defined for each defined in a

generic design hierarchy ∆, i.e., is defined for the sub-specification of each abstract

class of design objects defined for each abstraction level∆Α,i in ∆. The taxonomy is

common to all abstraction levels∆Α,i defined in∆.

1. The complete realization structure description of the target system will certainly have moreinformation than just identifying the building blocks and their connections. Although, since at thispoint we are discussing decomposition, for clarity and simplicity, we just concentrate on this par-ticular issue of the realization structure description.

a b¬∧⟨ ⟩¬

Pio j,


56

As shown in Figure 9, the abstract sub-specification , defined for the abstract class

of objects “j” at the abstraction layer∆Α,i, can be partitioned into two general catego-ries.

1) Thebehavioral sub-specification, denoted by , where “B” denotes behavior.

This abstract sub-specification contains all behavior related properties for a givenabstract class of design objects “j” considered at the abstraction level∆Α,i in ∆. The

sub-specification is, thus, aimed at defining how the artifact should “behave” in

order to accomplish its function.

2) The realization structure sub-specification, denoted by , where “S” denotes

structure.

This abstract sub-specification contains all realization structure related properties for agiven abstract class of design objects “j” considered at the abstraction level∆Α,i in ∆.

The sub-specification is, thus, aimed at defining how the artifact will be actually

‘realized’.

Realization Structure Sub-Specification

Pi S,o j,

Behavioral Sub-Specification

Pi B,o j,

RealizationStructure

Description

Pi S D, ,o j,


Constraints

Pi S C, ,o j,


Requirements

Pi S R, ,o j,

BehavioralDescription

Pi B F, ,o j,

BehavioralConstraints

Pi B C, ,o j,

BehavioralRequirements

Pi B R, ,o j,

FIGURE 9 A taxonomy of abstract specifications

Pio j,

Pi B,o j,

Pi B,o j,

Pi S,o j,

Pi S,o j,


57

The two subsets of abstract properties, the behavioral sub-specification and the realiza-tion structure sub-specification, are further partitioned into three sub-categories, as indi-cated in Figure 9. Note the total symmetry in these partitions for behavior and forrealization structure. The two next sections will characterize each of these sub-catego-ries. It is important, though, to note at this point the fundamental difference betweenconstraints andrequirements. Requirements are givens of the design problem, i.e., fig-ures of merit of performance and functional characteristics that must necessarily beachieved in the final design object. Constraints, on the other hand, are imposed by thedesigner, in an attempt to control design complexity and/or to adequately prune the solu-tion space. This fundamental distinction will be illustrated during the discussion of ourtaxonomy.

4.3.4.1 Characterizing the behavioral sub-specification

The behavioral sub-specification can be further partitioned into three sub-specifications:behavioral description, behavioral constraints and behavioral requirements.

1) Behavioral description, , where “D “denotes description.

The sub-specification is comprised of at least one abstract property of type

, where is a behavioral description. In our notation “k” identifies

the particular abstract property in the set. Note that we may have several distinct behav-ioral descriptions (i.e., behavioral descriptions expressed in different forms) coexistingfor a given design object. A behavioral description can correspond to a fundamentalfunctional decomposition, or to non-fundamental functional decomposition (see Defini-

tion 16). An example of a possible value for , in the context of the example given

in Section 4.3.3.1, is d = COND(a, NOR(b, c)).

2) Behavioral constraints, , where “C” denotes constraints.

This sub-specification is aimed at defining specific constraints on behavioral descrip-tions. This category of abstract properties is fundamental in design, particularly whenthe intended behavior for the design object is “ideal,” i.e., it has characteristics that areknown to be physically or technologically impossible to achieve or implement, but canbe approximated by a real design object. In such cases, the abstract sub-specification

is aimed at characterizing a convenient type of approximate behavioral descrip-

Pi B,o j,

Pi B D, ,o j,

Pi B D, ,o j,

pi B D, ,o j k, , pi B D, ,

o j k, ,

pi B D, ,o j k, ,

Pi B C, ,o j,

Pi B C, ,o j,


58

tion. (Note that the approximate description itself is actually represented in ).

The phase during which the designer derives convenient values for some properties ofthis category is traditionally called conceptual design.

For instance, for the case of the lowpass filter discussed earlier, the selected approxima-tion transfer function and the related order of the filter constitute behavioral constraints.Note that we cannot enumerate a universal set of behavioral constraints. The specific

abstract properties contained in may be strongly dependant on the design disci-

pline and may also be dependant on the specific class of design objects being defined.

3) Behavioral requirements, , where “R” denotes requirements.

This specification is aimed at defining specific requirements on behavior. This categoryof sub-specification is fundamental in design, being frequently given as initial “behav-ioral specification” for a given system or device, either when the intended behavior forthe target system has ideal characteristics or when the complete behavioral descriptionof such a system is too complex to be directly managed, at least in the initial stages of

the design process. The abstract sub-specification is, thus, typically used for

validating and tuning approximate descriptions derived for the design object, or to helpthe derivation of a convenient realization structure for the design object.

Returning to our low pass filter example, in the VLSI digital circuit design discipline,these behavioral requirements are grouped into the lowpass frequency response specifi-cation, and include tolerances for the stop band of the filter and for the maximum devia-tion between the ideal and real filter amplitudes. In the context of the VLSI analogcircuits design discipline, the behavioral requirements of an operational amplifier can bedivided into static requirements and dynamic requirements. An example of a staticrequirement for an operational amplifier is the ability to maintain a dc voltage some-where between the power supply limits across a specified load resistor. This implies thatthe output stage should have a low Thevenin output resistance and should be efficient inorder to avoid large power dissipation in the amplifier. An example of a dynamicrequirement is the ability to charge or discharge a large capacitance at a specified voltagerate (also known as slew rate). This dynamic requirement does not require a low outputimpedance, but does demand high current. Some of these requirements may be contra-dictory in nature, thus requiring careful trade-offs to be achieved by designers.

As in the previous case, we cannot enumerate an universal set of behavioral require-

ments. The specific abstract properties contained in may be strongly dependent

Pi B D, ,o j,

Pi B C, ,o j,

Pi B R, ,o j,

Pi B R, ,o j,

Pi B R, ,o j,


59

on the design discipline, and may also be dependent on the specific class of designobjects being defined.

4.3.4.2 Characterizing the realization structure sub-specification

The realization structure sub-specification can be further partitioned into three sub-spec-ifications: realization structure description, realization structure constraints, and realiza-tion structure requirements.

1) Realization structure description, , where “D” denotes description.

is comprised of one abstract property,1

=

where:

is a realization structure description. A realization structure description can cor-

respond to a fundamental structural decomposition or to a non-fundamental structuraldecomposition. (see Definition 15) Note that, differently from its counterpart in thebehavioral partition, i.e., the behavioral description sub-specification, the realization

structure description sub-specification is comprised of a single property.2 An

example of a possible value for , in the context of the example given in Section

4.3.3.1, is d = CONDacdo(a, NOR2(b, c)).

2) Realization structure constraints, , where “C” denotes constraints.

This specification is aimed at defining specific constraints on the realization structure.This category of abstract properties is also fundamental in design, allowing the designer,for instance, to impose global constraints on model parameters for the primitive building

1. The realization structure description may evolve during the design process, yet new descrip-tions should also supersede the previous ones.2. Note that this property describes how the object is realized.

Pi S,o j,

Pi S D, ,o j,

Pi S D, ,o j,

Pi S D, ,o j, pi S D, ,

o j,

pi S D, ,o j,

Pi S D, ,o j,

pi S D, ,o j,

Pi S C, ,o j,


60

blocks, such as threshold voltages in VLSI design. It also allows the designer to con-strain the realization structure to specific topologies or to particular fabrication technolo-gies. For example, we may want to constrain the realization of a given digital circuit toCMOS fabrication technology or to a specific layout style, such as gate array. We maywant to constrain the design of the water tank to a given construction technique, and/orto a specific set of construction materials. The phase in which the designer derives con-venient values for some of the properties in this category is traditionally called concep-tual design.

Also, when the representation structure primitives at the ground abstraction level are toocomplex, the realization structure constraint sub-specification may be (alternatively)used, to specify how to manufacture the design object. The idea is to avoid the need for

specifying , i.e., the description of the realization structure for the design object.

Let us illustrate this last situation for the ground level of abstraction of the VLSI analogand digital design disciplines, i.e., the manufacturing process abstraction level. The real-ization structure description, at the manufacturing process level of abstraction, is a com-plex 3-D structural representation of transistors, capacitors, and so forth. Figure 10illustrates the 3-D structure of a MOS n-type transistor. [21]

At the ground level of abstraction, the designer is not expected to produce such a 3-Drepresentation structure of the design object, but instead, he or she are expected to pro-duce a mask layout for the design object. A mask layout [21] is a realization structureconstraint that, if complemented by proper model parameter values, describes how thedesign object should be manufactured.

Note that, as in the behavioral case, we cannot enumerate a universal set of realization

structure constraints. The specific abstract properties contained in may be

strongly dependent on the design discipline and may also be dependent on the specificclass of design objects being defined.

pi S D, ,o j,

p-doped substraten+ n+

PolyOxide

FIGURE 10 MOS n-type Transistor

Pi S C, ,o j,


61

3) Realization structure requirements, , where “R” denotes requirements.

This sub-specification is aimed at defining specific requirements on the realization struc-ture, thus allowing for realization structure validation, including model parameter tun-ing. Examples of such requirements are area and dissipated power, in general VLSIdesign or cost and resistance to earthquakes, in civil engineering. As in the behavioralcase, some of these requirements may be contradictory in nature, thus demanding care-ful trade-offs to be achieved by designers.

Note that, as in the behavioral case, we cannot enumerate a universal set of realizationstructure implementation constraints. The specific abstract properties contained in

may be strongly dependent on the design discipline and may also be dependent

on the specific class of design objects being defined.

4.3.5 Models and Behavioral Descriptions

Realization structure primitive building blocks are themselves abstract classes of design

objects which must necessarily be represented in their corresponding abstraction layer,1∆A,i, for the specific design discipline. Models are therefore behavioral descriptions of

realization structure primitive building blocks. So, according to the definition of

we may have several behavioral descriptions (models), for instance with differentdegrees of accuracy, for the exact same primitive building block, for instance, a CMOStransistor. On the other hand, the realization structure of a primitive building block, at itscorresponding abstraction layer, should be “atomic”, i.e., should be a “black box” with aset on inputs and a set of outputs. This is consistent with the definition of the realization

structure description sub-specification, , since it has only one abstract property

for a specific design object. This also means that different (alternative) models for prim-itive devices or processes should only be differentiated at behavioral level.

It is important to note that primitive behavioral building blocks, contrary to what hap-pens to their realization structure counterparts, do not have any corresponding abstractclasses of design objects. They are just formalisms, i.e., representation abstractions, usedto express particular relations between the inputs and the outputs of design objects.

1. The abstraction layer where they are defined as primitive building blocks.

Pi S R, ,o j,

Pi S R, ,o j,

Pi B D, ,o j,

Pi S D, ,o j,


62

4.3.6 Example

Let us now give some examples of possible property instances for the abstract class of

design objects “inverters”. A possible is illustrated below.


Description


Constraints


Requirements

BehavioralDescription

BehavioralConstraints

BehavioralRequirements

Transistor (Circuit) Level

CMOS,Rp, Rn,

, ,

Vdd, Vss

Area,Dynamic/

Staticpower dissi-

pation

Vout = f(Vin, ZL)

Iout = f(Vin, ZL)Selection ofapproximateequations forinput-output

characteristicsof transistors

VIL, VIH,

VOH, VOL,

Inverterdelay pair

Pio inv,

Pi S D, ,o inv, Pi S C, ,

o inv, Pi S R, ,o inv, Pi B D, ,

o inv, Pi B C, ,o inv, Pi B R, ,

o inv,

Vin Vout

Vdd

Vss

VTP VTP

VoutVIL VIH

Vin

VOH

VOL

t

dynamic

static

tf tr

Design Processes

63

Note that the behavioral constraints of the above example are a global form of indicatingthe accuracy intended for the behavioral descriptions of the realization structure primi-tive building blocks, i.e., the transistors.

4.4 Design Processes

In the previous section we discussed the semantics of the abstract properties that charac-terize abstract classes of design objects. It is now time to see how design objects of theseclasses are actually “designed”, i.e., how their corresponding property instances areactually manipulated during design processes.

4.4.1 Consistency Constraints

Two or more abstract properties are said to be non-independent if their values are con-strained by an arbitrarily complex relation. In design, a significant number of abstractproperties are non-independent. Abstract properties belonging to the same or to differentabstraction levels, and to the same or to different abstract classes of design objects, maybe constrained by a given relation. The relation and the corresponding abstract proper-ties constitute anabstract consistency constraint, or abstract restriction, denoted bycn.

Returning to our inverter example given in Section 4.3.6, examples of specific abstractconsistency constraints that may defined for an instance of the particular abstract class of

design objects, inverters, at the transistor level of abstraction would be:1

VIL = f(Vdd, VTP, VTN), or VIL = (3 Vdd + 3 VTP + 5 VTN)/8;

and

VIH = f(Vdd, VTP, VTN) , or VIH = (5 Vdd + 5VTP +3 VTN)/8.

The relation associated with a consistency constraintcn is denoted byRn. The sub-spec-ification (set of abstract properties) associated with a given abstract consistency con-straint can be further partitioned into two subsets: theconstraining sub-specificationandthe constrained sub-specification. For instance, for the above two consistency con-straints, the set of constraining properties could be Vdd, VTP, VTN, while the set ofconstrained properties could be VIL, for the first case, and VIH , for the second case.Note that defining which abstract properties belong to which group is design methodol-ogy and/or discipline dependent, and a complete discussion of this topic is beyond thescope of this research.

1. Assuming VSS = 0.


64

The constraining abstract sub-specification of a consistency constraintcn, denoted by

, where “f” denotes free, is defined as follows:

= ,

and, similarly, the constrained abstract sub-specification of a consistency constraintcn,

denoted by , where “d” denotes dependent, is defined as follows:

= ,

where “j” denotes the abstract class of design object and “i” denotes the abstraction layer∆Α,i in ∆.

Definition 17: An abstract consistency constraint, denoted bycn, isdefined by

cn = (Rn, , ),

where:

Rn denotes the relation of the consistency constraint; denotes the con-

straining abstract sub-specification of the consistency constraint; and

denotes the constrained abstract sub-specification of the consistency con-straint.

Definition 18: An active consistency constraint, denoted by cn,q, where “q”designates the particular instance ofcn in the design process, is defined by

cn,q = (Rn, , ),

where:

Rn denotes the relation of the consistency constraint; denotes the con-

straining sub-specification instance of the active consistency constraint; and denotes the constrained sub-specification instance of the active con-

sistency constraint.

Definition 19: An active consistency constraint, denoted cn, is said to bederived from an abstract consistency constraint cn, denoted cn ↵ cn, if the

Pcn f,

Pcn f, Pi cn f, ,o j,

j∪

i∪

Pcn d,

Pcn d, Pi cn d, ,o j,

j∪

i∪

Pcn f, Pcn d,

Pcn f,

Pcn d,

Pcn f, Pcn d,

Pcn f,

Pcn d,

Design Processes

65

constraining sub-specification and the constrained sub-specificationinstances of the active consistency constraint derive from the constrainingabstract sub-specification, and the constrained abstract sub-specificationinstance of the abstract consistency constraint, respectively. In short,

cn = (Rn, , ) ↵ cn = (Rn, , ),

if ↵ , and ↵ .

For each active consistence constraint, a predicate can be derived with the form _satis-fied_(cn), or equivalently, A(cn), whose value is “true” if and verify the

consistency constraint relationRn of cn, and “false” otherwise.

Definition 20: If A(cn) = true, then and are said to bepartial-

ly_consistentwith cn.

Definition 21: We say that an active consistency constraint isassociatedwith a given sub-specification instance when the constraining and the con-strained sub-specifications of the active consistency constraint are a sub-setof the sub-specification instance.

4.4.2 Constraint reasoning

We may say that a given design is complete when a ground level representation for thefinal design object is generated that simultaneously verifies all active consistency con-straints associated with the particular sub-specification instance. Assume for themoment thatRn, the relations defining the consistency constraints, are algebraic.1

Reasoning with a numerous set of multidimensional, typically non-linear, design consis-tency constraints can be an extremely complex task. Satisfying a large set of arbitrarilycomplex equality and inequality constraints is, in essence, a non-linear programmingproblem and, in general, is not analytically solvable. Although the general problem can-not be analytically solved, much can be done to assist the designer. Indeed, a large bodyof research exists on solving constraint problems, by propagation and relaxation, and ingeneral adequate formulation and simplification of constraint problems.

1. Sometimes such relations are not algebraic. Furthermore, sometimes these relations are toocomplex to be even analytically formulated. In such cases designers may have to rely on simula-tions.

Pcn f, Pcn d, Pcn f, Pcn d,

Pcn f, Pcn f, Pcn d, Pcn d,

Pcn f, Pcn d,

Pcn f, Pcn d,


66

The paradigm followed by constraint propagation methods is to assume that each activeconsistency constraint “is” a procedure indicating how some specific design decision orproperty value can be determined once other property values are known. For instance,returning to the inverter example given in Section 4.3.6, examples of two such “proce-dures” would be:

VIL = f(Vdd, VTP, VTN), or VIL = (3 Vdd + 3 VTP + 5 VTN)/8;

and

VIH = f(Vdd, VTP, VTN) , or VIH = (5 Vdd + 5VTP +3 VTN)/8.

These “procedures” can then be executed, in sequence, until the design is complete. It isimportant to note that this family of constraint propagation methods requires a depen-dence ordering or topological sorting of active consistency constraints.

Constraint propagation methods in general take advantage of the fact that satisfying alarge number of consistency constraints does not imply that all of the constraints must besolved simultaneously. The simplest type of constraint sets are indeed those which donot need any simultaneous solution of constraints. Such constraints are said to be seri-ally decomposable and algorithms exist for detecting serial decomposability in a con-straint problem and for ordering the solution sequence of such constraint sets.

When a constraint set is not serially decomposable, the related “procedures” have to besolved simultaneously. Methods and strategies have been developed for finding the cou-pled constraints and for solving the resulting constraint sub-problems. Such methodsattempt to isolate and identify the subsets of the entire constraining set which necessarilyhave to be solved simultaneously. [22] [23] [24] Note that solving coupled constraintsmay involve simplifying the “chain of relations” created by such constraints. A possibleway of breaking a chain of relations is to perform a single-degree-of-freedom search onone abstract property value, instead of solving all property values simultaneously. Aftergenerating such a property value, the remaining unknown property values in the chain ofrelations can be determined from an equal number of consistency constraints containedin the chain. The remaining consistency constraint in the chain can then be used to cal-culate a new value for the searched abstract property. If there is some error between bothvalues, a new value for the searched abstract property is guessed, and the procedure isrepeated. Iterations are carried out until the error is within an acceptable limit.

Some groups see constraint reasoning [22] [24] [25] as the basis for design theory. Notethe fundamental difference between a design theory that formalizes constraint reasoningrepresentations and methods and a design theory that is concerned with formally repre-

senting design spaces and describing design processes in general.1 In the first case, themain issues are actually related to reformulating and occasionally reordering the set of

Design Processes

67

constraints typically associated with properly specified design problems, such that theseproblems become directly solvable by specific heuristic methods, or by simulation based

methods.1 Note also that such reasoning can be performed in the context of specificCAD Tools, aimed at solving specific classes of design problems. In the second case, themain issue is adequately representing and describing design processes, by properly cap-turing and characterizing all elements, at conceptual level and/or design environmentrelated, that actually condition and/or contribute and/or cooperate in order to complete adesign process. These two areas are therefore complementary.

4.4.3 A high-level view of design processes

In this section we introduce and discuss the elements needed for characterizing anddescribing a design process.

The initial sub-specification instance for the object under designed (i.e., the abstract sub-specification that initially receives values) may vary significantly from design process todesign process. Note also that such initial sub-specification instance can, in principle,belong to any abstraction level∆Α,i defined for the discipline.

Typically, in designing a given final design object, the ultimate goal is to derive a value

for the property instance , in other words to produce the description of a

ground level realization structure for the target design object that satisfies all behaviorand realization structure related requirements and constraints (i.e., those stated by the

sub-specifications , , , and ) at each abstraction level

∆Α,i traversed during the design process.

We said “typically”, because, for some design disciplines, simply deriving ,

i.e., the realization structure description for the design object, may either be not enough,or may be simply inadequate, in terms of complexity.

We already alluded to the VLSI digital and analog cases, where at the manufacturinglevel, the goal is to specify how the final design object should be produced or manufac-tured, instead of fully representing the complex 3-D realization structure of the designobject itself. So, the design is considered complete when the designer produces an ade-quate mask layout, which is a property belonging to the realization structure constraintssub-specification.

1. Our work belongs to the second category.1. Note that there is no solution for general constraint problems.

pG S D, ,o j,

Pi S C, ,o j, Pi S R, ,

o j, Pi B F, ,o j, Pi B C, ,

o j,

pG S D, ,o j,


68

Note also that in other cases, such as in software engineering, in which there is no finalmapping to an actual physical device, but instead to a “process”, both the realization

structure description, , and the behavioral description, , have to be

fully derived. In such cases, , i.e., the realization structure description,

describes the software architecture, meaning, processes and communication and syn-

chronism protocols, while , i.e., the behavioral description sub-specification

specifies the actual programs to be executed by such processes. The reason for this “par-ticular case” is that, when the object being designed is an actual physical system, thebehavior is inherent to the structure. In other words, a specific behavior is uniquely

determined by the realization structure, and therefore only needs to be speci-

fied at the end of the design process. Note that this does not happen when we are design-ing a “non-physical” product, as is the case of software programs in the software

engineering design discipline, and therefore we need both and .

Hardware-software co-design can be seen as an intermediate case which can also behandled by this design theory.

Typically real world design is under-specified in that for each Po,j we have a set of alter-

native realization solutions that meets Po,j. Furthermore, frequently the set of

specification relations defined by the set of active consistency constraints are just toocomplex to be considered at once. Moreover, the complexity of some of these constrain-ing relations is sometimes so high in nature that it may be virtually impossible in somecases to derive an analytical solution to the problem so that designers will have to relyon simulations.

As mentioned above, active consistency constraints represent the set of arbitrarily com-plex relations which must be verified among the properties that compose the specifica-tion instance of a given object being designed. Due to the reasons summarized in theprevious paragraph, it is virtually impossible for most real world design cases to derive aconsistent and complete specification instance for the design object from the initiallygiven sub-specification, in just one problem solving step. So, typically the design pro-cess will consist of an arbitrarily complex partially ordered sequence ofgenerationsdesign steps interleaved withtest design steps.

Accomplishing a generation design step typically involves the selection of a sub-specifi-cation (among those instantiated in the design process) and the selection of a subset ofthe associated active consistency constraints, and after that: (1) the generation of prop-erty values for abstract properties that still do not have an attributed value, which is typ-

PG S D, ,o j, PG B D, ,

o j k, ,

pG S D, ,o j,

PG B D, ,o j,

PG S D, ,o j,

PG S D, ,o j, PG B D, ,

o j,

TPo j,o j,

Design Processes

69

ically called a synthesis design step; or (2) the generation of new property values forabstract properties that already have a value, thus modifying these existent values, whichis typically called an optimization design step.

Note thepartial scope in which a generation design step typically takes place, either byonly considering a subset of the relevant active consistency constraints while derivingvalues for abstract properties and/or by frequently considering only a ‘simplified’ ver-sions of such consistency constraints. Such a partial scope during generation leads to thepossibility of introducing inconsistencies, for instance, relative to the remaining, not yetconsidered, active consistent consistency constraints.

Test steps are aimed at detecting these inconsistencies. Accordingly, test steps typicallyconsist of selecting a particular sub-specification in which all property instances havealready attributed values, and then selecting all active consistency constraints associatedwith this particular sub-specification, and finally calculating the value of the predicateA(cn) for each of the above consistency constraints.

When the value ofA(cn) is false,backtracking or optimization may be considered. As ageneral rule, backtracking occurs when at least one design decision associated with aconstraining property referred by any of the consistency constraints active in the designprocess, is undone. Otherwise, we say that optimization is occurring. Notice that, due tothe interdependencies which may occur among the several active consistency constraintsof a given design process, an optimization step may also imply a backtracking step.

We may see each design step category as actually accomplishing a specificdesign objec-tive of a similar nature. In other words, since a design step is indeed a problem solvingstep, each particular abstract design objective defines a general category of design prob-lem whose solution is achieved by means of a design step. Being even more specific,design objectives are aimed at issuing specific design goals in the design process con-text, such that the particular goal and the relevant property instances (in the design pro-cess context) will actually constitute a completely defined design problem. So, abstractdesign objectives, denoted bygα, define possible problem solving design goals, denotedby gα, which can be pursued in design processes, and also define the control knowledgeassociated with achieving these design goals. Accordingly, in design we have twoabstract classes of objectives: generation abstract objectives, denoted byggeneration, andtest abstract classes of objectives, denoted bygtest. ggeneration objectives can be furtherspecialized into synthesis abstract design objectives, denoted bygsynthesis, and optimiza-tion abstract design objectives, denoted bygoptimization.

Design operators are design functions, implemented by means of algorithms and/or pro-

cedures,1aimed at accomplishing synthesis, optimization, and test design objectives.2


70

The successful application of a design operator is a design step. In order to accomplishspecific design objectives, design operators are applied to particular sub-specificationinstances in a given design process in order to derive, modify, or extract property values,preserving the relations associated with the set of associated active consistency con-straints, for this same design process.

Notice that the exact same type of objective, applied to sub-specifications defined fordifferent abstract classes of design objects, may imply totally different operator imple-mentations, i.e., algorithms or procedures, for accomplishing the corresponding designobjective. Notice also that we may have a significant variety of alternative algorithms orprocedures to actually perform the “same” category of design step for the exact sameabstract class of design objects. Some of these operators may be more effective for oneparticular region of the solution space, others more effective for a different region. So,

we may have alternative operator implementations for performing a given design step.1

Notice that the definition of abstract design objectives,gα, is necessary, in addition tothe definition of abstract design consistency constraints,cβ, since in a design process theexact same set of consistency constraints may be involved in realizing synthesis, optimi-zation, and/or test design objectives. So, design objectives are necessary for defining theflow of control in a design process.

Abstract objectives,gα, may also have their own abstract specification, denoted byPg,α.

The abstract properties inPg,α are aimed at: characterizing the specifics of the particularproblem solving methods that may be used for accomplishing the abstract objective and/or conveying any additional information that may be needed by such problem solvingprocesses. Examples of objective related abstract properties are stimuli for test (simula-tion) objectives and stopping criteria for optimization objectives.

The existence ofPg,α creates the need for introducing a new classification level in ourtaxonomy of abstract specifications associated with a design process. Indeed, the firstpartition that can be done, in the general set of abstract properties that may be definedfor characterizing a given design discipline, is betweendesign object related sub-specifi-

cations, or Po’s, extensively discussed in Section 4.3, andobjective related sub-specifi-

cations, orPg’s, being introduced here.

1. Derived from first principles or from heuristic knowledge.2. In other words, operators solve problems stated by the design objectives.1. As discussed in Section 4.4.2 on page 65, the complexity of design constraint problems can bevery high and no general solution exists for such problems, yet avarietyof heuristic (and general)methods is available for partially and differently addressing such classes of problems.

Design Processes

71

Abstract consistency constraints,cn, can also be defined for objective related abstractproperties. Actually, such consistency constraints can freely intermix this last categoryof properties with the design object related properties. This allows for restricting valuesof objective related abstract properties in terms of specific abstract classes of designobjects being targeted or the abstraction level(s) at which the objective is being accom-plished.

4.4.4 Representing design processes and projects

In this section the concepts of design object instance, design process hierarchy, designobjective, design state, design problem, and design space are formally introduced.

Definition 22: A design object instance “k” of the abstract class of design

objects “j”, denoted by , is an ordered set (by abstraction layer∆Α,i)

of sub-specification instances such as:

∀i, if ∈ then ↵ , where “i” denotes the

abstraction layer∆Α,i in ∆.

Note that a given specific design object instance can, in general, be mapped onto morethan one design object. Note also that since a given design process may have several dis-tinct design object instances of the same abstract class of design objects, in order toidentify a design object instance in a given design process we need an ordered pair ofidentifiers (j, k), where “j” denotes the abstract class of design objects and “k” denotesthe particular design object instance of class “j” in the design process.

Definition 23: During the design process, a two dimensional hierarchy ofsub-specification instances is created, called thedesign process hierarchy,

denoted by , where “j” identifies the abstract classes of

design objects and “k” identifies the specific design object instances of theseclasses, in the context of the particular design process.

The hierarchy of abstraction levels defined in∆, the design hierarchy for the targetdesign discipline, defines thevertical or abstraction dimension of the design processhierarchy. Functional and structural decompositions, together, define the second dimen-sion of the design process hierarchy that we designate thehorizontal or decompositiondimension. These two dimensions are represented in very simple terms on Figure 11.

O∆o j k, ,

Pio j, O∆

o j k, , Pio j, Pi

o j,

DO∆

o j k, ,

k∑

j∑∆


72

More specifically, the abstraction dimension of the design process hierarchy defines apartition in the specification instance contained in each design object instance repre-

sented in the design process hierarchy. Such partitions, denoted by for a design

object instance , are directly derived from the corresponding partitions defined

by the abstraction dimension of∆ in the abstract specifications of the abstract class of

design objects instantiated in , i.e., the abstract class of design objects “j”.

Structural and functional decompositions are the only allowed mechanisms for instanti-ating new abstract classes of design objects in a design process hierarchy, i.e., for creat-ing new design object instances and adding them to the design process hierarchy.

Therefore, such new design object instances are always the ‘components’1 of decom-posed design object instances that were already represented in the design process hierar-chy. Note that these components are first instantiated at the exact same abstraction level

FIGURE 11 Simplified View of a Design Process Hierarchy

Abs

trac

tion

Obj1.SubObj2.l1

Obj1.SubObj3.l1

Obj1.SubObj4.l1

Obj3.SubObj5.l1


Obj1.SubObj2.l2

Obj1.SubObj3.l2

Obj1.SubObj4.l2

Obj3.SubObj5.l2


Decomposition

O∆A i,o j k, ,

O∆o j k, ,

O∆o j k, ,

Design Processes

73

at which the ‘parent’ (just decomposed) design object instance is represented when thedecomposition occurs. Functional and structural decomposition are, thus, the mecha-nisms that “populate” the horizontal dimension in the design process hierarchy.

Note also that when new design object instances are incorporated into a design processhierarchy, in a given abstraction layer∆Α, i, a set of consistency constraints, represent-ing the relations among these elements, should be instantiated (activated) in the designprocess. More specifically, such constraints are aimed at relating the sub-specification ofthe original design object instance, or ‘parent’ design object instance, with the sub-spec-ifications of the ‘component’ design object instances, also called ‘descendant’ designobject instances. Notice also that, as the design progresses into different abstraction lay-ers∆Α, i, new consistency constraints should also be activated, relating these sub-speci-fications throughout the abstraction layers and inside each layer. In conclusion, activeconsistency constraints may relate properties of the same or of different design objectinstances and may also relate properties defined at a common or at different abstractionlevels∆Α, i.

Let us illustrate the concept of a design process hierarchy in the context of a design pro-cess. In order to do so, we return to the example presented in Section 4.3.3.1, and discussthe development of a final design object for implementing the realization structuredefined by d = CONDacdo(a, NOR2(b, c)). For simplicity purposes we will represent thedesign process hierarchy in terms of the realization structure description property

, yet the concepts being illustrated for this particular property are directly appli-

cable to all abstract properties in our proposed taxonomy. Note finally that the designobject instances represented in our example of a design process hierarchy will be identi-fied just by a name, again for simplicity.

So, the realization structure for our target design object starts by being defined at logicallevel, as shown in Figure 12. The modeling primitives for the abstraction level areshown within a square. Note that the realization structure description for the targetdesign object corresponds to a non-fundamental structural decomposition, since it con-tains the non-primitive realization structure building block “COND”. Note that CONDitself becomes a design object instance, i.e., a new design object that has also to bedesigned. In Figure 12 this new design object instance is designated “Conditional designobject”. Note also the consistency constraint c1, relating the two final design objects cur-

rently represented in the design process hierarchy.1

1. Defined by the utilized non-fundamental realization structure building blocks or non-funda-mental behavioral constructs.

pi S D, ,o j,


74

In Figure 13 we show a second snapshot of the design process hierarchy for the samedesign process. Two abstraction levels are at this point represented in the design processhierarchy, the logic level of abstraction and the transistor or circuit level of abstraction.The realization structure primitives at the circuit level of abstraction are representedwithin a circle. Note also in the example the indication of active consistency constraints,denoted c1 to c6, relating properties from the same and from different abstraction levels.

In Figure 13 we see that the realization structure description for the target design object,at the transistor level, is also a non-fundamental structural decomposition, since the real-ization structure building block “COND”, at the transistor level, is also a non-primitivebuilding block. Note that this does not necessarily need to occur. In fact, the use of a dif-ferent synthesis operator could have lead to a different outcome for the same design pro-cess. For instance, Figure 14 shows an alternative outcome for this same design process.As can be seen in this case, the realization structure description for the target final designobject at the transistor level is a fundamental structural decomposition. In this newexample, the synthesis operator that refined the “target design object” representationfrom logic to transistor level, started by ‘flattening’ the realization structure descriptionof this design object instance at logical level, thus eliminating the existence of the designobject instance ‘COND’ at lower levels of abstraction.

1. We would have a set of consistency constraints relating different properties of both designobject instances, and not just one. We represented just this “global” consistency constraint forsimplicity purposes.

Target design object Conditional design object

CONDai

a

b

c

x

da

x

do

LOGIC LEVEL

FIGURE 12 Illustrating design process hierarchy

c1

Design Processes

75

Definition 24: An abstract design objective, denoted by gα, is defined by

gα = (gα,Mα, Pg,α)

where

gα denotes the design goal associated with the abstract objective;

Mα denotes the possible means for achieving the objective, i.e., defines the

control knowledge associated with the specific objective;1

Pg,α denotes the objective related abstract specification.

Abs

trac

tion

Decomposition


CONDai

a

b

c

x

da

x

d

CONDa

i

Vdd

Vss

o

o

VddVss

Vdd

Vss

a

b

c

d

x

VddVss

Vdd

a

x

d

Vss

Vss

Vdd

LOGIC LEVEL

TRANSISTOR LEVEL


c1

c2 c3

c4

c5

c6


76

Definition 25: An active design objective, denoted by gα,q, where “q” des-ignates the specific instance of the abstract design objectivegα in the particu-lar design process, is defined by:

gα,q = (gα, , Pg,α, q, status)

where:

gα denotes the instantiated abstract design objective;

1. See Definition 29.

Abs

trac

tion

Decomposition


CONDai

a

b

c

x

d

a

x

do

Vdd

Vss

a

b

c

VddVss

Vdd

d

Vss

Vdd

LOGIC LEVEL

TRANSISTOR LEVEL


c1

c2

c5

Vss

SYNTHESIS

a

Gα q,SUB

Design Processes

77

denotes the set of sub-objectives generated by gα,q1;

Pg,α, q denotes the sub-specification for gα,q; and

statusindicates the status of the objective gα,q.

Possible values for status are ACCOMPLISHED, FAILED, READY, NOT_READY,BEING_DIRECTLY_ADDRESSED, BEING_INDIRECTLY_ADDRESSED. It isimportant to note that, for some types of objectives, such as optimization, status infor-mation cannot be derived just from inspecting the existence of specification values, thuscreating the need for the variablestatus.

Definition 26: A design state, or the current state of a design process, isdefined by:

sn = < , , , >

where,

denotes the design process hierarchy;

denotes the set of all active design objectives instantiated in the

design process;

denotes the set of all active consistency constraints defined for the

properties contained in , and in ;

denotes the set of all predicates of type “A” or “_satisfied_” that can be

defined for .

Note that all design process data developed so far, including design object representa-

tions, is part of the design state sn. Note also that explicitly stores, for each active

1. See Definition 33.

Gα q,SUB

DO∆

o j k, ,

k∑

j∑∆ GD

∆ CD∆ AD

∆

DO∆

o j k, ,

k∑

j∑∆

GD∆

CD∆

DO∆

o j k, ,

k∑

j∑∆ GD

∆

AD∆

CD∆

AD∆


78

consistency constraint represented in the design state, whether such consistency con-straint is being satisfied or not.

Each , which denotes a particular active objective instance “q” of the

abstract class of objectives “α”, instantiated in a given design process, defines subsets in

, , and , denoted respectively by , ,

and .

Definition 27: Given a current design state sn, each active design objective

defines adesign problem in sn, with the form:

= < , gα,q, , >

where

denotes all abstract class of design object related properties

relevant for achieving the active design objective instance gα,q;

denotes all consistency constraints associated with

;

denotes the set of predicates “A” or “_satisfied_” that are relevant

for the accomplishment of the design process objective instance gα,q.

Note that =∅.

gα q, GD∆∈

DO∆

o j k, ,

k∑

j∑∆ CD

∆ AD∆ D

O∆o j k, ,

k∑

j∑∆ gα q,,

CD∆ gα q,,

AD∆ gα q,,

gα q, GD∆∈ sn

α q,

snα q, D

O∆o j k, ,

k∑

j∑∆ gα q,,

CD∆ gα q,,

AD∆ gα q,,

DO∆

o j k, ,

k∑

j∑∆ gα q,,

CD∆ gα q,,

DO∆

o j k, ,

k∑

j∑∆ gα q,,

AD∆ gα q,,

AD∆ ggenerationq,,

Design Processes

79

So, the set of all problems that can be derived from a design state sn, denoted as ,

has cardinality equal to the cardinality of . Any new problem added to sn will, in

principle, remain in sn, and thus in , until the end of the design process, with the

associated active objective eventually reaching ACCOMPLISHED status. Backtrackingis the only way of removing a problem from sn.

Definition 28: A design step is adesign state transitionfrom state sn to statesn+1, indicated by:

where the transition function, , can be implemented by any operator

Θα that may be suitable for accomplishing the active design objective gα.

The operatorΘα maps sn into sn+1 by partially considering the relevant con-

sistency constraints represented in the design problem ,

which is defined in sn by the active design objective gα,q. In short:

Θα ( ) = sn+1

Observe that at first glance, we might be lead to think that there is some redundancy inseparately specifying objectives, operators and consistency constraints. Indeed, thiswould be the case if design knowledge was complete and ideal, and if we always hadavailable a set of CAD tools (operators) that properly implemented all conceivable con-straint satisfaction value transformations and/or propagations directly derived from suchconsistency constraints. In an “ideal context”, given a set of constraints, the CAD toolable to properly address the specific constraint problem would be uniquely determined.Unfortunately this is not generally the case, and frequently CAD tools implement onlysimplified versions of such constraint relations, yet still produce acceptable results. Fur-thermore, we may have different CAD tools implementing different weak methods foraddressing the same class of constraint problem. So, the notion of having a limited set ofavailable operators, that may or may not contain one adequate for solving the specificdesign problem at hand, constitutes quite an important characteristic of design pro-cesses, since it may strongly influence their course of action. Thus there is no redun-dancy in independently specifying operators, since in real design processes they are notuniquely determined by sets of constraints and objectives.

SnT

GD∆

SnT

sn sn+1.

Tgα,q

Tgα q,

CD∆ gα q,,

snα q,

snα q,


80

As mentioned above, an abstract design objectivegα is defined by:


where Mα denotes the possible means for achieving the objective. We will now defineMα.

Definition 29: Design objectives may be achieved in two different ways,which we call modes of achievement.These aredirect achievement,

denoted by , and indirect achievement, denoted by , where

.

We say that an active design objective achieved in direct mode was directlyachieved and that an active design objective achieved in indirect mode wasindirectly achieved.

Definition 30: An active objective gα,q can bedirectly achieved if there

exists an available operator that is able to directly solve the design prob-

lem , defined by gα,q in sn.

Note that the generic specification provided by is thus trivial.

If such an operator is not available, the active objective gα,q can only be indirectly

achieved, according to the specification provided by . is thus aimed at specify-

ing how a generic design problem associated with the abstract objective gα should bedecomposed into small, less complex, subproblems, in order to solve the impasse gener-

ated by the unavailability of a suitable, direct, design operator. In other words,

should specify forms of generating subsets of , , and

, and arrange these subsets in terms of new design problems, defined in sn.

MαD Mα

I

Mα MαD Mα

I , ⊆

Θxα

snα q,

MαD

MαI Mα

I

MαI

DO∆

o j k, ,

k∑

j∑∆ gα q,,

CD∆ gα q,,

AD∆ gα q,,

Design Processes

81

So, a way of defining these subsets is what needs to be specified in as part of the

definition of the abstract class of design objectivesgα. Note that the abstract design

objectives associated with the new generated design subproblems, denoted by , are

always of the same type of the abstract objective associated with the original design

problem, denoted , i.e.gα, and, therefore, they do not need to be explicitly specified

in .

Note finally that, for each new sub-problem resulting from the subsets defined by

, a new active design objective gα,r is created and incorporated in sn, such that

.

Definition 31: The indirect mode of achievementof an abstract objective

gα, denoted by , specifies how a generic design problem associated with

the abstract objective gα should be decomposed into small, less complex,

subproblems. is as an ordered set of criteria that allows for the specifi-

cation of subsets in .1 The criteria are:

1. Create subsets by different abstract classes of design objects;

2. Create subsets by different abstraction level;

3. Create subsets by different general categories of abstract specifications(behavioral versus structural);

4. Create subsets by different subcategories of abstract sub-specifications(description, requirement, constraint);

5. Create subsets by abstract property.

1. Note that the remaining subsets (on and ) can be derived from this

last one. Note also that such subsets may share common elements.

MαI

snα r,

snα q,

MαI

snα r,

MαI

gα r, GD∆∈

MαI

MαI

DO∆

o j k, ,

k∑

j∑∆ gα r,,

CD∆ gα q,,

AD∆ gα q,,


82

So, a particular may constitute from none to all of these criteria. The relative order-

ing should be also specified, if different from the one shown above. The ordering indi-cates the sequence according to which the problem decomposition criteria should be

tried for a given design problem .

Definition 32: A sub-problem directly generated from a problem

has the form:

= < , gα,r, , >

where,

gα,r is the new active objective defining the sub-problem;1

;

;

and

;

thus implying the partial inclusion relation,2

.

As said before, an active design objective is defined as follows:

gα,q = (gα, , Pg,α,q).

1. Note that gα,r is of the same abstract class gα of the original active objective gα,q;

2. It is only partial inclusion since excludes the active design objectives component of and

.

MαI

snα q,

snα r, sn

α q,

snα r, D

O∆o j k, ,

k∑

j∑∆ gα r,,

CD∆ gα r,,

AD∆ gα r,,

DO∆

o j k, ,

k∑

j∑∆ gα r,,

DO∆

o j k, ,

k∑

j∑∆ gα q,,⊆

CD∆ gα r,,

CD∆ gα q,,⊆

AD∆ gα r,,

AD∆ gα q,,⊆

snα q,

snα r,

snα r, °sn

α q,∠

Gα q,SUB

Design Processes

83

denotes the set of active design objectives generated by gα,q in case it was indi-

rectly achieved.

Definition 33: The set of activedesign sub-objectives generated by gα,q,

denoted , is defined by:

= gα,r |

where the common index “n” guarantees that only immediate descendant

active objectives of gα,q are represented in .

If gα,q happens to be directly achieved, then =∅

Definition 34: For a given current design state sn, the nextset of problemsthat may be concurrently solved, in parallel, or independently, denoted by

, is the subset of those problems contained in :

(1) whose associated active consistency constraints have disjoint constrainedspecifications; and

(2) whose constraining sub-specifications, defined for the active consistencyconstraints, are composed by properties which already have a value.

All such problems will have their associated active objective withstatus = ‘READY’.

Note that the ordering/sequencing in the assessment of design (sub)problems, if strictlybased on consistency and on design methodology issues, can and should be representedin terms of consistency constraints, and, thus, influence the set of problems that at agiven moment are ‘READY’ to be addressed.

Definition 35: Thehistory of a design process, denoted by S+, contains theordered sequence of all design steps undertaken so far in the design process.The original design state is denoted by s0. So, for a current design state sn, S+has the general form shown below,

S+ = (Θα , ), (Θβ , ), ....,(Θγ , ).

Definition 36: The design spacewhere design processes for a given designdiscipline take place, denoted byDP , is defined by:

DP = <∆, G, C,Ω, sn, S+>

Gα q,SUB

Gα q,SUB

Gα q,SUB sn

α r, °snα q,∠

Gα q,SUB

Gα q,SUB

SnR Sn

T

s0α q, s1

β r, snγ p,


84

where,

∆ represents the design hierarchy for the design discipline;

G represents the set of all abstract design objectives for the design discipline;

C represents the set of abstract consistency constraints that can be defined forthe design discipline;

Ω represents the set of operators available for the design discipline;

sn represents the current design state;

S+ represents the history of the design process.

Note that∆, G, C, andΩ represent the knowledge dimension of the design space, while

sn and S+ represent the dynamic data dimension of the design space.

Definition 37: A design project, denotedP, consists of a set ofalternativedesign processes, i.e., a set of design processes sharing the same s0:

P = <∆, G, C,Ω, Sn, Σ+>

where


G represents the set of all abstract design objectives for the design discipline;

C represents the set of abstract consistency constraints that can be defined forthe design discipline;


Sn represents the set of current design states in the project, one for each alter-native design process;

Σ+ represents the set of design histories in the project, one for each alterna-tive design process.

Note that the knowledge component of the design space is not repeated for each alterna-tive design process contained in a given project.

4.5 Discussion of the applicability of the proposed theory of design

The theory of design that we have proposed can be directly applied in all design disci-plines that share the fundamental assumption on which the theory is based, that is thatthe design problems are of thenearly decomposable type. This means that even if theconsistency constraints relating the property instances characterizing a given designobject are too complex to be considered at once, there must be a possible domain depen-

The Y-Chart

85

dent means for: (1) simplifying the constraint problem, either by only partially consider-ing the relations between the original constraints and/or by simplifying such relations;and (2) establishing some sort of partial ordering among the resulting, simplified, consis-tency constraints. Such ordering should guarantee that, in most cases, a satisficing prob-lem solution can be found in a limited amount of time.

In real world design problems, when consistency constraints which are too complex tobe dealt with at once are simplified into less complex and more manageable consistencyconstraints, as a general rule, the most pervasive resulting consistency constraints arethen used to define synthesis and/or optimization design operators, while the less perva-sive ones are used to define test operators. A “generation-test” design loop is thus cre-ated, aimed at gradually refining possible solutions.

Notice that concepts such asabstraction and hierarchy are means for exploring thenearly decomposable assumption, for complexity control purposes. The nearly decom-posable nature of problems is a fundamental assumption of our theory because all tech-niques for controlling design complexity formulated in the theory rely on thisassumption. So, if a particular complex design discipline does not allow such anassumption, then the proposed theory of design is not applicable to that discipline.

Conversely, we can claim that our formal design theory is not limited to just design dis-ciplines. Indeed, the proposed theory of design can in principle be directly applied to anyproblem solving discipline that shares the above fundamental assumption. In [26] wecan find the direct use of the problem space proposed in our theory for solving two prob-lems that are classical in the computer science literature, and that are indeed orthogonalto design: a robot manipulator task planner solving problems in the blocks world [27],and the travelling salesman problem [28]. In [26] we can also find a third application ofour theory of design, but in this case in solving a “design” problem, specifically, thedesign of the rehabilitation of a manufacturing plant.

4.6 The Y-Chart

The Y-Chart, also called tripartite representation of design, is a widely accepted form ofexpressing the hierarchy of design representations for digital design processes. Becauseof this we feel that it is worthwhile discussing it in order to illustrate the concepts intro-duced by our theory of design. The figure below shows a version of the Y-Chart, as pre-sented in [29]. Table 2 shows the Y-Chart in table version, as presented in [30]. Bothversions are consistent with each other.


86

It is interesting to note that the Y-Chart is somewhat imprecise since it considers threefundamental dimensions in design, namely behavior, structure and physical, while infact we believe that only two fundamental dimensions exist: realization structure andbehavior. Let us now see what is actually represented in each of the columns of the tableversion of the Y-Chart.

The behavioral column in Table 2 enumerates the main families of languages and/or for-malisms used for specifying behavioral descriptions at each abstraction level in the digi-tal hierarchy. Examples are: register transfer micro-operations for register transfer level;boolean equations for logic level, and network equations for transistor level.

Table 2:

LEVEL Behavioral Structural Physical

System (PMS) communicatingprocesses

processors,memories,switches

cabinets

Algorithmic(ISP)

input-outputtransform

single processormemory unit

boards

Register-Trans-fer (SCS)

register-transfermicro-opera-

tions

register, ALUs,multiplexers,

busses

ICs, macro cells

Logic boolean equa-tions

gates, flip-flops standard cells,gate arrays

Transistor network equa-tions

transistors,wires

mask geometry

Cells, ModulesChipsBoardsCabinets

PolygonsDifferential Equations

Boolean expressionsRegister Transfers

AlgorithmsSystemsProcessors

Memories, ALUsRegisters

Gates, FFsTransistors

BehaviorStructure

Geometry

Y-Chart

The Y-Chart

87

The structural column shows the primitive realization structure building blocks, definedfor each abstraction level of the digital hierarchy. Examples are: processors and memo-ries for the system level of abstraction; single processors and memory units for the algo-rithmic level; registers, ALUs, multiplexors, and busses for Register Transfer Level ormicro-operations level; and gates and flip-flops for the logic level.

Unfortunately, the physical column in Table 2 is problematic. If we consider the threehighest levels of abstraction of the table, i.e., System, Algorithmic, and Register Trans-fer, we could conclude that the physical dimension of the Y-Chart is aimed at showingtypical non-primitive realization structure building blocks. Examples are: cabinets forsystem level; boards for algorithm level; and ICs and macro cells for Register TransferLevel. However, as we go down in the hierarchy the physical column inexplicably startsshowing how to implement the specific realization structure at the next lower level ofabstraction. Indeed, at the lowest level of abstraction in Table 2, called the transistorlevel, we find:

• behavior = differential/network equations;

• structure = transistors, wires;

• physical/geometrical = polygons, layout masks.

The transistor is indeed a fundamental realization structure building block at circuit ortransistor level. The behavior of a circuit represented at transistor level can indeed berepresented by differential equations as indicated in the Y-Chart. However, the mask lay-out of a design object represented at circuit or transistor level is not a description of anon-fundamental realization structure building block, as it could be suggested by onlylooking to the three high level geometric/physical descriptions depicted in the Y-Chart.

In fact, the mask layout is a realization structure constraint belonging to an immediatelylower level of abstraction, that we call the manufacturing process level of abstraction.This level constitutes the ground abstraction level for the discipline of VLSI digital andanalog circuits. Note that the realization structure description, at the manufacturing pro-cess level of abstraction, is a complex 3-D structural representation of transistors andstructure related requirements and constraints, at this level of abstraction, are values ofjunction depth, impurity concentrations, sheet resistances, and oxide thicknesses, asmentioned in Section 4.3.4.2. So, clearly, the transistor level is an abstraction (i.e., sim-plified view) of the manufacturing process level. Therefore, the Y-Chart, in its lower lev-els of abstraction, actually intermixes abstraction levels. It is important to note that,whatever the intention of the physical column, it must be consistent throughout all levelsof abstraction depicted in the Y-Chart. Furthermore, the abstraction levels of the digitalhierarchy should be properly indicated in this chart. In conclusion, we find the Y-Chart,as it is known right now, a quite imprecise and a confusing way of conveying designconcepts.


88

4.7 Closing Comments

A formal theory of design has been proposed to be a complete and integrated character-ization of design as a problem space. This theory is general enough for describing a vari-ety of design processes from distinct design disciplines, not only the VLSI circuit designprocess. The proposed design formal theory can be useful for:

- conception and development of new CAD tools and, particularly, new CAD Frame-work meta-tools, that address all kinds of design and/or design process planning andmanagement problems;

- characterization of existing CAD tools keeping in mind, among other things, theirproper integration in design environments;

- properly conveying the overall logic behind design in a very systematic and thus clearform.

Note that our main purpose in developing such a design theory was not to develop a for-mal body in order to demonstrate particular properties of design, but rather to providethe CAD community with a logical, complete and integrated vision of design processes.In the next chapter we propose a representation of design spaces based on this designtheory.

Introduction

89

CHAPTER 5 Design SpaceRepresentation

5.1 Introduction

Based on our theory of design and on our design process planning and management para-digm, we can develop a domain independent and heuristically and epistemologically ade-quate general representation of the design space. Through such a representation we canmodel design processes as a problem solving activity that takes place in this design space.

Our proposed design space representation consists of knowledge level structures and datalevel structures. Considering the definition of a design space given in Chapter 4,

DP = <∆, G, C,Ω, sn, S+>

where,


G represents the set of all abstract design objectives;

C represents the set of abstract consistency constraints that can be defined for thedesign discipline;


sn represents the current design state;

S+ represents the history of the design process;

we see that, in order to represent the design space, we need to develop knowledge levelstructures for representing∆, the design hierarchy,G, the set of abstract design objectives,andC, the set of abstract consistency constraints, for the specific design discipline. And we

also need to develop data-level structures for representing sn, the design state, and S+, thedesign process history.

A comment is in place here about the set of operatorsΩ. In Section 3.2 we discussed howthe specific behavior of some design operators (CAD tools) may be difficult to accuratelycharacterize. We also pointed out that the configuration of design operators available to

design environments may change with some frequency.1 In order to address this difficulty,in our representation the set of design operatorsΩ is assumed to be complete, i.e., it is

assumed that an operator exists for solving each particular design problem.2 Impassesderived from operators inexistence or inadequacy are solved as explained in Section 5.2,

Design Space Representation

90

when we discuss in detail a design agent cooperation and coordination protocol for ourdesign process planning and management paradigm. As will be seen, our proposed designspace representation reflects a careful trade-off between generality, adequacy and simplicity.

The remaining of this chapter is organized as follows. In the next section we describe theknowledge structures necessary for representing the design space, i.e., we describe knowl-edge structures for representing∆, G, andC. Then, in Section 4.3, we describe data struc-

tures for representing the design state, sn, and the design process history, S+. Finally, weconclude by illustrating how transformational synthesis, and structural and functionaldecompositions, as well as further recompositions, are represented given the proposedknowledge level structure of a design space.

5.2 Knowledge level structure of a design space

This section describes the basic knowledge structures needed for representing the designspace. We propose a knowledge-level structure for a design space that is modularly orga-nized in terms of a set of basic knowledge structures calledtemplates. Some of these tem-plates are complex in the sense that they are built up in terms of other, less complex,occasionally primitive, knowledge structures or templates. The main idea was to derive a“building block” like global knowledge organization that, when mapped onto a convenientknowledge base implementation technology, would result in a flexible and extendable gen-eral knowledge organization.

5.2.1 Defining Design Hierarchy.

In our proposed knowledge structure of a design space, design domain template graphs

GFTand facet template trees are the complex knowledge structures used for defining a

specific design hierarchy∆ for a particular design discipline. Figures 15 and 16 illustrate,respectively, a possible graph of design domain templates and the corresponding extracted

tree of facet templates.1 The tree can be derived from the graph as follows: for each specific

1. Some changes may be “permanent” (for instance, a new CAD tool becoming available to thedesign environment) while others may be “temporary” (for instance, when a networking problemmakes a set of CAD tools unreachable for a specific period of time).2. This assumption is made at the moment of plan generation.1. The graph instance shown in Figure 15 is incomplete, as is the corresponding facet tree. Notethat the purpose of this example is not to propose a particular organization of design domains forthe discipline of VLSI digital design, but rather to illustrate the concepts of design domain tem-plates and facet templates, and how they are organized and related to each other, by means of GFT

and , in order to define a design hierarchy∆.

TGDTFT

TGDTFT

Knowledge level structure of a design space

91

design domain template in the graph, we have as many derived facets in the extracted tree,or tree nodes, as we have different paths defined in the graph, beginning with the specificnode associated with the particular design domain and ending with the root node of thegraph. The extraction process is illustrated for the node “PROCESSING ELEMENT” inFigure 17.

If we try to make a direct analogy between the facets tree , shown in Figure 16, and the

design hierarchy∆ defined in our proposed formal theory of design, we notice that there is a

general root node in , connecting the root nodes of all abstraction levels, that did not

exist in the design hierarchy∆, as defined in Chapter 4. We decided to include a root node inour proposed knowledge representation to clearly indicate the design discipline covered bythe entire hierarchy, i.e., the most general abstract class of design objects covered by the

LOGICAL

DEVICE/TRANSISTOR

ALU

ADDER

VLSI - DIGITAL

PROCESSINGELEMENT

REGISTER

MANUFACTURING

STORAGEELEMENT

RTL

0

1

2

3

4

5

6

7

8

9

FIGURE 15 Design Domain Templates Graph

TGDTFT

TGDTFT


92

specific design hierarchy. So, in the example of Figure 16, the root design domain templatenode indicates that the particular design hierarchy being represented is defined for thedesign discipline of VLSI Digital Circuits. Note that the design hierarchy∆, defined by agiven design domain graph and by the corresponding facets tree, can be directly obtained byremoving the root node from these structures. The resulting design hierarchy of knowledge

templates, denoted by∆k,1 will thus be equivalent to∆.

As we can see in the example shown in Figure 18, the∆k, derived from the previous designdomain template graph and related facet template tree, has four levels of abstraction, RTL(id

1. The superscript “k” stands for knowledge structure. It is not an index.

ALU

REGISTER

ALU

ALU

ALU

ADDER

REGISTER

REGISTER

RTL

LOGICAL

MANUFACTURING

DEVICE/TRANSISTOR

VLSI - DIGITAL

0-0

1-1

2-2

3-3

4-4

1-7

2-7

3-7

1-8

1-9

2-9

4-9

4-7

ADDER

ADDER

ADDER 2-8

3-8

4-8

1-5

2-5

3-5

4-5

REGISTER3-9

PROCESSINGELEMENT

PROCESSINGELEMENT

PROCESSINGELEMENT

PROCESSINGELEMENT

1-6

2-6

3-6

4-6

STORAGEELEMENT

STORAGEELEMENT

STORAGEELEMENT

STORAGEELEMENT

FIGURE 16 Design Domain Facets Tree


93

= 1), Logic (id = 2), Transistor (id = 3), and Manufacturing (id = 4). Manufacturing is the

ground level for∆k.

The nodes of the facet template tree, calledfacet knowledge templates, directly implementthe domain private facetsδi,j defined in Chapter 4, where i denotes the abstraction level andj denotes the particular abstract class of design objects. Thedesign domain knowledge tem-plates, that constitute the nodes of the design domain graph, directly implement the abstract

design domains , also defined in Chapter 4, where j is the index denoting the particular

class of design objects. So, in the example given in Figure 16, the abstract class of designobjects or abstract design domain, ALU (Arithmetic and Logic Unit), is represented in thehierarchy by a knowledge design domain template, whose id (or unique identification) is“7”. This knowledge design domain template has four domain private facets, or facet knowl-edge templates, one for each abstraction level defined in the hierarchy.

RTL

LOGICAL

MANUFACTURING

DEVICE/TRANSISTOR

VLSI - DIGITAL

0-0

1-1

2-2

3-3

4-4

- 5PROCESSINGELEMENT

FIGURE 17 Generating the Design Domain Facets Tree

1

2

3

4

∆H j,o


94

Since facet knowledge templates are knowledge structures aimed at implementing designdomain private facets, denoted byδi,j, they are knowledge structures basically aimed atdeclaring the abstract sub-specifications meaningful for the associated abstract class of

design objects being represented at each particular abstraction level in∆k. Furthermore,similar to what was described in Chapter 4 for∆, the complete sub-specification for a partic-ular class of design objects at each abstraction level consists of the sub-specificationdeclared in the corresponding facet knowledge template for the specific abstract designobject, plus the abstract sub-specification defined by the inheritance path of this last facet

knowledge template in∆Κ. So, returning to the example of Figure 18, the complete abstractsub-specification for the abstract class of design objects ALU, at logic level, is the union ofthe abstract properties declared in: (1) the facet knowledge template of ALU at logic level;(2) the facet knowledge template of PROCESSING ELEMENT, also at logic level, and (3)

ALU

REGISTER

ALU

ALU

ALU

ADDER

REGISTER

REGISTER

RTL

LOGICAL

MANUFACTURING

DEVICE/TRANSISTOR

1-1

2-2

3-3

4-4

1-7

2-7

3-7

1-8

1-9

2-9

4-8

4-7

ADDER

ADDER

ADDER 2-8

3-8

4-9

1-5

2-5

3-5

4-4

REGISTER3-9

PROCESSINGELEMENT

PROCESSINGELEMENT

PROCESSINGELEMENT

PROCESSINGELEMENT

1-6

2-6

3-6

4-6

STORAGEELEMENT

STORAGEELEMENT

STORAGEELEMENT

STORAGEELEMENT

RTLABSTRACTIONLEVEL

LOGICABSTRACTIONLEVEL

TRANSISTORABSTRACTIONLEVEL

MANUFACTURINGABSTRACTIONLEVEL

(1)

(2)

(3)

(4)

FIGURE 18 Design Knowledge Hierarchy ∆k


95

the facet knowledge template of LOGICAL, also at logical level. (Note that the node VLSIDIGITAL shown in Figure 16 is a dummy node, not containing any information.)

Since abstract properties are defined by means of independent knowledge structures (desig-nated property knowledge templates and design issue knowledge templates) being, there-fore, only declared in the knowledge facet templates, we describe them in a an independentsection.

5.2.2 Design Objective Templates

According to our general formal theory of design, an abstract design objectivegα is definedas follows


where

gα denotes the design goal associated with the abstract objective;

Mα denotes the possible modes of achievement for the objective, i.e., defines the con-trol knowledge associated with the specific objective;

Pg,α denotes the objective related abstract specification.

Since the abstract properties contained inPg,α are defined by means of independent knowl-edge structures, being only declared in the knowledge objective templates, we describe themin a an independent section.

As discussed in Chapter 4, design objectives may have two different modes of achievement:

(1) direct achievement, denoted by , and (2) indirect achievement, denoted by . We

say that an objective achieved in direct mode has been directly achieved, while an objectiveachieved in indirect mode has been indirectly achieved.

An active design objective gα,q can be directly achieved if at least one operator exists

that is potentially able to directly generate a solution to the design problem defined by

gα,q in sn.

The same design objective gα,q may also be achieved indirectly. In order to allow for this,

specifies proper criteria for generating convenient subsets on , the sub-

MαD Mα

I

Θxα

snα q,

MαI D

O∆o j k, ,

k∑

j∑∆ gα q,,


96

specification associated with gα,q. These subsets are then used to generate new sub-prob-

lems based on the original problem .

At this point a very important remark is in order. Nothing else was further specified or

defined in the formal theory of design either for or for because the proposed for-

mal design theory is general, i.e., it does not embody the specifics of any particular designprocess planning paradigm. So, throughout this chapter, we are actually discussing theapplication of our theory of design to the specific design process planning and managementparadigm proposed in Chapter 3.

As briefly mentioned in Chapter 4, abstract design objectives define the control flow ofdesign processes, being therefore the knowledge structures naturally most impacted by the

design process planning and management paradigm defined in Chapter 3.1 So, first of all, weneed to describe in some more detail the coordination and cooperation protocol specifics ofour design process planning and management paradigm, in order to make clear what do weneed to represent in the design objectives. We then introduce the main knowledge structuresused for defining a design objective template, and discuss the adequacy, compactness, andsimplicity of the proposed knowledge representation structures.

5.2.2.1 Coordination and communication protocol

Recall the design process planning and management paradigm described in Chapter 3,where we defined four basic categories of design agents that intervene in the design activity:2

• Design Process Context Managers, DPM’s, aimed at representing the current state

of a given design process, and the design history, i.e., sn and S+. The total number ofDPM’s for a given project is arbitrary. Each DPM represents a different alternativebeing developed for the same original problem;

• Designer Agents, DA, aimed at driving/conducting the design planning activity in adistributed basis, i.e., in a (sub)problem basis. The total number of DA’s for a givenproject is arbitrary; DA’s can be started and terminated at any stage of the design pro-cess;

• Knowledge Base Manager, KBM, aimed at defining all design discipline dependantelements intervening in a design process. There is only one KBM for a given project;the same KBM can be shared by different projects;

1. The application area did not have any particular impact on the definition of design domain tem-plates and facet templates, and so we decided to introduce this discussion only at this point.2. The design space manager agent is irrelevant for this discussion, so we will ignore it.

snα r, sn

α q,

MαD Mα

I


97

• Executive Manager, EM, is the front end to the executive system, being aimed at val-

idating design plans, i.e., checking if there exists at least one operator potentially

able to generate a solution to a given design problem, and then executing validateddesign plans. There is only one EM for a given project, yet nothing precludes the EMfrom concurrently executing an arbitrary number of (sub)plans that have been concur-

rently or sequentially generated by all the DPM’s.1 The same EM can be shared by dif-ferent projects.

Designer agents, are the drivers of the design activity. They work in an asynchronous andautonomousproblem selectionandproblem solving cycle. So, they are supposed to asyn-chronously start the dialogue with a given DPMi, and then request from the particular DPMithe current status of the design. Based on this information, DA’s will select the next problemto address, among the problems in sn whose status is READY, and communicate this fact tothe DPMi, thus finishing the problem selection phase of the cycle. Notice that only problemswhose objectives are in the direct mode of achievement are selectable, meaning that prob-lems whose objectives are in the indirect mode of achievement are going to be indirectlysolved by means of their related subproblems.

After concluding the problem selection phase, the problem solving phase starts. The directachievement of active objectives is realized in four distinct phases:plan generation, planvalidation, plan execution,and execution validation. These phases are controlled by theDPMi, based on the knowledge structure defining the indirect achievement mode, denoted

by , for the abstract design objectivegα associated with the particular active objectivegα,q. Such knowledge structures reside in the KBM. So, as soon as an active objective gα,q

is instantiated in sn, the corresponding is sent to DPM by KBM on direct request ofDPMi.

In order to properly characterize what needs to be specified in for a given abstractobjective gα, let us now outline the cooperation and coordination protocol used by thedesign agents during each of the problem solving sub-phases of the direct achievementmode:

• Plan Generation: The DPMi asks the executive agent EM if there is at least one avail-

able operator that is potentially able to directly generate a solution for the selected

(sub)problem . EM sends back the result: SUCCESS, if at least one operator was

1. Notice that EM is just the front end to the executive system.

Θxα

MK α,D

MK α,D

MK α,D

Θxα

snα q,


98

found, along with the list of selected operators (i.e., CAD tools or meta-tools), orFAILURE, otherwise. When the DPMi receives a result from EM, it updates sn,

including the status information for the problem , based on the overall outcome

of the phase. Specifically, if SUCCESS is reported by EM, the DPMi turns the objec-

tive status again into READY, so the DA’s can access it again.1

• Plan Validation: The DPMi sends to the design agent that just selected the particular

problem , denoted by DAj, the plan generation results previously sent by EM to

the DPMi during the plan generation phase of . In case of SUCCESS, DAj is

allowed to accept the plan or to partially accept the plan, by indicating that it does notwant a specific subset of the selected operators (CAD tools) to be used, or it can sim-ply reject the plan. In case of FAILURE, and in case of plan rejection, the DAj is fur-ther asked to select a follow on action. Typical follow on actions presented to thedesigner are CONTINUE-DEFAULT, RESTART CURRENT OBJECTIVE,RESTART PARENT OBJECTIVE, and DECOMPOSE. The DPMi updates sn, includ-

ing the status information for the problem , based on the overall outcome of the

phase.

• Plan Execution: The DAj requests the DPMi to execute the validated plan for .2

The DPMi redirects this request to the EM. After finishing execution, the EM sends

the plan execution result back to the DPMi.3 The result of a plan execution can be

SUCCESS or FAILURE. In both cases the EM may also send some additional infor-mation to the DPMi, such as the CAD tool used and a meta-level description of thedesign data generated, or the EM may send a diagnosis of the failure. When the DPMireceives the results from the EM, it updates sn, including the status information for the

problem , based on the overall outcome of the phase. Then, for both cases, i.e.,

SUCCESS or FAILURE being reported by the EM, the DPMi turns the objective sta-tus into READY again, so the DA’s can access it.

• Execution Validation: The DPMi sends the results of the plan execution for to

the DAj. The DAj is asked to ACCEPT or REJECT the execution results. In the case ofrejection, DAj is asked to select a follow on action. Typical follow on actions pre-

1. FAILURE implies transition of the related active design objective to the indirect achievementmode. We address this second mode of achievement later on in this section.2. Notice that this phase is only reached if the generated plan was previously accepted by DAj.

3. This communication is done asynchronously.

snα q,

snα q,

snα q,

snα q,

snα q,

snα q,

snα q,


99

sented to the designer are DEFAULT, RESTART CURRENT OBJECTIVE,RESTART PARENT OBJECTIVE, and DECOMPOSE. DPMi updates sn, including

the status information for the problem , based on the overall outcome of the

phase.

We have just outlined what happens when an objective is directly achieved in the context ofour proposed coordination and cooperation metaphor. We did this in order to be able toproperly discuss, in the next section, an adequate knowledge representation structure for

, as part of the objective template definition. Now, having the same objective in mind

for , let us discuss what happens when an objective is to be indirectly achieved.

Indeed, indirect achievement of an active objective gα,q implies that the original problem

defined by gα,q was decomposed. As defined in our theory of design, problem decom-

position is achieved by defining proper subsets in , the sub-specification associ-

ated with the original problem . Our theory specifies a set of possible criteria for

deriving such subsets and defines how these criteria should be sequenced for a givenabstract objective, but says nothing about how to implement such criteria. We have chosento implement these criteria in an indirect form, as explained next.

Instead of working with a small set of objectives and directly implementing the ‘partition’criteria of our theory of design on the sub-specifications of these objectives, we choose toallow the definition of “partial” design objectives (and related partial goals), in addition to

the general ones.1 Such sub-objectives must implicitly define partitions on the sub-specifica-

tion associated with a general objective. These new partial objectives are,

therefore, aimed at partially accomplishing the more general synthesis, optimization and testobjectives, i.e., they will act as sub-objectives of the previous ones.

Some examples of partial objectives that can be defined for aGeneral_Synthesis objective(previously designated “synthesis”) could be:

1. The general objectives are generation (i.e., synthesis and optimization) and test.

snα q,

MK α,D

MK α,I

snα q,

DO∆

o j k, ,

k∑

j∑∆ gα q,,

snα q,

DO∆

o j k, ,

k∑

j∑∆ gα q,,


100

- Synthesis_Transformational: for a given design object instance, this objective wouldonly be concerned with mapping specifications from a given level of abstraction onto alower level of abstraction;

- Conceptual_Design: this objective would only be concerned with deriving propervalues for abstract properties of the Structure Realization Constraints type and of theBehavior Realization Constraints type, i.e., properties belonging to the abstract sub-specifications and , for an abstract class of objects “j” at the level ofabstraction i;

- Decomposition: this objective would only be concerned with deriving non-funda-mental structural or functional decompositions for a given design object instance, i.e.,deriving “non-fundamental” values for the abstract sub-specification behavioraldescription and/or for the abstract sub-specification realization structure description,respectively and , for an abstract class of objects “j” at the level ofabstraction i.

Similarly, theGeneral_Test objective (previously designated only test), could generate thesub-objectivesGeneral_VerifyandGeneral_Analysis. General_Analysis is aimed at extract-ing values for abstract properties defined at a given abstraction level from the values ofabstract properties defined at a lower abstraction level. General_Analysis, thus, traverses thedesign process hierarchy in the opposite direction ofSynthesis_Transformational. General_-Verify, on the other hand, is aimed at extracting values for abstract properties defined at agiven abstraction level, from the values of abstract properties defined at this same abstrac-tion level.

Using the same line of reasoning we also allow the definition of design objectives, that whenchanged to indirect mode of achievement, “jump” immediately to the last (fifth) problemdecomposition criteria of the formal theory of design, i.e., “create subsets by abstract prop-erty.” In such cases, the target properties, i.e., the abstract properties driving problem

decomposition, would be explicitly signaled in the specification related templates.1

An example of an abstract objective whose template definition can be dramatically simpli-fied by using this representation mechanism is the General_Verify abstract design objective.Indeed, it may make sense to decompose the General_Verify objective into Particular_Ver-ify sub-objectives, one for each “verifiable” property contained in the sub-specification ofthe original problem. The same can be said for the General_Analysis abstract design objec-tive.

So, by allowing the definition of such “small granularity” (sub)objectives and also by allow-ing the definition of a global objective, which we callDesign and which has, as a goal, the

1. Notice that partition criteria from 1 to 4 can be implemented by using small granularity sub-objectives. Criteria 5 is the only one that had to be directly treated.

Pi B C, ,o j, Pi S C, ,

o j,

Pi B D, ,o j, Pi S D, ,

o j,


101

actual “universal goal” of design, i.e., to produce the ground level representation of a givenabstract class of design objects meeting an initial specification, we were able to significantly

simplify the specification of . Indeed, for a given abstract class of design objectivesgα, becomes an easily manipulated objective decomposition description, where each

specified sub-objective implicitly looks only to a subset of the sub-specification that was rel-evant for the original objective. Sub-objective sequencing and actions to be taken given spe-

cific outcomes on the accomplishment of such sub-objectives are also represented in .

Moreover, simplicity and compactness of the resulting representation structures are not the

only reason for adopting the proposed way of specifying . Indeed, using such a (sub)-objective based representation for specifying the indirect achievement mode of abstractdesign objectives is particularly interesting, because it is clearly consistent with the way realworld operators (implemented by CAD tools) are defined. In other words, by defining con-venient “small granularity” design objectives for each specific design discipline, a direct and“high-level” mapping can be establish between abstract (sub)objectives and operators. Inother words, plan generation and plan validation tasks become almost trivial operations.

In our theory of design, an active design objective gα,q is defined by

gα,q = (gα, ,Pg,α,q, status)

where gα denotes the instantiated abstract design objective, denotes the set of active

design objectives generated by gα,q, in case gα,q is being achieved in indirect mode, and

Pg,α,q denotes the objective related specification. Thus, an active objective “knows” what

sub-objectives were generated by it when problem decomposition occurs. However,is specified forgα, the abstract design objective, and in some cases, as discussed bellow, weonly know the total of sub-objectives (and thus subproblems) created by problem decompo-sition by gα,q, when gα,q changes to indirect mode, during the design process. For instance,considering the General_Verify objective, i.e., when problem decomposition uses the fifthproblem decomposition criteria, the final number of objectives depends on the number of“verifiable” abstract properties contained in the original problem that currently have anattributed value.

So, while in some cases we can discriminate the sub-objectives to be instantiated by gα,q

directly in , in others we cannot because we do not know a priori how many actualactive sub-objectives of a given type we will have, and this number typically varies from

MK α,I

MK α,I

MK α,I

MK α,I

Gα q,SUB

Gα q,SUB

MK α,I

MK α,I


102

case to case. This fact creates the need for specifying in terms of two specific knowl-

edge structures, and , denoting indirect achievementknown sub-objectives and

indirect achievementunknown sub-objectives, respectively. We will see that both and

can be represented using the same knowledge structures as was used for specifying

.

We are now ready to introduce the knowledge level structures needed for characterizing thedesign objectives in a design process.

5.2.2.2 Defining Knowledge Structures

The knowledge structure for representing the direct achievement mode for a given abstract

design objectivegα, , is an ordered set ofObjective-Phase knowledge structures, orOP’s. Each OP consists of a set of condition-action pairs, denoted by , indicat-ing what the corresponding design process manager agent, DPMi, should do for each possi-ble overall outcome of the phase.

So, the condition part of the pair, or COND, is a tuple of the form:

(

Phase_Outcome,

Designer’s_Feedback,

Type_of_Generated_Information or Sub_Objective Status

)

and the action part, ACT, is aprimitive action specified from a predefined (built in) set.

For instance, the specification for a Synthesis_Transformation abstract objectivecould be as partially illustrated below, where we are indicating three OP’s: PLAN VALIDA-TION, PLAN EXECUTION, and EXECUTION VALIDATION. PLAN VALIDATION hasthree tuples, PLAN EXECUTION has only two tuples indicated, and EXECUTION VALI-DATION has only one tuple indicated.

=

......................................................

Objective Phase:PLAN VALIDATION

MK α,I

MK α,I K– MK α,

I U–

MK α,I K–

MK α,I U–

MK α,D

MK α,D

MK α,D

COND ACT→

MK α,D

MK synthesis transformation–,D


103

(Phase Outcome:SUCCESS ----- /means EM reported SUCCESS to DPMi/

Designer’s Feedback:ACCEPTED ------/means DAj reported unconditional acceptance to DPMi/

Type of Generated Information or Sub_Objective Status: ANY) / information is irrelevant /

==> Action:GO TO PLAN EXECUTION PHASE

(Phase Outcome:SUCCESS ----- /means E reported SUCCESS to DPMi/

Designer’s Feedback:PARTIALLY ACCEPTED/means DAj reported partial acceptance to DPMi,

i.e., specified set of operators not to be considered/

Type of Generated Information or Sub_Objective Status: LIST OF IDS) /list of rejected operators /

==> Action:GO TO PLAN EXECUTION PHASE

(Phase Outcome:SUCCESSDesigner’s Feedback:REJECTED RESTART PARENT OBJECTIVEType of Generated Information or Sub_Objective Status: ANY) / information is irrelevant /

==> Action:RESTART PARENT OBJECTIVE......................................................

Objective Phase:PLAN EXECUTION

(Phase Outcome:SUCCESSDesigner’s Feedback:CONTINUE ------ / DAj asks for default action/


==> Action:GO TO EXECUTION VALIDATION PHASE

(Phase Outcome: FAILURE

Designer’s Feedback: RESTART CURRENT OBJECTIVE

Type of Generated Information or Sub_Objective Status:ANY) ------/ information is irrelevant /

==> Action: RESTART CURRENT OBJECTIVE

(Phase Outcome: FAILURE

Designer’s Feedback:CONTINUE ------ /DAj asks for default action/

Type of Generated Information or Sub_Objective Status:ANY) ------/information is irrelevant/

==> Action: RETURN_UP -----/reports failure to ‘parent objective’, if existent/

......................................................

Objective Phase:EXECUTION VALIDATION

(Phase Outcome:SUCCESS


104

Designer’s Feedback: ACCEPTED ------ / DAj asks for default action/


==> Action: IMPLEMENT TRANSFORMATION

......................................................

....................................................

/end of definition of /

5.2.2.3 Defining Knowledge Structures

is the knowledge structure used for specifying indirect achievement using a set ofknown and, therefore, possible toa priori discriminate, sub-objectives. The organization of

the knowledge structure is similar to the one described for , except that the condition

action pairs are organized by abstract sub-objective. Furthermore, allows to specifyalternative objective decompositions for a given abstract design objective gα. These alterna-tive objective decompositions can be indexed by design domain and/or by origin of facet.Alternative objective decompositions can also be indexed by the value of a particular prop-

erty.1

So, the description of is composed by a set of alternative decompositions,

where “i” denotes the discriminating index. A default decomposition must always beprovided. A specification of indirect achievement mode for the “global” objectivedesign

may contain the following condition-action pairs associated with the sub-objective

conceptual design:

=

......................................................

Sub_Objective: Conceptual Design

1. Such property may be called “design methodology”, and may have TOP_DOWN and BOT-TOM_UP as possible values.


MK α,I

MK α,I K–

MK α,D

MK α,D

MK α,I-K MK α,

I-K,i

MK α,I-K,D

MK design,I-K,i

MK design,I-K,i


105

(Phase Outcome:SUCCESS ----- /means “Conceptual Design” reported SUCCESS to “Design”/

Designer’s Feedback: CONTINUE / default /


==> Action: ACTIVATE(Synthesis_Transformation)

.......................................................................................

Sub_Objective: Synthesis_Transformation

(Phase Outcome:FAILUREDesigner’s Feedback: CONTINUE /default/


==> Action: RETURN UP

......................................................................................

......................................................

Note that active sub-objectives may report failure to their parent objective, as is shown inthe example above, where “Synthesis_Transformation” reports failure to “design.” This is

done by means of the primitive action RETURN UP in the of the sub-objective. This

situation is illustrated in .

Finally, structures, i.e. knowledge structures for specifying indirect achievement usinga set of unknown, and thus impossible to discriminate, sub-objectives, are represented simi-

larly to , yet they only have one body of condition-action pairs. So, all sub-objectivesreturning messages are matched against this only body of CONDs. Note, though, that in thiscase the third value on the condition tuples, designated Type of Generated Information orSub_Objective Status, is aimed at discriminating the status of the unknown set of sub-objec-tives. Possible values for Type of Generated Information or Sub_Objective Status in thiscase are: ALL_ADDRESSED_NO FAILURE, ALL_ADDRESSED_AT_LEAST_ONE_FAILURE, NOT_YET_ALL_ADDRESSED_FIRST_FAILURE, NOT_YET_ALL_AD-

DRESSED. A possible example for a specification for the abstract objective test

is shown bellow.

MK α,D


MK α,I U–

MK α,D

MK test,I U–


106

=

......................................................

(Phase Outcome:SUCCESS ----- /means a sub objective just reported success/


Type of Generated Information or Sub_Objective Status: ALL_ADDRESSED_NO FAILURE)

/ means all sub-objectives are achieved with success /

==> Action: RETURN_UP / return success to parent objective, if existent /

(Phase Outcome:SUCCESS ----- /means a sub objective just reported success/


Type of Generated Information or Sub_Objective Status: NOT_YET_ALL_ADDRESSED)

/ means still sub-objectives to be addressed /

==> Action: STORE AND STAY

......................................................

Finally notice that, for objective decompositions specified by a knowledge struc-

ture, there are no means for specifying a particular activation sequencing for the “unknown”

sub-objectives. Being more specific, in a decompositions specified by a knowledge

structure, all sub-objectives become instantaneously READY the moment they are instanti-ated in sn. Although, for all cases where this type of problem decomposition is being used,namely for “General_Test” abstract objectives and in “Decomposition” abstract objectives,for controlling the problems generated for the new specified structural or functional decom-positions, this is exactly the desired situation, i.e., the resulting (sub)problems can (andshould) be addressed concurrently.

5.2.3 Knowledge Structures for defining Abstract Specifications and AbstractConsistency Constraints

Based on the abstract specifications taxonomy developed for design objects related proper-ties and for objectives related properties, we define bellow three semantic categories ofproperties, aimed at making it simpler to discriminate the set of abstract properties meaning-ful to each design discipline. Furthermore, based on the values such properties can take, wedefined six syntactical categories of property templates. Consistency constraints defined foreach of these property types have specific forms. We will address the knowledge structuresfor representing properties and consistency constraints bellow.

MK test,I U–

MK test,I U–

MK test,I U–


107

5.2.3.1 Knowledge Structures for defining Abstract Specifications

Abstract property members of sub-specifications of typePo or Pg may be of six syntacticaltypes, Integer, Real, String, Option-One-In-Many, Option-Several-In-Manyand Descrip-tion. The so called syntactical type defines the general type of property values.

All types are self-explanatory except for Description. The value of a description type prop-erty consists of an option, meaning the particular language used in the description, and adescription body, that in pure syntactical terms is a string of arbitrary size. This type is usedfor complex properties such as behavioral descriptions or realization structure descriptions.

Restrictions on property values may be associated with abstract properties. The restrictiontype depends on the syntactical type of the property. The restrictions available for the firstthree syntactical types, i.e., Integer, Real, and String, are unit andrange. Such restrictionsare optional. The only restriction associated with the remaining syntactical types is alist ofoptions, and this restriction is mandatory. For the syntactical types Option-One-In-Manyand Option-Several-In-Many, the restrictionlist of options enumerates the specific values(or options) the property can take. In the other case, Description, the restriction enumeratesthe languages available for “formally describing” the property value.

As mentioned in the introductory part of this section, abstract properties are organized intothree main semantic types: Canonical Properties, Design Issues or Constraints, and Require-ments. Let us discuss each of these semantic types.

• Canonical Properties: This semantic type comprehends all abstract properties that canalways be defined for every abstract class of design objects, at any abstraction level inthe design hierarchy. Specifically, one member of the sub-specification Behavioral

Description, denoted by ,1 and the member of the sub-specification Realiza-

tion Structure Description, denoted by , are the properties belonging to this

semantic type, i.e., are the canonical properties. Canonical properties are always of theDescription type.

• Design Issues: This semantic type basically comprehends abstract properties belong-

ing to the sub-specifications Behavior Realization Constraints, or , and Struc-

ture Realization Constraints, or . Design Issues are always of the type Option-

1. If several behavioral description type of abstract properties are available for characterizing agiven abstract class of design object, only one can be chosen as the canonical property. Theremaining will be treated as requirements, i.e., will belong to the third semantic type, which isdescribed bellow.

Pi B D, ,o j,

Pi S D, ,o j,

Pi B C, ,o j,

Pi S C, ,o j,


108

One-In-Many. Design issues can individually be declared as optional/deferrable or asmandatory/immediate.

• Requirements: This semantic type comprehends abstract properties belonging to the

sub-specifications Behavior Realization Requirements, or , Structure Realiza-

tion Requirements, or , andobjective related, orPg,α, yet it may also contain

properties belonging to the sub-specifications Behavior Realization Constraints,

or , and Structure Realization Constraints, or .1 Requirements can be of

any syntactical type. As in the case of design issues, requirements can be declared asdeferrable or as immediate.

This indeed constitutes a simplification of our proposed taxonomy of abstract specifications.We basically collapsed realization structure and behavioral sub-specifications, while keep-ing the discrimination between the three sub-categories defined for these two major groups,i.e., realization structure/behavioral descriptions, requirements and constraints. We pre-served the last three sub-categories of properties in our representation because their role inthe design process is indeed quite specific and differentiated (see the discussion in Section4.3) which implies an objective need for their discrimination in the design space representa-tion. This is not the case for the realization structure general sub-specification and thebehavioral general specification, and so we decided to relax this level of classification, sinceit would only introduce difficulty in the knowledge acquisition process, without an obviousadvantage.

Abstract properties are defined independently and are further associated with facet tem-plates. In this association process, values can be attributed to any abstract property. In suchcases, we say that the property has an implicit value for the particular design domain facet,as it will be explained in next section.

5.2.3.2 Knowledge Structures for defining Abstract Consistency Constraints

We have made a distinction between (1) consistency constraints relating design issues; and(2) consistency constraints relating the two other specification semantic groups. Actually,one of the fundamental distinctions between those semantic groups is indeed the less flexi-ble, though simple and very effective, consistency constraint knowledge structures used fordesign issues, and the more flexible yet not so simple consistency constraint knowledgestructures defined for the other two categories of properties.

1. An example of this last case, for the VLSI design discipline, is the property layout mask.

Pi B R, ,o j,

Pi S R, ,o j,

Pi B C, ,o j, Pi S C, ,

o j,


109

In the case of design issues, consistency constraints are defined in a(design issue, designoption) pair basis. For each option of each design issue we have to list all (design issue,design option) pairs that turn the particular option inconsistent.

Let us use again the filter problem to illustrate how consistency constraints are defined fordesign issues. So, let us assume that we have the following two design issues:

Design Issue: Filter Algorithm

Design Options:

• Finite Impulse Response (FIR)

• Infinite Impulse Response (IIR)

and

Design Issue: Polynomial Approximation Technique

Design Options:

• Equiripple ( (Filter Algorithm, IIR) )

• Frequency Sampling ( (Filter Algorithm, IIR) )

• Windowing ( (Filter Algorithm, IIR) )

• Beta ( (Filter Algorithm, IIR) )

• Elliptic ( (Filter Algorithm, FIR) )

• Butterworth ( (Filter Algorithm, FIR) )

• Chebyshev ( (Filter Algorithm, FIR) )

As it can be seen above, all the design options defined for the Polynomial ApproximationTechnique design issue have represented a consistency constraint, related to a specificdesign option of the Filter Algorithm design issue. Such consistency constraints indicate, forinstance, that choosing the Equiripple design option is incompatible with the design deci-sion IIR for the Filter Algorithm design issue.

Design issues can be declared as local or as global, where global is the default. The value ofa global design issue associated to a given design object instance should be propagated to allcomponents of such design object in case they exist. This constitutes a simplified form ofdeclaring propagation constraints, a particular case of consistency constraints, amongdesign issues.

For the remaining syntactic groups, consistency constraints knowledge structures are infor-mative in nature and have the following general form:

- Constraining properties: list of property unique identifiers (can be empty list)

- Constrained properties: list of property unique identifiers

- Relation: symbolic relation


110

- Filter for constraining properties:qualifier

- Filter for constrained properties:qualifier

For instance, if we want to define a consistency constraint stating that the chip area of agiven design object should be bigger than or equal to the sum of the area of its components,we will specify the following abstract consistency constraint:

- Constraining properties: Area

- Constrained properties: Area

- Relation:

- Filter for constraining properties:SELECT_PARENT

- Filter for constrained properties:SELECT_ALL_DESCENDANTS

Notice that the above consistency constraint is totally generic, in the sense that it can beinstantiated in the context of any set of design domains and related facets that happens tohave “Area” as an abstract property.

As mentioned earlier, the above class of consistency constraints has onlyinformative pur-poses. The idea is to show to the designer the consistency constraints relevant to the particu-lar problem being solved, and the current values of the properties involved in such

constraints.1 These consistency constraint relations are expected to be (at least partially)implemented in the CAD Tools selected to solve the specific problem.

Finally, a special form of consistency constraint, designated a “degenerated” one, is allowedto be formulated for any type of abstract specification. It allows for any generic facet tem-plate to implicitly impose values on the properties inherited from its inheritance path, what-ever the semantic type of the inherited property is.

In order to illustrate this type of degenerated consistency constraint, let us consider the

abstraction layer in∆k shown below.

1. This is specially useful when there exist dependencies among properties associated to differentproblems, and the designer is working in a concurrent design environment.

Area Constraining( , )∑ Area Constrained( , )∑≥

ALU

REGISTER

LOGICAL

2-2

2-7

2-9

ADDER 2-82-5

PROCESSINGELEMENT

2-6STORAGEELEMENT

LOGICABSTRACTIONLEVEL

(2)

Representing Design Processes

111

In defining the facet PROCESSING ELEMENT, the user is allowed to also specifyimplicitproperty valuesfor all abstract properties inherited by PROCESSING ELEMENT. Suchimplicit values will then be automatically inherited by all descendants of the facet, in thiscase ALU, ADDER and REGISTER. These last facets can also specify implicit propertyvalues for their inherited properties that still do not have a value.

This concludes the discussion of the main knowledge-level structures needed for represent-ing the knowledge level component of the design space. In the next section we will addressthe data structures needed for representing the data level component of the design space.

5.3 Representing Design Processes

As mentioned before, the representation of each design process in a project is kept by aDPMi agent. Each design process is represented by a complex, and design problem oriented,structure, describing: (1) the current state of the design process, sn; and (2) the design his-

tory S+ that lead to this state.

The basic building blocks that compose such a complex structure are:design domaininstances and their relatedfacet instances; active design objectives, also calledobjectiveinstances; andinstances of abstract properties of the three semantic types and their relatedactive consistency constraints.

We start this section by briefly describing each of these instance types. Then we discuss howthey are organized in order to actually compose the representation of a design process ofarbitrary complexity. We finish the by section discussing how this conceptual organizationallows a simple, very regular, modeling of design situations, at a first glance so diverse asfunctional and structural decompositions, and later recompositions, and transformationalsynthesis.


112

5.3.1 Design Domain Instances and Facet Instances

The most relevant information kept by a design domain instance is:

The most relevant information kept by a facet instance is:

• GLOBAL ID: the identification of thecorresponding design domain template in

∆k;

• LOCAL ID: the local identification of the corresponding instance of designdomain template (in the context of the particular DPMi);

• LIST OF FACET INSTANCES: a list of all facet instances already instantiatedfor the particular design domain instance;

• ACTIVE FACET: facet currently active for the particular design domain instance;

• FACET TRANSITIONS: the transformational path followed in the design of theparticular object.

• FACET GLOBAL ID: the identification of the facet template within the corre-sponding design domain template;

• LOWER LEVEL OF DESIGN REPRESENTATION: indicates if current facet is

the ground level for the particular design domain template in∆k;

• ORIGIN OF FACET: indicates what type of design step originated the particularfacet, Examples of origin of facet values are INITIAL, DECOMPOSITION,TRANSFORMATION, and SPECIALIZATION;

• DESIGN SPACE INFORMATION: meta information on the design data associ-ated with the particular facet.


113

DESIGN SPACE INFORMATION is a list ofdesign data object instances. The most rele-vant information kept by a design data object instance is:

In order to illustrate the role of the DESIGN SPACE INFORMATION data structure, let usgive an example. Suppose that we have a new facet being generated by a transformation ona given sub-specification, and after that, an optimization is performed in the context of sucha facet. Note that, by definition, an optimization does not refine the level of abstraction atwhich a given abstract design object is represented. Therefore, at the end of the seconddesign step, we will still have just one facet, with an ORIGIN OF FACET equal to TRANS-FORMATION, and with two design data objects instances in the DESIGN SPACE INFOR-MATION list of the facet. The first element in the list will be related to the piece of designdata generated by the first transformation. So, DATA CHARACTERIZATION for this ele-ment will be DATA OBJECT RESULTS FROM TRANSFORMATION. The second ele-ment of the data structure will be related to the piece of design data generated by theoptimization design step, and thus DATA CHARACTERIZATION for this element will beDATA OBJECT RESULTS FROM OPTIMIZATION. So, as we see, the history of thedesign steps performed in the context of this facet is being kept, partially with the help ofthis structure.

5.3.2 Organization of Design Domain and Facet Instances in a Design Process

Design domain instances related to a given design process are organized in trees, designatedProcess Trees. Notice that the information on descendant design domains (or components) isimplicit to the organization, i.e., does not need to be kept explicitly on design domaininstances. Facet instances are organized as lists, inside the related design domain instancesas shown in Figure 23.

• DATA OBJECT IDENTIFICATION : the identification of a particular piece ofdesign data associated with the facet instance (this id is given by the executive);

• RESPONSIBLE OBJECTIVE and/or PROPERTY: the particular objective orproperty that originated the above piece of data;

• DATA CHARACTERIZATION: states how current piece of data was generated.Possible values are: DATA OBJECT IS A DECOMPOSITION, DATA OBJECT ISA RECOMPOSITION, DATA OBJECT RESULTS FROM TRANSFORMATIONand DATA OBJECT RESULTS FROM OPTIMIZATION;

• DATA SUB-OBJECTS CONNECTIVITY: identifies the particular piece of datawhere the non-fundamental structural or behavioral decomposition is stored, if thisis the case;

• SUB-OBJECTS DESCRIPTION: identifies the components involved in a recom-position. This structure only refers to the “design data objects instance” stored inthe facet instances that actually represent the referred components.


114

5.3.3 Active Design Objectives or Objective Instances

The main information contained in an Objective Instance is as follows:

F1RTL

F1

ALU (7)

RTL

F1

ADDER(8)

RTLF1

REGISTER(9)

RTL

REGISTER(9)

F4MAN

F4MAN

F2LOG

PROCESSINGELEMENT (5)

F1RTL

F4MAN

FIGURE 19 The Process Tree: organizing Design Domain Instances and FacetInstances in a Design Process.

Design Domain Instances

Facet Instances


115

5.3.4 Organization of Objective Instances in a Design Process

Design objective instances are globally organized as a tree. The information on descendentsub-objectives is implicit to the organization, and, therefore, does not need to be explicitlystored on objective instances. Each design objective instance is owned by a specific facetinstance. Based on that, facet-related sub-trees of objectives can be defined in the main

objective tree, as illustrated in Figure 20.1

1. The purpose of this example isnot to propose specific forms of decomposing particularabstract design objectives, but rather to illustrate how adequate decompositions would be possibleto be specified by means of the proposed knowledge based description of an abstract objective.

• GLOBAL OBJECTIVE ID: unique identification of the abstract design objective;

• OWNERS: domain and facet id;

• LOCAL OBJECTIVE ID: unique identification of the active objective within the con-text of the facet that owns it;

• Mα: specification of possible modes of achievement for the objective;

• HISTORY: collection of COND’s that arrived to the active objective till the moment.

• STATUS: indicates the of the active objective. Values for status can be: READY, NOTREADY, BUSY, WAITING FOR INFORMATION FROM EXECUTIVE, WAITINGON SUB-OBJECTIVES ACCOMPLISHMENT, ACCOMPLISHED, FAILED;

• PHASE: NOT_STARTED, PLAN GENERATION, PLAN VALIDATION, PLANEXECUTION, EXECUTION VALIDATION, INDIRECT ACHIEVEMENT KNOWNSUB OBJECTIVES, INDIRECT ACHIEVEMENT UNKNOWN SUB-OBJECTIVES,ACCOMPLISHED, IMPASS;

• PLAN: information on the plan for the problem defined by the objective. It may alsorefer to ‘DATA OBJECT INSTANCE’ elements stored in the owner facet.


116

5.3.5 Property Instances and Active Consistency Constraints

In this section we discuss how property instances of the three semantic types and theyrelated active consistency constraints are represented and organized in the context of adesign process.

5.3.5.1 Design Issues and related Consistency Constraints

The main information contained in a design issue is as follows:

F1RTL

F1

ALU (7)

RTL

PROCESSINGELEMENT (5)

FIGURE 20 Relating the Process Tree with the Objectives Main Tree.

ObjectiveInstances

Design

Conceptual_Design Synthesis_T

Design


Sub-Treesof Objectives


117

The main information contained in an option instance is as follows:

Notice that consistency constraints for this particular semantic type are embedded in theproperty template itself.

5.3.6 Organization of Design Issues Instances in a Design Process

Design Issues are organized in asparse net, with the ordering constraints defining thearrows of the net. A sparse net is a set of trees where nodes can be shared by more than onetree. As in the case of active design objectives, design issues are owned by facet instances,and, therefore, sub-nets can be defined in the global net based on facet ownership, as illus-trated in Figure 21.

• GLOBAL ISSUE ID: unique identification of the design issue;

• OWNERS: domain and facet id’s;

• LIST OF OPTIONS: value restrictions. Each option is also an instance in itself;

• TYPE: DEFFERABLE, IMMEDIATE;

• CONTEXT_TYPE: LOCAL, GLOBAL;

• ISSUE_STATE: OPEN READY, OPEN NOT READY, CLOSED;

• DECISION: “option”, from LIST OF OPTIONS;

• IS DECISION PROPAGATED: TRUE, FALSE;

• IS DECISION IMPLICIT : TRUE, FALSE;

• IMPOSING DECISIONS ON: list of (issue, option) pairs. Facilitates backtracking.

• OPTION ID: unique identification of the design option;

• CONSTRAINTS: list of issues and related options that are invalidated by this option;

• OPTION SPECIFICS: allows for imposing consistency constraints between valuesof this particular semantic type of abstract property (design issues) and the canonicalspecs. Being more specific, here we can declare that this option is incompatible withpresence or absence of a value for any of the canonical specs;

• STATUS: CONSISTENT, INCONSISTENT, UNDEFINED;

• TOTAL OF INHIBITIONS : total of design decisions taken so far that make this par-ticular option inconsistent (for backtracking purposes).


118

In the example shown in Figure 21, the design issues owned by the three represented facetinstances, (ALU, F1), (ADDER, F1) and (REGISTER, F1), are indicated. We can see thatthe design issue Fabrication Technology is closed, i.e., already has an associated designdecision, for the three represented facets. In fact, the particular design decision, CMOS, waspropagated from the parent facet (ALU, F1) to the descendant facets (ADDER, F1) and(REGISTER, F1). The remaining design issues are all still opened, meaning that they areprobably classified as deferrable, in the context of the particular facets.

5.3.7 Canonical Properties, Requirement Instances and, ConsistencyConstraints

The main information contained in a property instance of the remaining two semantic typesis as follows:

LAYOUTSTYLE

F1

REGISTER(9)

TRANS

F1

ALU (7)

TRANS

F1

ADDER(8)

FIGURE 21 Relating the Process Tree with the Sparse Net of Design Issues

TRANS

FABRICATIONTECHNOLOGY

CMOS

FABRICATIONTECHNOLOGY

CMOSFABRICATIONTECHNOLOGY

CMOS

BIT SLICE

LAYOUTSTYLE

LAYOUTSTYLE

BIT SLICE

BIT SLICE


119

The information contained in active consistency constraints is as follows:

5.3.8 Organization of Canonical Properties, Requirements and ConsistencyConstraint Instances in a Design Process

Property instances are organized in a sparse net which is generated as follows: for eachactive consistency constraint, an arrow representing a dependency is generated from eachproperty belonging to the constraining set of properties, to every property of the constrainedset of properties, as shown in Figure 22. These property instances are owned by facetinstances and may also be owned by objective instances and, therefore, sub-nets can bedefined in the global net based on facet/design objective ownership. Figure 22 illustratessub-nets defined by facet ownership.

• GLOBAL SPEC ID: unique identification of the property;

• OWNERS: domain and facet id’s. Also objective id, in case of being an objectiverelated property;

• SYNTACTIC TYPE: INTEGER, REAL, STRING, OPTION-ONE-IN-MANY,OPTION-SEVERAL-IN-MANY, DESCRIPTION;

• RESTRICTIONS: value restrictions;

• TYPE: DEFERABLE, IMMEDIATE;

• KEY: TRUE, FALSE. Indicates if property value is fundamental in characterizingthe design object;

• STATUS:OPEN READY, OPEN NOT READY, CLOSED;

• VERIFIABLE: TRUE, FALSE;

• DATA OBJECT IDENTIFICATION: similar to information kept in facets. For can-nonical properties, just refers to related ‘DATA OBJECT IDENTIFICATION’ ele-ment, stored in the owner facet.

• CONSTRAINING PROPERTIES: unique identification of involved properties;

• CONSTRAINED PROPERTIES: unique identification of involved properties;

• RELATION: SYMBOLIC RELATION.


120

5.4 Relating All Organizations in the Design Process: s n and S+

The current state of a design process, sn, is thus represented by the related process tree andby all the remaining data structures defined from it, such as the objectives tree and the prop-

erties sparse nets. S+ is also described in such structures, in the facet the instances and in theactive objectives, as pointed out before.

Given this complex structure, a problem becomes uniquely identified by selecting a tuple(DDI, FI(DDI), OI(DDI, FI)), whereDDI represents a particular design domain instance ofthe process tree,FI(DDI) represents a particular facet owned byDDI, andOI(DDI, FI) rep-

AREA

F1

REGISTER(9)

TRANS

F1

ALU (7)

TRANS

F1

ADDER(8)

FIGURE 22 Relating Process Tree with Sparse Net of Active Properties

TRANS

CONSTR 1

DISSIPATEDPOWER

DISSIPATEDPOWER

AREA

AREA

CONSTR 3

CONSTR 2

AREA

DISSIPATEDPOWER

Discussing Some Snapshots of Design Processes

121

resents an objective instance owned by the previous domain and facet. All remaining infor-mation, such as properties, becomes uniquely identified by this tuple.

So, when a DAj agent (i.e., an arbitrary designer agent) wants to select a problem to workon, it basically has to select a domain instance on the process tree, a facet within thisdomain, and an objective from the sub-tree of objectives owned by the facet, as illustrated inFigure 23. Objective instances have ‘status’ information, and, therefore, in the selection pro-cess, DAj is only allowed to select objectives whose status is READY, as mentioned before.

5.5 Discussing Some Snapshots of Design Processes

In this section we discuss how some key design steps, i.e., transformational synthesis,design object decomposition, and design object recomposition, are captured in our designprocess representation. All examples shown in this section correspond to actual views ofdesign processes directly created by Minerva, a prototype design process planning and man-agement system that implements our proposed design space representation (see Chapter 6).

Facet

Design

Synthesis_T Analysis_G

Design Domain Inst: ALU

: Logic

ObjectiveInstances

Total of problems being represented: 3Main problem: (Design, (ALU, Logic))Sub problems: (Synthesis_T, (ALU, Logic)), (Test, (ALU, Logic))

FIGURE 23 Representing design problems


122

5.5.1 Transformational Synthesis

In the example shown in Figure 24, a synthesis (transformational) design step is illustrated.The active objective Synthesis_T, owned by (ADDER, F1), was first achieved in directmode. Then, assuming that DAj accepted the execution results, the primitive action IMPLE-MENT_FACET_TRANSITION was executed, as specified in the knowledge structure

defined in the example given in Section 5.2.2.2. The execution of the

above built in primitive action implies, among other things, that Synthesis_T commutes tothe ‘indirect mode, unknown sub-objective’ mode of achievement, and that the top levelobjective associated to the current facet F1 is propagated to the new facet, generated by thetransformational step. After this, objective Synthesis_T waits until its new descendantobjective, Design,owned by (ADDER, F4), reports back results, either SUCCESS or FAIL-URE. On receiving such results, Synthesis_T RETURN_UP, another built in primitive, theparticular result to its parent objective, Design, owned by (ADDER, F1). In case of success,this will be the end of the particular design process. The sequence of events and actions just

reported can be easily declaratively described in .

F1

ADDER(8)

RTL

F4MAN

Design


Design

READY

ACCOMPLISHED

WAITING ONSUBOBJECTIVES

OBJECTIVE STATUS:

FIGURE 24 Illustrating Transformational Synthesis


MK synthesis transformation–,I U,


123

5.5.2 Structural or Functional Decomposition

Figure 25 illustrates how structural and functional decomposition are represented in theprocess tree and related global objective tree.

In the scenario illustrated in Figure 25, Synthesis_T failed during its direct achievement and

commuted toindirect mode known sub-objectives, described by .

Note that only specifies one sub-objective, designated “Decomposi-

tion.” In the design process snapshot being illustrated, Synthesis_T is currently waiting forresults from Decomposition. Decomposition, on the other hand, was already achieved indirect mode, and as a result of SUCCESS, invoked the built in primitive IMPLEMENTDOMAIN DECOMPOSITION. Such primitive generates pairs (DDI, FI(DDI)) for each ofthe components resulting from the decomposition, and then it propagates the top levelobjective associated to the original facet to the new descendant facets. Finally, Decomposi-tion commutes toindirect mode unknown sub-objectives and stays waiting from the results

F1

ALU (7)

RTL

F1

ADDER(8)

RTL F1

REGISTER(9)

RTL

DesignDesign

Design


Decomposition

FIGURE 25 Illustrating Structural or Functional Decomposition

MK synthesis transformation–,I K,

MK synthesis transformation–,I K,


124

of its descendant sub-objectives. The two new “design” objectives, owned by (ADDER, F1)and by (REGISTER, F1) respectively, are now simultaneously ready for selection.

5.5.3 Recomposition

Figure 26 illustrates a design object recomposition design step. The sub-trees of objectivesfor both facets of Register are omitted (only the top objective of the RTL facet is shown),and the sub-tree of objectives for adder is only partially shown, for simplicity purposes.

Note that Figure 26 actually illustrates a later phase of the same design process shown inFigure 25. So, we assume that the two “design” objectives, owned by (ADDER, F1) and by(REGISTER, F1), eventually reported SUCCESS to Decomposition, and that Decomposi-tion then reported SUCCESS to Synthesis_T. Synthesis_T then invoked the built in primi-tive IMPLEMENT FACET TRANSITION FOR RECOMPOSITION. This primitive createsa facet transition in the domain instance ALU. Figure 27 illustrates how the new facet (F4)in the original domain (ALU) is determined during recomposition.

Notice finally how the threedesign objectives, respectively owned by (ALU, F1), by(ADDER, F1), and by (ALU, F4) decomposed differently in direct mode of achievement.

This happened because we assumed an indexed by ORIGIN OF FACET, as

referred to before. Indeed, each of the facets has a different origin, leading to differentdecomposition for the maindesignobjective.

MK design,I K,


125

F1

ALU (7)

RTL

F1

ADDER(8)

RTL

F1

REGISTER(9)

RTL

Design

Design


DecompositionF4

MAN

Design

Recomposition

F4MAN Design


Analysis_G

F4MAN

FIGURE 26 Illustrating Recomposition

Verification_G


126

5.5.4 Built in Primitive Actions

The built inprimitive actions defined for this knowledge structure are listed below.

• GO TO PLAN VALIDATION PHASE

• GO TO PLAN EXECUTION PHASE

• GO TO EXECUTION VALIDATION PHASE

• GO TO INDIRECT ACHIEVEMENT KNOWN SUB-OBJECTIVES

• GO TO INDIRECT ACHIEVEMENT UNKNOWN SUB-OBJECTIVES

• IMPLEMENT DOMAIN DECOMPOSITION

• IMPLEMENT FACET TRANSITION

ALU

REGISTER

ALU

ALU

ALU

ADDER

REGISTER

REGISTER

RTL

LOGICAL

MANUFACTURING

DEVICE/TRANSISTOR

VLSI - DIGITAL

0-0

1-1

2-2

3-3

4-4

1-7

2-7

3-7

1-8

1-9

2-9

4-9

4-7

ADDER

ADDER

ADDER 2-8

3-8

4-8

1-5

2-5

3-5

4-5

REGISTER3-9

PROCESSINGELEMENT

PROCESSINGELEMENT

PROCESSINGELEMENT

PROCESSINGELEMENT

1-6

2-6

3-6

4-6

STORAGEELEMENT

STORAGEELEMENT

STORAGEELEMENT

STORAGEELEMENT

FIGURE 27 Finding Recomposition Facet

Design History

127

• IMPLEMENT FACET TRANSITION FOR RECOMPOSITION

• IMPLEMENT SPECIALIZATION

• RESET PHASES INTERNAL

• RETURN UP

• CONDITIONAL SEQUENCE SUB OBJECTIVES OR RETURN UP

• STORE AND STAY

• SET NEW STRATEGY AND STAY

The meta-actions performed by the most relevant of these primitive actions were alreadydiscussed throughout this chapter. Notice that the only “input” needed by such primitives isthe tuple specified in COND and occasionally the type of generated information. Therefore,

they are totally general, thus allowing a fully declarative specification of , ,

and knowledge structures.

5.6 Design History

The proposed representation for a design process contains the detailed history of the associ-ated design process. In this section we discuss how to efficiently access this information.

The history of a design process can be accessed at various levels of detail. For instance, theprocess tree allows a quick identification of all design objects involved in a specific designprocess, and the abstraction levels (design facets) at which these design objects were repre-

sented and manipulated during the particular design process.1 On the other hand, the sub-tree of design objectives associated with each design facet allows a quick identification ofthe types of design problems addressed in the context of the particular facet. Therefore, theorganization of facet instances and the organization of objective instances in the design pro-cess representation provide a basic outline of the data related “events” and of the controlrelated “events” in the particular design process, respectively. If we want to analyze in detailspecific parts of the design history, we should first localize the particular facet instances and/or objective instances of interest, and then look at the information stored in these specificdata level structures.

In our design process representation, each piece of design data is semantically abstracted asa property value in the context of a given design domain and in the context of a given facetwithin this particular design domain. Moreover, any data object (i.e., property value) gener-ated by means of the execution of a design plan is further characterized in a special data

1. Note that facets are abstractions of the real data.

MK α,D K, MK α,

I K,

MK α,I U,


128

level structure designated DESIGN SPACE INFORMATION, which resides in the corre-sponding facet instance. This particular data-level structure was described in Section 5.3.1.

As discussed in Section 5.3.3., the overall flow of control during the design process is keptin the objective instances. For instance, the number of times a particular design objectivewas accessed by a designer (according to the problem solving phases defined for the partic-ular objective), the outcome of each of these problem solving phases, and also the designer’sfeedback given the result of each phase. This information is kept in the objective instancefield HISTORY. Moreover, design objective instances also store the particular plans gener-

ated for their achievement.1 This information is kept in the objective instance field PLANS.Note also that PLANS uniquely identifies design data generated by the corresponding planexecution.

In summary, the design history provided by our design process representation not only stati-cally characterizes each piece of design data generated during the design process, as a par-ticular property of a particular design object represented at a given abstraction level, but alsofully characterizes the specific context that lead to the generation of each of these propertyvalues, or pieces of design data. This includes other relevant property values, either require-ments or constraints, that may have impacted the particular value derivation. Furthermore, italso includes the plans that were produced and executed during the design process, either togenerate the particular property value, or to optimize such value, or to verify the value. Notethat since plans explicitly refer to their relevant design data objects, the data events and thecontrol events of a given design process became thus properly related/unified in the repre-sentation. The ability to maintain such a complete and semantically expressive history of thedesign process allows for several useful applications. We will return to this issue in Chapters7 and 8.

5.7 Conclusions

This concludes our description of the knowledge level structures and data level structuresneeded to represent an arbitrarily complex design process, as defined by our formal theoryof design. In this description we decided not to be exhaustive, but rather to convey the mostimportant concepts involved in the derivation of the design space representation.

In Chapter 6 we will briefly describe the implementation of a Design Process Planning andManagement system, named Minerva, for being incorporated into general purpose CADFrameworks. Minerva directly implements the knowledge and data structures defined in thischapter.

1. Note that previous plans to solve specific design problems can always be reused, even if theoriginally used CAD tools no longer exist, since we are working at the CAD task level. (See dis-cussion on Chapters 1 and 2.)

Minerva Prototype

129

CHAPTER 6 Minerva

6.1 Minerva Prototype

Minerva [31] is a meta-tool for providing design process planning and management servicesthat was developed to be incorporated in state-of-the-art general purpose CAD Frameworks,i.e., CAD frameworks provided with CAD task management services. Minerva implementsthe knowledge and data level structure of a design space described above and provides theframework with mechanisms for representing, planning, and managing arbitrarily complexdesign processes. Since Minerva’s representation of design processes is problem-based, wemay say that Minerva implements the “problem level” of abstraction in CAD frameworks.

Our prototype employs a distributed architecture, which is composed of several executableprograms that implement the different agents of the paradigm described in Chapter 3. Theseexecutable programs are the Designer(also called Working Window), theSpace Manager,theKnowledge Baseand theDesign Process Manager (also called Planning Context). Min-erva is a domain independent system. The knowledge templates described in Chapter 5 pro-vide the means for customizing Minerva to a given design discipline. The knowledge baseof Minerva is currently ‘customized’ to VLSI digital design. All examples given in Section5.5 were taken from tests that were actually run using the prototype.

Minerva can work with any configuration of CAD resources, and does not preclude the useof interactive tools, such as layout editors. Minerva does not require complete knowledge ina given discipline to provide design process planning and management services, yet themore complete the knowledge base is, the better Minerva performs its various tasks. Fur-thermore, the highly structured problem oriented representation of design process providedby Minerva also provides CAD frameworks with the necessary infrastructure to effectivelyallow the incorporation of sub-systems for support of decision making that occurs during theconceptual phase of design.[32]

CAD frameworks provided with a Minerva design process planning and management sys-tem interface with human designers trough Designer type agents, or Working Windows.Designer type agents in CAD Framework applications of our paradigm are thereforeinter-active agents, in which they constitute the front-end offered by Minerva to human designers,

to actually undertake their design activity.1 Working windows provide a high-level, problem

based, view of design processes,2 aimed at helping designers to concentrate their effort on

1. From now on we will refer to designer type agents as working windows.

2. Natural in the sense that it tries to mimic the way designers conceptually conceive design.

Minerva

130

the creative and decisive aspects of design, i.e., on developing convenient problem specifi-cations that adequately prune the solution space before a design step is actually undertaken.

We will now illustrate the use of Minerva trough a series of snapshots from two sessions. Inthe first example we are interested in designing a 16 bits ripple carry adder, starting at logi-cal level. A problem in Minerva is characterized by a tuple that identifies the design domain,the facet, and the design objective of the problem. First of all, the designer is asked to selectthe first two elements of the problem definition tuple, i.e., the design domain and the facet

that will constitute the problem context. Figure 28 shows a view of∆k, the design domainhierarchy defined in Minerva’s knowledge base, that is offered to the designer to allow himor her to select the specific design domain and specific design facet for the target problem.Note the indication of the inheritance path for the currently selected design facet, in the bot-tom right corner of the window.

While the designer is browsing on∆k, he/she can request information characterizing the spe-cific facets being displayed. For instance, when the designer presses the button “InspectDecisions”, inside Adder, he or she verifies that the specific facet (Adder, Logical) corre-sponds a ripple carry adder, as shown in Figure 29. The designer then selects this particularfacet, by pressing the “Select Domain” button and then the “OK” button. The designer is

FIGURE 28 Defining the target problem - browsing on ∆k.

Minerva Prototype

131

then expected to select the particular design objective he/she wants to achieve within thiscontext. Figure 30 shows the process of selecting the design objective, i.e., the third compo-nent of the target design problem. As we can see, the designer selects the objective “Synthe-

size”.1

1. The selected “Synthesize” objective corresponds to the objective Synthesize_T discussed inchapter 5, where “T” denotes transformational.

FIGURE 29 Inspecting implicit design decisions.

FIGURE 30 Defining the target problem - the design objective.

Minerva

132

After the target design problem is selected, the design process commences. Figure 31 showsthe initial state of the design process. Note that at this point the process tree has just onenode, Adder, and the corresponding objectives sub-tree has also only one node, the Synthe-size objective.

By pressing the “Is A” button, the designer can verify the inheritance path of the selectedadder facet, as indicated in Figure 32.

FIGURE 31 Problem Selection Phase.

FIGURE 32 Displaying the inheritance path of facets represented in thedesign process tree.

Minerva Prototype

133

The designer still needs to complete the specification of the target problem, by assigningvalues to its domain dependant and to its objective dependant properties. In order to do so,he/she should press the “Specifications” button in the domain facet (Adder) and/or in thedesign objective (Synthesize).

Figure 33 shows the set of domain dependant properties shown to the designer after he/shepresses the button “Specifications” in Adder. Note that the “Behavioral_Representation”property has an implicit value for the facet. This means that the carry lookahead adderbehavioral description is already specified in Minerva’s knowledge base.

Since our designer wants to specify a 16-bit word size for the adder, he/she selects the word-size property, by pressing the corresponding button. Figure 34 shows a value being assignedto the word-size. Note the value restrictions “Unit” and “Range”, displayed on the upper leftcorner of the window. Note also the consistency constraint relating the properties word-size

and area.1 Both properties are at this point without a value. Figure 35 shows the set of prop-erties for (Adder, Logical), after the designer ‘closes’ word-size.

1. Note that the area property is displayed as an objective dependent property (the id “3” corre-sponds to the objective synthesize).

FIGURE 33 The set of properties for (Adder, Logic).

Minerva

134

Figure 36 shows the set of properties defined for the objective “Synthesize”. Figure 37shows the designer assigning a value to the area property. Note the consistency constraint,already indicating the value previously assigned to word-size.

FIGURE 34 Assigning a value to the word-size property.

FIGURE 35 The set of properties for (Adder, Logic).

Minerva Prototype

135

As soon as the designer finishes assigning values to the relevant properties, he/she shouldpress the “OK” button in the problem selection window shown in Figure 31. After doing so,

the first problem solving phase for the corresponding objective starts.1 Figure 38 shows thedesigner being notified by Minerva that the next problem solving phase for the currentdesign objective (Synthesis) is plan generation. After asking for the completion of the phase,

FIGURE 36 The set of properties for the synthesize objective.

FIGURE 37 Assigning a value to the area property.

Minerva

136

the designer has to select again the problem, as described before. In this new problem-solv-ing cycle, the designer is notified that the new problem solving phase is plan validation, asindicated in Figure 39.

During the plan validation, as shown in Figure 40, the designer is informed that resourceswere found (by the executive) to attempt to solve the synthesis problem. Note how the

designer forces the usage of the OCT tools, by rejecting the other candidate tool.1

The plan execution phase that follows is trivial. Only requests the designer to explicitly indi-

cate that he/she wants the plan to be executed.2

1. Note that such objective problem solving phases are declaratively specified in Minerva’sknowledge base, as discussed in Chapter 5.

1. Note that if the designer explicitly rejects all candidate tools, he/she creates an impasse. Wewill illustrate impasse resolution in the second example given in this session.

2. Note that, for instance, the designer may be interested in executing particular plans only at latehours.

FIGURE 38 Problem solving phase notification.

Minerva Prototype

137

Finally, the designer enters the execution validation phase, as shown in Figure 41. At thispoint Minerva informs the designer about the outcome of the plan execution, as indicated inFigure 42. Note that even if the plan is successfully executed, the designer is allowed toreject its results. The default option given to the designer, for rejection, is the “Reject” but-


FIGURE 40 Success in plan generation.

Minerva

138

ton, in which case Minerva executes its default action. The designer is also allowed toexplicitly request backtracking, either by restarting the current problem or by restarting the

parent problem.1

1. Since in our case the current problem is the top level problem (in the process tree), restartingthe parent problem “degenerates” is restarting the current problem.


FIGURE 42 Success in plan execution.

Minerva Prototype

139

Our designer decides to accept the plan execution results, by pressing the “Accept” button,and Minerva incorporates in the design process tree the high-level representation of thedesign step just performed. Figure 43 shows the resulting process tree, which indicates that afacet transition just occurred for the Adder. By pressing the button “is A”, the designer isinformed that the new facet in the process tree is an adder represented at Physical (or manu-facturing) level, as shown in Figure 44. Note that none of the facets is now selectable, which

indicates that the target problem is considered solved by Minerva.1

1. Note that the manufacturing level is the ground level for the VLSI digital design discipline.

FIGURE 43 Process tree indicating a transformational synthesis step.

FIGURE 44 The inheritance path for the new adder facet.

Minerva

140

The previous example was a behavior-driven design process. Let us now give a second andmore complex example, showing a realization driven design process. Let us assume that weare interested in designing a 16-bit Arithmetic Logic Unit (ALU). Let us also assume thatour designer is interested in start working at the register transfer level. Figure 45 shows theproblem definition tuple being selected, i.e., (ALU, RTL, design).

Figure 46 shows the design problem just defined already constituting the top level problemof the design process. The designer then press the “Specifications” button in ALU, in orderto specify domain dependent property values. Figure 47 shows the set of properties definedfor (ALU, RTL). The behavioral description property is displayed as open, which indicatesthat this property does not have an implicit value specified in Minerva’s knowledge base.Figure 48 shows a value being attributed to the word-size property. Figure 49 shows the listof properties defined for the pair (ALU, RTL) when the designer concludes the phase ofassigning values to properties. Note that the property behavioral description is left non-spec-ified.

FIGURE 45 Selecting the target problem.

Minerva Prototype

141

FIGURE 46 Problem Selection Phase.

FIGURE 47 The set of properties for (ALU, RTL).

Minerva

142

Figure 50 shows the first phase of the direct achievement of the “Design” top level objec-

tive, i.e., plan generation.1 Plan generation fails, as indicated in Figure 51. This outcomewas expectable since none of the canonical and/or key properties, such as ALU behavioral

FIGURE 48 Assigning a value to the word-size property.

FIGURE 49 The set of properties for (ALU, RTL).

Minerva Prototype

143

description and ALU structural description, had a value specified. The designer chooses toaccept the default action of Minerva for solving the plan generation impasse, by pressing the“Continue” button. The default action for solving a plan generation impasse for the“Design” objective, for the current Minerva knowledge base, is objective decomposition.

So, our designer presses the “Continue” button, and objective decomposition occurs. Figure52 shows the resulting objectives sub-tree for the pair (ALU, RTL). Note that at this pointthe sub-objective Conceptual Design can be selected, while the sub-objective Synthesis can

not.1 Our designer then selects conceptual design and a new problem solving cycle starts,now for the problem (ALU, RTL, Conceptual Design). Figure 53 shows the ConceptualDesign sub-objective, being addressed. In order to accomplish such an objective, the set of

design issues defined for the pair (ALU, RTL) is presented to the designer.2 Note the order-ing constraint forcing the design issue “fabrication technology” to be addressed before the

design issue “layout style.”3

1. Note that these phases, for each design objective, are declaratively defined in the knowledgebase.

1. As in the previous case, the objective decomposition and sequencing of sub-objectives isdeclaratively specified in Minerva knowledge base.

2. Such design issues are declaratively specified in Minerva’s knowledge base.

3. The visible outcome of the consistency constraint is that the design issue layout style cannot beselected at this point.


Minerva

144

FIGURE 51 Failure in plan generation.

FIGURE 52 Objective decomposition. Conceptual design ready for selection.

Minerva Prototype

145

Figure 54 shows the “fabrication technology” design issue being addressed, i.e., the relateddesign options being presented to the designer, for selection. After deciding on the technol-ogy to be used, the design addresses the “layout style” design issue, as shown in Figure 55.Note that the option “gate array” is depicted as inconsistent with previous decisions. Byselecting an inconsistent option the designer is informed about the previous design deci-sion(s) that made the specific design option inconsistent, as shown in Figure 56.

FIGURE 53 Conceptual Design: two open design issues and one closed design issue.

Minerva

146

FIGURE 54 Conceptual Design: addressing the fabrication technology design issue.

FIGURE 55 Conceptual Design: addressing the layout style design issue.

Minerva Prototype

147

Figure 57 shows the result of a designer attempt to delete an implicit design decision, duringconceptual design. A warning window is issued, to inform why such request cannot begranted. Figure 58 shows a request for re-opening a given design issue being granted.

Let’s jump to a later point, in this same design process. Figure 59 shows a snapshot of theobjectives sub-tree associated with the facet (ALU, RTL) in this new point. As can be seen,the plan generation phase for the synthesis objective also failed, and the impasse was alsosolved by objective decomposition, i.e., the objective synthesis issued a “Decompose” sub-objective. The objective decompose will now attempt to perform structural decompositionfor the (ALU, RTL), in order to proceed with the design process. So, as it can be seen,

FIGURE 56 Conceptual Design: consistency constraint.

FIGURE 57 Conceptual Design: backtracking.

FIGURE 58 Conceptual Design: backtracking.

Minerva

148

design object decomposition, as any other design action, is achieved by means of a specificdesign objective

As in the case of “Conceptual Design”, the “Decompose” objective also has an alternatives

exploration problem solving phase.1 Figure 60 shows the designer addressing the “decom-position” design issue. The design options are constituted by a set of predefined decomposi-tions and by a “My_Form” option, that allows the designer to enter his/her own structuraldecomposition.

1. Again, it is declaratively defined that way, in the current Minerva’s knowledge base.

FIGURE 59 The decomposition design objective

Minerva Prototype

149

Figure 61 shows the process tree resulting from the selection of one of the pre-compileddecompositions. Both descendant domain facets are represented at register transfer level,

and both have associated sub-tree of objectives composed by a single node, “Design”.1 Thisdesign process has currently two design problems that can be addressed concurrently:(Adder, RTL, Design) and (Register, RTL, Design). Such problems would be addressed asillustrated before. Due to space limitations, this concludes the discussion of our secondexample.

1. When design object decomposition occurs, Minerva propagates the top level design objectiveassociated with the parent facet to the descendant facets.

FIGURE 60 The decomposition design issue.

Minerva

150

6.2 Integration Issues

Minerva is currently running with a specially designed executive system that emulates out-

comes of a real CAD framework executive.1 The reason for this specially designed execu-

tive, i.e., the reason why Minerva is not yet working with the executive of Odyssey2, is thatat present each employ a different characterization of design data and CAD tools. More spe-cifically, at present, data and tool encapsulations in Odyssey have been defined so as toresult in the efficient preparation of data for tool executions within the context of CAD

tasks. Thus, current CAD tool encapsulations follow a fundamentally syntactical approach3

somewhat mirroring the CAD task definition, i.e., specifying the number of data entities

1. However, plans generated by Minerva were successfully used to provide the OCT tools withthe necessary input for generating digital processing elements such as ALUs and adders.

2. As mentioned before, Odyssey is a general purpose CAD framework under development atCMU.

3. A syntactical representation is one more concerned with form or syntax than with content orsemantics.

FIGURE 61 Process tree: design object decomposition.

Integration Issues

151

needed to run a given tool and the specific syntax for each of the corresponding datainstances, when given as inputs to a particular tool. Data encapsulations are also basicallysyntactically oriented, since they are primarily aimed at fulfilling CAD task related needs.This information is indeed absolutely necessary, but it is not rich enough to support designprocess planning and management.

Minerva requires design data, i.e., values for design object related sub-specifications, to be“semantically abstracted” in their respective encapsulations. In particular, each relevantpiece of design data, or design data instance, available to the framework should be properly

classified according to the design hierarchy∆k characterized in Minerva’s knowledge base.This semantic characterization of design related data is absolutely essential for supporting ameta-tool like Minerva. For instance, when a synthesis tool generates a new piece of designdata, itmust return to Minerva, not only the “id” of the actual physical data itself, but also asummary characterization of such data, i.e., at least an indication of the design domain andspecific facet that constitute the semantic context of the generated piece of design data.

Even if tool encapsulations do not really have a primary impact on Minerva, a proper toolencapsulation may lead to an easier and, thus, more efficient communication between theexecutive component of the framework and Minerva. Tool encapsulations should identifythe specific design function or set of design functions performed by their correspondingtools, preferably according to the design objective definitions characterized in Minerva’s

knowledge base.1 Furthermore, design data instances, that are created, used and/or modifiedeither as inputs and as outputs by such encapsulated tools, should also be properly character-ized in the tool encapsulation, or the tool encapsulation should refer to a proper externalcharacterization.

Let us give some examples. A proper tool encapsulation should define, for instance,

• switch level simulators as operators aimed at simulating the timing behavior of dataobject instances defined at the logic level;2

• the synthesis and optimization subset of the OCT tools [33][34] as a synthesis meta-operator that transforms a given behavioral description defined at the logical level intoa structure realization constraint (i.e., a mask layout) defined at manufacturing level;

• OASYS as a synthesis operator that transforms a set of functional requirements forthe domain of operational amplifiers, defined at circuit level, into a structure realiza-tion constraint (i.e., a mask layout) for the same operational amplifier, defined at man-ufacturing level.

1. CAD tools are operators aimed at solving design (sub)problems. Recall that design objectivesare the elements in the design problem that characterize the problem type. (See Chapter 4)

2. So, any design data instance associated with a facet that derives from the logic level in the fac-ets tree will allow for the use of the particular simulator.

Minerva

152

Note that by using such encapsulations, the output produced by OASYS can be staticallycharacterized as being a structure realization constraint (i.e., a mask layout) of an OPAMP atthe manufacturing level. Similarly, the output produced by the synthesis configuration of theOCT tools can be statically characterized as belonging to the design domain of the objectwhose logic behavior was described as input, but now represented at the manufacturinglevel. As illustrated in the two previous examples, the problem of semantic characterizationof design data can much easily be addressed if proper tool encapsulations are provided in theframework.

Moreover, we believe that introducing this new semantic dimension in the design data andCAD tool encapsulations would benefit the Odyssey executive itself. Indeed, we have beenintroducing a set of conceptual directives aimed at guiding tool and data encapsulations thatcould substitute with significant advantage the ad-hoc methods currently used, since itwould allow for minimizing the potential for introducing redundancies and inconsistenciesin those encapsulations. Note that Cyclops, the resources manager of Odyssey, has potentialto support any type of encapsulation, and, therefore, the specific resource level needs intro-duced by Minerva can be easily handled by Odyssey.

6.3 Evaluation Issues

In Section 6.1 we illustrated two real design process planning and management sessionswith Minerva. These examples are intended to demonstrate that our proposed knowledgeand data level structure of a design space can be implemented, and it also demonstrates thatdesign process planning and management services can be offered by general purpose CADframeworks. Yet, a reasonable question to be posed at this point is “how good is our pro-posed design space representation”.

We feel that absolute claims on the optimality of our representation are simply not meaning-ful. It is important to note that most problem solving techniques can be seen as a science andan art.[35] The science aspect lies in providing methods and algorithms for solving properlyformulated problems. The art aspect results from the fact that decision problems usuallyinclude important intangible factors which cannot be directly translated in terms of a modelusing some sort of systematic procedure. Note that a model in this context should be thoughtof as a vehicle for “summarizing” (i.e., defining and describing) a problem in a manner thatallows a systematic identification and evaluation of all decision alternatives of the problem.

Maybe the most important among these “fuzzy” factors is the presence of humans in theproblem solving or decision environment. Because we are dealing with design, the ultimateexample of an artificial science, the usefulness and the success of a design space representa-tion largely depends on a clever identification and adequate assimilation of the humanrelated factors.[36] This fact makes any design space representation very difficult to evalu-ate in absolute, i.e., quantitative, terms, and therefore only claims on the adequacy of our

Evaluation Issues

153

specific design space representation and comparisons with previous approaches are reason-able to be made.

Unfortunately, comparisons with other formal theories for describing design processes areimpossible, because such theories do not exist, at least with the same generality, and com-pleteness, as the one proposed here. So, in order to evaluate our proposed design theory andrepresentation of the design space, we have to compare the performance of a designer inter-acting with the framework at the “problem level”, implemented by Minerva, with the perfor-mance of a designer working solely with the framework executive, i.e., interacting with theCAD framework at the CAD task level. Note finally that the services provided by Minervatarget designers and project managers, and, therefore, these services should be evaluatedfrom those two points of view

Let us start then by discussing the services provided for the designer. Minerva has the capa-bility of:

• assisting decision making;

• enforcing consistency among design decisions taken throughout the design processand assisting designers in general consistency issues;

• generating design plans (or partially ordered sequences of operators) subject to avail-able resources and users preferences;

• monitoring plan execution;

• solving plan generation and plan execution impasses.

While the need for such services has been acknowledged by all designers we have talked to,they are not willing to give up any flexibility in their ability to explore the solution space or,to abandon their preferred design methodology, in order to have these design process plan-

ning and management services.1 The key issue, from the designer’s point of view, is, there-fore, getting an adequate design space representation.

Properly addressing the designer’s interest in maintaining flexibility has been a fundamentalconcern throughout our work. We feel that our proposed solution for design process plan-ning and management successfully maintains flexibility. Specifically,

(1) Minerva allows any design methodology to be used, or even several design meth-odologies to be intermixed, during the design process;

(2) Minerva supports both routine and exploratory designs. Routine design processesbegin with a well-defined set of specification values. Exploratory design processes

1. As discussed in Chapter 1, these services cannot be offered by CAD task and flow-basedapproaches.

Minerva

154

begin with an incomplete set of specifications values, that may significantly changethroughout the process;

(3) Minerva allows designers to naturally change the “default” design process controlflow, by providing them with a complete set of alternative courses of action that maybe taken, given the outcome of any specific plan generation or plan execution phase;1

(4) Minerva does not impose any pattern for addressing (sub)problems in the designprocess, i.e., it only enforces problem sequencing when consistency has to be guaran-teed;

(5) Minerva is fully customizable, i.e., it does not impose any particular design hierar-chy and any methodology for exploring the solution space. Adequate design hierar-chies and design methodologies with any complexity can be captured in Minerva’sknowledge base.

Let us now discuss the project manager’s point of view. Minerva has the capability to:

• represent projects, that consists of sets of alternative design processes being developedsimultaneously for a given target problem;

• show the conceptual differences and reasons motivating each design alternative;

• show the exact state of development of each alternative;

• show which design methodologies are being used locally and globally;

• show which problems can be addressed concurrently at each given moment;

• show which problem each designer or team of designers is working on.

To date these types of services have not been included in any CAD Framework. Moreover,Minerva provides the foundation to start addressing two common concerns frequentlyexpressed by project managers. To date, once a design has been completed, it is virtuallyimpossible to retrieve any data relative to such a project. Sometimes, reverse engineering isthe only option left when, after a certain amount of time, an in-house design has to beaccessed for some additional work. The second concern is that the design expertise in acompany lies almost exclusively in its designer’s heads. No know-how seems to be accumu-lated in any effective form by the institution itself.

These concerns can be addressed in terms of two very specific issues. The first is defininghow to store and organize design data, after a project is concluded, in order to guaranteeeasy retrieval of such data. The second involves deciding what is actually worth storingfrom the entire project history keeping in mind further reuse of the associated expertise orknow-how. Minerva provides the foundation to start addressing these important issues. Inparticular, Minerva provides the basic foundation for implementing “run time” collection of

1. Designers are allowed to modify the default control flow of the design process for any designphase outcome, and not just when a impasse occurs.

Evaluation Issues

155

know-how in companies, in a non-intrusive way, and would naturally organize such infor-

mation in terms of problems.1 Note that this natural problem based organization provided byMinerva can prove to be very convenient for storing, examining and retrieving informationsince it is a highly abstracted representation. We will return to this issue while discussingfuture work in next chapter.

1. As opposed to information explicitly declared by designers, that can thus suffer from incom-pleteness or even inaccuracy, and that takes time to be produced.

Minerva

156

Main Contributions

157

CHAPTER 7 Conclusions and FutureWork

7.1 Main Contributions

The main contributions of this work can be summarized as follows:

• development of a formal theory of design for describing design processes;

• development of a paradigm for design process planning and management that properlyaccommodates all real world agents and resources cooperating in the design activity;

• development of a domain independent, and heuristically and epistemologically ade-quate general representation of the design space based on the proposed design formaltheory, and in the proposed design process planning and management paradigm;

• modelling of design processes as a problem solving activity developed in a designspace defined by the previous design space representation;

• realization of a new abstraction level for CAD Frameworks, the problem level, aimedat supporting design process planning and management services in CAD Frameworks.

7.2 Future Work

The discussion of future work is organized in two sections, one addressing continuity issuesand the other addressing new research areas opened by our contribution.

7.2.1 Continuity Issues

A general knowledge acquisition tool should be developed to assist designers and/or knowl-edge engineers in the development of knowledge bases specially tailored to the interests ofspecific communities of designers, and/or in inserting additional knowledge into existentknowledge bases. An important issue directly related with this topic is the question of main-taining the overall consistence of the knowledge captured in specific knowledge bases. Top-

ics such as detecting redundancy and finding optimal topologies for∆k should be carefullyaddressed in this context.

Another important continuity issue is related with the effective integration of Minerva intothe Odyssey CAD Framework. A key issue at this point is the proper implementation in the

Conclusions and Future Work

158

executive component of Odyssey of the communications protocol described in Section5.2.2.1. Another important issue is to provide Odyssey with adequate, i.e., semanticallyexpressive, tool and data encapsulations.

A final continuity issue is concerned to providing Minerva with multimedia facilities aimedat capturing less traditional/formal types of information. This would provide designers withcapability for effectively capturing and sharing, in the context of a given design process, alltypes of information generated during the entire design process. This includes the particu-larly vague and informally stated information that is typically generated during the very ini-tial stages of design process.

7.2.2 New Topics in CAD Frameworks

The two new research topics in the area of CAD Frameworks created by our contributionare: (1) automatic learning in CAD Frameworks, in order to create shared memories of com-munities of designers; and (2) integrated coverage for the entire design cycle, i.e., applica-tion of Minerva to manufacturing, thus “closing” the design cycle.

Minerva provides the basic foundation to start exploring automatic learning capabilities inCAD Frameworks. Two particular areas seem promising for the application of such learningtechniques. One area in which automatic learning can play a key rule is in deriving, by directand automatic inspection of design objects created during design processes, new, more spe-cialized, abstract classes of design objects to be added to existing knowledge bases. Notethat, after such new abstract classes of design objects are properly identified and added tothe knowledge base, nothing precludes designers and/or knowledge engineers from com-pleting (adding more knowledge to) the generated domain facets.

A second key area in which the application of automatic learning techniques, specificallylearning by analogy techniques [37] provide an interesting outcome is in extracting generaldesign expertise from inspecting the compete history of design processes. Being more spe-cific, previously developed design plans can be properly characterized in a problem basisand then stored for further reuse when a similar problem is recognized. By proper character-ization we mean a proper indexing scheme defining what constitutes a similar problem for agiven design discipline. Such schema would certainly explore concepts such as domain gen-eralizations and specializations, key abstract properties, and intervals of values for suchproperties. This incremental learning process should be done in a non-intrusive way. Notethat by successfully implementing such learning techniques, CAD frameworks can indeedbecome active recipients of designer’s knowledge. A side effect of this work would be toautomatically generate and maintain, in the CAD Framework, an “alive” data base of previ-ous designs.

Another very promising area for further research is in extending the use of CAD Frame-works, and particularly Minerva, to Manufacturing Processes. The specific application we

Future Work

159

feel is worth pursuing is the “design” of VLSI manufacturing processes. The main ideabehind this is to provide the means for bringing two usually very distant communities a littlecloser: the designers and the process engineers. This would certainly have a positive impactin improving the efficiency of the entire design cycle, since a significant percentage of prob-lems arising in such a cycle is generally acknowledged to result from lack of communicationbetween designers and process engineers. The main issues related to applying Minerva tothe “design” of VLSI manufacturing processes were already explored by us and the prelimi-nary results show that the design of manufacturing processes indeed verifies the validityassumptions of our design theory, i.e., that Minerva can be directly used to provide designprocess planning and management services for the design of manufacturing processes.

Conclusions and Future Work

160

161

APPENDIX A An operator’s scenario forVLSI digital circuits

As discussed in Chapter 3, the complexity and/or granularity of CAD tools may vary signif-icantly from design discipline to design discipline. It may also vary significantly within thesame broad design discipline, depending on the specific types of problems being addressedand/or on the particular abstract classes of design objects under design. Yet, in order to pro-vide some insight on what may constitute a real world CAD environment, in this appendixwe briefly discuss theOct Tools, an extensive and coherent set of CAD tools for logic syn-thesis that have been developed in the last decade at UCB. Below we enumerate some of theCAD tools contained in the Oct Tool set.

• Expresso: boolean minimizer;

• Electra: static CMOS gate-matrix module generator;

• GEM: CMOS module generator macro;

• OCTPLA: PLA1 generation macro;

• Anchor/Octopus: PLA module generator;

• Genie: generalized array optimizer;

• MiscII: multiple-level combinatorial logic optimizer;

• TimberWolfMC: macro-cell placement and routing;

• TimberWolfSC: standard-cell placement and routing;

• Musa: multi-level simulator (former BDSIM);

• PadPlace: pad placement;

• BDSYN: transforms behavioral description into logic equations;

• Sparcs: IC symbolic layout spacer;

• VEM: graphics editor;

It is important to note that not all tools contained in the above set are in the same stage ofdevelopment, i.e., have the same robustness and generality in addressing their specificdesign problems. Note also that some of these tools, such as GEM, are just “macros”, aimedat running other tools in a particular sequence.

Describing the functionality of each of the above CAD tools would be tedious and not veryinformative from the point of view of characterizing a possible VLSI digital circuit design

1. PLA stands for programmable logic array.

162

environment. Instead, we choose to give some examples of the usage of these tools inaddressing a synthesis problem. Being more specific, we will illustrate the usage of the Octtools set for implementing a particular logic circuit. Three design alternatives will be devel-oped using different layout techniques:standard-cell, PLA, and gate-matrix. Before startingthe discussion on the usage of the tools, and in order to put in perspective the particulardesign alternatives being explored, let us thus briefly discuss the issue of the layout style.

Full custom layout has been traditionally error prone, time consuming, and requires expertswell-trained in the art. The alternative layout techniques mentioned above try to exploitsome sort of regularity in the final layout, at the cost of some area, power and speed penal-ties. Let us now discuss the specifics of each of these regular layout techniques.

Standard-cell designs rely on a set of predefined cells organized in a library. Such cells havea predefined layout and logic. Complexity of cells can vary from small scale of integration

(SSI) type components, such as gates1 and latches,2 to medium and large scale of integration

(MSI/LSI) type components, such as RAMs.3 Recently, systems have been proposed andimplemented that hierarchically group primitive cells together to form larger blocks andthen combine these to realize complete circuits.

Programmable logic array (PLA) design, on the other hand, provides a regular structure forimplementing combinatorial and sequential logic functions. The basis for a PLA is a sum ofproducts form of representation of binary expressions. A typical PLA uses an AND-ORstructure similar to that shown below. A PLA may be used to take inputs and perform somecombinatorial function of these inputs, thus forming a combinatorial circuit or, additionally,some outputs may be feedback to the inputs, thus forming a sequential circuit.

1. Gates are realization structure building blocks that implement primitive functions of combina-torial logic. Examples of gates are NAND and NOR.

2. Latches are realization structure primitive building blocks implementing memory primitives.Latches are essential for building sequential logic, i.e., circuits whose outputs depend on pastinputs. An example of a latch is an SR (set-reset) flip-flop.

3. RAM stands for random access memory.

ANDPLANE

LATCHES

ORPLANE

LATCHES

inputs outputs

clock clock

163

Finally, gate-matrix is a layout technique that promotes regularity by employing a matrix ofintersecting transistor diffusion rows and polysilicon columns. The use of such constrainedstyle can aid in the design of large circuits where many design teams have to design largeblocks concurrently. The basic format is not hierarchical, though. Blocks must be assembledin their entirety and pasted together at the mask level. In addition, there is no freedom tolocally optimize geometry, such as alter transistor sizes to reflect circuit loading.

We are now ready to illustrate the usage of the Oct Tool set for designing a logic circuitusing the three layout techniques just discussed. Note that in all cases the cell is initiallydescribed in a high level logic language, then this description is translated into logic equa-tions, then minimized, and finally implemented.

Let us start by discussing the standard-cell implementation. Initially the designer would

invoke the CAD tool bdsyn, to translate the BDS1 functional description into a set of logic

equations in the BLIF2 format. Bdsyn is thus a description translator that was written to be afront end to the Berkeley synthesis system. The designer would then invoke the toolmiscII,that takes as input the BLIF description and optimizes the logic equations, i.e., produces anoptimized set of logic equations which preserves the input-output behavior of the macro-cell. The tool includes algorithms for minimizing the area required to implement the logicequations and a technology mapping step to map a network into a user specified cell library.Note that miscII has a sophisticated set of network manipulation commands and a commandinterpreter that allows designers to have significant control over the optimization techniquesused for minimizing the boolean equations. After concluding this minimization step, thedesigner should invoke the toolmusa, a logic and switch level simulator, in order to verifythe correctness of the description produced by miscII. If the original logic behavior is stillpreserved in the current description, the designer would invokepadplace, a tool used for

assigning terminal implementations and locations in the chip.3 After concluding this step,the designer should invokeTimberWolfeSC, a standard cell placer and global router. Timber-WolfSc attempts to find a placement of the standard cells such that the total estimated wirelength is minimized. Furthermore, final standard cell placement adjustments are performedso as to minimize the total number or wiring tracks required to route the chip. The adjust-ments include cell orientation changes and neighboring cell interchanges. Note that somewires may have to be added by the designer, since the routing coverage achieved by Timber-WolfSC is not always of one hundred percent. Finally, the designer would invoke againmusa, in order to verify if the logic is still the same. The designer can also invokevem, agraphical editor, to take a look at the chip, in order to better identify problem areas.

1. Bds is a high level simulation language, used for high-level simulation in DECSIM. DECSIMis a multilevel simulator developed by Digital Equipment Corporation.

2. BLIF stands for Berkeley Logic Interchange Format.

3. Being more specific, padplace assigns terminal types, directions, edges, and positions in thechip.

164

Let us now discuss a PLA implementation of the exact same circuit, using again the OctTool set. As in the previous case, the designer starts by invoking bdsyn, in order to convertthe original behavioral description, given in BDS format, to logic equations. Then, he/shewould invoke OCTPLA, a macro that sequentially executes five tools. The first tool invokedby OCTPLA is misII, in order to convert the BLIF format into the PLA format. Then, OCT-PLA runs the toolexpresso to minimize the logic. After that, OCTPLA runsgenie to gener-ate the PLA array, and then runsoctopus to connect the cells. Finally, OCTPLA runssparcs,to compact the layout. At this point the designer would use musa, to simulate the PLA inorder to verify if the logic is still the same. As in the previous case, the designer can theninvoke the graphical editor vem, to take a look at the PLA.

Finally, let us consider the gate-matrix implementation. As in the previous case, the designerstarts by invoking bdsyn, in order to convert BDS to logic equations. Then, he/she wouldinvokegem, a macro that sequentially executes five tools. The first tool invoked by gem ismisII, in order to convert the BLIF format into the PLA format. Then, gem runs the toolexpresso to minimize the logic. After that, gem runsgenie to generate an array, and thenrunselectra to connect up the cells. Finallysparcs is invoked to compact the layout. At thispoint the designer would use musa, to simulate the gate-matrix implementation in order toverify if the current logic description is still correct. As in the previous case, the designercan then invoke vem, to take a better look at the result.

Note that even if the Oct Tools set provides tools for addressing most design problems inthis particular design sub-discipline, the verifier musa and the graphical editor vem are stillabsolutely necessary, since, as mentioned before, the various Oct tools not always success-fully accomplish their tasks. Frequently the designer must intervene to modify incorrectsolutions, or to remove the tool from a deadlock situation, trying to “push it” to a morefavorable region of the solutions space. Furthermore, certain tools, such as the logic mini-mizers and the placers and routers, have a variety of input parameters that allow the designerto select the particular methods to be used in the problem solving process, and to furthertune these methods to the specifics of the situation. In other words, some key decisions arestill expected to be done by the designer. A detailed discussion of these examples can befound in [33].

165

Bibliography

[1] Architecture Technical Subcommittee: Requirements Task Group.CAD FrameworkUsers, Goals, Objectives, and Requirements. CAD Framework Inniciative (CFI)Technical Report, Version 1.4, February 1990.

[2] J. Brockman, T. Cobourn, M. Jacome, and S. Director. The ODYSSEY CAD Frame-work. IEEE DACT Newsletter on Design Automation, Spring 1992.

[3] M. Terk. A Problem-Centered Approach To Creating Design Environments ForFacility Development. PhD thesis, Carnegie Mellon University, Department ofCivil Engineering, June 1992.

[4] J.B. Brockman.A Schema-Based Approach to CAD Taks Management. PhD thesis,Carnegie Mellon University, Department of Electrical and Computer Engineering,June 1992.

[5] A. Casotto, R. Newton, and A. Sangiovanni-Vicentelli. Design Management based onDesign Traces. In Proceedings of27th ACM/IEEE Design Automation Confer-ence, ACM Press, 1990.

[6] P.R. Sutton, J.B. Brockman., and S.W. Director. Design Management Using Dynami-cally Defined Flows. In Proceedings of30th ACM/IEEE Design Automation Con-ference,ACM Press, 1993.

[7] K.O. ten Bosh, P.Bingley, and P. van der Wolf. Design Flow Management in theNELSIS CAD Framework. In Proceedings of28th ACM/IEEE Design Automa-tion Conference, ACM Press, 1991.

[8] T. Cobourn. Resource Management for CAD Frameworks. PhD thesis, Carnegie Mel-lon University, Department of Electrical and Computer Engineering, May 1992.

[9] J. Pearl.Heuristics. Intelligent Search Strategies for Computer Problem Solving.Addison-Wesley, 1984.

166

[10] A. Dewey.Principles of Very Large Scale (VLSI) System Planning. PhD thesis, Car-negie Mellon University, Department of Electrical and Computer Engineering,June 1989.

[11] R. Harjani.OASYS: A Framework for Analog Circuit Synthesis. PhD thesis, Carn-egie Mellon University, Department of Electrical and Computer Enginering,March 1989.

[12] H.A. Simon.The Sciences of the Artificial. The MIT Press, 1981.

[13] E. Sacerdotti. Planning in a Hierarchy of Abstraction Spaces. InArtificial Intelli-gence, (5):115-135, 1974.

[14] C. Zozaya-Gorostiza, C. Hendrickson, and D. Rehak.Knowledge-Based ProcessPlanning for Construction and Manufacturing. Academic Press Inc., 1989.

[15] L.D. Herman, F. Hayes-Roth, V.R. Lesser, and D.R. Reddy. The HEARSAY-IIspeech understanding system: Integrating knowledge to resolve uncertainty. InComputing Surveys, 12(2):414-42, 1990.

[16] S.N. Talukdar, P.S. de Souza, R. Quadrel, and V.C. Ramesh.A-Teams: Multi-AgentOrganizations for Distributed Iteration.Carnegie Mellon University, EDRC 18-30-92, 1992.

[17] B. Hayes-Roth. A Blackboard Architecture for Control. InReadings in DistributedArtificial Intelligence. Morgan Kaufmann, 1988.

[18] R.G. Smith. The Contract Net Protocol: High-Level Communication and Control ina Distributed Problem Solver. InReadings in Distributed Artificial Intelligence.Morgan Kaufmann, 1988.

[19] R. Davis, and R.G. Smith.Negotiation as a Metaphor for Distributed Problem Solv-ing. InReadings in Distributed Artificial Intelligence. Morgan Kaufmann, 1988.

[20] E. Siepmann.A Design Theory for Engineering Design.Submitted for publication,.1993.

167

[21] R.L. Geiger, P.E. Allen, and N.R. Strader. VLSI Design Techniques for Analog andDigital Circuits. McGraw-Hill, 1990.

[22] R.J. Papalmbros, and D.J. Wilde. Principles of Optimal Design. Cambridge Univer-sity Press, 1988.

[23] A. Sangiovanni-Vicentelli. An Optimization Problem Arising from Tearing Meth-ods. InSparse Matrix Computations. Academic Press, 1976.

[24] J. Gosling.Algebraic Constraints. PhD thesis, Carnegie Mellon University, Schoolof Computer Science, 1983.

[25] J.N. Hooker, and H.Yan. Tight Representation of Logical Constraints as CardinalityRules.Carnegie Mellon University, EDRC 70-06-92, 1992.

[26] A. Diaz-Calderon.A Comparison of Task Management Approaches for EngineeringDesign Processes.MS thesis, Carnegie Mellon University, Department of CivilEngineering, April 1993.

[27] E. Rich.Artificial Intelligence. McGraw-Hill, 1983.

[28] H.A. Taha.Operations Research: An Introduction. Collier Macmillan, 1987.

[29] N. Weste, and K.Eshraghian.Principles of CMOS VLSI Design: A Systems Perspec-tive. Addisson-Wesley, 1988.

[30] R.L. Blackburn.Relating Design Representations in an Automated IC Design Sys-tem.PhD thesis, Carnegie Mellon University, Department of Electrical and Com-puter Engineering, October 1988.

[31] M.F. Jacome, and S.W.Director. Design Process Management for CAD Frame-works. In Proceedings of29th ACM/IEEE Design Automation Conference.ACMPress, 1992.

168

[32] J.C. Lopez, M.F.Jacome, and S.W. Director. Design Assistance for CAD Frame-works. In Proceedings ofFirst GI/ACM/IEEE/IFIP European Design Automa-tion Conference. ACM Press, 1992.

[33] R.L. Spickelmier, and P.Cohen.Examples of Tool Use in Octtools 3.5.University ofCalifornia, Berkeley, Electronics Research Laboratory, Technical Report, 1990.

[34] DeMicheli, G.,Computer-Aided Synthesis of PLA-Based Systems1984, Universityof California, Berkeley, Electronics Research Laboratory:

[35] A. Newell, and H.A. Simon.Human Problem Solving.Englewood Cliffs, 1972.

[36] R.S. Michalski, J.G. Carbonell, and T.M. Mitchell. Machine Learning: An ArtificialIntelligence Approach. Morgan Kaufmann, 1983.

design process planning and management for cad … f. jacome carnegie mellon university pittsburgh,...

Documents