Synapse: An Expert System for VLSI Design

  • Upload
    pa

  • View
    216

  • Download
    2

Embed Size (px)

Citation preview

  • Synapse: An ExpertSystem for VLSI Design

    P A. SubrahmanyamAT&T Bell Laboratories

    aB1.

    "I

    V LSI design involves mapping aproblem specification into mask

    V descriptions for circuit fabrica-tion. This typically spans at least threedifferent dimensions for representing aproblem-behavioral (or functional),structural (architectural), and physical(capturing placement and geometry)-aswell as several levels of abstraction alongeach dimension. Functional abstractionsinclude Boolean expressions, programs inconventional languages such as C, Lisp,Pascal, and Ada, as well as representationindependent of axiomatic or equationalspecifications, such as programs in OBJ. IStructural abstractions include descrip-tions at the register-transfer level, theswitch-level, the transistor level, and soon. Physical abstractions capture place-

    ment and geometry, and include program-mable logic arrays (PLAs); symbolicdescriptions that use logical symbols, forexample, 0's and I's, such as storage logicarrays (SLAs)2 and path programmablelogic arrays (PPLs)3; symbolic descrip-tions using circuit elements4; and mask-level descriptions.

    A major factor that complicates thedesign problem is that each of thesedimensions has its own set of concepts,associated terminology, and tool idiosyn-cracies. We believe that a better approachwould be to build a design system around acommon pool of concepts (not necessarilycommon languages) which tie together thegoings on at the various levels. By doingthis, we would gain a common basis for

    0018-9162/86/0700-0078$01.00 i 1986 IEEE

    I

    ,I

    A

    Ai

    78 COMPUTER

  • synthesis and analysis; conceptual integri-ty in VLSI design, which has been recog-nized as being crucial in software design;and the potential for developing a familyof integrated tools rather than a discon-nected set of tools.

    This belief has led to the design ofSynapse, I an expert system for supportingVLSI design. The primary goal of the sys-tem is to enable very high level specifica-tions of a problem (consisting of thedesired functional and performance speci-fications) to be mapped into custom VLSIcircuits. More generally, the system ar-chitecture supports the development of in-tegrated software-hardware systems. Asmall set of algebraic primitives is used tomodel several of the levels of abstractionalong the dimensions involved in VLSIdesign. 5,6 Systems at all levels of abstrac-tion, and in all dimensions, are repre-sented as (algebraic) expressions. Thetranslation process consists of repeatedlytransforming expressions that representsystem descriptions.

    Such an approach to VLSI design clear-ly represents a significant departure frommost existing paradigms. Consequently,for a system based on this paradigm to beacceptable, it must support a gradualevolution of design paradigms, from theheuristic to the formal. The Synapse ar-chitecture accommodates this goal byallowing for expert agents that performspecialized subtasks in synthesis that maybe heuristic or procedural in flavor, basedon a taxonomy of the (sub)expressionsrepresenting system descriptions. Anothergoal of Synapse is to support human in-teraction and machine learning.

    System architectureSynapse's transformations of formal

    expressions representing system descrip-tions are formal symbolic manipulationsgoverned by the axioms characterizingmodels (user interfaces) at various levels ofabstraction and the equational semanticsof user-defined functions. In general,transformations either change the dimen-

    'Synapse may be loosely interpreted as a SynthesisAid (Apprentice) for Paralel Systems (Environments).Any neurological associations are entirely to the creditof the reader.

    Figure 1. Support for formal manipulations.

    sion or the level of abstraction of an ex-pression (typically increasing the amountof detail), or they improve the system'sperformance attributes.

    AUl transformations are formally prov-en to leave the functional behavior of thesystem unchanged. Such proofs need becarried out only once for each transfor-mation, when it is first added to the knowl-edge base. The proof itself is aided by theunderlying formal manipulation system,and can be automatic or interactive.

    Figure I shows the general structure ofthe system component that supports for-mal manipulations. This consists of a setof inference rules that support variousforms of simplification and reasoning, aset of axioms that capture the problem-specific properties and/or the user inter-face at a specific level of abstraction, anda set of strategy-guidance rules. Thismachinery is mostly independent of theexpression's dimension and the abstrac-tion level.The specification input to the system

    forms the initial expression. Any numberof transformations may be applied to thisexpression, and all of the resulting expres-sions may be viewed as representing eitherlegitimate outputs or intermediate designstates. If a design has the desired perfor-mance characteristics, and is in the proper

    dimension, such as a mask description, itmay then be viewed as a final output.

    Several implementations may typicallybe generated if all the applicable trans-formations are used. Therefore, strategiesto focus the search in the space of alter-native designs are needed. The searchstrategy (that is, the rule-application strat-egy) is controlled by local cost estimates,weighting the axioms or expressions tobias their choice by a program, user in-teraction, and global optimization usingan appropriate technique such as simu-lated annealing.

    While the main design development istop-down, the system supports bottom-upcorrection, where bottom-up informationflow can modify some choices made dur-ing top-down design. However, these deci-sions affect only the performance criteriaand architecture of the resultant designs.Functional correctness is always guaran-teed by construction independent of thedevelopment path's specifics.

    Expression taxonomy: specialized sili-con compilers. Given the above generalparadigm, it is sometimes advantageous todivide the (sub)expressions in systemdescriptions into different classes for com-putational efficiency. That is, we can have

    79July 1986

  • Figure 2. Examples of expression subclasses.

    specialized techniques to transform cer-tain classes of expressions: The strategy todeal with such subclasses of expressions isgenerally better understood, and thereforethe expense of finding out what to do nextcan be greatly reduced.Examples of such specialized silicon

    compilation strategies (see Figure 2) in-clude techniques that deal with uniformrecurrence equations, 7 synchronizer spe-cifications,8 regular expressions, 9 andtypical sequential programming con-structs. 10 An analogy is the use of built-infunctions provided in programming lan-guage implementation for arithmeticoperations and input-output operations,as well as microcoded support for com-piler implementation.Some of the advantages in adopting

    specialized techniques for transformingexpression subclasses include the modu-larity gained by partitioning the system'sknowledge domain, the improved exe-cution efficiency (and potentially superiordesigns), and use of existing special-purpose software tools such as symboliccomputations packages in Macsyma.A further variant that improves flex-

    ibility is to let the user perform the actualtransformations. In this case, the user isprimarily responsible for proving that thetransformations are correct and for ensur-ing consistency between representations.

    The user-guided transformations may inturn be supported by an underlyingmethodology and an associated set oftools. While we have experimented withprototypes for several of the specializedsilicon compilers described above,8"'1-'2they are not yet integrated into the currentimplementation.

    System implementation environment.The environment chosen for Synapse'simplementation can be categorized intocomponents that support the formalmanipulations needed for inferencing andsymbolic computation, design of theheuristic (expert) agents, general-purposeprogramming, and VLSI-specific opera-tions such as editors for schematics andsymbolic layout.

    In the current implementation (seeFigure 3), the formal manipulations aresupported by a theorem-proving systemwritten in Pascal and running on a VAXmainframe. 13 Some of the symbolic com-putation routines needed for complexitycomputations are implemented with Mac-syma. 14 The expert system componentsare written in a combination of KEE'5and ZetaLisp running on Symbolics LispMachines.

    Future generations of the system willmore extensively use languages that direct-ly support equational reasoning and

    knowledge-based program construction.Such languages are not yet mature enoughto support large software development.The VLSI-specific operations and

    graphics-support routines, such as thosefor editing schematics and symbolic lay-outs, are written in a combination of Lispand C and execute on VLSI workstations,Lisp Machines, and VAX computers. Thegeneral-purpose programming environ-ment that combines these components isprovided by a Lisp Machine.The system is configured as a set of

    loosely coupled (distributed) agents, thatis, the agents execute on different ma-chines in a local network. The logical in-teractions are done via files and remoteprocess invocations rather than via sharedmemory. This organization will be dis-cussed further after some more details ofSynapse have been presented.

    Examples. The notion of algebraic"behavior expressions" used in describingconcurrent systems in Synapse is intro-duced next. The input, output, and globalsynthesis strategy of Synapse are thendiscussed via examples.

    Behavior expressions: concurrent sys-tem specifications. Recall that a system atany level of abstraction-and any dimen-sion-is represented by an algebraic ex-pression. Such expressions represent mul-tipliers, sorters, arithmetic units, lists,integers, and the like; these objects aregenerally parameterized.

    For example, lists may be of boundedsizeN (a parameter instantiated by an in-teger) and made up of objects of type T(aparameter instantiated by any type thathas a comparison operator defined on it).All such objects are obtained by applyingfunctions to other objects. Constants areviewed as nullary functions, that is, func-tions with no arguments.To make things a little more concrete,

    consider a specification ofa chip that sortselements in a list. The chip, called Sort-Chip, accepts a list I at the port labeled"InputList" (denoted InputList-I) andoutputs a sorted version of the list at theport labeled "OutputList" (denoted Out-putList-Sort()). This behavior may bedescribed as

    SortChip = InputList-l- >OutputList-Sort(l)

    where I is an instance of a list and Sort is a

    COMPUTER

    ;d>S.S< -;;> \ 0 - |Sp ci i silicon compiler

    Uniform recurrence relations

    tCt;| Behavior expressions | ia

  • function defined on lists. The symbol - >may be read as "followed by" and in-dicates that the input is first accepted at theport InputList; this is followed by the out-put of the sorted list at the port Out-putList. If, as we would normally desire,the chip repeats this cycle, this behaviorcan be expressed by the recursive behaviorexpression

    SortChip = InputList-I- >OutputList-Sort() - > SortChip

    More formally, I is an instance of theparameterized abstract data type Listthat can be defined axiomatically. I (Thesidebar entitled "An automated proof oftransformation equivalence" definessome of the functions used in this article.)The definition of the function Sort maytake the form

    Sorto) = if I = NewList then NewList elseAdd(Sort(Delete(,Max(l))), Maxo))

    1,/e-General-purpose programmin VLSI-specific workstations150">_ 1 Zetalisp/Symbolics' Lrt i;i2\ ' VAX/6800

    Figure 3. Components of the support environment in Figure 2. Broken arrows denoteloose coupling, while solid arrow denotes strong coupling.

    where NewList denotes an empty list andAdd serves as a constructor function thatbuilds up lists from elements. There isnothing distinguished about this particulardefinition for Sort. Any equivalent defini-

    tion can be assumed as the initial equa-tional specification because the equationsdefine Sort only up to the congruence classinduced by the entire set of equations

    defined on the type. Problem-specificrewrite rules can be used to transform anexpression into an equivalent form ifnecessary.

    July 1986 81

  • I.0

    Unit: SORTER in knowledge base SORT-CHIPCreated by subra on 10-Nov-85 1:03:31Modified by subra on 1 1 -Nov-85 9:23:19Member Of: (OBJECTS in kb CADRE)

    This is the input specification for a sort chip.

    Own slot: BEHAVIOR from SORTERInheritance: OVERRIDE.VALUESValueClass: (BEHAVIOR- EXPRESSIONS in kb CADRE)Comment: 'The behavior-expression describing this object'Values: SORTER-BE

    Own slot: IMPLEMENTATIONS from OBJECTSInheritance: OVERRIDE.VALUESComment: 'A set of one or more implementations of an object.'Values: Unknown

    Own slot: PERFORMANCE-REQUIREMENTS from SORTERInheritance: OVERRIDE.VALUESPincount: (

  • specified bit width), and lists of unspeci-fied length, having components that areeight-bit integers. Such partial instantia-tions would yield partially instantiated ar-chitectural skeletons as outputs.

    System output. Given a fully instan-tiated behavior expression as input, alongwith (optional) performance require-ments, the system's output is a maskdescription for a complementary metal-oxide semiconductor (CMOS) circuit.(The automatically synthesized outputmay not completely fulfill the desired per-formance goals; if it does not, interactivefacilities let the designer attain the goals.)Figure 5 shows examples of the layoutdescription for a part of the circuit pro-duced by Synapse's leaf-cell expert. 16

    Global synthesisstrategy

    The main steps in synthesis are* Automatically simplifying the input

    expression as far as possible with axiomsand rewrite rules.

    * If desired, interactively transformingthe expression describing the system to anequivalent expression, perhaps more ap-propriate for later steps. The proof ofequivalence between the two expressionsis aided by the underlying inferencemechanisms.

    * Automatically mapping expressionsat the functional level into an expressiondescribing a system at the architecturallevel with general- or special-purposetransformation schemata.The intermediate expressions obtained

    during this mapping are simplified auto-matically using the axioms and rewriterules that characterize the level of abstrac-tion. Both conventional compiler optimi-zations and technology-specific optimiza-tions fall into this class of manipulations.Furthermore, such expressions can also beinteractively transformed into othersemantically equivalent expressions.At the lower levels, the technology-

    dependent circuit-building paradigms canbe axiomatically characterized, and the in-ference engine can synthesize the circuitbehavior from available primitives. Thisprocess should be used judiciously, as itcan become very compute- intensive.

    e

    Own slot: LAYOUT from INV-MODULE-12Inheritance: OVERRIDE.VALUESComment: 'PAS. Describes the symbolic layout of the module."

    Facet Inheritance: OVERRIDE. VALUESValues: (:LAYOUT (#))

    (.TO-PARENT((CADRE:AREA 99.0) (CADREASPECT9.0 11.00)(CADRE:PORT-POSITION VSS 00) (CADRE:PORT-POSITION VSS 90)(CADRE:PORT-POSITION VDD 011) (CADRE:PORT-POSITION VDD 9

    11)(GADFPORT- 6N0OUT0ro(CADRE:PORT4POSmON IN 04)))

    Figure 5. Partial Synapse output.

    * Factoring the expression describingthe system to obtain an architecture. Dif-ferent factorizations yield different parti-tionings of the resultant architecture. Thispartitioning is guided by the performancerequirements and performance metrics,and can be affected by lower level designdecisions.

    * Converting the complete structuraldescription into a physical layout. Thisphase uses a system of cooperating agentsthat perform lower level tasks such asfloorplanning and leaf cell layout. 17 Hintsfor the physical layout are obtained as partof the input from the previous phases ofdesign. Weexpect that problematic aspectsin the architectural design discovered atthis level will be communicated back up tothe architectural designer for subsequentautomatic modification.

    Transforming expressions. An expres-sion describing a system-initially, the in-put specification-can be transformedinto an equivalent expression at the sameor at a lower level of abstraction. As men-tioned earlier, this is done automatically(by simplification or the use of trans-formation schemata) or interactively. Inthe interactive mode, the equivalence ofthe two expressions may be proved withthe aid of the inference engine mentionedearlier.The following example illustrates a

    transformation on the initial expressiondefining the function Sort and describesthe use of a special-purpose schema togenerate a pipelined implementation forthe input behavior expression. The reasonfor applying the first transformation is tocoerce the initial expression defining Sort

    into a form appropriate for the special-purpose schema. When such transforma-tions are made automatically, they areguided by the available set of schemataand the performance criteria.

    Consider the subterm Delete(l,Max(l))in the definition of Sort. It is possible tofactor out the single common argument Iand define a new function DeleteMax thatoperates on a list and deletes its largest ele-ment. Once this is done, the expressionSort(Delete(l,Max(l) ) can be rewritten asSort(DeleteMax(l) ). An automaticallyobtained inductive proof of the equiva-lence of the two forms is illustrated in thesidebar entitled "An automated proof oftransformation equivalence."

    Special-purpose schemata. Transfor-mation schemata provide implementa-tions for subclasses of expressions. Theyare implemented as clusters of productionrules in the expert system environment.Each transformation maps a behavior ex-pression (which is initially the inputspecification) into another behavior ex-pression (which is ultimately a descriptionof the fmal circuit or a part thereof).Each transformation is associated with

    a set of attributes that characterize the per-formance metrics of the network thatresults from applying this transformation.These attributes guide the overall trans-formation strategy. Since the correctnessof each schema is formally proven, theintermediate and final implementations(circuit architecture) are guaranteed topreserve the initially specified behavior.The correctness proofs are aided by theinference engine.

    July1986 83

  • Unit: SCHEMA-INV-RIPPLE in Knowledge base CADRECreated by File-Server on 28-Oct-85 10:29:32Modified by subra on 30-Oct-85 13:38:13Member Of: SCHEMAS

    Own slot: BEHAVIOR-EXPRESSION-CLASS from SCHEMA-INV-RIPPLEInheritance: OVERRIDE.VALUESValueClass: BEHAVIOR-EXPRESSIONSFunction-Variables: SCHEMA-INV-RIPPLE-FUNCTIONComment: "This defines the class of behavior expressions that is handled by this schema."Values: *INV-RIPPLE 5 [(INPUT*IN-1*X.1) (INPUT *IN-2 *X2)I

    (OUTPUT -OUT (APPLY *SCHEMA-INV-RIPPLE-FUNCTION (*Xl -2)))*INV-RIPPLE

    Own slot: FUNCTIONS-IMPLEMENTED from SCHEMA-INV-RIPPLEInheritanoe: OVERRIDE.VALUESValueClass: FUNCTIONSCardnality. Min: 1Values: SCHEMA-INV-RIPPLE-FUNCTION

    Own slot: HARDWARE-MODULE from SCHEMA-INV-RIPPLEInheritance: OVERRIDE.VALUESValueClass: HARDWARE-MODULESValues: SCHEMA-INV-RIPPLE-TUPLE-MODULE

    Own slot: INPUT-REPRESENTATION-FUNCTION from SCHEMASInheritance: OVERRIDE.VALUESLisp-Definition: (LAMBDA (X) X)Algebraic-Definition: IDENTITYComment: "Defines the manner in which the input is enooded, i.e., the map from the ext

    ernal representation to the module to the intemal representation for the module."Values: Unknown

    Figure 6. Part of a special-purpose schema.

    The schemata used by the system can becategorized into two classes:

    1. An extendable set of special-purposeschemata to synthesize implementationsof specialized subclasses of functiondefinitions (or behavior expressions).

    2. A fixed set of general-purpose sche-mata used as defaults when the neededbehavior is neither available as a primitivenor synthesizable with the list of special-purpose schemata.Some representative components of a

    typical schema are input-behavior-expres-sion (function-definition), output-behav-ior-expression (the implementation),properties of the implementation, precon-ditions that must be satisfied by the inputfor application of this schema, and post-conditions that hold after application ofthe schema.An example representation of a special-

    purpose schema for linear pipelining is

    indicated in Figure 6. A schema of thisform provides an implementation for abehavior/function definition that matchesa certain template: the input behavior ex-pression. The output behavior expressionof the schema describes a network im-plementation that results from applyingthis schema.

    Typically, the resulting network de-pends on the variable values instantiatedwhen a schema matches an input behavior.The properties associated with a particularmethod of implementing the input behav-ior expression characterize various perfor-mance attributes of the schema, such aswhether it decreases area or improvesresponse time. The preconditions andpostconditions respectively indicate theproperties that must hold before and afterthe schema's application.As mentioned earlier, the subterm

    Delete(l,Max(l) can be rewritten as

    DeleteMax(), which is defined asDeleteMax(NewList) = NewListDeleteMax(Add(l,x)) = if x > Max(l)then I else Add(DeleteMax(l),x)This form of the definition of the func-

    tions DeleteMax and Max matches func-tion definitions in two of the special-purpose schemata in the system.5 Figure 7shows the resulting architectural skele-tons. Intuitively, the first implementationis an array of processors. Each processortransmits the larger of the top and left in-puts to the right, simultaneously trans-mitting the smaller input to the bottom.Overall, if the tuple representing the list isinput at the top ports and the left ports aretied to - oo, the bottom outputs representthe input list with its largest elementdeleted and the rightmost output repre-sents the largest element in the list.The second implementation is a pipe-

    lined implementation for the combinationof functions Delete and Max. It has an ac-cumulator that stores the largest elementof the list portion so far streamed throughthe element. It outputs this element whenthe end-of-stream marker is input, signal-ing the end of the stream. In general, atransformation can provide an implemen-tation for two functions simultaneously,such as Delete and Max.

    Using a schema for function applicationand the fact that the function Sort hasbeen transformed to the form

    Sort() = Add(Sort(DeleteMax()),Max(l))we can now obtain several implementa-tions for Sort that use the previously de-rived networks for Max and DeleteMax.Figure 8 shows three networks that areautomatically synthesizable by Synapse.The first is a single processing element witha feedback loop and a buffer. The secondhas a triangular shape and uses a tuplerepresentation of lists for input and out-put. The third uses a linear representationof lists and cascades an appropriate num-ber of processing elements for Max andDeleteMax.Even after a design has been detailed to

    the level of Boolean primitives, the in-ference mechanism can be used in syn-thesis. This is done by using an axiomaticcharacterization of the lower level designparadigms to automatically synthesizesome of the technology-dependent partsof the circuit. While such a technique canbe used at other design levels in the design,this should be done judiciously because it

    COMPUTER84

  • can become computationally expensive.The sidebar entitled "Inference engine forlow-level synthesis" is an example of sucha synthesis, where an inverter is automati-cally synthesized in terms ofCMOS primi-tives (P-type and N-type transistors) by arefutation (theorem-proving) process.To use this technique, all functions are

    characterized by their I/O table (their out-puts are defined for each combination ofthe input values). Thus, an inverter isfunctionally characterized by a predicateOUTPUT(1,0,inv). This predicate statesthat the output value is 1 if the input is 0and that the output value is 0 if the input is1. The third parameter, inv, is merely adescriptive name tag used for book-keeping.

    For an n-input Boolean function, thepredicate output will have 2"1 + 1 argu-ments: the first 2" will describe the out-puts corresponding to all possible inputcombinations, while the last parameterwill capture the symbolic name of thefunction (or its manner of implementa-tion).

    General-purpose schemata. The behav-ior expressions in this article may beviewed as a language skeleton for describ-ing concurrent systems. The advantage ofthis approach is that it allows a simplealgebraic (equational) characterization ofthe semantics ofthe underlying primitives,which in turn aids the formal algebrabased tools.The functional expressions that param-

    eterize a particular behavior expressionmay be mapped into hardware by conven-tional silicon compilation techniques, aswell as by transformation-based method-ologies. The current implementation ofSynapse is mainly transformation-based.However, we have earlier experimentedwith other strategies'1l-10 that are brieflydescribed below, since they can be used inthe context of Synapse.To handle the general class of expres-

    sions, the basic syntactic constructs of thelanguage must be translated into hardwaredescriptions. This has several correspon-dences with traditional compilation strate-gies, but allows various forms of hard-ware-specific optimizations that may notbe relevant when generating programs.The main components of the compila-

    tion task include generating synchronizersto coordinate explicit parallelism such as

    Figure 7. Implementations for DeleteMax and Max using special-purpose schemata.

    Figure 8. Examples of synthesized implementations for the function Sort. (a) A sequen-tial implementation of the Sort function. (b) A triangular network forthe Sort function. (c)A linear pipelined network for the Sort function.

    July 1986 85

  • concurrent access to shared resources,generating hardware modules that imple-ment the functional expressions (the func-tional modules and connections betweenthem), and generating state machines(synchronous or self-timed, centralizedor distributed) that control data transfersbetween modules and provide neededsynchronization. 18

    In generating hardware modules for thefunctional expressions, we used variantsof conventional compiler representationsfor program fragments, where the basicblocks (pieces of straight line code) arerepresented as directed acyclic graphs(DAGs) and the control flow between thevarious pieces of code is represented at theblock level. This enables us to exploitvarious standard compiler optimizationstrategies and additionally use strategiesspecific to hardware generation. In par-ticular, we found it expedient to performsome block-level transformations to in-crease the amount of exploitable paral-

    lelism. Such transformations includemerging blocks, eagerly evaluating forconditionals (evaluating both arms of aconditional statement in parallel, alongwith the predicate), and unrolling loops atcompile time. &l lThe hardware description is expressed

    as a set of wired functional modules suchas adders, registers, multiplexers, andmultipliers. (The wires connecting themodules are called data paths.) A statemachine controls the transfer of data be-tween the functional modules over thedata paths. While this state machinetends to be centralized, it may in principlebe distributed. Furthermore, the statemachine and the associated logic may beeither synchronous or asynchronous (orself-timed). II

    Cost estimates control decisions aboutwhat trade-offs are made in allocatinghardware resources. The nodes in theDAG are typically labeled by variables in

    the program. Actual hardware registersneed not often be assigned to all suchvariables, since some of the programvariables (those implemented as signals)are ephemeral. Different types ofvariablesare often handled differently. For exam-ple, arrays below a certain size are im-plemented with a register file, while thoseabove this threshold size might be im-plemented with random access memorycells.The nodes in the DAG representing

    computations to be performed have a par-tial order induced on them by datadependencies. The computations in thesenodes are scheduled, subject to resourceallocation constraints.We have so far experimented with three

    approaches to implementing data paths:* manual layout of the data path forSLA/PPL designs; 19

    * automatic (but suboptimal) PPLlayout of the data path, followed by

    86

    L

    COMPUTER

  • compaction with a PPL-specificcompactor1I; andassuming a floor-planning paradigmwhere the bit slices (cells for eachfunctional unit) are placed at rightangles to the direction in which theprimary data busses and globalsignals (such as power, ground, andclocks) are run.

    While the second technique yieldedreasonable results in a few cases, we foundthe approach to be impractical on a largescale because ofthe compactor's exponen-tial time algorithm. An ongoing imple-mentation of a floor planner that will beincorporated into Synapse aims for a morecustomized floor-planning strategy. 20 Figure 9. An automatically generated leaf cell layout.

    Synchronizer synthesis. The controllerin a hardware implementation is the statemachine that controls data transfers be-tween functional modules. The datadependency between the operationsneeded to evaluate an expression can be in-ferred and expressed as a set of temporalconstraints. A schedule for the operationscan then be obtained from a model thatsatisfies these constraints. 5,8,21-22 Synapseuses schema-based techniques in combina-tion with constraint-based optimizationmethods.

    Mapping structural descriptions. Agroup of experts in lower level tasks, suchas floor planning and leaf cell layout,translate structural descriptions tophysical layouts. 17 The structural descrip-tion is typically subjected to local technol-ogy-specific transformations, 23 which canbe based on an algebraic model of thetechnology (such as structured logic arraysor CMOS). 6 A set of algebraic rules of in-ference can be used to determine the over-all geometric shape of the resulting net-works. Such information can be used, forexample, to guide the floor-planningmodules.A rule-based layout tool called Topolo-

    gizer16 provides a leaf cell symbolic lay-out. This expert takes as input a descrip-tion of transistor connectivity and a set ofconstraints that define transistor sizing,external connection, area, and aspectratio. What it produces is a CMOS sym-bolic layout of the cell in a form suitablefor processing by the virtual grid layoutsystem Mulga. 4 Figure 9 shows the output

    of a leaf cell layed out by Topologizer, anda comparable manually crafted cell.

    Expert system issuesSalient features in the current version of

    Synapse, from an expert systems view, in-clude provisions for multiple perspectiveson objects, consistency maintenance,search mechanisms, history maintenance,and machine learning.

    Perspectives. The Synapse architecturesupports multiple perspectives on the ob-jects manipulated. A distinguishingfeature stems from the desire for aframework that allows a gradual transi-tion from informally based designparadigms to formally based paradigms:Most objects have an algebraic representa-tion that provides an interface to the for-mal tools. This algebraic representation istypically an addition to other perspectivesthat are perhaps more common to VLSI-related tools, such as graphical perspec-tives for aiding user input, and display ofthe circuit representations appropriate tothe abstraction level, such as architecturalfloor plans, schematics, and symbolicmask layouts.A procedural (Lisp) perspective is used

    to smoothly interface with the Lisp en-vironment, while the graphical and frameperspectives are inherited from KEE.

    It is obviously not necessary for an ob-ject to have all possible perspectives at alllevels of abstraction. However, it is some-

    July 1986

    times important or convenient to havemore than one perspective.

    Consistency maintenance. The Ac-tiveValues facility in KEE is used to main-tain consistency between multiple repre-sentations-this esseentially results in theinvocation of demon procedures when-ever any of a set of related attributes ismodified. (This is only done for some at-tributes in the current version of Synapse.)The underlying rerpesentation structure

    lets the history of the development of adesign-both the hierarchical structureand the temporal ordering of the nodes-be maintained in a mechanically read-able form. This is intended to facilitate in-cremental redesign caused by alterations inthe initial specifications. We plan to use atruth-maintenance mechanism in this con-text, particularly to record major decisionpoints in the development sequence.

    Search mechanisms. Synapse uses boththe forward- and backward-chainingmechanisms in KEE. Backward chainingis used for the main synthesis, where thequery

    THE IMPLEMENTATION OF Initial-Specification IS ?SYNTHESIZED-IMPLEMENTATION

    causes a backward chaining of the syn-thesis rules in the appropriate rule classes.These rules in turn invoke the trans-formation schemata. Other parameterscontrol options such as the number of dif-ferent solutions sought and whether theuser should be consulted during synthesis.

    87

    TopologizerManual

  • The Synapse design isintended to support a

    gradual transitionfrom heuristic to

    algorithmic to formaltechniques.

    The overall search strategy is hierar-chical and uses a predictor-corrector ap-proach that tries to reconcile the top-downand bottom-up design paradigms. Top-down refinement (factoring/expansion ofthe expression representing the system) in-volves design decisions made on the basisof approximate, inaccurate, or sometimeunavailable performance estimates of adecision's effects on the eventual design.Two kinds of performance vectors are

    associated with each design option at aspecific level of abstraction: a top-downperformance estimate parameterized atthe level of abstraction and a bottom-upestimate obtained from library primitivesor previously elaborated designs.

    Based on complexity estimates at the ex-isting level of abstraction (and the nextlevel of refinement), the most promisingdesign option is pursued, unless a point isreached where the performance of thedesign is in conflict with the desired con-straints. When this occurs, the design isbacked up to the first point where the mostrecent design elaboration allows a moreaccurate reevaluation of alternativedesigns. The best of these is then exploredfurther.The complexity measures appropriate

    to the abstraction level under considera-tion are possible only if the design descrip-tion is appropriately parameterized. Thus,absolute values for performance criteriahave only limited value until bottom-upcomplexity estimates are available. Theframework we adopted supports such aparameterization naturally and thereforeoffers an important advantage over mostother approaches.

    Furthermore, the performance vector ismultidimensional, allowing the considera-tion of several relevant criteria during theearly design stages. Currently, the designallows for area, response time, through-put, pin count, and topological hints to the

    floor planner. It is being augmented to in-clude other factors such as testability.

    Machine learning. Forward chaining isused for implementing machine learningtechniques. Such learning techniques areused to discover new special-purposeschemata that help solve some subclassesof problems. 24 Furthermore, the systemcan learn by rote so all interactions withthe user and the synthesized system resultsare permanently recorded and retrievablelater. We are implementing these learningtechniques in Synapse.

    Trade-offs in system design. The cur-rent version of the expert system is thefourth prototype. The previous imple-mentations had somewhat different (andnonoverlapping) focuses of interest. Thefirst attempt focused on a program trans-formation system written in Interlisp tosupport the development of software/hardware systems. The hardware targetwas SLAs, while the input was a subset ofAda. 10,18 The control unit was self-timedand generated automatically, while thedata-path wiring was done manually. Thesecond prototype8 experimented with atemporal logic specification to generatesynchronizers. The third prototype fo-cused on more traditional compilationstrategies applied to hardware generation.The hardware target structures were gen-erated naively with path-programmablelogic. The resulting layouts were opti-mized with a PPL layout compactor. I IThe current effort is an attempt to syn-

    thesize custom CMOS implementations,placing the emphasis on tools and tech-niques that can guarantee rigorous cor-rectness of the resulting designs. In somesenses, the current version of the systemfalls short of the long-term goals set foran implementation, mostly because thenecessary programming language con-cepts, models, and implementationsneeded to support the overall structure ofSynapse have not yet matured. These in-clude programming languages that sup-port parameterized data types with in-heritance and reasoning about formalequational (axiomatic) definitions.Another reason is that even if such a

    framework were available, several years ofprogramming effort would be required toport all of the software tools we now use tothe new environment. The pragmatic dif-ficulty in doing this has prompted the

    loosely coupled structure of the currentsystem, which is aimed at aiding a grad-ual transition from informal to formalapproaches.

    WA I e have presented an overview ofSynapse, an expert system in-tended to aid in the design of

    custom VLSI circuits.The distinguishing features of the

    Synapse architecture, compared to relatedefforts25-31 aimed at aiding VLSI designinclude* a cohesive formal algebraic frame-work that supports input specifica-tions at a very high abstraction level,

    * algebra-based synthesis, verificationand analysis techniques and toolsacross a wide spectrum of designtasks,

    * the use of conventional expert systemtools and special-purpose theoremprovers,

    * bottom-up feedback during design,and

    * accommodation of machine learningtechniques, including rote learning.

    Synapse is a means to explore languageand expert systems issues in VLSI design,and is part of a long-term research project.It is therefore important to realize that theSynapse design is intended to support agradual transition from heuristic to algo-rithmic to formal techniques. Future workwill be directed at enriching the knowledgebase of the system and augmenting itslearning capabilities. O

    AcknowledgmentsI wish to thank Bryan Ackland, Bob

    Ensor, John Gabbe, and the referees forhelpful comments on an earlier version ofthis article.

    References1. J. A. Goguen, "Parameterized Program-

    ming," IEEE Trans. Software Eng., Vol.SE-10, Sept. 1984, pp. 528-552.

    2. S. S. Patil and T. Welch, "A Program-mable Logic Approach for VLSI," IEEETrans. Computers, Vol. C-28, No. 9,Sept. 1979, pp. 594-601.

    3. A. B. Hayes, "Self-Timed IC Designswith PPLs," Proc. Caltech VLSI Conf.,Computer Science Press, Mar. 1983.

    88 COMPUTER

  • 4. N. Weste and B. Ackland, "A PragmaticApproach to Topological Symbolic ICDesign," in Very Large Scale Integration,John P. Gray, ed., Academic Press, 1981.

    5. P. A. Subrahmanyam, "The AlgebraicBasis of an Expert System for VLSI De-sign," in FormalAspects of VLSIDesign,G. Milne and P. A. Subrahmanyam, eds.,North Holland, Amsterdam, 1986.

    6. S. Rajopadhye and P. A. Subrahmanyam,"Formal Semantics for a Symbolic ICDesign Technique: Examples and Ap-plications," Integration: The VLSI Jour-nal, No. 3, Mar. 1985, pp. 13-32.

    7. P. Quinton, "The Systematic Design ofSystolic Arrays," IRISA TechnicalReport, May 1983.

    8. P. A. Subrahmanyam, "From Anna + toCircuits: Automating the Synthesis ofHardware Synchronizers from TemporalLogic Specifications," internal report,Dept. of Computer Science, University ofUtah, Mar. 1982.

    9. J. D. Ullman, H. W. Trickey, and A. R.Karlin, "Experience with a Regular Ex-pression Compiler," Proc. IEEE Int'lConf. Computer Design: VLSI in Com-puters, Oct. 1983, pp. 656-665.

    10. S. V. Rajopadhye and P. A. Subrahman-yam, "TRACIS: Transformations onAda for Circuit Synthesis," Dept. ofComputer Science, University of Utah,Aug. 1983.

    11. P. A. Subrahmanyam, "An Experimentin Using Compilation Strategies for Map-ping Pascal Programs into CircuitDescriptions," internal report, Universityof Utah, July 1983.

    12. P. A. Subrahmanyam, "AutomatedDesign of a Class of Systolic Arrays," un-published AT&T Bell Laboratoriestechnical memorandum, Dec. 1984.

    13. E. L. Lusk and R. A. Overbeek, TheAutomated Reasoning System ITP,Argonne National Laboratory, Argonne,Ill., 1984.

    14. R. Ramachandran, "A Complexity Com-putation Package for Data Type Im-plementations," Dept. of ComputerScience, University of Utah, June 1982.

    15. KEE Software Development SystemUser's Manual, IntelliCorp, Jan. 1985.

    16. P. W. Kollaritsch and N. H. E. Weste,"Topologizer: An Expert SystemTranslator of Transistor Connectivity toSymbolic Cell Layout," VLSI Design,Aug. 1984, pp. 62-66.

    17. B. D. Ackland et al., "CADRE-ASystem of Cooperating VLSI Design Ex-perts," Proc. IEEE Int'l Conf. ComputerDesign: VLSI in Computers, Oct. 1985,pp. 99-104.

    18. P. A. Subrahmanyam, "SynthesizingVLSI Circuits from Behavioral Specifica-tions: A Very High Level Silicon Com-piler and Its Theoretical Basis," in VLSI83: VLSI Design of Digital Systems, FAnceau and E. J. Aas, eds., NorthHolland, Aug. 1983.

    19. E. I. Organick and R A. Subrahmanyam,"Transformation of Ada Programs intoSilicon," Third Semiannual TechnicalReport, University of Utah, Apr. 1983.

    20. H. Watanabe and B. D. Ackland,"FLUTE: A Heuristic Floorplanner forFull Custom VLSI Design," Proc. 23rdIEEE Design Automation Conf., June1986.

    21. T. S. Ananthatraman et al., "CompilingPath Expressions into Circuits," Proc.12th Ann. SIGACT/SIGPLAN Symp.Principles of Programming Languages,Jan. 1985, pp. 191-204.

    22. Z. Manna and P. Wolper, "Synthesis ofComputing Processes from TemporalLogic Specifications," Proc. WorkshopLogics of Programs, Springer-VerlagLNCS, New York, 1981.

    23. J. A. Darringer et al., "LSS:A System forProduction Logic Synthesis," IBM J.Research and Development, Vol. 28, No.5, Sept. 1984, pp. 537-545.

    24. P. A. Subrahmanyam, "Machine Learn-ing Techniques for Designing Circuits,"AT&T Bell Laboratories memorandum,Jan. 1985.

    25. J. R. Southard, "MacPitts: An Approichto Silicon Compilation," Computer, Vol.16, No. 12, Dec. 1983, pp. 74-82.

    26. D. Gajski and R. Kuhn, "New VLSITools," Computer, Vol. 16, No. 12, Dec.1983, pp. 11-14.

    27. H. Brown, C. Tong, and G. Foyster,"Palladio: An Exploratory Environmentfor Circuit Synthesis," Computer, Vol.16, No. 12, Dec. 1983, pp. 41-58.

    28. T. M. Mitchell, L. I. Steinberg, and J. S.Shulman, "VEXED: A Knowledge-Based VLSI Design Consultant," Lab forComputer Science, Rutgers University,July 1984.

    29. D. E. Thomas et al., "Automatic DataPath Synthesis," Computer, Vol. 16, No.12, Dec. 1983, pp. 59-73.

    30. J. Granacki, D. Knapp, and A. Parker,"The ADAM Advanced Design Automa-tion System: Overview, Planner andNatural Language Interface," Proc. 22ndDesign Automation Conf., June 1985,pp. 727-730.

    31. N. Bergmann, "A Case Study of theFIRST Silicon Compiler," Proc. CaltechVLSI Conference, Computer SciencePress, Mar. 1983.

    July 1986

    P. A. Subrahmanyam is a member of thetechnical staff in the Research Division ofAT&T Bell Laboratories. Before joiningAT&T, he was on the Computer Science facultyat the University of Utah and a visiting pro-fessor at the University of Southern CaliforniaInformation Sciences Institute. His research in-terests include very high level silicon compila-tion, programming language semantics, ar-tificial intelligence, and logic programming.Subrahmanyam received a BS in physics,

    chemistry, and mathematics and an M.Tech incomputer science from the Indian Institute ofTechnology in Madras, India, and a PhD incomputer science from the State University ofNew York at Stony Brook, where he was twiceawarded an IBM Fellowship.

    Readers may write to the author at AT&T,Room 4F61 10, Holmdel, NJ 07733.

    lb133 papers in 34 sessions. Major topics consistof: algorithms, vector/array processing, pro-blem mapping and scheduling, architectures,systolic problems, computation, languages,memory, numeric processing, interconnectionnetworks, data flow, numeric computing, net-work performance, and performance measure-ment. 888 pp.

    Order #637Proceedings-1985 IntemationalConference on Parallel Processing

    Nonmembers-S88.00Members-$44.00

    Handling Charges ExtraOrder from

    IEEE Computer Society Order Dept.PO Box 80452, Worldway Postal Center

    Los Angeles, CA 90080 USA(714) 821-8330

    WM;amP;~.Ton

    _:-- An_Z=