Knowledge based method and apparatus for designing integrated circuits using functional specifications
FIELD AND BACKGROUND OF THE INVENTION 
     This invention relates to the design of integrated circuits, and more particularly relates to a computer-aided method and apparatus for designing integrated circuits. 
     An application specific integrated circuit (ASIC) is an integrated circuit chip designed to perform a specific function, as distinguished from standard, general purpose integrated circuit chips, such as microprocessors, memory chips, etc. A highly skilled design engineer having specialized knowledge in VLSI circuit design is ordinarily required to design a ASIC. In the design process, the VLSI design engineer will consider the particular objectives to be accomplished and tasks to be performed by the integrated circuit and will create structural level design specifications which define the various hardware components required to perform the desired function, as well as the interconnection requirements between these components. A system controller must also be designed for synchronizing the operations of these components. This requires an extensive and all encompassing knowledge of the various hardware components required to achieve the desired objectives, as well as their interconnection requirements, signal level compatibility, timing compatibility, physical layout, etc. At each design step, the designer must do tedious analysis. The design specifications created by the VLSI design engineer may, for example, be in the form of circuit schematics, parameters or specialized hardware description languages (HDLs). 
     From the structural level design specifications, the description of the hardware components and interconnections is converted to a physical chip layout level description which describes the actual topological characteristics of the integrated circuit chip. This physical chip layout level description provides the mask data needed for fabricating the chip. 
     Due to the tremendous advances in very large scale integration (VLSI) technology, highly complex circuit systems are being built on a single chip. With their complexity and the demand to design custom chips at a faster rate, in large quantities, and for an ever increasing number of specific applications, computer-aided design (CAD) techniques need to be used. CAD techniques have been used with success in design and verification of integrated circuits, at both the structural level and at the physical layout level. For example, CAD systems have been developed for assisting in converting VLSI structural level descriptions of integrated circuits into the physical layout level topological mask data required for actually producing the chip. Although the presently available computer-aided design systems greatly facilitate the design process, the current practice still requires highly skilled VLSI design engineers to create the necessary structural level hardware descriptions. 
     There is only a small number of VLSI designers who possess the highly specialized skills needed to create structural level integrated circuit hardware descriptions. Even with the assistance of available VLSI CAD tools, the design process is time consuming and the probability of error is also high because of human involvements. There is a very significant need for a better and more cost effective way to design custom integrated circuits. 
     SUMMARY OF THE INVENTION 
     In accordance with the present invention a CAD (computer-aided design) system and method is provided which enables a user to define the functional requirements for a desired target integrated circuit, using an easily understood functional architecture independent level representation, and which generates therefrom the detailed information needed for directly producing an application specific integrated circuit (ASIC) to carry out those specific functions. Thus, the present invention, for the first time, opens the possibility for the design and production of ASICs by designers, engineers and technicians who may not possess the specialized expert knowledge of a highly skilled VLSI design engineer. 
     The functional architecture independent specifications of the desired ASIC can be defined in a suitable manner, such as in list form or preferably in a flowchart format. The flowchart is a highly effective means of describing a sequence of logical operations, and is well understood by software and hardware designers of varying levels of expertise and training. From the flowchart (or other functional specifications), the system and method of the present invention translates the functional architecture independent specifications into structural an architecture specific level definition of an integrated circuit, which can be used directly to produce the ASIC. The structural level definition includes a list of the integrated circuit hardware cells needed to achieve the functional specifications. These cells are selected from a cell library of previously designed hardware cells of various functions and technical specifications. The system also generates data paths among the selected hardware cells. In addition, the present invention generates a system controller and control paths for the selected integrated circuit hardware cells. The list of hardware cells and their interconnection requirements may be represented in the form of a netlist. From the netlist it is possible using either known manual techniques or existing VLSI CAD layout systems to generate the detailed chip level geometrical information (e.g. mask data) required to produce the particular application specific integrated circuit in chip form. 
     The preferred embodiment of the system and method of the present invention which is described more fully hereinafter is referred to as a Knowledge Based Silicon Compiler (KBSC). The KBSC is an ASIC design methodology based upon artificial intelligence and expert systems technology. The user interface of KBSC is a flowchart editor which allows the designer to represent VLSI systems in the form of a flowchart. The KBSC utilizes a knowledge based expert system, with a knowledge base extracted from expert ASIC designers with a high level of expertise in VLSI design to generate from the flowchart a netlist which describes the selected hardware cells and their interconnection requirements. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The invention will be better understood by reference to the detailed description which follows, taken in connection with the accompanying drawings, in which 
     FIG. 1a illustrates a functional level design representation of a portion of a desired target circuit, shown in the form of a flowchart; 
     FIG. 1b illustrates a structural level design representation of an integrated circuit; 
     FIG. 1c illustrates a design representation of a circuit at a physical layout level, such as would be utilized in the fabrication of an integrated circuit chip; 
     FIG. 2 is a block schematic diagram showing how integrated circuit mask data is created from flowchart descriptions by the KBSC system of the present invention; 
     FIG. 3 is a somewhat more detailed schematic illustration showing the primary components of the KBSC system; 
     FIG. 4 is a schematic illustration showing how the ASIC design system of the present invention draws upon selected predefined integrated circuit hardware cells from a cell library; 
     FIG. 5 is an example flowchart defining a sequence of functional operations to be performed by an integrated circuit; 
     FIG. 6 is a structural representation showing the hardware blocks and interconnection requirements for the integrated circuit defined in FIG. 5; 
     FIG. 7 is an illustration of the flowchart editor window; 
     FIG. 8 is an illustration of the flowchart simulator window; 
     FIG. 9 is an illustration of the steps involved in cell list generation; 
     FIG. 10 is an example flowchart for a vending machine system; 
     FIG. 11 illustrates the hardware components which correspond to each of the three macros used in the flowchart of FIG. 10; 
     FIG. 12 is an initial block diagram showing the hardware components for an integrated circuit as defined in the flowchart of FIG. 10; 
     FIG. 13 is a block diagram corresponding to FIG. 12 showing the interconnections between blocks; 
     FIG. 14 is a block diagram corresponding to FIG. 13 after register optimization; and 
     FIG. 15 is a block diagram corresponding to FIG. 14 after further optimization. 
    
    
     DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 
     FIGS. 1a, 1b and 1c illustrate three different levels of representing the design of an integrated circuit. FIG. 1a shows a functional (or behavioral) representation architecture independent in the form of a flowchart. A flowchart is a graphic representation of an algorithm and consists of two kinds of blocks or states, namely actions and conditions (decisions). Actions are conventionally represented in the flowchart by a rectangle or box, and conditions are represented by a diamond. Transitions between actions and conditions are represented by lines with arrows. FIG. 1b illustrates a structural (or logic) level representation of an integrated circuit. In this representation, blocks are used to represent integrated architecture specific circuit hardware components for performing various functions, and the lines interconnecting the blocks represent paths for the flow of data or control signals between the blocks. The blocks may, for example, represent hardware components such as adders, comparators, registers, system controllers, etc. FIG. 1c illustrates a physical layout level representation of an integrated circuit design, which provides the detailed mask data necessary to actually manufacture the devices and conductors which together comprise integrated circuit. 
     As noted earlier, the design of an integrated circuit at the structural level requires a design engineer with highly specialized skills and expertise in VLSI design. In the KBSC system of the present invention, however, integrated circuits can be designed at a functional level because the expertise in VLSI design is provided and applied by the invention. Allowing the designer to work with flowcharts instead of logic circuit schematics simplifies the task of designing custom integrated circuits, making it quicker, less expensive and more reliable. The designer deals with an algorithm using simple flowcharts at an architecture independent functional (behavioral) level, and needs to know only the necessary logical steps to complete a task, rather than the specific means for accomplishing the task. Designing with flowcharts requires less work in testing because flowcharts allow the designer to work much closer to the algorithm. On the other hand, previously existing VLSI design tools require the designer to represent an algorithm with complex circuit schematics at a structural level, therefore requiring more work in testing. Circuit schematics make it harder for the designer to cope with the algorithm function which needs to be incorporated into the target design because they intermix the hardware and functional considerations. Using flowcharts to design custom integrated circuits will allow a large number of system designers to access VLSI technology, where previously only a small number of designers had the knowledge and skills to create the necessary structural level hardware descriptions. 
     The overall system flow is illustrated in FIG. 2. The user enters the functional specifications of the circuit into the knowledge based silicon compiler (KBSC) 10 in the form of a flowchart 11. The KBSC 10 then generates a netlist 15 from the flowchart. The netlist 15 includes a custom generated system controller, all other hardware cells required to implement the necessary operations, and interconnection information for connecting the hardware cells and the system controller. The netlist can be used as input to any existing VLSI layout and routing tool 16 to create mask data 18 for geometrical layout. 
     System Overview 
     The primary elements or modules which comprise the KBSC system are shown in FIG. 3. In the embodiment illustrated and described herein, these elements or modules are in the form of software programs, although persons skilled in the appropriate art will recognize that these elements can easily be embodied in other forms, such as in hardware. 
     Referring more particularly to FIG. 3, it will be seen that the KBSC system 10 includes a program 20 called EDSIM, which comprises a flowchart editor 21 for creating and editing flowcharts and a flowchart simulator 22 for simulation and verification of flowcharts. Actions to be performed by each of the rectangles represented in the flowchart are selected from a macro library 23. A program 30 called PSCS (path synthesizer and cell selector) includes a data and control path synthesizer module 31, which is a knowledge based system for data and control path synthesis. PSCS also includes a cell selector 32 for selecting the cells required for system design. The cell selector 32 selects from a cell library 34 of previously designed hardware cells the appropriate cell or cells required to perform each action and condition represented in the flowchart. A controller generator 33 generates a custom designed system controller for controlling the operations of the other hardware cells. The knowledge base 35 contains ASIC design expert knowledge required for data path synthesis and cell selection. Thus, with a functional flowchart input, PSCS generates a system controller, selects all other hardware cells, generates data and control paths, and generates a netlist describing all of this design information. 
     The KBSC system employs a hierarchal cell selection ASIC design approach, as is illustrated in FIG. 4. Rather than generating every required hardware cell from scratch, the system draws upon a cell library 34 of previously designed, tested and proven hardware cells of various types and of various functional capabilities with a given type. The macro library 23 contains a set of macros defining various actions which can be specified in the flowchart. For each macro function in the macro library 23 there may be several hardware cells in the cell library 34 of differing geometry and characteristics capable of performing the specified function. Using a rule based expert system with a knowledge base 35 extracted from expert ASIC designers, the KBSC system selects from the cell library 34 the optimum cell for carrying out the desired function. 
     Referring again to FIG. 3, the cells selected by the cell selector 32, the controller information generated by the controller generator 33 and the data and control paths generated by the data/control path synthesizer 31 are all utilized by the PSCS program 30 to generate the netlist 15. The netlist is a list which identifies each block in the circuit and the interconnections between the respective inputs and outputs of each block. The netlist provides all the necessary information required to produce the integrated circuit. Computer-aided design systems for cell placement and routing are commercially available which will receive netlist data as input and will lay out the respective cells in the chip, generate the necessary routing, and produce mask data which can be directly used by a chip foundry in the fabrication of integrated circuits. 
     System Requirements 
     The KBSC system can be operated on a suitable programed general purpose digital computer. By way of example, one embodiment of the system is operated in a work station environment such as Sun3 and VAXStation-II/GPX Running UNIX Operating System and X Window Manager. The work station requires a minimum of 8 megabytes of main storage and 20 megabytes of hard disk space. The monitor used is a color screen with 8-bit planes. The software uses C programming language and INGRES relational data base. 
     The human interface is mainly done by the use of pop up menus, buttons, and a special purpose command language. The permanent data of the integrated circuit design are stored in the data base for easy retrieval and update. Main memory stores the next data temporarily, executable code, design data (flowchart, logic, etc.), data base (cell library), and knowledge base. The CPU performs the main tasks of creating and simulating flowcharts and the automatic synthesis of the design. 
     Flowchart Example 
     To describe the mapping of a flowchart to a netlist, consider an example flowchart shown in FIG. 5, which is of part of a larger overall system. In this illustrative flowchart, two variables, VAL1 and VAL2 are compared and if they are equal, they are added together. In this instance, the first action (Action 1) involves moving the value of variable VALI to register A. The second action comprises moving the value of variable VAL2 to register B. Condition 1 comprises comparing the values in registers A and B. Action 3 comprises adding the values of registers A and B and storing the result in register C. 
     In producing an integrated circuit to carry out the function defined in FIG. 5, the KBSC maps the flowchart description of the behavior of the system to interconnection requirements between hardware cells. The hardware cells are controlled by a system controller which generates all control signals. There are two types of variables involved in a system controller: 
     (1) Input variables: These are generated by hardware cells, and/or are external input to the controller. These correspond to conditions in the flowchart. 
     (2) Output variables: These are generated by the system controller and correspond to actions in the flowchart. 
     FIG. 6 illustrates the results of mapping the flowchart of FIG. 5 onto hardware cells. The actions and the conditions in the flowchart are used for cell selection and data and control path synthesis. The VALI register and VAL2 register and the data paths leading therefrom have already been allocated in actions occurring before Action 1 in our example. Action 1 causes generation of the data register A. Similarly, Action 2 causes the allocation of data register B. The comparator is allocated as a result of the comparison operation in Condition 1. The comparison operation is accomplished by (1) selecting a comparator cell, (2) mapping the inputs of the comparator cell to registers A and B, (3) generating data paths to connect the comparator with the registers A and B and (4) generating input variables corresponding to equal to, greater than, and less than for the system controller. Similarly the add operation in Action 3 causes selection of the adder cell, mapping of the adder parameters to the registers and creating the data paths. 
     Following this methodology, a block list can be generated for a given flowchart. This block list consists of a system controller and as many other blocks as may be required for performing the necessary operations. The blocks are connected with data paths, and the blocks are controlled by the system controller through control paths. These blocks can be mapped to the cells selected from a cell library to produce a cell list. 
     Interactive Flowchart Editor and Simulator 
     The creation and verification of the flowchart is the first step in the VLSI design methodology. The translation from an algorithm to an equivalent flowchart is performed with the Flowchart Editor 21 (FIG. 3). The verification of the edited flowchart is performed by the Flowchart Simulator 22 The Flowchart Editor and Simulator are integrated into one working environment for interactive flowchart editing, with a designer friendly interface. 
     EDSIM is the program which contains the Flowchart Editor 21 and the Flowchart Simulator 22. It also provides functions such as loading and saving flowcharts. EDSIM will generate an intermediate file, called a statelist, for each flowchart. This file is then used by the PSCS program 30 to generate a netlist. 
     Flowchart Editor 
     The Flowchart Editor 21 is a software module used for displaying, creating, and editing the flowchart. This module is controlled through the flowchart editing window illustrated in FIG. 7. Along with editing functions the Flowchart Editor also provides checking of design errors. 
     The following is a description of the operations of the Flowchart Editor. The main editing functions include, create, edit, and delete states, conditions, and transitions. The create operation allows the designer to add a new state, condition, or transitions to a flowchart. Edit allows the designer to change the position of a state, condition or transition, and delete allows the designer to remove a state, condition or transition from the current flowchart. States which contain actions are represented by boxes, conditions are represented by diamonds, and transitions are represented by lines with arrows showing the direction of the transition. 
     Edit actions allows the designer to assign actions to each box. These actions are made up of macro names and arguments. An example of arguments is the setting and clearing of external signals. A list of basic macros available in the macro library 23 is shown in Table 1. 
     
                       TABLE 1                                                     
