- Email: [email protected]
VLSI design with object-oriented knowledge bases
VLSI design with object-oriented knowledge bases Phillip C-Y Sheu One major technology that is needed is the development of a system that can integrate design tools and design databases, and is able to design an entire engineering system based on formal specifications. In this paper, a knowledge engineering framework for designing VLSI computer architectures is introduced. This framework introduces three core concepts: knowledge abstraction, object-oriented design, and very high-level design programming. The input to the system is a descriptive specification of the behaviour of a computing system. The description is then matched against the existing design knowledge in the knowledge base, where the knowledge is abstracted and organized as classes. If a match can be found, the abstract knowledge is instantiated and can be reused; otherwise a heuristic synthesis process will be performed according to the design knowledge stored in the system. In the worst case, the designer goes one level down and decomposes the system into a set of smaller systems, where a structural description among different modules is specified, but only the behavioural specification for each module is given. The process is then repeated until a complete structural description is developed. A t the bottom level, the system is designed to support and automate the following tasks: integration of layout design tools," propagation of dynamic changes; propagation and abstraction of performance measurements," incremental design rule checking," and version control. computer-aided design, VLSI, object-oriented design
In general, VLSI circuit design is a 'cut-and-try' process. Despite the availability of CAD software, the actual design process requires trying many different methods and selecting the one that works the best. The designer develops tentative solutions and then selects his tentative solutions by analysing the results of executing one or more steps. At the abstract level, VLSl design is a subclass of the general problem-solving problem whose solutions include a sequence of operations given the initial and the final state of the problem. The dream of silicon compilation (i.e. to develop automatically an entire VLSI system from a formal behavioural specification) cannot become true unless there is a design environment that integrates the design database (which stores the states of design process), design tools (which serve as the operations to change the state of a design and to analyse the performance of a design) and design knowledge (which determines how the states of a design process are changed) 1 . Such an environment maps a problem specification into mask descriptions for circuit fabrication 2. This typically spans at least three different dimensions for
Electrical Engineering, Purdue University, West IN 47907, USA
School of
272
Lafayette,
representing a problem: behavioural (or functional), structural (or architectural), and physical (or geometric); along several levels of abstraction along each dimension. Functional abstractions include Boolean expressions and programs written in a high-level programming language. Structural abstractions include descriptions at the registertransfer level, the switch level, the transistor level, and so on. Physical abstractions capture placement and geometry. In carrying out the transformation process automatically, the design environment described above has to have the following capabilities: •
Management of complex objects at different levels of abstraction. • Management of dynamic changes made to design representations at different levels of abstraction. • Support of design evolution. • Integration of different design tools. Most of the research in the past has addressed some, but not all, of the above issues; and therefore provided partial, but not complete, solutions to the next-generation design automation system. Research in the area of CAD databases 3-8 has concentrated on the following two issues. First, extending the relational database framework with semantic data models that may capture more of the semantics of CAD objects 9-12. Second, extending conventional database frameworks with the capabilities of CAD transaction management 13-1s and version control16-18 In another direction, CAD researchers have developed more intelligent design tools to facilitate the processes of performance analysis and physical layout 2'19-31 . Such tools have been demonstrated to be useful in analysing circuit designs and transforming structural descriptions of circuits into geometric descriptions. Consequently, according to the requirements listed above, research is needed to address the following issues: •
Integration of design database and design tools in a coherent, uniform environment. • Representation and management of design knowledge. • Development of automatic design synthesis methodology according to which a sequence of design operations/decisions can be made to satisfy the design requirement. • Management of design entities such that state changes in the environment can be made consistently. According to the above requirements, an integrated knowledge-based system approach for the purpose of automatic VLSI system design is described. At the top level, this approach is based on the concepts of object-oriented design, reusability, and knowledge-based design synthesis. The input to the design environment is a descriptive specification of the desirable behaviour of a computing system.
0010-4485/88/050272-09 $03.00 © 1988 Butterworth & Co (Publishers) Ltd
computer-aided design
Finally, a knowledge-based heuristic search approach for automatic circuit synthesis is sketched.
The description is then matched against the existing design knowledge in the knowledge base, where the knowledge is abstracted and organized as classes. If a match can be found, the abstract knowledge is instantiated and can be reused. If the target design fails to match an existing class, the system will try to synthesize a satisfactory design based on the design knowledge stored in the knowledge base. When both approaches fail, the designer goes one level down and decomposes the system into a set of smaller systems, where a structural description among different modules is specified, but only the behavioural specification for each module is given. The process is then repeated until a complete structural description is developed. At the bottom level, the system is designed to support and automate the following tasks:
ACTIVITIES IN VLSI SYSTEM DESIGN PROCESSES Since Mead and Conway first described VLSI technology32, the term silicon compilation has drawn much attention. In a broad sense 33, silicon compilation can be defined as a translation process from a high-level description into a layout. A typical VLSl design system based on silicon compilation methodology is shown in Figure 1. A functional (or behavioural) description of the circuit is specified by the user as the input (where the functional description may be in the form of finite state machine, Boolean expression, or more general form of logic), and a schematiclevel description is generated by the circuit synthesizer (through a semantic compilation process). The schematiclevel description is then converted into a description of the circuit at stick level with the aid of libraries. With all the coordinates instantiated, and with the assistance of a technology file, the stick-level description is transformed into a geometric description of the circuit. A circuit description at geometric level can be converted into a switchlevel description (through a circuit extraction process) such that timing analysis and simulation can be performed. Finally, geometric circuit models are linked together with placement and routing tools to form a chip layout. In an interactive design environment, the designer is allowed to use schematic or layout editors to change the descriptions at different levels. In general, the design of a VLSl circuit involves several iterations of refinement and optimization at each level of design. One of the major reasons for this is that multiple
• integration of layout design tools • propagation of dynamic changes • propagation and abstraction of performance measurements • incremental design rule checking • version control This paper is organized as follows. The next section briefly reviews the activities involved in VLSl system design processes. The section that follows reviews the essence of object-oriented knowledge bases. In the fourth section, an object-oriented design methodology facilitated by the framework of an object-oriented knowledge base is described. The fifth section discusses how structures of VLSI circuits at different levels of abstraction can be described in object-oriented knowledge bases. The five tasks that can be automated for supporting integrated, intelligent circuit layout environment are described in the sixth section.
f
~Stick-level
Expansion instantiotion of coordinates placement routing
description
=--
• node w/I
Geometry - level description
• box XoJ,o xdyd
• line
- rotation
• point • via
-translation • layer I
• reference
• cell (collection of shapes)
• transistor • pull up
- rotate
• pull down
- translate
• enhancement mode
G~~ /
-scale
• depletion mode
• point x y • wire XoY0 x I Yl X2Yz
• coll
g
Mask
• polygon • port (points of reference in calls)
i
Switch-level description
Logic- level description - -
O
•• transistor node s~g, ,ci
o
nodes
~
~
-PLA -FSM - regular expression
o
2, "6
Designer
E
O3
--
Schematic-level description
J -i
Semantic compilation
Behoviour description -,,,=---
Figure I. VLSI system design activities
volume 20 number 5 june 1988
273
q Gool definition] g
(o ÷
g *6
selection I
8
]
i
-5
i
I Refinement I JOptimizationJ
g
Count description + constraints
orooo"on I
~,
o
Failure
-rEstimationIZ '~
~
1
r-'l
~
Yes
explanation
T
l
| design
;
Refined -J
• •
NO
I
Figure 2. Design process model 33 design alternatives can be applied at each stage of the design. For example, an adder can be designed as a 'ripplethrough' or as a 'carry-look-ahead' adder; a chip may use a one-phase or a two-phase clocking scheme. Another reason is that multiple optimization heuristics may exist for the same optimization process and thus may affect the design decision when the performance requirement is critical. According to GajskP 3, as well as refinement and optimization, three other tasks are essential for the design process: constraint propagation, design evaluation, and trade-off analysis. Constraint propagation processes the partial constraints assigned to a design module into constraints associated with each of its components. The design evaluation process must be performed to determine how far the constraints have been satisfied, and to find the cause of failure if they have not been satisfied. In cases where there is no design that can satisfy a given set of constraints, trade-off analysis should be performed to achieve a nearly acceptable design. A design process model including constraint propagation, design evaluation, and style selection (trade-off analysis) is shown in Figure 233 .
OBJECT-ORIENTED
KNOWLEDGE
BASES
A deductive knowledge base34 is considered to consist of a finite set of constants and a set of first-order clauses without function symbols. The general form of clauses that will represent facts and deductive laws is P1 A P2 A ... A Pk '* R1 V R2 V ... V Rq
274
The conjunction of the Pis is referred to as the left-handside of the clause and the disjunction of the R/s as the right-hand-side. According to the values of # and q, clauses can be classified as integrity constraint, fact, or deductive law. For all deductive laws of the form p ~ - p i A ...A Pn, p is called a derived predicate. Predicates other than derived predicates are called base predicates. Generally q ~< I to keep a database definite. In such databases, queries are usually represented as conjunctions of predicates with uninstantiated variables. Briefly speaking, facts in deductive databases are organized as relations, and a relational database can be viewed as an interpretation of a first-order language. In Sheu 3s, the above knowledge base framework was extended by incorporating the concept of object, class, and method 36. Conceptually, an object-oriented knowledge base is considered to consist of a set of objects. A class is a group of structurally similar objects; and a class defines a set of methods which are the customized operations that can be performed on the objects belonging to the same class. In this object-oriented knowledge base framework, the first-order language consists of the following: class(a) is true if a is an object class. instance(a,b) is true if object a is an instance of class b. • attribute_value(a,b,c) is true if object a has c as the value of its attribute b. • e x e c u t e ( c : a ( x i , . . . , x r , Y i , . . . , y p ) ) is true if a is an operation associated with class c and when a is executed with the input arguments x l , . . . , X r , the output arguments obtained are Y l , . . . , Y p - In this case, we call c: a (xl, ..., Xr, Yz, ..., Yp) a method predicate. • f(xz, ...,Xn) is true if < x l , ...,Xn > is a member of user-defined relation f. In this case, we call f ( x l , ..., Xn) a relational predicate. The first-order language just introduced provides a syntax by which integrity constraints and deductive laws can be asserted. With these, the associated object base can be assured to be consistent and new objects can be derived from existing ones. The general form of clauses that will represent integrity constraints and deductive laws is P1AP2A...
AP#~
R1
If R1 is a method predicate, then call it a derived method. Similarly, if RI is a relational predicate, call it a derived relation.
OBJECT-ORIENTED R E USABI L ITY
DESIGN
AND
Object-based design is based on a number of different sources. One of the most important of these is a well known article by Parnas3~. He was concerned with the 'criteria to be used in decomposing systems into modules'. He believed that the modules of a system should be designed in such a way that separate groups can develop and alter them with a high degree of mutual independence. Informally, the object-oriented design methodology can be described by the following three steps 38- 40. • •
Step (1): define the problem Step (2): develop an informal strategy for solving the problem
computer-aided design
Combinatorial systems See Figure 3.
inpuLa
_I
co
-I
outpuLa
Figure 3. Combinatorial systems
o inpuLa
J
instance_ of (a, combinatorial_ computing-system) A attribute_value (a, inputs, input_a) A attribute_value (a, outputs,output_a) A co (input_a, output_a) Sequential systems
I
output°a
See Figure 4. instance (a, sequential_computing-system) A attribute_value (a, inputs, 7-,input- a.0) A ...... A attribute_value (a, inputs, T+n, input_ a.n) A attribute_value (a, outputs, T, output_a.0) A ...... A attribute_value (a, outputs, T+m,output_a.m) A co (input_a.0, ...,input_a.n, output_a.0, ... ,output_a.m)
Figure 4. Sequential systems • Step (3): formalize the strategy: o (a) identify the types and objects (or tasks) o (b) identify operations on the objects o (c) implement the operations (tasks) Note that the process is recursive: in step 3(b) new but smaller problems are defined and the same process ( 1 ) - ( 3 ) is repeated. Also note that although most of the literature about object-oriented design is given in the software community, in recent years the same methodology has been accepted as a paradigm for hardware design as well 41'42 . Now, assume that for each method a that is associated with an object class (note that a class is an abstract entity in object-oriented systems), there exists at least one VLSl implementation ]a- The behaviour (or functionality) of each Ja can be described with the following deductive law: J a(X) <- fa(X). Consequently, given the functional requirement g(Y) of a module to be designed, Ja implements g if g(Y)-* fa(X) can be proved, Since the framework of an object-oriented knowledge base supports this, the objectoriented design methodology mentioned earlier can be restated as follows: • Step (I): define and specify the problem. If the user thinks he/she is able to design the corresponding architecture efficiently, then go to step (2); otherwise if the knowledge base has the knowledge to design the corresponding architecture then retrieve the knowledge and terminate. Otherwise go to step (2). • Step (2): develop an informal strategy for designing the architecture. • Step (3): formalize the strategy: o (a) Identify the types and objects (tasks). o (b) Identify operations on the objects. If the user thinks he/she is able to design the corresponding architecture then go to step (2); if the knowledge base has the knowledge to implement an operation or the task, then retrieve the knowledge and terminate. Otherwise go to (c). o (c) Implement the operations (tasks). Note that in the object-oriented knowledge base framework, the relationship between the input and the output of a computing system can generally be described as a conjunctive formula as in the following.
volume 20 number 5 june 1988
Some examples are given in the following. Example 1: relational join systems One of the most important operations in database applications is the 'join' operation 43. Let theta represent any valid scalar comparison operator. The theta-join of relation a on attribute x with relation b on attribute y is the set of all tuples t such that t is the concatenation of a tuple a belonging to A and a tuple b belonging to b and the predicate 'a.x theta b.y' evaluates to true. For a system which computes the join of two relations a and b as described above, its behaviour can be described as follows: instance (d,combinatorial_computing_system) A attribute_value (d, input, [a, b] ) A attribute_ value (d, output, c) A instance_of(a, relation) A instance (b, relation) A instance_of (c, relation) A attribute_value (a, column, x) A attribute_value (b,column, y) A a :join (x, b,y,c), where the predicate a:join(x,b,y,c) is true if the join of the relation a (on column x) and the relation b (on column y) is the relation c. Example 2: finite state machine systems A finite state machine is a system (s,i,o,a,~,so,f) (see Hopcroft and Ullman44), where s is a finite, nonempty set of states, i is a finite set of inputs, 0 is a finite set of outputs, cz is a mapping of sxi onto s, i~ is a mapping of sxi onto o, So in s is the initial state, and f is the set of final states. A finite state machine system as described above can be described in logic as follows instance (a, sequential_computing_systems) A attribute_value (a, input, i) A attribute_value (a, output, o) A attribute_value (a, state,s) A attribute_value (a, initial_ state, s0) A attribute _value (a, final _state, f) A [ (-equal (s,P, T) V -equal (i, U, T)) V (equal (s,ol(P, U), T + I ) A equal (o,~(P, U), T ) ] Example 3: finding a short path Consider the object class graph. Provided that associated to graph there is a method path (A, B,P), which asserts a path P between two vertices A and B in a graph. It will
275
also be assumed that associated to the class graph there are two other predicates: member(V,P) and length (P, L), where member(V,P) is true if the vertex V is included in the path P and length (P, L) asserts that L is the length of the path P. The following formula describes a combinatorial system which finds a 'short' path between two vertices in a given graph. instance (a, combinatc,, ial_computing_systems) A attribute_value (a, input, [a, b, r, g] ) A attribute_value (a, output, P) A g : path (a, b, P) A g: length (P, L ) A lesseq (/_, r).
class (box) attribute (box, xdist, integer), attribute (box, ydist, integer) attribute (box, xcent, integer), attribute (box, ycent, integer) instance (a, box) attribute-value (a, xdist, 6), attribute-value (a, ydist, 2) attribute-value (a, xcent, 1 ), attribute-value (a, ycent, 3) at-layer (a, diffusion) a: rotate (c, d, b) *-... b: translate (c,f,g) ~-... member (a,p) member (b,p)
Figure 5. Examples of geometry-level descriptions Example 4: coordinating finite state machines Two or more finite state machines can communicate and coordinate to perform certain tasks. The following formula describes two finite state machines al and a2; they work independently except when al is at state sl and a2 is at state s2 simultaneously, both machines will terminate. Note that in the following, a high-level structural description is also included. Machine 1 instance (a,sequential_computing_systems) A attribute-value (a, input, [ia, terminate_a] ) A attribute_value (a, output, oa) A attribute_value (a, state,Sa) A attribute_value (a, initial- state,Sa0 ) A attribute_value (a, final_state, fa) A [ (-equal (sa,P, T) V -equal (ia, U, T)) V (equal (Sa,aa(P, U), Y+l) A equal (o,¢la(P, U), Y)] a [-equal (terminate_ a, high, T) V equal (Sa,fa, Y)]
Machine 2 instance (b,sequential_computing_systems) A attribute_value (b, input, lib,terminate_ b] ) A attribute_value (b,output, ob) A attribute-value (b,state,sb) A attribute_value (b, initial _state, sb0 ) A attribute_value (b,final_state,fb) A [ (-equal(sb,P, T) A -equal (ib,U, r ) ) V (equal (sb,a b (P, U), T+I) A equal (O,~b(P~U), T)] A
[-equal (terminate_ b,high, T) V equal (sb,fb, T) ]
The Coordinator [(-equal (Sa,Sl, T) V -equal (sb, s2, T)) V (equal (terminate_a, high, T)) A equal (terminate_ b, high, 7)) DESCRIBING STRUCTURES OF VLSI CIRCUITS WITH LOGIC In general, structures of VLSI circuits can be described at geometry level, sticks level or switch level. They will be briefly described in turn.
Geometry-level description Geometry-level circuit description languages (e.g. CIF a2) usually use coloured rectangles, or more generally, coloured shapes, as their primitives. It is possible to fabricate a chip directly from a design expressed in these languages. It is straightforward to describe a circuit at this level with logical statements. More specifically, a primitive shape
276
can be defined as a class, instances of a shape are defined as objects with appropriate attribute values, operations on geometric objects are implemented through methods, and a relation can be defined to constrain the layer location of an object. Some simple examples are given in Figure 5. Sticks-level description When circuits are described by sticks languages, transistors and vias are represented by points of a grid, and wires are represented by lines. Information regarding the thickness of wires and the exact positions of the points is supplied by the compiler that translates the sticks language into geometry. The relative location of the various circuit elements is supplied by the designer. A circuit that is represented in the stick language can be equally well described by logic according to the following rules: • A point is defined as an instance of the class point, which has two attributes: xpos and ypos. • The class point has the following subclasses: via, reference, terminal, enhancement-mode transistor, and depletion-mode transistor. In turn, the class enhancement-mode transistor has subclasses pulldown and pass transistor; the class depletion-mode transistor has a subclass pulldown. For transistors, the width/length ratio for the channel is an attribute. • For transistors, the operation 'rotation' can be defined and applied to obtain transistors with different orientations. A transistor may have up to 3 terminals: the gate, the drain, and the source. The fact that a point p is the gate of transistor t is declared by the predicate gate-of (p,t). Similarly, the predicates source-of and drain-of associate a source terminal and a drain terminal to a transistor. • The class wire describes the wires in a circuit that connects two points. A wire object has the following attributes: width, layer, point.l, point.2. • A cell can be defined as a set of points and wires. • Ports of cells are described by the class port, which has two attributes: point and cell. For example, the following predicates describe the port a of the cell b (which is actually point c) instance (a, port) attribute-value (a, point, c) attribute-value (a, cell, b) In addition, borders of a cell can be defined with set constructs.
computer-aided design
The following operations are associated with each object
Switch-level descriptions A switch-level description of a circuit is usually generated from its geometry-level description with circuit extraction algorithms. There are two basic classes of objects in switchlevel descriptions of circuits: nodes and transistors. Nodes are primitive objects that represent electrical contacts in a circuit, and a transistor is a composite object having four attributes: mode, source, gate, and drain. The domain of the attribute mode is ~.enhancement, depletionS, and the domains of the attributes source, gate and drain are node.
ACTIVITY MANAGEMENT KNOWLEDGE BASES
IN V L S I D E S I G N
In this section, the activities that can be automated in a VLSI design knowledge base are investigated, assuming the formal representation discussed earlier. For simplicity, the following assumptions and abstractions are made in this section. A VLSI circuit, a, has representations at five levels: the behavioural-level (logic level) description ba, the schematiclevel description Sa, the sticks-level description ta, the geometric-level description ga, and the switch-level description Wa. These representations at different levels of abstraction are related by the predicate implementation_of (x,y), where x is a representation of a circuit a at lower level and y is a representation of a at higher level. Consequently, the following predicates are true for a circuit a implementation-of (Sa, ba) implementation-of (ta, Sa) implementation-of(ga, ta) implementation-of(ga, Wa) A circuit description ga for a circuit a at geometry-level has the following components: boxes and points, as discussed in the section on geometry-level description. A circuit description ta for a circuit a at sticks-level has the following components: points and lines, as discussed in the section on sticks-level description. Note that a cell is a set of points and lines. A circuit description Wa for a circuit a at switch-level has the following components: nodes and transistors, where each transistor has a set of nodes as the values of its attributes. A circuit description ga for a circuit a at schematic-level has the following components: cells, ports and wires, where a cell has a set of ports and a wire connects two ports in a circuit. For a component x E ga and a component y (Eta, the predicate i m p l e m e n t e d _ b y ( y , x ) is true if the abstract object y is implemented by x in ga- Note that an abstract object may need to be implemented by more than one object at a lower level of abstraction. The predicate can
also be applied to two components x and y, where x (E t a and y (E Sa, x (E Sa and y (E ba or x (E ga and y E Wa. The following operations transform a circuit description into another circuit description, given a circuit a semantic-compile (ba, Sa) expand (Sa, ta) stick-compile (ta, ga) circuit-extract (ga, wa) f placement-routing (ga, ga), where g~ is another description at geometry-level after routing and placement is done.
volume 20 number 5 june 1988
define _ object_ class (a) define _object_attribute (a, b, c) define_ object (a, b) deft ne_object_attribute (a,b,c) delete_object(a) delete_object_class (a) define_relation (f) add_fact (f(x,, ..., Xn)) delete_ fact (f (xl, ..., Xn)) The following operation computes the preparation delay d between two nodes at switch-level propagation_ delay (a, b, d) All the circuits are instances of the class 'circuit'. All the circuit descriptions are instances of the class 'circuit description', which has the following subclasses: schematic, sticks, geometry, and simulation. Based on the above assumptions, some tasks can be identified that can be automated in the object-oriented knowledge base framework. Propagation of dynamic changes For a circuit which is represented at different levels of abstraction, it is often desirable that changes made at one level of representation can be propagated (downward or upward) automatically to representations at different levels. To achieve this, there are the following integrity constraints • delete_object(A) A instance (A , set) A member (A ', a) -* delete_object (A ') • delete_object(A ) A implementation_of (,4, B) -+ delete_object (B) • assert(member(A,X)) A member(X, Y) A instance (Y, schematic) A implementation_of(Z, Y) A expand (A, B) -+ Z: add_ member (B) • assert(member(A,X)) A member (X~ Y) A instance(Y, sticks) A implementation_of(Z, Y) A sticks_ compile (A, B) -* Z: add_ member (B) Propagation of performance Usually, the performance of a circuit is computed at switch-level. However, it is often desirable to obtain the performance at higher levels of abstraction (i.e. at schematic-level). Instead of doing this manually, performance at schematic-level can be obtained automatically given the following deductive laws shown in Figure 6.
if instance(X~ port) A instance(Y, port) A member(X, Z) A member(Y,Z) A instance(Z, schematic) then propagation_delay (X, Y, P) +- implemented_by(X,A,) Aimplemented_by(Y,B,) A implemented_by (.4 I,A 2 ) A implemented_by (BI, B2 ) A implemented_ by (.4=, C1 ) A implemented_by (B=, C2 ) A member(C1, D) A member(C2, D) A instance(D, switch) A propagation_delay (C1, C2, P)
Figure 6. Deductive laws
277
Incremental design rule checking When changes to a circuit are done at sticks-level or schematic-level, the property of the procedure stickscompile can assure that no design rule violation may occur at geometry-level. However, when changes are made at geometry-level, design rule checking has to be performed. Instead of performing a global, circuitwide design rule checking, it is desirable that the scope of the checking process be as narrow as possible. Assuming that there are design rules of the form: instance (A, X) A instance (B, Y) A distance (,4, B, C) -* C ~> K then for each rule of the above form, an equivalent integrity constraint can be constructed of the form assert (member (A,S)) A instance (4, X ) A enlarge (4, K, R) A intersect(R, Q) ~ ~ instance (Q, Y) rotate (A, D, R ) A instance (R, X) A enlarge (R, K, S) A intersect(S, Q) -+ ~ instance(Q, Y) translate (4, D, R ) A instance (R, X) A enlarge (R, K, S) A intersect(S, Q) -~ ~ instance (Q, Y)
Version control In a VLSI design environment, the organization of the design versions has dimensionality 1°. First, as described earlier, design representations may include system architecture, register transfer, logic, circuit and geometric layout. Second, for a design in one representation, designers may try various implementation alternatives (for example, using different technologies, design algorithms and design constraints). Third, for each alternative, multiple versions of a design are generated over time to fix bugs or to optimize the performance of a circuit. In Katz eta/. 16 a version maintenance mechanism was introduced to support the following major tasks: • organize the design into configurations across representations • maintain version histories • support workspaces, in which designers can make private changes • permit the changes to be shared with other designers through semipublic workspaces • implement the careful update of the design archive by insuring that objects added to it have been successfully validated and that all equivalence relationships are in force
Desig(XII, n gll)Design...(X~ Figure 7. Structure of general design tree 278
Clearly, the notion 'version' and 'equivalence' can be realized in the framework of object-oriented knowledge base with the predicates derived_from(X, Y), which is true if X is a version derived from a representation Y equivalent(X, Y), which is true if the layout X of a circuit is logically equivalent to the switch-level description Y of the circuit.
KNOWLEDGE-BASED DESIGN SYNTHESIS AND CONCLUSION In this paper, the use of object-oriented design and logical description to facilitate automatic VLSl computer architecture design has been proposed. The framework of object-oriented knowledge bases has been proposed to organize design knowledge, to describe the behaviour of computing systems, to describe the structure of computing systems, and to manage designs at different abstract levels consistently and intelligently. The main advantages of this approach can be summarized as follows: • Since the knowledge base represents our knowledge about VLSI computer architecture design, users can understand the contents of the system by querying the knowledge base. • Logic provides a powerful way to describe the behaviour of computing systems and our design knowledge. • Since patterns of systems can be highly abstracted, design knowledge can be reused when a system is given to be implemented. • Since a knowledge base can be expanded incrementally, the intelligence of the system can therefore evolve with time. • Since most of the low-level layout tasks can be automated, circuit designs at different abstract levels can be maintained consistently and efficiently. Also designers are able to evaluate a design at different abstract levels once a design is completed. One major extension of the work reported here is to synthesize VLSI designs according to the knowledge stored in the knowledge base. In general, VLSI system design is a 'cut-and-try process'. Even with CAD software, the actual design process requires trying many different methods and selecting the one that works best. The designer develops tentative solutions and then selects his tentative solutions by analysing the results of executing one or more steps. Such processes can best be characterized by the model depicted in Figure 2. Computationally, the design process model shown in Figure 2 can be realized by an AND-OR tree search process as shown in Figure 7. Assuming that each design problem in an object-oriented knowledge base is initiated by a design query of the form design (X, Y), where X is the circuit to be designed and Y is a conjunctive formula specifying the desirable performance requirements, since a conjunctive formula can be constructed as a class in the knowledge base, Y is an object in the class conjunctive formula; consequently the knowledge base remains of first-order and an AND-OR search tree can be constructed as follows:
computer-aided design
• Each OR node represents a design activity. Each branch of an OR node is a possible design approach (based on some style and refinement/optimization), and the corresponding terminal is an AND node. • Each AND node represents a constraint propagation problem. Each terminal of an AND branch represents a design activity. • All the terminal nodes are design nodes.
4
McLellan, P 'Effective data management for VLSI design' Proc. 22nd A CM/IEEE Des. A utomation Conf. (1984) pp 652-657
5
Katz, R H 'Managing the chip design databases' IEEE Computer Vo116 No 12 (December 1983)
6
Katz, R H Information management for engineering design Springer-Verlag, Berlin, FRG (1985)
7
Guttman, A and Stonebraker, M 'Using a relational database management system for CAD data' IEEE Database Engineering (June 1984) pp 56-60
Apparently, each OR node in a search tree can be expanded according to deductive laws of the general form if fl(Y) design(X, Y) *- design (X/, Y)
8 (*)
and each AND node can be expanded according to the deductive law of the following form ifg/(V) design (Xh Y) *- design (XI1, Y) A design (Xi2, Y2 ) A ... A design(X/j, Yj)AffY, Y1,..., Yj) To avoid an exhaustive search, a best-first search can be performed as follows, assuming that a certainty factor is associated with each deductive law of the form (*). Upon receiving a seed query design (X, Y), the planner first picks the rules that are applicable to the goal design (X, Y), and forms an OR node in the search tree. It then tries to expand the most promising child first, and this process repeats as long as a leaf node is not generated. Whenever an OR node is generated, the certainty factor of the rule being applied is attached to that node; all the leaf nodes have a priori certainty factors defined also. Whenever a leaf node is generated, its logical value (true or false) is generated by testing the performance of the design and its certainty factor is adjusted to be 0 or 1 accordingly. At this time, this new certainty factor may affect the certainty factors of its ancestors, and changes should be reflected from bottom to top by applying the following rules CF(AI A ... A An) = CF(AI V ...VAn) =
max
1 <~l<~n
max
1 <<.l<~n
CF (Ai) CF (Ai)
After all the certainty factors of the current search tree have been adjusted, the planner restarts the search from the root. The above process is repeated until a successful design is achieved or certain tolerance measure has been exceeded. Since there may be an infinite number of ways to propagate the constraints, a metaplanner can be constructed on the top of the search tree to adjust the local component constraints, according to the observations made during the search.
REFERENCES
Wiederhold, G, Beetem, A and Shat, G E 'A database approach to communication in VLSI design' IEEE Trans. Comput.-Aided Des. Integrated Circuits Systems (April 1982) 9 Afsarmanesh, H, McLeod, D, Kanapp, D and Parker, A 'An extensible object-oriented approach to databases for VLSl/CAD' Proc. 17th VLDB (August 1985) 10 Batory, D S and K/m, W 'Modeling concepts for VLSl CAD objects' ACM Trans. Data Struc. (September 1985) pp 322-346 11 Nguyen, G T 'Semantics of CAD objects for generalized databases' Proc. ACM/IEEE 23rd Des. Automation Conf. (1986) pp 3 4 - 4 0 12 Wolf, W 'An object-oriented, procedural database for VLSl chip planning' Proc. 23rd ACM/IEEE Des. Automation Conf. (1986) pp 744-751 13 Bancilhon, F, K/m, W and Korth, H 'A model for CAD transactions' Proc. l l th VLDB (August 1985) 14 Katz, R H and Weiss, H S 'Design transaction management' Proc. ACM/IEEE 21st Design Automation Conf. (June 1984) 15 K/m, W e t al. 'Nested transactions for engineering design databases' Proc. VLDB (August 1984) 16 Katz, R H, Anwarrudin, M and Chang, E 'A version server for computer-aided design data' Proc. 23rdACM/ IEEE Des. Automation Conf. (1986) pp 27-33 17 Katz, R H, Chang, E and Bhateja, R 'Version modeling concepts for computer-aided design databases' ACM SIGMOD (1986) pp 379-386 18 Katz, R H and Lehman, T J 'Database support for versions and alternatives of large design files' IEEE Trans. Software Eng. SE-10 No 2 (March 1984) 19 Baker, C M and Terman, C 'Tools for verifying integrated circuit design' Lambda No 1 (1980) 20 Terman, C J 'Simulation tools for digital LSI design' MIT Computer Science Laboratory, MA, USA TR-304 (1983) 21 Newton, A R and Sangiovanni-Vincentelli 'Computeraided design for VLSl circuits' Computer (April 1986) 22 Brewer, F D and Gajski, D P 'An expert system paradigm for design' Proc. 23rd ACM/IEEE Des. Automat/on Conf. (I 986)
1
Carter, H W 'Computer-aided design of integrated circuits' Computer (April 1986) pp 19-36
2
Subrahmanyam, P A 'Synapse: an expert system for V LSI design' IEEE Computer (july 1986) pp 78-89
23 Bushnell, M L and Director, SW'ULYSSES: an expertsystem based VLSl design environment' Proc. CHDL'85 North-Holland (1985) pp 391-403
3
Haskin, R and Lorie, R 'On extending the functions of a relational database systems' Proc. ACM SIGMOD (June 1982)
24 Kowalski, T J An artificial intelligence approach to VLSI design Kluwer Academic Publishers, Hingham, MA, USA (1985)
volume 20 number 5 june 1988
279
25
Joobbani, R and Siewiorek, D P ‘Weaver: a knowledgebased routing expert’ Proc. 22nd ACM/IEEE Des. Automation Conf. (1985) pp 266-272
26
Juhannsen, D L, Tsubota, S K and McElvain, K ‘An intelligent compiler subsystem for a silicon compiler’ Proc. 24th ACM/IEEE Des. Automation Conf. (1987) pp 443-450
27
Kahn, H J and Filer, N P ‘An application of knowledgebased techniques to VLSI design’ Proc. Expert System 85 Cambridge University Press (1985)
36
Sheu, P C-Y ‘Query processing and communication control in object bases and distributed object bases’ PhD dissertation University of California, Berkeley, CA, USA (1986)
37
Parnas, D ‘On the criteria to be used in decomposing systems into modules’ CACM (December 1972)
38
Abbott, R ‘Program design by informal criptions’ CACM (November 1983)
39
Booth, G Software engineering with Ada Benjamin/ Cummings, Melo Park, CA, USA (1983)
40
Booth, G ‘Object-oriented development’ IEEE Trans. Software Eng. Vol 3 No 1 (February 1986)
41
Cesen, T, lodiu, E and Tsareff, C ‘PAMS: an expert system for parameterized module synthesis’ Proc. 24th ACMjIEEE Des. Automation Conf. (1987) pp 666-671
English des-
28
Kowalski, T and Thomas, D ‘The VLSI design automation assistant: what’s in a knowledge base’ Proc. 23rd ACM/IEEE Des. Automation Conf. (1985)
29
Lin, Y-L, Steve, and Gajski, D D ‘LES - a layout expert system’ Proc. 24th ACMfIEEE Des. Automation Conf. (1987) pp 672-678
30
Wu, C F, Wojcik, A S and Ni, L M ‘A rule-based circuit representation for automated CMOS design and verification’ Proc. 24th ACMfIEEE Des. Automation Conf; (1987) pp 786-792
42
Girczyc, E F and Ly, T ‘STEM - an IC design environment based on the Smalltalk model-view-controller construct’ Proc. 24th ACM/IEEE Des. Automation Co& (1987) pp 757-763
31
Gregory, D, Bartlett, K, de Geus, A and Hachtel, G ‘Socrates: a system for automatically synthesizing and optimizing combinational logic’ Proc. 23rd Des. Automation Conf. (1986)
43
Ullman, J D Principles Science Press (1983)
44
Hopcroft, J E and Ullman, J D Formal languages and their relation to automata McGraw-Hill (1976)
32
Mead, C and Conway, L Introduction Addison-Wesley (1980)
33
Gajski, D ‘Silicon (November 1985)
compilation’
to VLSI systems
VLSI System Design
BIBLIOGRAPHY
34
Kellogg, C ‘From data management to management’ Computer (January 1986)
35
Goldberg, A and Robson, D Smalltalk-80: the language and its implementation Addison-Wesley (1983)
280
of database systems Computer
knowledge
Burnstein, N and Pelevin, R ‘Hierarchical wire routing’ IEEE Trans. CAD of IC and Systems (October 1983) Johannsen, compilation’
D L, McElvain, K and Tsubota, S K ‘Intelligent VU/ Systems Design (April 1987)
computer-aided
design
In general, VLSI circuit design is a 'cut-and-try' process. Despite the availability of CAD software, the actual design process requires trying many different methods and selecting the one that works the best. The designer develops tentative solutions and then selects his tentative solutions by analysing the results of executing one or more steps. At the abstract level, VLSl design is a subclass of the general problem-solving problem whose solutions include a sequence of operations given the initial and the final state of the problem. The dream of silicon compilation (i.e. to develop automatically an entire VLSI system from a formal behavioural specification) cannot become true unless there is a design environment that integrates the design database (which stores the states of design process), design tools (which serve as the operations to change the state of a design and to analyse the performance of a design) and design knowledge (which determines how the states of a design process are changed) 1 . Such an environment maps a problem specification into mask descriptions for circuit fabrication 2. This typically spans at least three different dimensions for
Electrical Engineering, Purdue University, West IN 47907, USA
School of
272
Lafayette,
representing a problem: behavioural (or functional), structural (or architectural), and physical (or geometric); along several levels of abstraction along each dimension. Functional abstractions include Boolean expressions and programs written in a high-level programming language. Structural abstractions include descriptions at the registertransfer level, the switch level, the transistor level, and so on. Physical abstractions capture placement and geometry. In carrying out the transformation process automatically, the design environment described above has to have the following capabilities: •
Management of complex objects at different levels of abstraction. • Management of dynamic changes made to design representations at different levels of abstraction. • Support of design evolution. • Integration of different design tools. Most of the research in the past has addressed some, but not all, of the above issues; and therefore provided partial, but not complete, solutions to the next-generation design automation system. Research in the area of CAD databases 3-8 has concentrated on the following two issues. First, extending the relational database framework with semantic data models that may capture more of the semantics of CAD objects 9-12. Second, extending conventional database frameworks with the capabilities of CAD transaction management 13-1s and version control16-18 In another direction, CAD researchers have developed more intelligent design tools to facilitate the processes of performance analysis and physical layout 2'19-31 . Such tools have been demonstrated to be useful in analysing circuit designs and transforming structural descriptions of circuits into geometric descriptions. Consequently, according to the requirements listed above, research is needed to address the following issues: •
Integration of design database and design tools in a coherent, uniform environment. • Representation and management of design knowledge. • Development of automatic design synthesis methodology according to which a sequence of design operations/decisions can be made to satisfy the design requirement. • Management of design entities such that state changes in the environment can be made consistently. According to the above requirements, an integrated knowledge-based system approach for the purpose of automatic VLSI system design is described. At the top level, this approach is based on the concepts of object-oriented design, reusability, and knowledge-based design synthesis. The input to the design environment is a descriptive specification of the desirable behaviour of a computing system.
0010-4485/88/050272-09 $03.00 © 1988 Butterworth & Co (Publishers) Ltd
computer-aided design
Finally, a knowledge-based heuristic search approach for automatic circuit synthesis is sketched.
The description is then matched against the existing design knowledge in the knowledge base, where the knowledge is abstracted and organized as classes. If a match can be found, the abstract knowledge is instantiated and can be reused. If the target design fails to match an existing class, the system will try to synthesize a satisfactory design based on the design knowledge stored in the knowledge base. When both approaches fail, the designer goes one level down and decomposes the system into a set of smaller systems, where a structural description among different modules is specified, but only the behavioural specification for each module is given. The process is then repeated until a complete structural description is developed. At the bottom level, the system is designed to support and automate the following tasks:
ACTIVITIES IN VLSI SYSTEM DESIGN PROCESSES Since Mead and Conway first described VLSI technology32, the term silicon compilation has drawn much attention. In a broad sense 33, silicon compilation can be defined as a translation process from a high-level description into a layout. A typical VLSl design system based on silicon compilation methodology is shown in Figure 1. A functional (or behavioural) description of the circuit is specified by the user as the input (where the functional description may be in the form of finite state machine, Boolean expression, or more general form of logic), and a schematiclevel description is generated by the circuit synthesizer (through a semantic compilation process). The schematiclevel description is then converted into a description of the circuit at stick level with the aid of libraries. With all the coordinates instantiated, and with the assistance of a technology file, the stick-level description is transformed into a geometric description of the circuit. A circuit description at geometric level can be converted into a switchlevel description (through a circuit extraction process) such that timing analysis and simulation can be performed. Finally, geometric circuit models are linked together with placement and routing tools to form a chip layout. In an interactive design environment, the designer is allowed to use schematic or layout editors to change the descriptions at different levels. In general, the design of a VLSl circuit involves several iterations of refinement and optimization at each level of design. One of the major reasons for this is that multiple
• integration of layout design tools • propagation of dynamic changes • propagation and abstraction of performance measurements • incremental design rule checking • version control This paper is organized as follows. The next section briefly reviews the activities involved in VLSl system design processes. The section that follows reviews the essence of object-oriented knowledge bases. In the fourth section, an object-oriented design methodology facilitated by the framework of an object-oriented knowledge base is described. The fifth section discusses how structures of VLSI circuits at different levels of abstraction can be described in object-oriented knowledge bases. The five tasks that can be automated for supporting integrated, intelligent circuit layout environment are described in the sixth section.
f
~Stick-level
Expansion instantiotion of coordinates placement routing
description
=--
• node w/I
Geometry - level description
• box XoJ,o xdyd
• line
- rotation
• point • via
-translation • layer I
• reference
• cell (collection of shapes)
• transistor • pull up
- rotate
• pull down
- translate
• enhancement mode
G~~ /
-scale
• depletion mode
• point x y • wire XoY0 x I Yl X2Yz
• coll
g
Mask
• polygon • port (points of reference in calls)
i
Switch-level description
Logic- level description - -
O
•• transistor node s~g, ,ci
o
nodes
~
~
-PLA -FSM - regular expression
o
2, "6
Designer
E
O3
--
Schematic-level description
J -i
Semantic compilation
Behoviour description -,,,=---
Figure I. VLSI system design activities
volume 20 number 5 june 1988
273
q Gool definition] g
(o ÷
g *6
selection I
8
]
i
-5
i
I Refinement I JOptimizationJ
g
Count description + constraints
orooo"on I
~,
o
Failure
-rEstimationIZ '~
~
1
r-'l
~
Yes
explanation
T
l
| design
;
Refined -J
• •
NO
I
Figure 2. Design process model 33 design alternatives can be applied at each stage of the design. For example, an adder can be designed as a 'ripplethrough' or as a 'carry-look-ahead' adder; a chip may use a one-phase or a two-phase clocking scheme. Another reason is that multiple optimization heuristics may exist for the same optimization process and thus may affect the design decision when the performance requirement is critical. According to GajskP 3, as well as refinement and optimization, three other tasks are essential for the design process: constraint propagation, design evaluation, and trade-off analysis. Constraint propagation processes the partial constraints assigned to a design module into constraints associated with each of its components. The design evaluation process must be performed to determine how far the constraints have been satisfied, and to find the cause of failure if they have not been satisfied. In cases where there is no design that can satisfy a given set of constraints, trade-off analysis should be performed to achieve a nearly acceptable design. A design process model including constraint propagation, design evaluation, and style selection (trade-off analysis) is shown in Figure 233 .
OBJECT-ORIENTED
KNOWLEDGE
BASES
A deductive knowledge base34 is considered to consist of a finite set of constants and a set of first-order clauses without function symbols. The general form of clauses that will represent facts and deductive laws is P1 A P2 A ... A Pk '* R1 V R2 V ... V Rq
274
The conjunction of the Pis is referred to as the left-handside of the clause and the disjunction of the R/s as the right-hand-side. According to the values of # and q, clauses can be classified as integrity constraint, fact, or deductive law. For all deductive laws of the form p ~ - p i A ...A Pn, p is called a derived predicate. Predicates other than derived predicates are called base predicates. Generally q ~< I to keep a database definite. In such databases, queries are usually represented as conjunctions of predicates with uninstantiated variables. Briefly speaking, facts in deductive databases are organized as relations, and a relational database can be viewed as an interpretation of a first-order language. In Sheu 3s, the above knowledge base framework was extended by incorporating the concept of object, class, and method 36. Conceptually, an object-oriented knowledge base is considered to consist of a set of objects. A class is a group of structurally similar objects; and a class defines a set of methods which are the customized operations that can be performed on the objects belonging to the same class. In this object-oriented knowledge base framework, the first-order language consists of the following: class(a) is true if a is an object class. instance(a,b) is true if object a is an instance of class b. • attribute_value(a,b,c) is true if object a has c as the value of its attribute b. • e x e c u t e ( c : a ( x i , . . . , x r , Y i , . . . , y p ) ) is true if a is an operation associated with class c and when a is executed with the input arguments x l , . . . , X r , the output arguments obtained are Y l , . . . , Y p - In this case, we call c: a (xl, ..., Xr, Yz, ..., Yp) a method predicate. • f(xz, ...,Xn) is true if < x l , ...,Xn > is a member of user-defined relation f. In this case, we call f ( x l , ..., Xn) a relational predicate. The first-order language just introduced provides a syntax by which integrity constraints and deductive laws can be asserted. With these, the associated object base can be assured to be consistent and new objects can be derived from existing ones. The general form of clauses that will represent integrity constraints and deductive laws is P1AP2A...
AP#~
R1
If R1 is a method predicate, then call it a derived method. Similarly, if RI is a relational predicate, call it a derived relation.
OBJECT-ORIENTED R E USABI L ITY
DESIGN
AND
Object-based design is based on a number of different sources. One of the most important of these is a well known article by Parnas3~. He was concerned with the 'criteria to be used in decomposing systems into modules'. He believed that the modules of a system should be designed in such a way that separate groups can develop and alter them with a high degree of mutual independence. Informally, the object-oriented design methodology can be described by the following three steps 38- 40. • •
Step (1): define the problem Step (2): develop an informal strategy for solving the problem
computer-aided design
Combinatorial systems See Figure 3.
inpuLa
_I
co
-I
outpuLa
Figure 3. Combinatorial systems
o inpuLa
J
instance_ of (a, combinatorial_ computing-system) A attribute_value (a, inputs, input_a) A attribute_value (a, outputs,output_a) A co (input_a, output_a) Sequential systems
I
output°a
See Figure 4. instance (a, sequential_computing-system) A attribute_value (a, inputs, 7-,input- a.0) A ...... A attribute_value (a, inputs, T+n, input_ a.n) A attribute_value (a, outputs, T, output_a.0) A ...... A attribute_value (a, outputs, T+m,output_a.m) A co (input_a.0, ...,input_a.n, output_a.0, ... ,output_a.m)
Figure 4. Sequential systems • Step (3): formalize the strategy: o (a) identify the types and objects (or tasks) o (b) identify operations on the objects o (c) implement the operations (tasks) Note that the process is recursive: in step 3(b) new but smaller problems are defined and the same process ( 1 ) - ( 3 ) is repeated. Also note that although most of the literature about object-oriented design is given in the software community, in recent years the same methodology has been accepted as a paradigm for hardware design as well 41'42 . Now, assume that for each method a that is associated with an object class (note that a class is an abstract entity in object-oriented systems), there exists at least one VLSl implementation ]a- The behaviour (or functionality) of each Ja can be described with the following deductive law: J a(X) <- fa(X). Consequently, given the functional requirement g(Y) of a module to be designed, Ja implements g if g(Y)-* fa(X) can be proved, Since the framework of an object-oriented knowledge base supports this, the objectoriented design methodology mentioned earlier can be restated as follows: • Step (I): define and specify the problem. If the user thinks he/she is able to design the corresponding architecture efficiently, then go to step (2); otherwise if the knowledge base has the knowledge to design the corresponding architecture then retrieve the knowledge and terminate. Otherwise go to step (2). • Step (2): develop an informal strategy for designing the architecture. • Step (3): formalize the strategy: o (a) Identify the types and objects (tasks). o (b) Identify operations on the objects. If the user thinks he/she is able to design the corresponding architecture then go to step (2); if the knowledge base has the knowledge to implement an operation or the task, then retrieve the knowledge and terminate. Otherwise go to (c). o (c) Implement the operations (tasks). Note that in the object-oriented knowledge base framework, the relationship between the input and the output of a computing system can generally be described as a conjunctive formula as in the following.
volume 20 number 5 june 1988
Some examples are given in the following. Example 1: relational join systems One of the most important operations in database applications is the 'join' operation 43. Let theta represent any valid scalar comparison operator. The theta-join of relation a on attribute x with relation b on attribute y is the set of all tuples t such that t is the concatenation of a tuple a belonging to A and a tuple b belonging to b and the predicate 'a.x theta b.y' evaluates to true. For a system which computes the join of two relations a and b as described above, its behaviour can be described as follows: instance (d,combinatorial_computing_system) A attribute_value (d, input, [a, b] ) A attribute_ value (d, output, c) A instance_of(a, relation) A instance (b, relation) A instance_of (c, relation) A attribute_value (a, column, x) A attribute_value (b,column, y) A a :join (x, b,y,c), where the predicate a:join(x,b,y,c) is true if the join of the relation a (on column x) and the relation b (on column y) is the relation c. Example 2: finite state machine systems A finite state machine is a system (s,i,o,a,~,so,f) (see Hopcroft and Ullman44), where s is a finite, nonempty set of states, i is a finite set of inputs, 0 is a finite set of outputs, cz is a mapping of sxi onto s, i~ is a mapping of sxi onto o, So in s is the initial state, and f is the set of final states. A finite state machine system as described above can be described in logic as follows instance (a, sequential_computing_systems) A attribute_value (a, input, i) A attribute_value (a, output, o) A attribute_value (a, state,s) A attribute_value (a, initial_ state, s0) A attribute _value (a, final _state, f) A [ (-equal (s,P, T) V -equal (i, U, T)) V (equal (s,ol(P, U), T + I ) A equal (o,~(P, U), T ) ] Example 3: finding a short path Consider the object class graph. Provided that associated to graph there is a method path (A, B,P), which asserts a path P between two vertices A and B in a graph. It will
275
also be assumed that associated to the class graph there are two other predicates: member(V,P) and length (P, L), where member(V,P) is true if the vertex V is included in the path P and length (P, L) asserts that L is the length of the path P. The following formula describes a combinatorial system which finds a 'short' path between two vertices in a given graph. instance (a, combinatc,, ial_computing_systems) A attribute_value (a, input, [a, b, r, g] ) A attribute_value (a, output, P) A g : path (a, b, P) A g: length (P, L ) A lesseq (/_, r).
class (box) attribute (box, xdist, integer), attribute (box, ydist, integer) attribute (box, xcent, integer), attribute (box, ycent, integer) instance (a, box) attribute-value (a, xdist, 6), attribute-value (a, ydist, 2) attribute-value (a, xcent, 1 ), attribute-value (a, ycent, 3) at-layer (a, diffusion) a: rotate (c, d, b) *-... b: translate (c,f,g) ~-... member (a,p) member (b,p)
Figure 5. Examples of geometry-level descriptions Example 4: coordinating finite state machines Two or more finite state machines can communicate and coordinate to perform certain tasks. The following formula describes two finite state machines al and a2; they work independently except when al is at state sl and a2 is at state s2 simultaneously, both machines will terminate. Note that in the following, a high-level structural description is also included. Machine 1 instance (a,sequential_computing_systems) A attribute-value (a, input, [ia, terminate_a] ) A attribute_value (a, output, oa) A attribute_value (a, state,Sa) A attribute_value (a, initial- state,Sa0 ) A attribute_value (a, final_state, fa) A [ (-equal (sa,P, T) V -equal (ia, U, T)) V (equal (Sa,aa(P, U), Y+l) A equal (o,¢la(P, U), Y)] a [-equal (terminate_ a, high, T) V equal (Sa,fa, Y)]
Machine 2 instance (b,sequential_computing_systems) A attribute_value (b, input, lib,terminate_ b] ) A attribute_value (b,output, ob) A attribute-value (b,state,sb) A attribute_value (b, initial _state, sb0 ) A attribute_value (b,final_state,fb) A [ (-equal(sb,P, T) A -equal (ib,U, r ) ) V (equal (sb,a b (P, U), T+I) A equal (O,~b(P~U), T)] A
[-equal (terminate_ b,high, T) V equal (sb,fb, T) ]
The Coordinator [(-equal (Sa,Sl, T) V -equal (sb, s2, T)) V (equal (terminate_a, high, T)) A equal (terminate_ b, high, 7)) DESCRIBING STRUCTURES OF VLSI CIRCUITS WITH LOGIC In general, structures of VLSI circuits can be described at geometry level, sticks level or switch level. They will be briefly described in turn.
Geometry-level description Geometry-level circuit description languages (e.g. CIF a2) usually use coloured rectangles, or more generally, coloured shapes, as their primitives. It is possible to fabricate a chip directly from a design expressed in these languages. It is straightforward to describe a circuit at this level with logical statements. More specifically, a primitive shape
276
can be defined as a class, instances of a shape are defined as objects with appropriate attribute values, operations on geometric objects are implemented through methods, and a relation can be defined to constrain the layer location of an object. Some simple examples are given in Figure 5. Sticks-level description When circuits are described by sticks languages, transistors and vias are represented by points of a grid, and wires are represented by lines. Information regarding the thickness of wires and the exact positions of the points is supplied by the compiler that translates the sticks language into geometry. The relative location of the various circuit elements is supplied by the designer. A circuit that is represented in the stick language can be equally well described by logic according to the following rules: • A point is defined as an instance of the class point, which has two attributes: xpos and ypos. • The class point has the following subclasses: via, reference, terminal, enhancement-mode transistor, and depletion-mode transistor. In turn, the class enhancement-mode transistor has subclasses pulldown and pass transistor; the class depletion-mode transistor has a subclass pulldown. For transistors, the width/length ratio for the channel is an attribute. • For transistors, the operation 'rotation' can be defined and applied to obtain transistors with different orientations. A transistor may have up to 3 terminals: the gate, the drain, and the source. The fact that a point p is the gate of transistor t is declared by the predicate gate-of (p,t). Similarly, the predicates source-of and drain-of associate a source terminal and a drain terminal to a transistor. • The class wire describes the wires in a circuit that connects two points. A wire object has the following attributes: width, layer, point.l, point.2. • A cell can be defined as a set of points and wires. • Ports of cells are described by the class port, which has two attributes: point and cell. For example, the following predicates describe the port a of the cell b (which is actually point c) instance (a, port) attribute-value (a, point, c) attribute-value (a, cell, b) In addition, borders of a cell can be defined with set constructs.
computer-aided design
The following operations are associated with each object
Switch-level descriptions A switch-level description of a circuit is usually generated from its geometry-level description with circuit extraction algorithms. There are two basic classes of objects in switchlevel descriptions of circuits: nodes and transistors. Nodes are primitive objects that represent electrical contacts in a circuit, and a transistor is a composite object having four attributes: mode, source, gate, and drain. The domain of the attribute mode is ~.enhancement, depletionS, and the domains of the attributes source, gate and drain are node.
ACTIVITY MANAGEMENT KNOWLEDGE BASES
IN V L S I D E S I G N
In this section, the activities that can be automated in a VLSI design knowledge base are investigated, assuming the formal representation discussed earlier. For simplicity, the following assumptions and abstractions are made in this section. A VLSI circuit, a, has representations at five levels: the behavioural-level (logic level) description ba, the schematiclevel description Sa, the sticks-level description ta, the geometric-level description ga, and the switch-level description Wa. These representations at different levels of abstraction are related by the predicate implementation_of (x,y), where x is a representation of a circuit a at lower level and y is a representation of a at higher level. Consequently, the following predicates are true for a circuit a implementation-of (Sa, ba) implementation-of (ta, Sa) implementation-of(ga, ta) implementation-of(ga, Wa) A circuit description ga for a circuit a at geometry-level has the following components: boxes and points, as discussed in the section on geometry-level description. A circuit description ta for a circuit a at sticks-level has the following components: points and lines, as discussed in the section on sticks-level description. Note that a cell is a set of points and lines. A circuit description Wa for a circuit a at switch-level has the following components: nodes and transistors, where each transistor has a set of nodes as the values of its attributes. A circuit description ga for a circuit a at schematic-level has the following components: cells, ports and wires, where a cell has a set of ports and a wire connects two ports in a circuit. For a component x E ga and a component y (Eta, the predicate i m p l e m e n t e d _ b y ( y , x ) is true if the abstract object y is implemented by x in ga- Note that an abstract object may need to be implemented by more than one object at a lower level of abstraction. The predicate can
also be applied to two components x and y, where x (E t a and y (E Sa, x (E Sa and y (E ba or x (E ga and y E Wa. The following operations transform a circuit description into another circuit description, given a circuit a semantic-compile (ba, Sa) expand (Sa, ta) stick-compile (ta, ga) circuit-extract (ga, wa) f placement-routing (ga, ga), where g~ is another description at geometry-level after routing and placement is done.
volume 20 number 5 june 1988
define _ object_ class (a) define _object_attribute (a, b, c) define_ object (a, b) deft ne_object_attribute (a,b,c) delete_object(a) delete_object_class (a) define_relation (f) add_fact (f(x,, ..., Xn)) delete_ fact (f (xl, ..., Xn)) The following operation computes the preparation delay d between two nodes at switch-level propagation_ delay (a, b, d) All the circuits are instances of the class 'circuit'. All the circuit descriptions are instances of the class 'circuit description', which has the following subclasses: schematic, sticks, geometry, and simulation. Based on the above assumptions, some tasks can be identified that can be automated in the object-oriented knowledge base framework. Propagation of dynamic changes For a circuit which is represented at different levels of abstraction, it is often desirable that changes made at one level of representation can be propagated (downward or upward) automatically to representations at different levels. To achieve this, there are the following integrity constraints • delete_object(A) A instance (A , set) A member (A ', a) -* delete_object (A ') • delete_object(A ) A implementation_of (,4, B) -+ delete_object (B) • assert(member(A,X)) A member(X, Y) A instance (Y, schematic) A implementation_of(Z, Y) A expand (A, B) -+ Z: add_ member (B) • assert(member(A,X)) A member (X~ Y) A instance(Y, sticks) A implementation_of(Z, Y) A sticks_ compile (A, B) -* Z: add_ member (B) Propagation of performance Usually, the performance of a circuit is computed at switch-level. However, it is often desirable to obtain the performance at higher levels of abstraction (i.e. at schematic-level). Instead of doing this manually, performance at schematic-level can be obtained automatically given the following deductive laws shown in Figure 6.
if instance(X~ port) A instance(Y, port) A member(X, Z) A member(Y,Z) A instance(Z, schematic) then propagation_delay (X, Y, P) +- implemented_by(X,A,) Aimplemented_by(Y,B,) A implemented_by (.4 I,A 2 ) A implemented_by (BI, B2 ) A implemented_ by (.4=, C1 ) A implemented_by (B=, C2 ) A member(C1, D) A member(C2, D) A instance(D, switch) A propagation_delay (C1, C2, P)
Figure 6. Deductive laws
277
Incremental design rule checking When changes to a circuit are done at sticks-level or schematic-level, the property of the procedure stickscompile can assure that no design rule violation may occur at geometry-level. However, when changes are made at geometry-level, design rule checking has to be performed. Instead of performing a global, circuitwide design rule checking, it is desirable that the scope of the checking process be as narrow as possible. Assuming that there are design rules of the form: instance (A, X) A instance (B, Y) A distance (,4, B, C) -* C ~> K then for each rule of the above form, an equivalent integrity constraint can be constructed of the form assert (member (A,S)) A instance (4, X ) A enlarge (4, K, R) A intersect(R, Q) ~ ~ instance (Q, Y) rotate (A, D, R ) A instance (R, X) A enlarge (R, K, S) A intersect(S, Q) -+ ~ instance(Q, Y) translate (4, D, R ) A instance (R, X) A enlarge (R, K, S) A intersect(S, Q) -~ ~ instance (Q, Y)
Version control In a VLSI design environment, the organization of the design versions has dimensionality 1°. First, as described earlier, design representations may include system architecture, register transfer, logic, circuit and geometric layout. Second, for a design in one representation, designers may try various implementation alternatives (for example, using different technologies, design algorithms and design constraints). Third, for each alternative, multiple versions of a design are generated over time to fix bugs or to optimize the performance of a circuit. In Katz eta/. 16 a version maintenance mechanism was introduced to support the following major tasks: • organize the design into configurations across representations • maintain version histories • support workspaces, in which designers can make private changes • permit the changes to be shared with other designers through semipublic workspaces • implement the careful update of the design archive by insuring that objects added to it have been successfully validated and that all equivalence relationships are in force
Desig(XII, n gll)Design...(X~ Figure 7. Structure of general design tree 278
Clearly, the notion 'version' and 'equivalence' can be realized in the framework of object-oriented knowledge base with the predicates derived_from(X, Y), which is true if X is a version derived from a representation Y equivalent(X, Y), which is true if the layout X of a circuit is logically equivalent to the switch-level description Y of the circuit.
KNOWLEDGE-BASED DESIGN SYNTHESIS AND CONCLUSION In this paper, the use of object-oriented design and logical description to facilitate automatic VLSl computer architecture design has been proposed. The framework of object-oriented knowledge bases has been proposed to organize design knowledge, to describe the behaviour of computing systems, to describe the structure of computing systems, and to manage designs at different abstract levels consistently and intelligently. The main advantages of this approach can be summarized as follows: • Since the knowledge base represents our knowledge about VLSI computer architecture design, users can understand the contents of the system by querying the knowledge base. • Logic provides a powerful way to describe the behaviour of computing systems and our design knowledge. • Since patterns of systems can be highly abstracted, design knowledge can be reused when a system is given to be implemented. • Since a knowledge base can be expanded incrementally, the intelligence of the system can therefore evolve with time. • Since most of the low-level layout tasks can be automated, circuit designs at different abstract levels can be maintained consistently and efficiently. Also designers are able to evaluate a design at different abstract levels once a design is completed. One major extension of the work reported here is to synthesize VLSI designs according to the knowledge stored in the knowledge base. In general, VLSI system design is a 'cut-and-try process'. Even with CAD software, the actual design process requires trying many different methods and selecting the one that works best. The designer develops tentative solutions and then selects his tentative solutions by analysing the results of executing one or more steps. Such processes can best be characterized by the model depicted in Figure 2. Computationally, the design process model shown in Figure 2 can be realized by an AND-OR tree search process as shown in Figure 7. Assuming that each design problem in an object-oriented knowledge base is initiated by a design query of the form design (X, Y), where X is the circuit to be designed and Y is a conjunctive formula specifying the desirable performance requirements, since a conjunctive formula can be constructed as a class in the knowledge base, Y is an object in the class conjunctive formula; consequently the knowledge base remains of first-order and an AND-OR search tree can be constructed as follows:
computer-aided design
• Each OR node represents a design activity. Each branch of an OR node is a possible design approach (based on some style and refinement/optimization), and the corresponding terminal is an AND node. • Each AND node represents a constraint propagation problem. Each terminal of an AND branch represents a design activity. • All the terminal nodes are design nodes.
4
McLellan, P 'Effective data management for VLSI design' Proc. 22nd A CM/IEEE Des. A utomation Conf. (1984) pp 652-657
5
Katz, R H 'Managing the chip design databases' IEEE Computer Vo116 No 12 (December 1983)
6
Katz, R H Information management for engineering design Springer-Verlag, Berlin, FRG (1985)
7
Guttman, A and Stonebraker, M 'Using a relational database management system for CAD data' IEEE Database Engineering (June 1984) pp 56-60
Apparently, each OR node in a search tree can be expanded according to deductive laws of the general form if fl(Y) design(X, Y) *- design (X/, Y)
8 (*)
and each AND node can be expanded according to the deductive law of the following form ifg/(V) design (Xh Y) *- design (XI1, Y) A design (Xi2, Y2 ) A ... A design(X/j, Yj)AffY, Y1,..., Yj) To avoid an exhaustive search, a best-first search can be performed as follows, assuming that a certainty factor is associated with each deductive law of the form (*). Upon receiving a seed query design (X, Y), the planner first picks the rules that are applicable to the goal design (X, Y), and forms an OR node in the search tree. It then tries to expand the most promising child first, and this process repeats as long as a leaf node is not generated. Whenever an OR node is generated, the certainty factor of the rule being applied is attached to that node; all the leaf nodes have a priori certainty factors defined also. Whenever a leaf node is generated, its logical value (true or false) is generated by testing the performance of the design and its certainty factor is adjusted to be 0 or 1 accordingly. At this time, this new certainty factor may affect the certainty factors of its ancestors, and changes should be reflected from bottom to top by applying the following rules CF(AI A ... A An) = CF(AI V ...VAn) =
max
1 <~l<~n
max
1 <<.l<~n
CF (Ai) CF (Ai)
After all the certainty factors of the current search tree have been adjusted, the planner restarts the search from the root. The above process is repeated until a successful design is achieved or certain tolerance measure has been exceeded. Since there may be an infinite number of ways to propagate the constraints, a metaplanner can be constructed on the top of the search tree to adjust the local component constraints, according to the observations made during the search.
REFERENCES
Wiederhold, G, Beetem, A and Shat, G E 'A database approach to communication in VLSI design' IEEE Trans. Comput.-Aided Des. Integrated Circuits Systems (April 1982) 9 Afsarmanesh, H, McLeod, D, Kanapp, D and Parker, A 'An extensible object-oriented approach to databases for VLSl/CAD' Proc. 17th VLDB (August 1985) 10 Batory, D S and K/m, W 'Modeling concepts for VLSl CAD objects' ACM Trans. Data Struc. (September 1985) pp 322-346 11 Nguyen, G T 'Semantics of CAD objects for generalized databases' Proc. ACM/IEEE 23rd Des. Automation Conf. (1986) pp 3 4 - 4 0 12 Wolf, W 'An object-oriented, procedural database for VLSl chip planning' Proc. 23rd ACM/IEEE Des. Automation Conf. (1986) pp 744-751 13 Bancilhon, F, K/m, W and Korth, H 'A model for CAD transactions' Proc. l l th VLDB (August 1985) 14 Katz, R H and Weiss, H S 'Design transaction management' Proc. ACM/IEEE 21st Design Automation Conf. (June 1984) 15 K/m, W e t al. 'Nested transactions for engineering design databases' Proc. VLDB (August 1984) 16 Katz, R H, Anwarrudin, M and Chang, E 'A version server for computer-aided design data' Proc. 23rdACM/ IEEE Des. Automation Conf. (1986) pp 27-33 17 Katz, R H, Chang, E and Bhateja, R 'Version modeling concepts for computer-aided design databases' ACM SIGMOD (1986) pp 379-386 18 Katz, R H and Lehman, T J 'Database support for versions and alternatives of large design files' IEEE Trans. Software Eng. SE-10 No 2 (March 1984) 19 Baker, C M and Terman, C 'Tools for verifying integrated circuit design' Lambda No 1 (1980) 20 Terman, C J 'Simulation tools for digital LSI design' MIT Computer Science Laboratory, MA, USA TR-304 (1983) 21 Newton, A R and Sangiovanni-Vincentelli 'Computeraided design for VLSl circuits' Computer (April 1986) 22 Brewer, F D and Gajski, D P 'An expert system paradigm for design' Proc. 23rd ACM/IEEE Des. Automat/on Conf. (I 986)
1
Carter, H W 'Computer-aided design of integrated circuits' Computer (April 1986) pp 19-36
2
Subrahmanyam, P A 'Synapse: an expert system for V LSI design' IEEE Computer (july 1986) pp 78-89
23 Bushnell, M L and Director, SW'ULYSSES: an expertsystem based VLSl design environment' Proc. CHDL'85 North-Holland (1985) pp 391-403
3
Haskin, R and Lorie, R 'On extending the functions of a relational database systems' Proc. ACM SIGMOD (June 1982)
24 Kowalski, T J An artificial intelligence approach to VLSI design Kluwer Academic Publishers, Hingham, MA, USA (1985)
volume 20 number 5 june 1988
279
25
Joobbani, R and Siewiorek, D P ‘Weaver: a knowledgebased routing expert’ Proc. 22nd ACM/IEEE Des. Automation Conf. (1985) pp 266-272
26
Juhannsen, D L, Tsubota, S K and McElvain, K ‘An intelligent compiler subsystem for a silicon compiler’ Proc. 24th ACM/IEEE Des. Automation Conf. (1987) pp 443-450
27
Kahn, H J and Filer, N P ‘An application of knowledgebased techniques to VLSI design’ Proc. Expert System 85 Cambridge University Press (1985)
36
Sheu, P C-Y ‘Query processing and communication control in object bases and distributed object bases’ PhD dissertation University of California, Berkeley, CA, USA (1986)
37
Parnas, D ‘On the criteria to be used in decomposing systems into modules’ CACM (December 1972)
38
Abbott, R ‘Program design by informal criptions’ CACM (November 1983)
39
Booth, G Software engineering with Ada Benjamin/ Cummings, Melo Park, CA, USA (1983)
40
Booth, G ‘Object-oriented development’ IEEE Trans. Software Eng. Vol 3 No 1 (February 1986)
41
Cesen, T, lodiu, E and Tsareff, C ‘PAMS: an expert system for parameterized module synthesis’ Proc. 24th ACMjIEEE Des. Automation Conf. (1987) pp 666-671
English des-
28
Kowalski, T and Thomas, D ‘The VLSI design automation assistant: what’s in a knowledge base’ Proc. 23rd ACM/IEEE Des. Automation Conf. (1985)
29
Lin, Y-L, Steve, and Gajski, D D ‘LES - a layout expert system’ Proc. 24th ACMfIEEE Des. Automation Conf. (1987) pp 672-678
30
Wu, C F, Wojcik, A S and Ni, L M ‘A rule-based circuit representation for automated CMOS design and verification’ Proc. 24th ACMfIEEE Des. Automation Conf; (1987) pp 786-792
42
Girczyc, E F and Ly, T ‘STEM - an IC design environment based on the Smalltalk model-view-controller construct’ Proc. 24th ACM/IEEE Des. Automation Co& (1987) pp 757-763
31
Gregory, D, Bartlett, K, de Geus, A and Hachtel, G ‘Socrates: a system for automatically synthesizing and optimizing combinational logic’ Proc. 23rd Des. Automation Conf. (1986)
43
Ullman, J D Principles Science Press (1983)
44
Hopcroft, J E and Ullman, J D Formal languages and their relation to automata McGraw-Hill (1976)
32
Mead, C and Conway, L Introduction Addison-Wesley (1980)
33
Gajski, D ‘Silicon (November 1985)
compilation’
to VLSI systems
VLSI System Design
BIBLIOGRAPHY
34
Kellogg, C ‘From data management to management’ Computer (January 1986)
35
Goldberg, A and Robson, D Smalltalk-80: the language and its implementation Addison-Wesley (1983)
280
of database systems Computer
knowledge
Burnstein, N and Pelevin, R ‘Hierarchical wire routing’ IEEE Trans. CAD of IC and Systems (October 1983) Johannsen, compilation’
D L, McElvain, K and Tsubota, S K ‘Intelligent VU/ Systems Design (April 1987)
computer-aided
design