______________________________________                                    
Macro         Description                                                 
______________________________________                                    
ADD (A,B,C)   C = A + B                                                   
SUB (A,B,C)   C = A - B                                                   
MULT (A,B,C)  C = A * B                                                   
DIV (A,B,C)   C = A div B                                                 
DECR (A)      A = A - 1                                                   
INCR (A)      A = A + 1                                                   
CLR (A)       A = 0                                                       
REG (A,B)     B = A                                                       
CMP (A,B)     Compare A to B and set EQ,LT,GT                             
              signals                                                     
CMP0 (A)      Compare A to 0 and set EQ,LT,GT                             
              signals                                                     
NEGATE (A)    A = NOT (A)                                                 
MOD (A,B,C)   C = A Modulus B                                             
POW (A,B,C)   C = A B                                                     
DC2 (A,S1,S2,S3,S4)                                                       
              Decode A into S1,S2,S3,S4                                   
EC2 (S1,S2,S3,S4,A)                                                       
              Encode S1,S2,S3,S4 into A                                   
MOVE (A,B)    B = A                                                       
CALL sub-flowchart                                                        
              Call a sub-flowchart. Pass A,B . . .                        
(A,B, . . .)                                                              
START (A,B, . . .)                                                        
              Beginning state of a sub-flowchart                          
STOP (A,B . . .)                                                          
              Ending state of a sub-flowchart                             
______________________________________                                    
 
    
     The Flowchart Editor also provides a graphical display of the flowchart as the Flowchart Simulator simulates the flowchart. This graphical display consists of boxes, diamonds, and lines as shown in FIG. 7. All are drawn on the screen and look like a traditional flowchart. By displaying the flowchart on the screen during simulation it allows the designer to design and verify the flowchart at the same time. 
     Flowchart Simulator 
     The Flowchart Simulator 22 is a software module used for simulating flowcharts. This module is controlled through the simulator window illustrated in FIG. 8. The Flowchart Simulator simulates the transitions between states and conditions in a flowchart. The following is a list of the operations of the Flowchart Simulator: 
     edit data--Change the value of a register or memory. 
     set state--Set the next state to be simulated. 
     set detail or summary display--Display summary or detail information during simulation. 
     set breaks--Set a breakpoint. 
     clear breaks--Clear all breakpoints. 
     show breaks--Display current breakpoints. 
     step--Step through one transition. 
     execute--Execute the flowchart. 
     stop--Stop executing of the flowchart. history ON or history OFF--Set history recording on or off. 
     cancel--Cancel current operation. 
     help--Display help screen. 
     close--Close the simulator window. 
     The results of the simulation are displayed within the simulator window. Also the editor window will track the flowchart as it is being simulated. This tracking of the flowchart makes it easy to edit the flowchart when an error is found. 
     Cell Selection 
     The Cell Selector 32 is a knowledge based system for selecting a set of optimum cells from the cell library 34 to implement a VLSI system. The selection is based on functional descriptions in the flowchart, as specified by the macros assigned to each action represented in the flowchart. The cells selected for implementing a VLSI system depend on factors such as cell function, fabrication technology used, power limitations, time delays etc. The cell selector uses a knowledge base extracted from VLSI design experts to make the cell selection. 
     To design a VLSI system from a flowchart description of a user application, it is necessary to match the functions in a flowchart with cells from a cell library. This mapping needs the use of artificial intelligence techniques because the cell selection process is complicated and is done on the basis of a number of design parameters and constraints. The concept used for cell selection is analogous to that used in software compilation. In software compilation a number of subroutines are linked from libraries. In the design of VLSI systems, a functional macro can be mapped to library cell. 
     FIG. 4 illustrates the concept of hierarchical cell selection. The cell selection process is performed in two steps: 
     (1) selection of functional macros 
     (2) selection of geometrical cells 
     A set of basic macros is shown in Table 1. A macro corresponds to an action in the flowchart. As an example, consider the operation of adding A and B and storing the result in C. This function is mapped to the addition macro ADD(X, Y, Z). The flowchart editor and flowchart simulator are used to draw the rectangles, diamonds and lines of the flowchart, to assign a macro selected from the macro library 23 to each action represented in the flowchart, and to verify the functions in flowcharts. The flowchart is converted into an intermediate form (statelist) and input to the Cell Selector. 
     The Cell Selector uses a rule based expert system to select the appropriate cell or cells to perform each action. If the cell library has a number of cells with different geometries for performing the operation specified by the macro, then an appropriate cell can be selected on the basis of factors such as cell function, process technology used, time delay, power consumption, etc. 
     The knowledge base of Cell Selector 32 contains information (rules) relating to: 
     (1) selection of macros 
     (2) merging two macros 
     (3) mapping of macros to cells 
     (4) merging two cells 
     (5) error diagnostics 
     The above information is stored in the knowledge base 35 as rules. 
     Cell List Generation 
     FIG. 9 shows the cell list generation steps. The first step of cell list generation is the transformation of the flowchart description into a structure that can be used by the Cell Selector. This structure is called the statelist. The blocklist is generated from the statelist by the inference engine. The blocklist contains a list of the functional blocks to be used in the integrated circuit. Rules of the following type are applied during this stage. 
     map arguments to data paths 
     map actions to macros 
     connect these blocks 
     Rules also provide for optimization and error diagnostics at this level. 
     The cell selector maps the blocks to cells selected from the cell library 34. It selects an optimum cell for a block. This involves the formulation of rules for selecting appropriate cells from the cell library. Four types of information are stored for each cell. These are: 
     (1) functional level information: description of the cell at the register transfer level. 
     (2) logic level information: description in terms of flip-flops and gates. 
     (3) circuit level information: description at the transistor level. 
     (4) Layout level information: geometrical mask level specification. 
     The attributes of a cell are: 
     cell name 
     description 
     function 
     width 
     height 
     status 
     technology 
     minimum delay 
     typical delay 
     maximum delay 
     power 
     file 
     designer 
     date 
     comment 
     inspector 
     In the cell selection process, the above information can be used. Some parameters that can be used to map macros to cells are: 
     (1) name of macro 
     (2) function to be performed 
     (3) complexity of the chip 
     (4) fabrication technology 
     (5) delay time allowed 
     (6) power consumption 
     (7) bit size of macro data paths 
     Netlist Generation 
     The netlist is generated after the cells have been selected by PSCS. PSCS also uses the macro definitions for connecting the cell terminals to other cells. PSCS uses the state-to-state transition information from an intermediate form representation of a flowchart (i.e. the statelist) to generate a netlist. PSCS contains the following knowledge for netlist generation: 
     (1) Data path synthesis 
     (2) Data path optimization 
     (3) Macro definitions 
     (4) Cell library 
     (5) Error detection and correction 
     The above information is stored in the knowledge base 35 as rules. Knowledge engineers help in the formulation of these rules from ASIC design experts. The macro library 23 and the cell library 34 are stored in a database of KBSC. 
     A number of operations are performed by PSCS. The following is a top level description of PSCS operations: 
     (1) Read the flowchart intermediate file and build a statelist. 
     (2) current --  context=START 
     (3) Start the inference engine and load the current context rules. 
     (4) Perform one of the following operations depending upon current --  context: 
     (a) Modify the statelist for correct implementation. 
     (b) Create blocklist, macrolist and data paths. 
     (c) Optimize blocklist and datapath list and perform error checks. 
     (d) Convert blocks to cells. 
     (e) Optimize cell list and perform error checks. 
     (f) Generate netlist. 
     (g) Optimize netlist and perform error checks and upon completion Goto 7. 
     (5) If current --  context has changed, load new context rules. 
     (6) Goto 4. 
     (7) Output netlist file and stf files and Stop. 
     In the following sections, operations mentioned in step 4 are described. The Rule Language and PSCS display are also described. 
     Rule Language 
     The rule language of PSCS is designed to be declarative and to facilitate rule editing. In order to make the expert understand the structure of the knowledge base, the rule language provides means for knowledge representation. This will enable the format of data structures to be stated in the rule base, which will enable the expert to refer to them and understand the various structures used by the system. For example, the expert can analyze the structure of wire and determine its components. The expert can then refer these components into rules. If a new object has to be defined, then the expert can declare a new structure and modify some existing structure to link to this new structure. In this way, the growth of the data structures can be visualized better by the expert. This in turn helps the designer to update and append rules. 
     The following features are included in the rule language: 
     (i) Knowledge representation in the form of a record structure. 
     (ii) Conditional expressions in the antecedent of a rule. 
     (iii) Facility to create and destroy structure in rule actions. 
     (iv) The assignment statement in the action of a rule. 
     (v) Facility for input and output in rule actions. 
     (vi) Provide facility to invoke C functions from rule actions. 
     The rule format to be used is as follows: 
     
         ______________________________________                                    
The rule format to be used is as follows:                                 
______________________________________                                    
Rule  &lt;number&gt; &lt;context&gt;                                                  
If {                                                                      
      &lt;if-clause&gt;                                                         
Then  {                                                                   
      &lt;then-clause&gt;                                                       
}                                                                         
where &lt;number&gt;         rule number                                        
      &lt;context&gt;        context in which this rule is                      
                       active                                             
      &lt;if-clause&gt;      the condition part of the rule                     
      &lt;then-clause&gt;    the action part of the rule                        
______________________________________                                    
 
    
     Inference Strategy 
     The inference strategy is based on a fast pattern matching algorithm. The rules are stored in a network and the requirement to iterate through the rules is avoided. This speeds up the execution. The conflict resolution strategy to be used is based on the following: 
     (1) The rule containing the most recent data is selected. 
     (2) The rule which has the most complex condition is selected. 
     (3) The rule declared first is selected. 
     Rule Editor 
     PSCS provides an interactive rule editor which enables the expert to update the rule set. The rules are stored in a database so that editing capabilities of the database package can be used for rule editing. To perform this operation the expert needs to be familiar with the various knowledge structures and the inferencing process. If this is not possible, then the help of a knowledge engineer is needed. 
     PSCS provides a menu from which various options can be set. Mechanisms are provided for setting various debugging flags and display options, and for the overall control of PSCS. 
     Facility is provided to save and display the blocklist created by the user. The blocklist configuration created by the user can be saved in a file and later be printed with a plotter. Also the PSCS display can be reset to restart the display process. 
     
         ______________________________________                                    
PSCS Example Rules:                                                       
______________________________________                                    
Rule  1                                                                   
      IF       no blocks exist                                            
      THEN     generate a system controller.                              
Rule  2                                                                   
      IF       a state exists which has a macro AND                       
               this macro has not been mapped to a block                  
      THEN     find a corresponding macro in the library                  
               and generate a block for this macro.                       
Rule  3                                                                   
      IF       there is a transition between two                          
               states AND there are macros in these                       
               states using the same argument                             
      THEN     make a connection from a register                          
               corresponding to the first macro to                        
               another register corresponding to the                      
               second macro.                                              
Rule  4                                                                   
      IF       a register has only a single connection                    
               from another register                                      
      THEN     combine these registers into                               
               a single register.                                         
Rule  5                                                                   
      IF       there are two comparators AND                              
               input data widths are of the same size AND                 
               one input of these is same AND                             
               the outputs of the comparators are used to                 
               perform the same operation.                                
      THEN     combine these comparators into                             
               a single comparator.                                       
Rule  6                                                                   
      IF       there is a data without a register                         
      THEN     allocate a register for this data.                         
Rule  7                                                                   
      IF       all the blocks have been interconnected AND                
               a block has a few terminals not connected                  
      THEN     remove the block and its terminals, or                     
               issue an error message.                                    
Rule  8                                                                   
      IF       memory is to be used, but a block has not                  
               been created for it                                        
      THEN     create a memory block with data,                           
               address, read and write data and                           
               control terminals.                                         
Rule  9                                                                   
      IF       a register has a single connection to                      
               a counter                                                  
      THEN     combine the register and the counter;                      
               remove the register and its terminals.                     
Rule  10                                                                  
      IF       there are connections to a terminal of                     
               a block from many different blocks                         
      THEN     insert a multiplexor;                                      
               remove the connections to the terminals and                
               connect them to the input of the multiplexor;              
               connect the output of the                                  
               multiplexor to the input of the block.                     
______________________________________                                    
 
    
     Additional rules address the following points: 
     remove cell(s) that can be replaced by using the outputs of other cell(s) 
     reduce multiplexor trees 
     use fan-out from the cells, etc. 
     Soft Drink Vending Machine Controller Design Example 
     The following example illustrates how the previously described features of the present invention are employed in the design of an application specific integrated circuit (ASIC). In this illustrative example the ASIC is designed for use as a vending machine controller. The vending machine controller receives a signal each time a coin has been deposited in a coin receiver. The coin value is recorded and when coins totalling the correct amount are received, the controller generates a signal to dispense a soft drink. When coins totalling more than the cost of the soft drink are received, the controller dispenses change in the correct amount. 
     This vending machine controller example is patterned after a textbook example used in teaching digital system controller design. See Fletcher, William I., An Enqineering Approach to Digital Design, Prentice-Hall, Inc., pp. 491-505. Reference may be made to this textbook example for a more complete explanation of this vending machine controller requirements, and for an understanding and appreciation of the complex design procedures prior to the present invention for designing the hardware components for a controller. 
     FIG. 10 illustrates a flowchart for the vending machine controller system. This flowchart would be entered into the KBSC system by the user through the flowchart editor. Briefly reviewing the flowchart, the controller receives a coin present signal when a coin is received in the coin receiver. State0 and cond0 define a waiting state awaiting deposit of a coin. The symbol CP represents &#34;coin present&#34; and the symbol -CP represents &#34;coin not present&#34;. Statel and condI determine when the coin has cleared the coin receiver. At state20, after receipt of a coin, the macro instruction ADD3.1 (lc, cv, sum) instructs the system to add lc (last coin) and cv (coin value) and store the result as sum. The macro instruction associated with state21 moves the value in the register sum to cv. The macro CMP.1 at state22 compares the value of cv with PR (price of soft drink) and returns signals EQ, GT and LT. The condition cond2 tests the result of the compare operation CMP.1. If the result is &#34;not greater than&#34; (-GT.CMP.1), then the condition cond3 tests to see whether the result is &#34;equal&#34; (EQ.CMP.1). If the result is &#34;not equal&#34; (-EQ.CMP.1), then control is returned to state0 awaiting the deposit of another coin. If cond3 is EQ, then state4 generates a control signal to dispense a soft drink (droppop) and the macro instruction CLR.1(cv) resets cv to zero awaiting another customer. 
     If the total coins deposited exceed the price, then state30 produces the action &#34;returncoin&#34;. Additionally, the macro DECR.1 (cv) reduces the value of cv by the amount of the returned coin. At state31 cv and PR are again compared. If cv is still greater than PR, then control passes to state30 for return of another coin. The condition cond5 tests whether the result of CMP.2 is EQ and will result in either dispensing a drink (droppop) true or branching to state0 awaiting deposit of another coin. The macros associated with the states shown in FIG. 10 correspond to those defined in Table 1 above and define the particular actions which are to be performed at the respective states. 
     Appendix A shows the intermediate file or &#34;statelist&#34; produced from the flowchart of FIG. 10. This statelist is produced as output from the EDSIM program 20 and is used as input to the PSCS program 30 (FIG. 3). 
     FIG. 11 illustrates for each of the macros used in the flowchart of FIG. 10, the corresponding hardware blocks. It will be seen that the comparison macro CMP (A,B) results in the generation of a register for storing value A, a register for storing value B, and a comparator block and also produces control paths to the system controller for the EQ, LT, and GT signals generated as a result of the comparison operation. The addition macro ADD (A,B,C) results in the generation of a register for each of the input values A and B, a register for the output value C, and in the generation of an adder block. The macro DECR (A) results in the generation of a counter block. The PSCS program 30 maps each of the macros used in the flowchart of FIG. 10 to the corresponding hardware components results in the generation of the hardware blocks shown in FIG. 12. In generating the illustrated blocks, the PSCS program 30 relied upon rules 1 and 2 of the above listed example rules. 
     FIG. 13 illustrates the interconnection of the block of FIG. 12 with data paths and control paths. Rule 3 was used by the data/control path synthesizer program 31 in mapping the data and control paths. 
     FIG. 14 shows the result of optimizing the circuit by applying rule 4 to eliminate redundant registers. As a result of application of this rule, the registers R2, R3, R7, R8, and R9 in FIG. 13 were removed. FIG. 15 shows the block diagram after further optimization in which redundant comparators are consolidated. This optimization is achieved in the PSCS program 30 by application of rule 5. 
     Having now defined the system controller block, the other necessary hardware blocks and the data and control paths for the integrated circuit, the PSCS program 30 now generates a netlist 15 defining these hardware components and their interconnection requirements. From this netlist the mask data for producing the integrated circuit can be directly produced using available VLSI CAD tools. 
     
         ______________________________________                                    
name rpop;                                                                
data path @ic&lt;0:5&gt;, cv&lt;0:5&gt;, sum&lt;0:5&gt;, @pr&lt;0:5&gt;;                          
state4 : state0;                                                          
state30 : state31;                                                        
state21 : state22;                                                        
state20 : state21;                                                        
state0 :. !cp state0;                                                     
state0 :. cp state1;                                                      
state1 :. cp state1;                                                      
state1 :. !cp state20;                                                    
state22 :. GT.CMP.1 state30;                                              
state22 :. !GT.CMP.1*EQ.CMP.1 state4;                                     
state22 :. !GT.CMP.1*!EQ.CMP.1 state0;                                    
state31 :. GT.CMP.2 state30;                                              
state31 :. !GT.CMP.2*EQ.CMP.2 state4;                                     
state31 :. !GT.CMP.2*!EQ.CMP.2 state0;                                    
state30 :: returncoin;                                                    
state30 :: DECR.1(cv);                                                    
state4 :: droppop;                                                        
state4 :: CLR.1(cv);                                                      
state31 :: CMP.2(cv,pr);                                                  
state22 :: CMP.1(cv,pr);                                                  
state21 :: MOVE.1(sum,cv);                                                
state20 :: ADD3.1(ic,cv,sum);                                             
}                                                                         
______________________________________