Parallel Machine Architecture for Production Rule Systems

The Expert System, or Production Rule System, is one of the most important products of recent Artificial Intelligence research Capable of emulating and at times transcending the behavior of human experts in practically any domain, Expert System programs are proving their worth in such diverse areas as medical diagnosis, mineral prospecting, diesel locomotive repair, computer design, organic chemical synthesis, and a host of others. The earliest of such systems, and most of the presently popular ones, have been characterized by a sufficient naivete of knowledge representation that conventional computer architectures were adequate for their execution. With each new insight into the mechanisms of capturing ever more of the complexity and cognitive depth of the human's reasoning processes, such architectures are proving increasingly inadequate if anything approaching real-time speeds of execution are required.

One of the best known Expert System languages is Carnegie Mellon's OPS. This language facilitates approaches to problem solving and knowledge representation and has considerable power. An unfortunate additional characteristic of many OPS systems, particularly those of any real cognitive complexity, is an abysmally low speed of execution on present computers. For example, in complex organic synthesis programs some runs consumed 30 hours of single-user VAX 11/780 time during which approximately 5000 rule firings occurred. The average rule firing rate of 3 per minute is atypically low for Expert Systems, but is representative of figures to be expected for the more complex Expert System programs now being written. It is generally believed that, for effective execution of this next generation of programs, a figure of 1000 firings per second will be required.

In general, the classical hardware approaches to achieving the speed enhancements which the above figures imply have involved the construction of large scale, generalized parallel processing systems (e.g., the CRAY and CYBER), or relatively small serial processors dedicated to the execution of a particular language (e.g., the various LISP machines). For most purposes, the CRAY class machines are far too expensive and, in any case, were they suited to the execution of OPS-like languages, could offer a speed advantage of at best a factor of about 200 with respect to a VAX. A LISP machine, although far less expensive, is not more than a factor of four to eight faster than a VAX, despite the fact that it executes the LISP language in which OPS is written.

On the software side, a popular matching algorithm is the Rete Match Algorithm (see the Forgy and Shepard reference cited below) which exploits common IF parts of production rules and processes these patterns before the system is interpreted. However, this algorithm assumes that few working memory elements change during each cycle (much less than 1%) and is not useful where significant fractions of the working memory elements change in each cycle.

The references listed below teach various types of expert systems and are representative of present day approaches to parallelism for achieving faster execution time. These references are representative of the background of the invention and are incorporated herein by reference.

P. M. Dew "VLSI Architectures For Problems In Numerical Computation", Supercomputers and parallel computation edited by D. J. Paddon, 1984.

Charles L. Forgy and Susan I. Shepard, "Rete: A Fast Matching Algorithm", AI Expert, January 1987.

Dan Neiman, "Adding the Rete Net to your OPS5 Toolbox", AI Expert, January 1987.

Robert J. Douglass, "A Qualitative Assessment of Parallelism in Expert Systems", IEEE Software, May 1985.

Beverly A. Thompson et al, "Inside An Expert System", BYTE, April 1985.

Charles L. Seitz, "The Cosmic Cube", Communications of the ACM, January 1985.

J. R. Gurd et al, "The Manchester Prototype Dataflow Computer", Communications of the ACM, January 1985.

William M. Raike, "The Fifth Generation in Japan", BYTE, April 1985.

Michael F. Deering, "Architectures for AI", BYTE, April 1985.

Robert H. Michaelsen et al, "The Technology of Expert Systems", BYTE, April 1985.

Patrick H. Winston, "The LISP Revolution", BYTE, April 1985.

Charles Forgy et al, "Initial Assessment of Architectures for Production Systems", Proceedings of the American Association of Artificial Intelligence, pp. 116-112, August 1984.

J. H. Griesmer et al, "WES/MVS: A Continuous Real Time Expert System", Proceedings of the American Association of Artificial Intelligence, pp. 130-136, August 1984.

Salvatore J. Stolfo, "Five Parallel Algorithms for Production System Execution On the Dado Machine", Proceedings of the American Association of Artificial Intelligence, pp. 300-307, August 1984.

An object of the invention is to provide a system for executing programs associated with Artificial Intelligence.

Another object of the invention is to provide a high speed computer architecture capable of executing large and complex OPS and OPS-like Production Rule programs at speeds several thousand times faster than those characterizing present machine architectures.

Yet another object of the invention is to speed up rule firings in a production rule system by utilizing a plurality of identical, independently and simultaneously functioning rule processors.

A further object of the invention is to provide a production rule system in which additional rule processors may easily and simply be incorporated into the system.

Yet another object of the invention is to provide a production rule system which operates efficiently on complex problems and does not rely on the Rete Matching Algorithm or any assumption that the number of working memory elements changing with each rule firing is necessarily small. Although the Rete Matching Algorithm may be used in the system of the present invention, the invention does not require it and its use is marginal in cases where large numbers of working memory elements change with each rule firing, or where there is little similarity among rules.

The invention is directed toward a parallel processing system for processing production rule programs having a plurality of rules wherein each rule includes at least one non-negated "if" condition left hand side and at least one "then" action right hand side. The system comprises a data bus, an address bus, a host processor and a plurality of rule processors. The host processor is connected to the data and address bus and executes the right hand sides of the rules. The plurality of rule processors are each connected to the data and address buses and each include a memory storage device having a data memory section storing data and a program memory section storing the at least one left hand side of at least one of the rules. The memory storage device has storage locations designated by address. Each rule processor operates for evaluating the at least one stored left hand side of the at least one rule and generates an associated match flag if all conditions specified in the stored at least one left hand side are satisfied by at least one combination of stored data. The host processor is responsive to the match flags from each of the rule processors for selecting one of the rules and executing the actions of the at least one right hand side of the selected rule for generating commands and associated data. The host processor is operative for transmitting the commands and associated data to all rule processors. Each of the rule processors receives the commands of associated data and selects ones of the commands in associated data for which the associated data is identified in at least one stored left hand side of the rule and changes the stored data in accordance with the selected one of the commands and associated data

FIG. 1 is a block diagram of a first embodiment of the invention;

FIG. 2 is a representation of a network memory map;

FIG. 3 is a timing chart showing the host/rule processor handshaking protocol;

FIG. 4 is a block diagram of another embodiment of the invention;

FIG. 5 is a block diagram of the interface board of FIG. 4;

FIG. 6 is a block diagram of the rule processor board control logic of FIG. 4;

FIG. 7 is a block diagram of the rule processor cell circuitry;

FIG. 8A is a diagram of the address multiplexer of FIG. 7, and FIG. 8B is a corresponding address/pin table;

FIGS. 9A-9C set forth the cell board layout;

FIG. 10 is a block diagram of major portions of the cell control logic circuit of FIG. 7;

FIG. 11 is a schematic diagram of the local memory control logic of FIG. 10;

FIG. 12 is a schematic diagram of the interrupt control logic of FIG. 10;

FIG. 13 is a schematic diagram of the arbitration control logic of FIG. 10;

FIG. 14 is a schematic diagram of the cell disable logic of FIG. 10;

FIGS. 15-17 are timing graphs for the rule processors;

FIGS. 18 and 19 are ROM tables;

FIG. 20 illustrates the top board circuitry of FIG. 9A;

FIGS. 21-27 illustrate circuit details of the board control/logic of FIG. 9C;

FIG. 28 is a block diagram of the rule processor memory control circuit of FIG. 5;

FIG. 29 is a graph of the refresh request and acknowledge signals;

FIG. 30 is a schematic diagram of the board clock circuit of FIG. 28;

FIG. 31 is a schematic diagram of the board reset logic circuit;

FIG. 32 is a schematic diagram of the reset port;

FIG. 33 is a schematic diagram of the board select logic circuit;

FIG. 34 sets forth the board select equations;

FIG. 35 is the board select ROM table;

FIG. 36 is a schematic diagram of the I/O decode logic;

FIG. 37 is a schematic diagram of the interrupt port;

FIG. 38 is a schematic diagram of the refresh programmable interval timer;

FIG. 39 is a schematic diagram of the refresh control circuit of FIG. 28;

FIG. 40 is a refresh ROM table;

FIG. 41 is a state machine diagram;

FIG. 42 is a schematic diagram of the arbitration control circuit of FIG. 28;

FIG. 43 is the arbitration ROM table;

FIG. 44 is a schematic diagram of the memory ready control circuit of FIG. 28;

FIG. 45 is the memory ready ROM table;

FIG. 46 is a schematic diagram of the timing control circuit of FIG. 28;

FIGS. 47 and 48 are graphs of the memory timing for a host access and a refresh access respectively;

FIG. 49 is a schematic diagram of the open collector interface bus lines;

FIG. 50 is a schematic diagram of the transfer acknowledge logics;

FIG. 51 is a transfer acknowledge ROM table;

FIG. 52 is a block representation of a message format for a make command;

FIG. 53 is a block representation of a message format for a REMOVE command;

FIGS. 54A and 54B illustrate the memory organization for the host and rule processors respectively;

FIG. 55 illustrates the handle organization for the memory management;

FIGS. 56 and 57 set forth vector tables for the rule processor reset and interrupt respectively;

FIG. 58 sets forth a table for the rule processor server command;

FIGS. 59 and 60 are tables for the rule processor stream code;

FIGS. 61-64 are flow charts for the interrupt-stream codes;

FIG. 65 illustrates the filter code organization for an illustrative example;

FIG. 66 sets forth the working memory organization of the illustrative example;

FIG. 67 gives the left hand side (LHS) list for the illustrative examples;

FIG. 68 sets forth the counter operation for the illustrative examples;

FIG. 69 illustrates the fireable and nonfireable list for the illustrative example.

A general discussion of production rule system with particular emphasis on the OPS5 programming language may be found in L. Brownston et al., Programming Expert Systems in OPS5--An Introduction to Rule-Based Programing, Addison-Wesley, 1986. Reference may also be made to the OPS5e User's Manual, Veraz Incorporated, San Diego, 1983, both of which references are incorporated herein by reference.

The OPS language is defined in terms of the following elements and certain relations among and operations on them:

1. The left and right parentheses; ()

2. The up arrow;

3. The right arrow; .fwdarw.

4. The left and right curly brackets; { }

5. The left and right angle brackets; < >

6. The left and right double angle brackets; << >>

7. The reserved words; "literalize", "make", "p", "write", "cbind", "modify", "remove", "bind",

8. Any character string or numeric representation

One can construct Expert System programs from these elements which embody to a surprising degree the human expertise of practically any domain and which exhibit behavior often transcending in competence that of the human.

Central to an appreciation of the OPS language is an understanding of the OPS Recognize-Act Cycle (RAC). OPS is fundamentally a pattern processing scheme. The elements of the patterns with which OPS deals are the attribute-value pairs. These are entities formally associated with some concept or idea. The first member of the pair, the attribute label, defines the meaning of the value entry which immediately follows. In general, the meanings of the attribute-value pairs are specific to the domain of the production rule system in which they occur. Example (I), taken from a system designed to perform organic chemical synthesis, illustrates the formal procedure by which association of attributes with a "concept" (here "compound-structure") is made.

(literalize C-S; compound-structure

FID; fragment-id

A-N; atom-number

A-T; atom-type

B-A-N; bonded-atom-number

B-A-T; bonded-atom-type

B-T); bond-type

From the attribute-value pairs are constructed the simplest pattern representations, the so-called working memory elements. These form the data structures of the production rule system (or, the system's representation of the "world"), and are stored in working memory. An example of such a pattern is the following, again from the organic chemical synthesis system. For the indicated working memory element, the concept with which the attribute-value pairs are associated is denoted by the symbol, "C-S". This working memory element represents, for a fragment numbered 13, the connection between one atom (carbon atom number 7) and another (oxygen atom number 3) by a double bond (d):

(C-S FID--A-N 7 A-T C B-A-N 3 B-A-T O B-T d).

Any organic molecule, or portion thereof, (neglecting, for the purposes of illustration, such details as stereo-chemistry, hydrogen bonding, and the like) can be represented by collections of working memory elements (i.e., by patterns of patterns) of this type which in effect define the molecule's inter-atomic connectivity.

It is the function of the Recognize part of the Recognize-Act Cycle (hereinafter RAC) to "recognize" those patterns (those combinations of working memory elements) which have specified meanings or relevance in the domain of the production rule system in which they occur. The Production Rule is the mechanism through which this meaning or relevance is defined. In its fundamental form, a Production Rule (hereinafter PR) is an IF.fwdarw.THEN statement. The IF part represents some set of conditions which must obtain (i.e., which must be recognized) among a subset of working memory elements (hereinafter WMEs) if the PR is to be found applicable. The THEN part comprises a set of actions which will be executed if the PR is in fact applied and constitutes the ACT part of the RAC. In general, these actions fall into two broad classes, those which affect in some way some or all of the WMEs to which the PR has responded, and those which add new WMEs to the working memory. In OPS nomenclature, a PR is represented as follows:

The following PR (again, from the organic chemical synthesis program) illustrates the recognition o a combination of WMEs representing a specific molecular configuration (methoxy) and the actions which are to be taken upon that recognition.

Translated literally into English, the IF part of the rule becomes: IF in working memory there can be found WMEs as follows:

(1) One representing an active goal to find a target-site in some fragment (denoted by the variable, <fid>)

(2) One representing a portion of a compound-structure (c-s) of the same fragment <fid>whose atom type (a-t) is carbon (c), whose atom number (a-n) has some value (denoted by the variable <an1>), bonded to the bonded atom type (b-a-t) oxygen (o) whose atom number (b-a-n) has a value denoted by the variable <an2>) by a bond which is of bond type (b-t) single (s)

(3) One representing a portion of a compound-structure (c-s) of the same fragment <fid> whose atom type is carbon (c), whose atom number (<an1>) is the same as that defined by (2), bonded to a hydrogen (h) atom whose number is <an3> by a single (s) bond

(4) One representing a portion of a compound-structure (c-s) of the same fragment <fid> whose atom type is carbon (c), whose atom number (<an1>) is the same as that defined by (2), bonded to a hydrogen (h) atom whose number is <an4> and greater (>) than <an3>, by a single (s) bond

(5) One representing a portion of a compound-structure (c-s) of the same fragment <fid> whose atom type is carbon (c), whose atom number (<an1>) is the same as that defined by (2), bonded to a hydrogen (h) atom whose number is <an5> and greater (>) than <an4>, by a single (s) bond.

Or, more simply, can there be found a carbon atom bonded to an oxygen atom by a single bond and by single bonds to three distinct hydrogen atoms. IF these conditions are met, THEN, perform the following actions:

(1) For the remainder of the rule, associate with the variable <type> the word methoxy

(2) For the remainder of the rule, associate with the variable <tid> a unique number generated by the LISP function "tgint"

(3) Write the message on the user's terminal: "found target site methoxy"

(4) Make a new target-site WME of the indicated form in which the current values for the variables, <fid>, <tid>, and <type> are inserted

(5) Make a new alter-bond WME of the indicated form in which the current values for the variables, <fid>, <tid>, <an1>, and <an2> are inserted

(6) For the remainder of the rule, associate with the variable <aa1> a unique number generated by the LISP function "agint"

(7) For the remainder of the rule, associate with the variable <aa2> a unique number generated by the LISP function "agint"

(8) Make a new add-atom WME of the indicated form in which the current values for the variables, <fid>, <tid>, <aa1>, and <an1> are inserted

(9) Make a new add-atom WME of the indicated form in which the current values for the variables, <fid>, <tid>, <aa2>, and <an2> are inserted.

More simply, notify the user that the methoxy target site has been found and make working memory elements, to which other rules will subsequently respond, indicating the nature of those chemical modifications dictated by the finding of the methoxy target site.

A production rule program of any substance comprises a collection of a large number (frequently thousands) of (often very complex) PRs of the general form illustrated in Example (III) above and a (generally much) larger number of WMEs. The WMEs may be regarded as constituting a dynamic pool of relational and factual information above which, and always scrutinizing it for matched patterns, reside the PRs. It is in the mechanisms underlying the processes of searching for matched patterns and performing the resulting operations on the contents of working memory (i.e., in the execution of the RAC) that inherent, but untapped, parallelism is found. These mechanisms are described in the following paragraphs.

As might be imagined, the mechanisms associated with the RAC fall into two broad categories, those which support the Recognize part and those which support the Act part. The Act part is conceptually simple and computationally economical and involves the execution of the operations defined by the right-hand-side action specifications of whatever rule the system selects for application (or, as it is generally referred to, for "firing"). The most important of these operations are those which make new WMEs, and those which modify or remove WMEs referenced in the left-hand-side of the selected rule.

It is the recognize part of the RAC which is by far the more conceptually and computationally difficult. In a naive view, it can be represented as a search over the entire contents of working memory for those sets of WMEs which self consistently satisfy the left-hand-side condition specifications of one or more of the system rules. If no such set can be found, the system halts. If only one set for only one rule is found, that one rule is applied and its right-hand-side actions executed. If two or more sets are found for one rule, or if sets can be found for more than one rule, a conflict-resolution operation is performed and the most "appropriate" set, or rule and set, selected for application. It is necessary merely to recall that a contemporary production rule system may consist of a thousand or more rules, each of several tens of left-hand-side condition specifications, each of these comprising several tens of attribute-value pairs, to appreciate the complexity of a search which must in effect compare all rules with the contents of a working memory which may contain several thousand WMEs!

OPS avoids the necessity of performing a complete search over working memory, a search which otherwise would have to be performed once per Recognize-Act Cycle, by constructing a network representation of the relations among the PRs. This network, in effect, links each left-hand side condition specification of each rule in the system with the right-hand sides of all rules whose actions could (as a result of their operations on the contents of working memory) in any way affect the potential response of the linked rule. Note that, since the information required for the construction of this network is inherent in the forms of the rules themselves, the network can be constructed once and need be altered only if new rules are added to the system, either by the user or by the executing PR system.

The two steps of (V) below define the formal construction of the network described above. The nine steps of (VI) provide a formal definition of the operation of the RAC in terms of the network.

(1) Associate with every left-hand-side condition specification of every rule an empty list.

(2) Create a network link between each of these lists and every right-hand-side whose literal form is congruent with the literal form of the associated left-hand-side condition specification over the full specification of that left-hand-side.

N.B. By literal form is meant the non-variable part of a left- or right-hand-side.

(1) If a rule can fire, evaluate in turn its right-hand-sides.

(2) For each right-hand-side which involves making a new WME, generate a unique number, assign it to the newly constructed WME, and send that number, suitably tagged with a reference indicating "make", over the network branches emanating from the right-hand-side to the lists of (V-1) above. Store the new WME itself in working-memory together with its unique numerical reference.

(3) For each right-hand-side which involves removing a WME, retrieve the unique numerical reference to the WME, send that number, suitably tagged with a reference indicating "remove", over the network branches emanating from the right-hand-side to the lists of (V-1) above. Remove the reference WME from working-memory and the references to it from those lists on which it appears.

(4) For each right-hand-side which involves modifying a WME, note that "modify" is a combination of the operations "remove" and "make" and perform the operations of (3) and (2) above.

(5) When all right-hand-sides have been executed and all network transmission completed, examine in turn (by rule) the lists of (V1) above to determine if, for one or more rules, there is at least one entry for the list associated with each non-negated left-hand-side of the rule under examination. Ignore as inapplicable those rules for which this condition is not met.

(6) For each rule for which the above stated condition is satisfied, retrieve from working memory those WMEs whose unique numerical references appear on the lists and examine these in turn (by rule) to determine if a set or sets can be found which self consistently satisfy the rule.

(7) If no such subset can be found, no rule can fire and the system halts.

(8) If one such subset can be found for one, and only one, rule, select that rule for application and return to (VI-1).

(9) If two or more subsets can be found for one rule, or if subsets can be found for two or more rules, perform the conflict resolution operation to select the most "appropriate" set under the current conflict resolution strategy, or rule and set, for application then return to (VI-1).

The discussion above has been a general one directed toward those aspects of pattern processing (network construction, the recognize-act-cycle) which would by definition underlie any OPS-like production rule system. It is important to remember in all that follows that no use whatsoever is made of the RETE pattern matcher which is central to other implementations of OPS. Although not well known within the broad area of computer science, these features are common currency in the AI community. In accordance with the teachings of the invention, hardware methods and apparatus are disclosed for exploiting to considerable advantage the parallelism which is inherent in several components of OPS-like production rule languages.

Parallelism is inherent in several aspects of the RAC above described. Of principal importance are those associated with the network transmission aspects of Example VI, (2), (3), and (4), and the left-hand-side operations of (5) and (6). The network aspects are discussed in the following three paragraphs.

It is important to recall that in a computer characterized by a conventional architecture (i.e., one capable only of serial execution of its instruction set), the operations required to notify all rules affected by the evaluation of a single right-hand-side action can be performed only on a one at a time basis. Although, in effect, the right-hand-side sends a signal over the network to each affected left-hand-side, in reality, a set of instructions is executed. The instructions comprising this set are executed as many times as there are network branches leading from the given right-hand-side. The number of sendings (or transmissions) may in principle equal the sum of all the left-hand-side condition specifications in the rule set, although it will generally be smaller than this.

In the new architecture, the network, which in a conventional computer can be represented only as a set of program instructions, is physically implemented as a collection of wires constituting a bus (hereinafter, the network bus) and a series of independently functioning network decoders which reside in parallel on the network bus. In practice, the network decoders are integral parts of the rule processors (RPs) which perform the operations associated with (5) and (6) above and are implemented, for example, by a microprocessor associated with one or more rules. For the moment, however, it is useful to consider the decoders as separate entities. At the "transmitting" end of the network bus is a single host processor whose function is to place on the network bus the information which results from the evaluation (in turn) of the right-hand-side actions of a rule which has been selected for firing. It is the function of each network decoder to identify and copy signals appearing on the network bus which are relevant to one or more of the left-hand-side condition specifications of the rule (or rules) with which the decoder is associated. Since the network decoders function independently and simultaneously, a given network transmission need be made only once; it is received in parallel by all network-linked left-hand-side condition specifications.

Example (VII) below illustrates the general format of the "messages" which the host transmits over the network bus.

(rule-number, right-hand-side-action-number, action-type, WME-reference-number, body-of-WME)

Rule-number refers to the system assigned number of the rule which has been selected for firing and whose resultant the network message represents. Right-hand-side-action-number refers to the specific right-hand-side action whose evaluation has resulted in the sending of the message. (In practice, it is possible to utilize a single identifier combining the rule number and right-hand-side-action-number.

Action-type refers to make, modify, or remove. The WME-reference-number is the unique number previously assigned by the system to an extant WME if the R-H-S action is "remove", or newly assigned to one which is the result of the specific right-hand-side actions "make" or "modify". Body-of-WME is the WME itself if action-type is "make" or "modify". This message slot is blank if action-type is remove.

The parallelism inherent in the left-hand-side operations VI,5 and VI,6 arises from the fact that each PR is a local entity. That is, each PR embodies a complete definition of the state of the world (i.e., the set of left-hand-side condition specifications) which must obtain if it is to be applicable, together with a complete specification of the operations (i.e., the right-hand-side action specifications) which are to be performed on the world (i.e., on the contents of working memory) if the rule is in fact applied. The network operations described in the preceding three paragraphs provide for the kind of bookkeeping (via the lists of V-1 above) which supports the inherent locality by permitting each PR to refer precisely to that portion, and only that portion, of the world to which it might be applied.

In order to take full advantage of the inherent parallelism described above, a rule processor, RP, is associated with each rule. (In practice, it is possible to associate one rule processor with several rules without severely limiting the performance of the overall system. In the implementation described herein by way of example, the rule processors are single chip microcomputers. Associated with each rule processor is a small amount of local memory (approximately 0.5 megabyte) in which are stored those WMEs (or the relevant parts thereof) which the associated rule decoder has, to the moment, recognized as being pertinent to the associated rule (or rules). It is this association of local memory with rule processor which makes it possible for all rule processors to execute the processes of (VI-5) and (VI-6) simultaneously on the contents of the local working memories.

Together with the rule processors and the network bus, four more components complete the system. The first of these is a small, conventional (i.e., serial processing) host processor with its associated global memory. It is in this global memory that the complete set of WMEs is stored, as well as the set of right-hand-side definitions for all the system PRs. Note that no rule processor need ever have access to the host's global memory.

The second of the four components is a single-wire ("open collector"), "processing complete" bus which serves to notify the host when all left-hand-side processing is complete. The third is a "potentially fireable" flag bus via which the host can ascertain which, if any, of the system rules is (are) satisfied (and thereby, fireable). The potentially fireable bus is a conceptual construct and need not be a distinct physical device. Its functions can be supported without temporal conflict by the network bus over which the host processor polls the individual rule processors when all left-hand-side processing is complete. The last component is an I/O device via which the user interacts with the system. The I/O device may, for example, be a CRT with graphics capability.

The remainder of this section is devoted to a description of the operation of a generalized hardware realization of the ideas presented thus far. Reference is made to the simple Conceptual Schematic of FIG. 1.

One of the difficulties in describing the behavior of any cyclical function is the choosing of a point within the cycle at which to begin the description. For the present purpose, it is convenient to enter the cycle just after the operations associated with the recognize part of the RAC have been completed and to close the descriptive circle with a discussion of how the next recognize operation is performed. Thus, we being with the firing of a selected rule and the execution by the host processor of the right-hand-side actions associated with it.

Send a token over the network indicating that a rule firing is to commence.

The leading left parenthesis may be used as a token indicating the beginning of a specific network message. Other indications of the system state may, of course, also be used.

1. Evaluate each right-hand-side action specification;

If the action is make, generate a WME of the specific form, transmit it, per the syntax of Example (VII), over the network bus, and write a copy of it in the host's global memory.

If the action is remove, transmit a message, per the syntax of Example (VII), so indicating and delete the referenced WME from the global memory of the host's global memory.

If the action is modify, perform the above two operations, the make first, followed by the remove.

The trailing right parenthesis will be used as a token indicating the end of a specific network message.

2. Each of the network decoders makes a temporary copy of the message. Alternatively, as in the specific embodiment described later, the message is directly written into each rule processor memory. Upon detection of an "end of message" token, each network decoder (which, it should be recalled, is only in a formal sense distinct from its associated rule processor) compares the leading two entries in the message (i.e., the fired rule number, and the right-hand-side action number) with the contents of a pointer-directed look-up table in which are stored references to those rule/right-hand-side pairs of potential utility to the associated rule. If the decoder determines that the message is relevant, the copy is retained for further processing. If not, the copy is deleted.

It is in terms of the aforementioned pointer-directed look-up tables that the network representation is encoded in the new architecture. It is important to note that this approach is, in principle, distinct from that used in conventional software implementations of OPS-like languages which utilize the RETE pattern matcher.

If more right-hand-side actions remain to be executed for the selected rule, return to (1). Otherwise, send a token over the network indicating that the actions associated with the firing of the selected rule are complete.

As each rule processor completes the tasks associated with the evaluation of the left-hand-side condition specifications for the rule (or rules) which it encodes, it releases its connection to the single wire (open-collector) completion bus. When all rule processors have released their connections to this bus, the host processor detects the resulting change of bus state and initiates the process polling the potentially fireable flags in order to determine which, if any, of the newly processed rules may now be fireable. The following conditions may obtain following rule processing:

(a) No rule is found to be satisfied.

(b) One, and only one, rule is satisfied by one, and only one, subset of WMEs.

(c) One and only one, rule is satisfied. Two or more subsets of WMEs are found which satisfy the rule.

(d) Two or more rules are satisfied, each for one or more subsets of WMEs.

The hose processor responds to these conditions as follows:

If condition (a) obtains, HALT the system.

If condition (b) obtains, return to (A) with the single rule as the selected rule.

If conditions (c) or (d) obtain, perform a conflict resolution operation to determine the "most appropriate" of the applicable rule-WME set combinations. Return to (A).

Note that the responses to conditions (b) through (d) bring the system to the point in the RAC at which the descriptive cycle began.

Discussed herein are some of the important hardware aspects of the invention which pertain specifically to the exemplary embodiment, in which the individual rule processors are Motorola 68000 single chip computers.

(A) Parallel Network mapped into the Host address space: By decoding the host address space properly, the network transmissions by the host to the rule processors become write operations to specific portions of the host's own (apparent) memory ("apparent" because the memory does not actually reside in the host but is distributed among the rule processors). The principal advantages of this approach include an increase in network transmission speed and a reduction in the complexity of the hardware on both the host and rule processor ends of the network. Once the RPs are started, they process asynchronously and halt independently of one another.

(B) Individual access to the Rule Processors by the Host: As suggested in (A) above, the host memory can be represented as a write-only "network" section of the (apparent) host memory, a section all processors share in common. A second section is set aside for those host-processor communications which are not shared. This section is to be sub-divided into a number of portions equal to the number of rule processors. Through each of these, the associated rule processor can be treated as an extension of a specific portion of the host's memory address space, a portion we refer to as the "processor window address space", or, more simply, as the "window." It is through this window that the host loads individual rule processors with the rules which have been assigned to them. The host utilizes the window for other functions as well, principal among these being the scanning for set, or raised, potentially ready to fire flags. It is worth noting that, since the host can have access to all of a processor's memory in this way, any number of new flags which may prove useful in future versions of the architecture can be simply implemented in software.

(C) RP CPU's HALT line as the Completion Flag: In the described implementation, the local 68000 HALT line, suitably buffered, becomes the "wired-or'ed" completion flag. This approach yields a simple mechanism for producing a single bit output for the completion flag. It supports as well the current network transmission scheme, under which all processors are halted during a network transmission and remain so until the transmission is complete (see A, above).

(D) Simple Host to RP CPU Arbitration Circuit: Although there are many rule processors, the arbitration circuitry associated with a given one of these is concerned only with arbitration involving the host and that processor. Thus, arbitration takes place in parallel both for network transfers and for the operations associated with global memory refresh.

(E) No ROM within the Rule Processor Cells: Because the Host can access and reset the rule processors individually, there need be no "boot ROM", address decoding, or ROM wait state generation circuitry within the Rule Processor cells.

(F) Rule Processor Request Line: A single, open-collector, request line is provided via which an individual rule processor can initiate a request for an action by the host. Perhaps the most important of these actions would be the reallocation of a rule for which a processor no longer had sufficient free memory. The host responds to a request to move the rule and working memory elements associated with it by copying rule and memory from the overloaded processor memory into the memory space of a less occupied processor. Because the copying can be effected at great speed, overall processing speed scarcely suffers. Another important application for the request line arise in connection with diagnostic support and error detection.

(G) Minimization of Rule Processor Circuitry: In any large system constructed by replication of a fundamental cell, it is vital to reduce to an absolute minimum the complexity and part count of the cell. Not only does the reduction result in lower costs, it generally leads to lower heat dissipation and greater reliability. It has proved possible to effect a considerable simplification in the fundamental cell (the RP) circuitry of the new architecture by moving many common circuit elements out of the cells and onto the only singular circuit board in the system. This board, the interface board, includes circuitry for memory refresh, address decoding, and host memory control.

Although the invention may be implemented with any appropriate hardware now known or later developed, the preferred embodiments described herein make use of currently available technology, in particular the Motorola 68000 microprocessor technology, and familiarity with same is assumed by those skilled in the art. Reference may thus be made to the following publications incorporated herein by reference.

Motorola MC68000 User's Manual, Second Edition

Motorola MC68000 Advance Information, April 1983

Motorola MC680l0 Advance Information, August 1983

Motorola MC68000 Family Speaker's Guide

Motorola Ap-Note AN-867

A High Performance MC68000L 12 System With No Wait States

Motorola AP-Note AN-881

Dual-Ported RAM for the MC68000 Microprocessor

Motorola Ap-Note AN-897

MC68008 Minimum Configuration System

Motorola Ap-Note AN-887

Dynamic Memory Refresh Considerations

Texas Instruments 1982 MOS Memory Data Book

TMS 4164 Dynamic RAM data sheet

Fujitsu 1984 Memory Data Book

MB8264A-15W 64K.times.1 memory data sheet

MB81256-15 246K.times.1 memory data sheet

Motorola MCM6257 256K.times.1 memory product preview

Texas Instruments TTL Data Book, Second Edition

In a first embodiment of the invention as illustrated in FIG. 1, the network concept for the OPS language involves the use of a single host processor 4 and a plurality of rule processors (RPs) 6a, 6b . . . 6n. The host processor is understood to include a CPU, ROM, RAM and either to include or be connected to a display, keyboard, disk controller and other peripherals as will be evident to one of skill in the art. The host sends information over a network bus 8 for reception by all rule processors. The plurality of rule processors may be referred to as a network 10. (More generally, the term network is used to indicate the RHS to LHS mapping which is made possible by the host/RP configuration of the system.) Each rule processor contains a CPU and RAM but need not contain ROM memory as the host 4 effects the loading of all necessary boot and operating system software. Each rule processor is responsible for a different rule or set of rules. During execution, after the rule processors receive information, they independently process the information (in parallel) until all are finished. Thus, the system is much faster than a single processor system. Each rule processor halts itself when its processing is completed. A complete ("comp") status signal is provided by each rule processor when its processing of rules is completed. Further, if a set of WMEs is found to self-consistently satisfy the LHS of a rule, the rule processor associated with that rule raises a "match" flag at a predetermined memory location. The halt pins on the 68000 processors are buffered and wired-OR'ed together to provide a composite completion signal on line 12. The host processor 4 waits until all rule processors 6 have finished before taking the next action.

From the system shown in FIG. 1, come two important points for the hardware implementation. First, the rule processors only listen to the network bus 8 and need not transmit data over the network bus 8. Thus, the host processor 4 is the only master W/R to the network bus. Further, the rule processors 6 are not required to be able to communicate with each other. These two points make the host-to-rule processor communication much less complicated than a general purpose multiprocessor system in which every processor must be able to communicate with every other processor or with at least some subset of "nearest neighbors". Also, since the rule processors are not connected with each other, there is no communication penalty as the number of rule processors is increased.

In the embodiment described herein, the system is configured for 128 rule processors and the system is described in detail assuming that 16 rule processors are utilized. For small OPS production systems, each rule processor would process one rule. However, the system is not limited to a production system of 128 rules or fewer. Several rules can be placed in each rule processor for large production systems. This may result in some speed reduction depending on which rules are placed together, but the system will still have 128 processors working in parallel. Further, the invention is applicable to systems with fewer or more processors as may be optimum for the production system of concern.

All rule processors should ideally be identical for both hardware and software considerations. Also it is desirable to have the rule processors 6 be of the same type as the host processor 4. Although this identity is not necessary, it is an important consideration in the coding and debugging of software in the rule processors. In the embodiment described herein the Motorola MC68000 16/32 bit microprocessor is utilized for the host and rule processors. Other types of microprocessors of greater or lesser processing speed could obviously alternatively be employed.

Utilizing the 68000 microprocessor, the network bus 8 is selected to be a 16 bit data bus with data words transmitted in parallel to optimize speed. Each rule processor 6 is provided with a memory means for storing one or more production rules. In the embodiment described herein, the memory means is fabricated with sixteen 256K.times.1 bit dynamic memory chips. The memory size selection thus produces 512 Kbytes of R/W memory for each rule processor Thus the total memory that is required for 128 rule processors is 64 Mbytes.

One method in which to implement the network would be to have a dedicated 16 bit parallel bus. All rule processors would then look at the network through their own 16 bit parallel input port. A handshake exchange would be required to acknowledge the transfer before the next word could be sent. Each rule processor would be required to have a CPU, local memory, a boot ROM, and a 16 bit input port.

The disadvantage of the above implementation is that each rule processor would be required to have a boot ROM and an input port. The simpler embodiment described herein allows the rule processor memories to be mapped into the host processor address space at the same address. In other words, the network transmission from the host simply becomes a host memory write to a certain area of its memory. This area of memory is decoded and forces a write to all 128 rule processors in parallel. One advantage of this method is speed. Network transmission can go as fast as possible since a memory write becomes the method of transmission Also, the host processor can fill the buffers of each rule processor without having to handshake at every word transfer

Further, the 16 bit input port on each rule processor can be eliminated. The host fills the rule processor's memory directly. By having as well a read/write window into each individual rule processor, the host can load the program code for each rule processor on power-up. This totally eliminates the need for a boot ROM and associated decode and control circuitry. The rule processor "window" has several other uses as well. For software debugging, the host can "peek" into individual rule processor memories to check for proper operation. Also, completion flags and ready-to-fire flags can be checked without having to include additional hardware to bring these flags out on a host input port separately.

Within the host processor address space, the network, two processor windows, and associated control features are allocated 2 Mbytes of address space. FIG. 2 shows the network memory map. The location within the host address space can be selected from any of 8 areas since the 68000 microprocessor can address 16 Mbytes of memory and I/O.

Note that since the address of the network is selectable, multiple networks can be supported on a single network bus. This network bus may either have a single host processor controlling multiple networks or can have multiple processors controlling multiple independent networks. In the interest of clarity, a single host-single network is described herein.

Within the 2 Mbytes of address space allocated to the network, there are three distinct regions The first region is the actual network space itself When the host writes to this region, all rule processors are enabled to accept data from the network bus. In this manner, all processors receive the information from the network at the same time. In this connection, it is important to note that the network bus is not a separate parallel bus, but is rather an extension of the host address and data bus. Also note that the network area is a write-only region as there is no need to read from all rule processors' memories at the same time.

The second region within the network address space is a two-processor window. Each window allows a read or write into a single, selectable, rule processor. The particular rule processor that is enabled for this window read/write is selected by a parallel output port. By scanning through all rule processors in the output port, all rule processors can be selected for rule loading, flag checking, or debugging. The rule processor windows comprise an important concept in this implementation since they provide the only way for loading each rule processor with its individual rule(s). Further, the output port allows any number of RPs to be added. The output port can also be thought of as a bank-switch scheme to allow 64 mbytes (on a 128 processor system) to be mapped into a smaller space.

The third region within the network address space is allocated for the interface board I/O and cell board status input. Two of the ports in this section control window number registers which select the rule processors that will respond to a read or write to the processor window regions Another port controls the power-up reset of all rule processors This is important since the rule processors have no ROM of their own. The hardware reset latch allows the host to keep all rule processors in the reset state until the host has loaded the boot code for all of the rule processors. Another output port controls the interrupt lines to all rule processors This can be used as a wake-up signal to the rule processors to start them processing after a network transmission. An input port must be used to check a completion flag that signals all rule processors have completed processing the network transmission. This is an open-collector single line input that represents the state of all rule processors combined. This single line status port has several benefits. The host does not have to scan all rule processors waiting for completion, and the rule processors are not delayed by the host processor periodically taking over the local memories. While processing, the rule processors are all allowed to execute at full speed.

FIG. 3 shows the relationship between the hardware and software for one cycle of the hardware/software handshaking.

The host processor actually "fires" the rules. As a result of a rule firing, some number of right-hand-side (RHS) actions are sent over the network bus. In one embodiment a single RHS action is sent at a time. This is advantageous since a single RHS action minimizes the memory in each rule processor allocated specifically to the network. Also, the host can send single RHS actions as it computes them. The rule processors can be "crunching" (i.e., adding WMEs to their respective list, generating fireable list, etc.) on their responses to RHS actions while the host is computing more RHS actions. In another embodiment, all RHS actions can be sent at once which would reduce overhead associated with Host-RP cycling

Assume that the network transmission starts the cycle as far as the hardware handshake cycle is concerned. During the network transmission, all rule processors are halted. This is a self-imposed halt condition that is not required to exist before transmission. However, if all rule processors are halted, the host memory access to all rule processors' memories will proceed without any interruptions from the rule processors. Thus, the host has no arbitration delays during a network transmission. Due to the nature of the OPS language, there is nothing that the rule processors could be doing at this time in any case, and thus, there is no penalty for having halted rule processors. The host processor fills a predetermined area of each RP memory with data resulting from RHS actions as in Example VII above. Then the host puts a flag in a certain location that indicates to the rule processors whether or not the current RHS action is the last for the rule being fired. If it is, the rule processors will then calculate the fireability of their respectively stored rule or rules for the conditions (WMEs) currently obtaining.

After the network transmission, the host processor will write to one of the network control ports to force an interrupt to all of the rule processors After the rule processors have had sufficient time to respond to the interrupt, which brings them out of the halted condition, the host will clear the interrupt control port.

The rule processors independently process the results of the RHS actions sent by the host in accordance with the specific rules or LHS considerations that each rule processor contains. If the host processor has indicated that the last RHS action was the last for the rule just fired, then the rule processors must also determine whether the rules they contain are ready to fire. If a self-consistent set of WMEs is found to satisfy the LHS of the rule within any rule processor, then that rule processor raises a "match" flag at a predetermined memory location within its network space. After each rule processor has completed, it then halts itself, and raises a completion flag. The completion flags are buffered and wired-OR'ed to make a single completion flag on line 12 to the host as shown in FIG. 1.

After the last rule processor completes, the host can determine from the single completion flag that it is free to select which rule to fire, assuming multiple rules are potentially fireable using a conflict resolution strategy based on considerations of recency and complexity of matching WME sets. The host then fires the selected rule and sends more information in the form of created WMEs or references to deleted WMEs over the network. This hardware/software cycle repeats until no more rules are fireable.

The handshaking technique of FIG. 3 insures that no unnecessary bottlenecks or constraints are placed on the software. As far as the hardware is concerned, there are two distinct advantages. The first arises because the rule processors are halted during network transmission. Thus, no complicated arbitration required nor arbitration delays are presented to the host processor. The second advantage derives from the fact that each individual halt pin becomes a single bit status output for the associated rule processor.

With a large system, software debugging becomes a critical factor in the system implementation. With 128 rule processors, it becomes unreasonable to attempt to connect a debug terminal to every rule processor. Since the host processor is the only one connected to any I/O devices, it is desirable to have the host act as an intermediary between a debug terminal and any of the rule processors. Thus, each rule processor may run a debug program within its own local memory and may check memory locations for console input and output status and data. The host sets and clears the appropriate flags within the rule processor's local memory using the rule processor window scheme of Fig. 2. This virtual terminal concept may be extended to allow all rule processors access to a disk drive by requesting a transfer from the host. However, as in the virtual terminals, the host would have to scan all rule processors periodically to see if there is a transfer request.

In what follows, the terms "assertion" and "negation" will be used extensively. This is done to avoid confusion when dealing with a mixture of "active-low" and "active-high" signals. The term "assert" or "assertion" is used to indicate that a signal is active or true, independent of whether that level is represented by a high or low voltage. The term "negate" or "negation? is used to indicate that a signal is inactive or false.

A variety of readily available choices for the host processor bus may be utilized, for example, Multibus, the VME bus, and VERSAbus. The Multibus is utilized in the detailed description which follows with four 68000 microprocessors being placed on a single Multibus board.

The VME bus and VERSAbus may, of course, also be utilized. Both buses are 32 bit buses with the VERSAbus being of relatively large physical size.

Due to the large number of rule processors, VLSI would be most desirable for implementing the rule processors. In the detailed description which follows, a multilayer PC board is utilized. For this latter technology, the square JEDEC 68000 packages and 256K.times.8 single-in-line hybrid memory modules are most space efficient. For control logic, a PLA and latch could form a control state machine for memory timing, memory refresh and other local rule processor cell functions. Also, a custom VLSI chip for the control logic would be desirable to save board space.

In the detailed embodiment described herein, all rule processor components are in bare chip form. Four microprocessors are placed on each of four Multibus boards for a total of 16 rule processors. The system may, of course, be expanded to include 128 rule processors or even a larger number if desired.

In accordance with a second embodiment of the invention as shown in FIG. 4, an interface 20 is interconnected between the host processor 4 and the rule processors 6 of the network 10. The interconnection is accomplished via a host bus 22 (sometimes referred to as the Multibus P1 connector) and an interface bus 24 (sometimes referred to the Multibus P2 connector). The interface 20 permits streamlining of the rule processor logic which must be utilized for each of the plurality of rule processors 6. Thus, the interface contains much of the functional logic to interface the 128 rule processors to the host processor bus. The data bus of the host Multibus still goes to the individual rule processor boards. However, all network address decoding and Multibus memory control functions to the rule processors are controlled by the interface board 20.

FIG. 4 also illustrates the RP board control logic 25 which is provided on each circuit board. This control logic 25 is explained more fully below in reference to FIG. 6.

FIG. 5 is a block diagram of the interface 20 which is seen to comprise, inter alia, a rule processor (RP) memory control 26 for host memory accesses, and a network address decode 28 for the network space, the rule processor window space, and the local interface board I/O.

The RP memory control 26 on the interface board is intended to reduce the hardware needed on the individual rule processors. Also, since the network will transmit to n rule processors at once (e.g., n=128), this method insures that all rule processors are doing the same thing at the same time. The RP memory control 26 is the only place that the Multibus memory control signals (memory read, memory write and data transfer acknowledge) are used by the system.

This arrangement has the advantage of allowing one to change busses (for example to utilize a VME bus or VERSAbus) with only one change to the interface board logic. Notice the I-MREADY> signal that comes back from the rule processors. This signal will not become true until all addressed rule processors have gone into the bus release state and are ready for a host memory transfer. If only one processor is being addressed through the window, this case is trivial However, if all rule processors are being accessed through the network, this signal only comes true when all of the rule processors are ready for a data transfer. Note that in the normal case of a network transmission, the rule processors would already be halted and this line would stay true. This allows a transfer at the fastest possible rate.

The network address decode 28 simply decodes the multibus address lines on the host bus 22 to give select lines for the network, the single processor window access, and local I/O on the interface board itself. When the network mode is selected, the network select line indicates to the rule processor boards that all rule processor memories are to accept in parallel the data being transferred. Notice that this is a write only transfer as far as the host is concerned. When the window mode is selected, only the rule processor which has been selected by an RP window register accepts the data transfer. Note that in this mode the transfer could either be a read or a write.

The interface board is also seen to contain a global dynamic memory refresh controller which includes a refresh timing circuit 30 and refresh counter 32. Since the 68000 timing does not allow totally transparent memory refresh, there is some overhead regardless of where the refresh control is placed. With the refresh control placed on the interface board, the refresh can take place at precisely timed intervals, reducing the number of unnecessary refresh cycles. Since the network transmission is a write-only process to the rule processor, the refresh may be thought of as a read of the network with data buffers disabled.

The interface board also contains some input and output registers to facilitate control of the rule processors. First, there are two window number latches 34 and 36 that are used to select a rule processor that is addressed in the window mode. These are write-only latches which can be incremented to scan through all rule processors if desired. There is a single bit status (flag completion) input port 38 that is used to determine when all rule processors have completed processing the data that were sent to them over the network. Also, there is an interrupt control register 40 that is used to interrupt all rule processors in parallel. Since the 68000 has three interrupt input lines, this port is a three bit write-only port. An additional single bit RP reset control port 42 is used to reset the rule processors. The reset output to the rule processor also reflects the latched state of the system reset signal. Only by software command by the host can the rule processors come out of the reset state. This is due to the fact that the software is loaded into the local memories of all rule processors before they are allowed to run.

Interface 20 is also seen to comprise an address mux 44 and address swap plug 46. The address mux 44 permits either host or refresh access to the RP memories. The address swap plug 46 preconditions host address lines to be consistent with the cell board wiring used for accessing local memory as explained more fully below. Interface 20 further comprises a transfer acknowledge control circuit 48 for acknowledging to the host a completion of data transfer to the RPs; a host interrupt circuit 50 and a plurality of buffers 52, 54, 56, 58, 60 and 62.

Due to the central nature of the interface 20 between the host and the rule processors, there are possibilities for additional functions therein. One possibility is to have a status cable coming from the interface board to a panel-mounted display. This display may display such useful information as the selected window number, the completion flag input from the rule processors, the interrupt control output, and the reset state of the rule processors The network and window selects may also be displayed. Any signal that is too quick to see should be buffered by a one-shot so that it becomes a useful visible status symbol.

FIG. 6 shows a diagram of the RP board control logic 25 which is required on each rule processor board to buffer control and status symbols. Control logic 25 is seen to comprise a board selection decode circuit 72 which, via an RP cell select circuit 74, selects all the rule processors when the network mode is selected or selects a single rule processor when the window mode is selected.

The host interface data come from the normal Multibus data bus of the host bus 22 even though the bus control signals for the rule processors are generated in the interface 20. On each rule processor board, the data bus is fed to a buffer 76 to prevent bus loading by the rule processors. This means that the Multibus is loaded by the number of boards in the system, not by the greater number of rule processors. The host address bus and refresh address are multiplexed for the dynamic memory at the interface 20 (FIG. 5), not the rule processor level. The address signals from the interface 20 are buffered in buffer 78 and sent along a buffered address bus 22A to cell bus CB. Similarly, the buffered data from data buffer 76 are sent to the rule processors via the buffered data bus 22B to cell bus CB.

The system clock 80 for all rule processors is in the board level logic. Again, this is done to reduce the circuitry required in each rule processor cell.

The host memory control signals from the RP memory control 26 of the interface board are buffered in miscellaneous buffer 82 and sent to the RP cells as needed. Note that one of the control lines from the interface 20 is used to select either the row or the column addresses on the address bus from the host. The miscellaneous buffers 82 to 84 also buffer certain control signals to (buffer 84) and from (buffer 82) the interface board. These signals include the I-RESET line, the interrupt control from the IF Board, and the open collector completion flag from the rule processors to the host. Buffers 82 and 84 are unidirectional and need no separate enable signal.

The RP Board control logic 25 also decodes the high order window number address on the interface bus 24 to give a board select. When the board is selected, the rule processor selected by the low order window number address is selected for a memory transfer. Also, when the network is selected, all rule processors are forced into being selected for a write regardless of whether or not the board was selected by the high order window-address lines.

The rule processor cell contains the circuitry that is to be repeated a number of times, i.e., n=128. Because of this relatively large number, it is advantageous to minimize circuit complexity. FIG. 7 shows a block diagram of the RP cell circuitry for a single cell.

The RP cell is based around a CPU 84 (for example, a 68000 processor) and includes a memory 86, local RAM address bus 85, address mux 88, data buffer 90 and control logic circuit 92. Notice that there is no ROM in the rule processors nor is any required since the host processor loads each RP cell's memory 86 with the appropriate software for proper operation. Also notice that there is no I/O circuitry. This is a result of the direct memory mapped network. Since there is no ROM nor rule processor I/O, there is no need for any address decode circuitry.

The 256K.times.16 dynamic memory of memory 86 can be accessed by either the RP cell CPU 84, the host bus 22 or interface bus 24 buffered on the cell boards to the cell bus CB. The data bus of the memory is further buffered to prevent conflicts with other RP cells on the same board. There need be no buffering between the memory 86 and the CPU 84 because the CPU 84 is in a bus grant state whenever the host is accessing the local RP memory 86.

The address for the dynamic memory 86 can come from one of three different sources. The first is from the host address bus buffered to the cell bus CB. The second source of address comes from the refresh circuitry of interface 20. The last source of memory address is from the CPU 84. The 18 bits of address are multiplexed into 9 bits before addressing the dynamic memory 86. The selection of the address source is controlled by a select signal from the control logic 92.

Note that 18 bits of CPU 84 are used to address the local memory 86. This allows for the use of 256K dynamic memories for a total of 512 Kbytes of memory on each rule processor. It is pointed out, however, that the rule processors do not have to be identical as far as memory population is concerned. There could be a small number of "super" rule processors that are assigned more memory intensive rules for processing.

The control logic 92 handles all local memory timing, host bus arbitration, and CPU reset. The most important function of the control logic 92 is to allow the local CPU 84 to access memory 86 at full speed without wait states. The local memory control is not concerned with memory refresh because this function is controlled by the interface 20.

Each rule processor is required to have its own local memory. This eliminates memory arbitration problems between a number of rule processors and a common global memory. The only need for arbitration is between each rule processor and the host processor. All host-to-RP memory transfers are initiated and controlled by the host. However, during most of the host-to-RP memory transfers, the rule processors will normally be halted to permit network transmission of the data resulting from RHS actions and to permit polling by the host of the match condition flag of each RP indicating a potentially fireable rule.

The data buffers 76 (FIG. 6) and 90 (FIG. 7) may take the form of 74LS245 integrated circuits. These data buffers are used to separate the host data bus from the local rule processor data bus. The direction signal comes from the cell-bus read/write signal, C-W*. This is essentially the same as the host read/write signal with one exception. When the interface 20 is performing a mass memory refresh to all rule processor memories, the C-W* signal must be high, signifying a read cycle. Because the interface performs a refresh essentially by doing a network read, which would cause data bus contention problems, a provision is made to disable the data buffers during refresh and eliminate contention problems. The cell-bus signal C-REFRESH will force the data buffers to be disabled during refresh. This signal insures that the data buffers are enabled only when the host is accessing local RP memory (memory 86 of each cell) and the C-REFRESH signal is low, signifying a normal read or write cycle from the host.

The address multiplexer 88 is utilized in addressing of the local RP memory 86 by both the CPU 84 and the host processor 4. FIG. 8A shows a diagram of the address multiplexer 88 and FIG. 8B shows an address/pin assignment table.

The control signals "Mux Ctrl A" and "Mux Ctrl B" select the source of the local memory address. Mux Ctrl A selects the row and column address from the CPU 84. When Mux Ctrl A is high, the row address is selected. When it is low, the column address is selected. Mux Ctrl A is high when a host memory transfer is taking place. Mux Ctrl B is high when the local CPU 84 is accessing memory and is low when the host processor 4 is accessing memory. The following table indicates the source of the address for each combination of Mux Ctrl A and Mux Ctrl B.

Note that the host address is not multiplexed at the cell level but is multiplexed via mux 44 at the IF board level in FIG. 5. This has several benefits. First, only 9 bits of address have to be sent to every RP cell instead of 18 bits. The second benefit is that it insures that all rule processors are in sync when the interface board is controlling a host network memory transfer or global refresh.

The most important aspect in assigning the inputs to the multiplexers is to be consistent in assigning the inputs from both the host address bus and the local address bus. Otherwise, a particular address from the host will not correspond to the same address from the local CPU 84. Thus, one must make sure that the host and local processor's addresses are mapped to equivalent bits on both the row and column addresses to the dynamic memory 86. For example, if the CPU 84 address line A7 is mapped to local memory address line 1, L-MA1, on the row address, the host A7 line must also be mapped to L-MA1 on the row address. Note that the actual order of address line assignments does not matter (since the memory 86 is random access) as long as both the host and local addresses correspond on both the row and column addresses. The address swap plug 46 of FIG. 5 basically insures the consistency between the host/local RP address designation.

The multiplexer circuit is implemented with five 74LS253 multiplexer chips of which 41/2 are utilized. Due to ringing problems on dynamic memory address inputs, 47 ohm resistors are used to smooth the signal transition from the output of the multiplexer array.

The table of FIG. 8B illustrates the address/pin assignments for the multiplexer 88. Pin assignments may be made considering wiring convenience. It is to be noted that FIG. 8A shows only one half of the 74ALS253 chip with the notation number 1/number 2 designating the first half/second half address/pin assignments. For example, local CPU row address A7 of multiplexer chip CH is assigned to pin 5 (i.e., number 1 of the 5/11 designation) whereas local CPU row address A6 of the same chip is assigned to pin 11 (number 2 of the 5/11 designation). It is noted that the 68000 processor does not have an A0 pin but uses upper and lower address strobes for selecting upper and lower bytes (8 bits) of a 16-bit word. Thus, the A0 address line need not be considered. In this manner, FIGS. 8A and 8B represent the 41/2 chips needed to generate the 9 row/column address lines for DRAM memory 86.

FIGS. 9A-9C set forth the cell board circuit layout. It is noted that in the detailed description set forth herein, four RP cells are placed on each board so that FIG. 9B is repeated four times per circuit board. The top and board control logic of FIGS. 9A and 9C appear only once per board and the signals generated thereby are used in common for all RP cells. The table set forth below may be utilized in conjunction with FIGS. 9A-9C and the detailed description herein as representative of commercially available chips used in implementing the invention. Specification of particular chips is made only to set forth a detailed embodiment of the invention and is not intended to limit the invention to such detailed implementation since alternate embodiments including VLSI technology may be equally suited to implement the invention.

In order to simplify the names of bus signals certain naming conventions are utilized. The prefix of the signal name specifies the location of the signal. The first character specifies the bus followed by a dash character. A list of the prefixes is given in Table 1. In order to specify the types of signals used the conventions and symbols shown in Table 2 are utilized.

The following signals are from the host processor bus 22 which is the Multibus connector P1. Other signals, such as the LDS, UDS, and R/W* also come from this bus. However, keep in mind that there will be a significant load placed on the Multibus for the signals that are used by the rule processor boards. For this reason, control signals may require buffering on the interface board before being placed in the interface bus 24.

H-A1 to H-A18

Host processor address lines to Interface board. Since there is a UDS and LDS to select lower address bit, A0 is not included here. In other words, A0 is selected by the use of UDS and LDS. These address lines are multiplexed by the address mux 44 (FIG. 5) and used for the multiplexed input of the dynamic memory 86.

H-D0 to H-D15

Host processor data lines to Interface board and RF boards. This is the data bus used for network transmissions and single processor windowing by the host processor.

The following signals are from the interface bus 24 which is the Multibus P2 connector. Some of the high order address lines from the host CPU are also placed on this bus. These address lines are used to extend the Multibus addressing, and are used only on the interface board for address decoding. The rule processor boards do not need these high order address lines.

The Interface Bus consists of four sections as listed below:

Board Select Control

Memory Control

Cell Reset Control

Miscellaneous Control

I-WA0 to I-IWA11

This 12 bit bus contains the number of the RP cell that is to be accessed during a window read or write. The interface board can change this number depending on what window mode it is in. I-WA2 to I-WA11 are used to select the cell board, and I-WA0 and I-WA1 select the particular cell on the selected board.

I-NETWORK*

This is the network select signal to force all rule processor cells to respond to a host write command. This signal is also used by the global refresh control circuit on the interface board.

I-WINDOW*

Window Select Signal. The cell that is selected by the window number on the window number bus is actually selected when this line is low.

I-STATEN*

Board Status Port Enable. This line goes low to allow the board selected by the window address lines to put the on-board 16 bit status port onto the host data bus.

I-W*

Read/Write Signal. This signal is normally a buffered version of the host R/W* line and is low (in the write state) only when the host is writing to the RP boards. However, this line is forced high, to the read state, during the global refresh cycle.

I-RAS*

Row address strobe signal The falling edge of this signal indicates that the row address is stable and should be latched by the selected RP cell memories. This signal is also used to clock in the refresh address during the global system refresh.

I-CASU*

Upper byte column address strobe.

I-CASL*

Lower byte column address strobe. The CAS signals latch the column address in the falling edge of the strobe and initiate the actual read or write.

I-MREADY>

Open collector memory ready signal. This signal is fed back to the interface board to indicate when it can actually make a bus transfer. During a single processor access, this signal is the state of the single selected processor cell. However, in the network or refresh mode, this signal is the overall memory ready state of all rule processor cells.

I-REFRESH

Refresh active signal. This signal is high during a refresh cycle and deselects the local data buffers to prevent bus contention problems.

I-A0 to I-A8

Nine bit multiplexed address bus. This bus contains the host row address, host column address, and refresh address multiplexed under control of the interface board.

I-RESET*

System level reset signal. Active Low.

I-RUN

This signal is used to enable the selected rule processor to come out of a reset state, by first bringing I-RUN high and then performing any memory access to the selected cell. The I-RUN signal is then brought low again. Note that a single processor is enabled to run through a read/write window, while all processors can be enabled by writing to the write-only network. In any case, only a single access is required. This signal should be low during the global refresh operation.

I-HALT

This signal is used to reset selected processors in a similar manner as the I-RUN signal. This signal must be low during the global refresh operation.

I-COMPLETE>

Single bit completion status of all rule processor cells. This is an open collector signal. When this line is low, there is at least one RP that is running. When this line is high, all RPs are halted.

I-REQUEST*>

Single bit request line from all rule processor cells. A single rule processor can pull this open collector signal low, requesting the attention of the host.

I-INT0* to I-INT2*

RP cell interrupt lines. These lines are normally high, indicating no interrupt. One or more of these lines will go low when an interrupt is to be serviced by all rule processor cells.

I-BDSEL*>

RP board selected line. This line can be used by the interface or buffer boards to determine if a board is present in a certain configuration. Its main intent is to allow several card cages to be attached to a single ribbon cable type interface bus. A buffer board could then buffer and transfer all signals to and from the cell boards in that particular cage. The open collector line gets around the need to have a cage decode circuit on the buffer board.

I-SPARE1, I-SPARE2

Spare IF Bus control output. The I-SPARE2 signal does not have a corresponding C-SPARE2 signal.

The signals on the cell bus go to every rule processor cell on a board. One of the purposes of the interface bus and cell bus is to separate the large number of rule processors into sections to prevent large bus loading problems.

The cell bus consists of four sections as follows:

Address and Data Bus

Memory Control

Cell Reset Control

Miscellaneous Control

C-A0 to C-A8

Multiplexed host row/column address and refresh address bus corresponding to bus 22A of FIG. 6. This 9 bit bus can contain three address types host row address, host column address, and Global Refresh Address. The host row and column addresses must correspond to the local CPU address connections.

C-D0 to C-D15

This is the 16 bit host data bus extension line 22B of FIG. 6. The naming scheme reflects that of the 68000 CPU chip, not the Multibus data bus naming convention.

C-W*

This is the host read/write* signal. During refresh, this signal must be high in order to do a memory read of all local rule processor memories The complement of this signal also is transmitted over the cell bus and is called C-W.

C-RAS*

Host row address strobe signal. The falling edge is used to latch the row address into the RAM chips. This signal is also used to clock in the refresh address.

C-CASU*

Upper byte column address strobe. Used to latch the column address from the host.

C-CASL*

Lower byte column address strobe. Used to latch the column address from the host.

C-MREADY>

Open collector memory ready signal. This open collector signal is used as feedback to the host to signify that all required local processors have given up the memory to the host. This signal should be thought of as a level type signal. The rising edge of this signal should not be used to proceed with the memory transfer. This is because there will be no rising edge if all local processors are already halted or reset. This signal is also used by the global refresh circuitry.

C-REFRESH

This is the refresh indicator signal. This signal will be high during the global refresh. This will cause all cell data buffers to disable during the global refresh.

C-SELECTn*

Cell Select Signal for n=0, 1, 2, 3. This is the only signal that is specific to an individual cell. This signal goes low when the host wishes to initiate a memory transfer and will go high again when the memory transfer has been completed.

C-RESET*

This is the system reset signal. This forces all rule processors to stop and remain in the reset state until enabled in the RUN state.

C-RUN

Cell run enable signal. In order to enable an RP cell to run, this signal must be high during a memory access to the desired cell. This signal must be forced to a low when a refresh operation is taking place.

C-HALT

Cell halt enable signal. In order to stop an RP cell, this signal must be high during a memory access to the desired cell. This signal must be forced to a low when a refresh operation is taking place.

C-COMPLETE>

Open collector completion flag. This signal will go high when all RP cells have halted, indicating that the recognize phase of the RAC is complete.

C-REQUEST*>

Open collector request line. This signal is pulsed by the RESET instruction of the rule processor to signal the host to scan all rule processors to see which one has a request.

C-INT0* to C-INT2*

Rule processor cell interrupt lines. These lines are normally high, indicating no interrupt pending. When a line or set of lines is brought low, the RP cell CPU will start an interrupt acknowledge sequence.

C-CLOCK

Rule processor cell clock. This is the clock to the rule processor CPU and control logic. This clock should be close to a 50% duty cycle.

C-STATUS*

Board status port enable. This signal is not used by the rule processor cells at all, but is sent to the top of the board where there is an eight bit input port. Four of these bits are used to allow the host to determine the run state of each of the RP cells. The other four bits can be used as test points for any reason. Note that this port is only the lower eight bits. The upper eight bits come from the bottom of the board where two more signals are brought in for input.

C-SPARE1

Spare cell bus signal. This is a spare signal that can be used for any reason. Currently, the board layout buffers the corresponding interface bus signal and transmits it over the cell bus.

The cell control logic is responsible for making all portions of the rule processor cell work properly. There are four main portions of the cell control logic. They are listed below and described in the following paragraphs.

Local Memory Control Logic

Interrupt Control Logic

Arbitration Control Logic

Cell Disable Logic (Reset Logic)

FIG. 10 is a block diagram of the major portions of the cell control logic circuit 92 which illustrates the signals that are common between the major portions of the logic and the relationships between the portions of the cell control logic. FIG. 10 illustrates the local memory control logic 100, interrupt control logic 102, arbitration control logic 104 and cell disable logic 106. Signals beginning with "C-" are cell-bus signals that are common to all cells on a board. The only exception is the C-SELECTn* signal which is specific to each rule processor cell. Signals beginning with "L-" are the local rule processor signals, i.e., the signals specific to a given cell as illustrated in FIG. 7.

The local memory control logic 100, illustrated in FIG. 11, is responsible for the dynamic memory control by the local CPU 84. The DTACK* logic is shown in FIG. 12 due to the dependence of DTACK* on the interrupt logic timing. FIGS. 13 and 14 show the arbitration control logic 104 and cell disable logic 106, respectively. FIGS. 15-17 show the timing of the 68000 CPU and the resulting dynamic memory timings. The timing diagrams are shown for a 12.5 Mhz 68000 to show the worst case timing for the dynamic memory.

Referring now to FIG. 11, a mux 108 (for example a 74LS257 multiplexer chip) is used to select between the local RAM control signals from the local rule processor 84 (W*, AS*, UDS*, LDS*) and the host RAM control signals from host 4 (signals having the "C" prefix). The outputs of the mux 108 go to the memory 86 which may take the form of a RAM chip array (for example, Fujitsu MB1256). The signals required by the RAM array are the read/write signal (L-MW*), row address strobe (L-MRAS*), and column address strobes for both the upper (L-MCASU*) and lower (L-MCASL*) data bytes. The corresponding signals from the host come directly from the cell bus CB. The Local*/Host signal is generated in response to a network or window access from the host and comes from the interface 20 via the arbitration control logic 104 of FIG. 13. This signal also serves as the Mux Ctrl B signal to address Mux 88 of FIG. 8A.

The RAS* for the local timing comes from the address strobe AS* of the CPU 84. The "mux Ctrl A" signal is connected directly to the AS*[B] signal line (originating in FIG. 12) and is fed as a select signal to mux 88 of FIG. 8A. The "Mux Ctrl A" must change to allow address multiplexer 88 to enable the column address onto the local RAM address bus 85. This is derived by a delayed version of AS*. The CAS* signal is generated by delaying AS*[B] via a flip-flop 110 a few gate delays (20-30 ns). The delay permits the generation of CAS* at the proper read timing as shown in FIG. 15. (Note in FIG. 15 that DS* is used to represent both the upper and lower data strobes from the local CPU.) For the write timing, the DS* signal from the 68000 is already delayed relative to the AS* signal as shown in FIG. 16.

The CAS* signals must be generated for both the upper byte memory bank and the lower byte memory bank. This is accomplished using OR gates 112 and 114 on the delayed AS* signal from flip-flop 110 and the UDS* and LDS* signals from the CPU 84. This has the added benefit of creating two CAS* cycles for the read-modify-write timing as shown in FIG. 17. Due to the UDS* and LDS* timing, the CAS* signals will go high at the same time RAS* goes high. However, this timing is still valid for normal DRAM timing.

FIG. 12 illustrates the interrupt control logic 102 and is seen to comprise a ROM 120 and inverters 122 and 124. A ROM table Cl for ROM 120 is set forth in FIG. 18. The function codes FC0-FC2 are provided by the CPU 84 and are all high to provide an interrupt acknowledge signal The VPA* signal is the 68000 valid peripheral address signal and is used to initiate an autovector interrupt mode when the function codes are in their highest priority state, namely state 7 (FC0=FC1=FC2=1) and the address strobe AS* is asserted (i.e., low). In the described implementation, there are seven levels of interrupt which are carried out in the autovector mode using the VPA* signal.

The interrupt control logic is responsible for the proper timing associated with the CPU 84 autovector interrupts. Autovector interrupts are used because a vector number is not required to be placed on the CPU data bus. Seven interrupt levels are sufficient for use in the rule processor cell. The interrupt inputs of the 68000 processor, namely IPL0* to IPL2*, provide the required input to the CPU to initiate an interrupt acknowledge cycle. These interrupt inputs occur asynchronously to the CPU clock and originate on the IF board, generated by host software.

Two signals are affected by the interrupt acknowledge requirements. The VPA* is required to go low to indicate to the 68000 CPU that autovector interrupts are to be used. The DTACK* signals should be high during an interrupt acknowledge cycle to ensure that a vector number is not on the data bus. During cycles other than interrupt acknowledge, DTACK* follows AS* to satisfy the memory control timing since there are no wait states for local memory access by the local RP.

The signals FC0 to FC2 are used in FIG. 12 to detect an interrupt acknowledge cycle. The 68000 timing specifies that all three lines go high during an interrupt acknowledge cycle. However, these lines are valid only during the period when AS* is low. Because AS* is a three-state signal, a pull-up resistor is used to ensure that AS* is never left floating.

The DTACK* signal generated in FIG. 12 is required by the CPU 84 to indicate the completion of a memory transfer cycle. Although the local CPU 84 does not need to worry about timing delays, decoding or the like, DTACK* is still required to be low to terminate a memory transfer cycle. However, due to the autovector interrupts that are used, DTACK* must be high during an interrupt acknowledge cycle to prevent the local CPU 84 from reading an interrupt vector number from the data bus enabling auto vector interrupt when VPA* is asserted (low). DTACK* is low during all memory reads and writes by the CPU 84. This insures that CPU 84 will execute at full speed with no wait-states.

The arbitration control logic 104 is shown in FIG. 13 and is seen to comprise a ROM 124 and flip-flops 126, 128, 130 and 132. The ROM table C2 for ROM 124 is set forth in FIG. 19. The arbitration control logic 104 is important in the communication between the host processor and the rule processor All memory transfers between the host and the local rule processor memory are initiated by the host processor. The local rule processor CPU does not have the ability to initiate such a transfer. The only need for the arbitration control logic is to ensure that the local rule processor has released the local address bus and data bus for use by the host processor. Notice that when the local RP is not running, either by being held in a reset state or by having executed the halt instruction, the arbitration is such that the host has immediate access to the local rule processor memory. In this state, the normal 68000 arbitration signals are not used to generate the signals required by other parts of the cell logic. This is because these signals cannot be guaranteed functional when the 68000 is held in the reset state These signals are functional when the RP is halted as via a halt instruction, but in this case they are simply ignored.

The C-SELECTn* input to flip-flop 126 comes from the interface 20 and is low whenever the host needs to initiate either a network or data transfer. The run state signal is generated by the cell disable logic of FIG. 14, indicating that the local CPU is running.

When the local 68000 is running, the arbitration circuit has to arbitrate between local RP memory accesses and host memory accesses. A memory access, either by the host or the local RP, is never interrupted mid-stream. Therefore, the host will have to wait until the local RP releases the bus before it can gain access to the local memory. The RPs (at this point) do not distinguish between actual host CPU accesses and memory refresh.

The flip-flops shown in FIG. 13 primarily ensure proper transitions at the edge of the clock. FIG. 19 shows the arbitration control ROM table for ROM 124. A finite state machine could be implemented using this ROM and the signals Y and YN+1. However, these signals are currently not used. ROM 124 generates the memory ready, local/host and the 68000 BR* and BGACK* signals For a simple arbitration scheme, BGACK* is tied high and the ROM entry for this is always 1. BR* to the 68000 RP is the same as the SELECT* input The ROM will ensure that the local RP remains in control of the memory until it receives a BG* assertion (low) from the local 68000 RP.

The cell disable logic has three main functions as shown in FIG. 14. The first function is to hold the local 68000 in a reset state until enabled by the host. This is important since the host has to load the local rule processor memory before the 68000 is allowed to start running. The second function is to provide the single bit open collector completion status signal that the host uses to determine the collective completion state of all rule processors The last function of the Cell Disable Logic is to allow the local rule processor to request the attention of the host.

The cell disable logic 106 may also be termed the reset logic and is seen to comprise flip-flop 130 inverting buffers 132-138, timing flip-flop 140, OR gate 142, flip-flop 144 and decoder 146. Inverting buffers 134-137 are open-collector gates indicated by the vertical bar within the triangular symbol. The upper portion of FIG. 14 including decoder 146, flip-flop 144 and inverting buffer 133 is used to generate a Run State signal from the RP CPU address lines A1, A22 and A23 serving as select inputs to decoder 146 (type LS138). The Run State signal is fed as an output of flip-flop 144 to the "D" terminal of flip-flop 128 of FIG. 13. The local RP CPU is running whenever Run State is high.

The lower portion of FIG. 14 is used for resetting the RP CPU 84. The flip-flop 130 is used to latch the reset state of the CPU 84. This flip flop is initially set to the reset state by a power-on reset signal. When the system is first powered up, a global system reset is generated by asserting C-RESET* which in turn forces and both HALT* and RESET* to be asserted (low) thus forcing a reset of the RP CPU 84. By configuring the host to control each RP's HALT and RUN lines, the host may remove from the system any CPU which is defective or otherwise not desired. Both the C-HALT and C-RUN lines must be low during normal refresh and normal memory access.

One important aspect of this scenario is that flip-flop 130 be latched on the falling edge of the C-SELECT* signal. This assures that the cell is reset when the host cycle is initiated. Otherwise, a bad cell that is not responding to arbitration requests properly will hang up the system. The global system reset C-RESET* is generated in the interface 20 in response to either a hardware or software reset as explained in more detail below.

The RESET* signal to the CPU 84 is buffered by an open-collector buffer and pulled up by a resistor due to the 68000 RESET instruction which will try to drive the RESET pin low. The HALT* line is buffered separately and is also used as an input to the completion status flip-flop 144. The HALT* from the 68000 does not accurately show the run state of the RP. For example, the HALT* pin is low on the 68000 only when the 68000 is being held in the reset state (in which case, the gate 135 pulls the 68000 HALT* line low) or when the 68000 has encountered condition known as double-bus-fault (described in the 68000 manual). In the double-bus-fault condition, the 68000 itself pulls the HALT* line low. The flip-flop 144 and decoder 146 allow the RP software to control the hardware to force Run State low when a 68000 STOP instruction is executed. The AS*(B) leading to the preset is the mechanism for setting the FF 144 into the "Run" state (AS*(B) goes low to force RUN STATE high).

After resetting the RP CPU 84 which is done simultaneously for all RPs through the C-RESET* line, each CPU 84 may be loaded with a common operating code, as, for example, the Polyforth kernel, and with individual LHS rule evaluation code specific to each RP. The RPs may then be started (again simultaneously) by asserting C-RUN and negating C-HALT, both of which originate from the interface 20 and are conditioned by host execution. The CPU 84 is then started by doing any kind of access such as a dummy read or write. When all RPs are started with C-RUN, the host must do a dummy write since it is not possible to read from all RPs at once. For a single RP, either a dummy read or write will be effective. To effect a halt of CPU 84, the C-HALT line is asserted and again a dummy access is made.

The need may arise for a single rule processor to request the attention of the host. This may be to signal the host that an error has occurred which requires the host's attention. The C-REQUEST*> signal is used to allow a single rule processor to interrupt the host. In order to minimize rule processor hardware, the manner in which the C-REQUEST*> signal is generated is unusual. The 68000 has a RESET instruction that normally allows the 68000 to reset the rest of the system. The RESET instruction pulls the RESET* pin on the 68000 low for 124 clock periods or 12.4 uS using a 10 Mhz clock. The C-REQUEST*> line uses this reset pulse to generate the request. Rule processor software may also set a flag to allow the host to identify the requesting rule processor.

The circuitry of FIG. 4A, the top of board logic, is shown in detail in FIG. 20 and is seen to comprise a tri-state buffer 150, inverting buffers 152-155 and LEDs 156-159. The run state signal of each cell, namely the C-RUNSTATEn signal of FIG. 14, is fed to the buffer 150 to permit the host to determine whether or not any individual RP is running. A visual indication of the RP running state is also provided by the LEDs 156-159 by buffering the run state signals with their respective buffers 152-155.

The board control logic of FIG. 9C is set forth in detail in FIGS. 21-27. FIG. 21 shows the conversion of the interface signals pre-fixed by the letter "I" to the cell bus signals pre-fixed by the letter "C". The clock signal generation is also shown in FIG. 21 and includes a clock oscillator 162 and a flip-flop 164 serving to divide the oscillator output by a factor of two. The clock signal C-CLOCK is fed to the clock inputs of each rule processor cell as shown in FIG. 11. Since each cell board has its own clock, it is possible to run each cell board at different clock rates for the CPUs contained on each board. (Notice the CPU clock signal of FIG. 11.) The network architecture and handshaking sequence (FIG. 3) also permit this different clock rate embodiment.

FIG. 22 illustrates the further buffering of the address line I-A0 to I-A8 from the interface 20 to the cell bus signals C-A0 to C-A8.

The window select logic circuit is shown in FIG. 23 and is seen to comprise a comparator 166 (made up of three 74LS85 comparators) and a DIP switch array 168. The window address lines are static lines and stay asserted until another board is selected since they are latched in the interface 20. The window address lines I-WA2 through I-WA11 are used for board selection.

FIG. 24 is a schematic diagram of the cell select logic which comprises B1 ROM 170, B2 ROM 172 and flip-flops 174 used for timing. The ROM tables for ROM 170 are shown in FIG. 26 and for ROM 172 in FIG. 27. The basic purpose of the cell selection circuit is to permit access by the host to a particular RP on the selected board. This access is achieved via the lower window address lines I-WA0 and I-WA1. The I-WINDOW* signal is asserted by the host when a window access is desired. I-NETWORK* is asserted (by either a host network write access or interface refresh) to indicate a network access. The BOARD-SELECT signal comes from the window select logic of FIG. 23 and represents a decode of the window address.

In the case of a window access only one of the RPs on the board will be selected corresponding to one of the basic C-SELECTn* being driven low. This decoding may be seen in rows 10-13 of the ROM table of FIG. 26 wherein Sn* corresponds to C-SELECTn* for n=0, 1, 2 and 3. For a network transmission, all RPs need to be accessed as seen in row 1 of the ROM table of FIG. 26.

The Sel* output of ROM 170 (FIG. 26) is designated as the S* input for ROM 172 (FIG. 27). In practice, ROM 170 and 172 may be thought of as a single ROM table, and it is only divided for the sake of implementing same from readily available commercial components.

The C-STATUS* output of ROM 172 (designated ST*) is connected to enable the tri-state buffer 150 of FIG. 20. With the exception of the S* (Select) input, the remaining inputs to ROM 172 come from the interface 20. For example, I-STATEN* comes from FIG. 33 described below. The BD DATA BUFFER ENABLE* enables the cell board data buffer 76 of FIG. 6.

FIG. 25 is a schematic diagram of the open collector lines and status latch. Tri-state buffer 180 and flip-flop 182 serve as a status port for providing the host the ability to monitor the C-COMPLETE> and C-REQUEST*> lines and is similar to the port 150 of FIG. 20 for the top of the circuit board. The open collector buffers are used for buffering the signals shown. It is noted that FIG. 25 represents the wire OR'ed connection of the like signals which are tied to the cell bus so that the C-COMPLETE> line of FIG. 25 is the OR'ed connection for each of the four completion signals of FIG. 14. (Note that FIG. 14 is repeated four times for each of the four RPs on the board as are all figures representative of details of the RP cell of FIG. 9B.)

The following description is provided to set forth details of the block diagram of FIG. 5. A block diagram of rule processor memory control circuit 26 is shown in FIG. 28. The RP memory control circuit 26 comprises a timer 200, refresh control circuit 202, arbitration control circuit 204, memory ready control circuit 206, timing control circuit 208 and miscellaneous control circuit 210. The miscellaneous control circuit 210 includes numerous input and output signals which are not shown in order to simplify the connection of the remaining illustrated blocks of the figure. However, the detailed schematics which follow more fully describe the interrelationship of the miscellaneous control circuit 210 with the other circuit block elements.

Timer 200 is a programmable interval timer which generates a refresh request (RF REQ) and waits for the receipt of a predetermined number, of refresh acknowledge (RF-ACK+) signals from the timer control circuit 208 via the refresh control circuit 202. The predetermined number of refresh acknowledge signals may, for example, be 16. During this time interval, the refresh request signal remains high forcing the remaining circuitry to perform a refresh cycle. The refresh cycle is terminated by negation of the refresh request signal after the predetermined number of refresh acknowledged signals is counted in a counter which forms part of the timer 200. The interrelationship of the refresh request signal and refresh acknowledge signal is illustrated in FIG. 29 which shows seven refresh acknowledge signals appearing within the asserted state of the refresh request signal. In practice, the predetermined number of refresh acknowledge signals is chosen to be 16 in the preferred embodiment described herein.

The arbitration control circuit 204 controls arbitration between the refresh and any type of host access such as a network or window access. The arbitration control is designed to operate on a first-come, first-served basis so that any "request" for refresh is simply treated as a request and is not operative in a true interrupt function. Thus, as between a host transfer and a refresh request, the existing mode of operation completes its cycle before deferring to the requesting second mode. The arbitration control circuit 204 includes a ROM table which operates, at least in part, according to the function table illustrated adjacent the arbitration control circuit block 204. When both the NETWORK* and HOST* signals are asserted, a network access is selected by the arbitration control circuit 204. If the NETWORK* is asserted with the HOST* negated, a refresh cycle is effected, whereas if NETWORK* is negated and HOST* is asserted, a window access is being performed. When NETWORK* and HOST* are negated, there is no memory transfer taking place to any of the rule processors.

The memory access control circuit 206 examines the I-MREADY> signal and the Complete signal, and if both are asserted, generates an "ACCESS2" signal which in turn causes a memory access operation. The ACCESS2 signal is transmitted to the timing control circuit 208 which generates the appropriate DRAM control signals for accessing all or a selected one of the memories 86 of the rule processors.

FIG. 30 illustrates the board clock circuitry which forms part of the miscellaneous circuits 210 of FIG. 28. The board clock circuitry 30 is seen to comprise a 25 Mhz oscillator module 220 and a plurality of counter chips 222 for dividing down the clock signal to provide the various divided signals as illustrated. Inverting buffers 224 are utilized with the upper counter chip 222 for sharpening the clock edges of the higher frequency clock signals.

FIG. 31 is a schematic diagram of the board reset logic which holds the two reset signals (L-RESET1* and L-RESET2*) low (active) for at least 81 microseconds which is long enough to effect the resetting of all of the rule processors CPUs. The circuit comprises two counters 226, NAND gates 228 and 230 and inverting buffers 232-234. The inputs to NAND gate 228 comes from either a hardware or software initiated pulse. The hardware pulse is the hardware set switch provided by the Multibus which generates the H-INIT* signal to the upper input of NAND gate 228. The interface may also provide a software reset as a decode of a predetermined output of the host databus for generating the software reset IF-RST* signal as a lower input to NAND gate 228.

One of the outputs of the board reset logic circuit of FIG. 31, namely L-RESET2* is fed to the reset port illustrated in FIG. 32. The reset port also forms part of the miscellaneous circuit 210 of FIG. 28. The reset port comprises a HexD flip-flop 240 AND gates 242 and 244 and a plurality of buffers and inverters as illustrated. The Request Int Enable and the Complete Int Enable are interrupt enable signals to the host to allow the host to be interrupted when a Request is generated or when all RPs complete processing.

The reset port provides the I-RESET* signal to FIG. 14 of the cell disable logic (termed C-RESET* in FIG. 14 since it is fed via the cell bus) as a buffered version of the L-RESET2* signal. The reset port provides the I-HALT and I-RUN signals to the cell disable logic of FIG. 14 (termed C-HALT and C-RUN respectively) conditioned by AND gates 242 and 244. The upper inputs of AND gates 242 and 244 come from the flip-flop 240 as a decode of the data from the host data bus. The lower input of each of AND gates 242 and 244 is connected to receive an inverted refresh signal from the arbitration control circuit 204 so as to negate the I-HALT and I-RUN signals during a refresh cycle. The reason both the HALT and RUN signals are negated is that the refresh cycle is a network type access to all rule processors whereas the HALT and RUN signals may be utilized in connection with all or a selected rule processor.

The AND gate circuitry is configured assuming that I-HALT and I-RUN are low when refresh occurs. Since Refresh is asynchronous to any host access, one cannot be sure when a refresh cycle will come along. Thus, for example, if the host is attempting to enable RP 43 (the forty-third rule processor), I-RUN is brought high through the reset port 240, RP 43 is accessed (any dummy access), followed by I-RUN being brought low again. If refresh started anywhere where I-RUN was high, all processors (not just RP 43) would start running. Thus, to prevent this erroneous result, the I-RUN and I-HALT signals are negated during refresh.

The network address decode logic 28 of FIG. 5 includes a board select logic circuit as illustrated in FIG. 33 and an I/O decode logic circuit as illustrated in FIG. 36. The board select logic circuit of FIG. 33 is seen to comprise a ROM 250, AND gates 252 and 254 and a flip-flop 256. The relevant equations governing the selection of the output signals as a function of the input signals are illustrated in FIG. 34 with the actual ROM table itself set forth in FIG. 35.

In FIG. 34, the symbol "@" represents an exclusive -OR operation, the symbol "*" indicates an AND operation (logical product), and the symbol "+" the logic OR (logical sum).

It is noted in FIG. 33 that the inputs to ROM 250 originate from the host address and R/W lines. The X-WINDOW* and X-NETWORK* signals go to the arbitration control circuit 204 (FIG. 28) and the signals from the flip-flop 256, namely WIG* and W2G* are utilized to enable the window ports to drive the window address bus. The clear and preset inputs of flip-flop 256 are conditioned by AND gates 252 and 254, the lower inputs of which are connected to receive the W1 and W2 access signals and the upper inputs of which are supplied respectively with signals W2CLK+ and W1CLK+.

Cell Bd Access line of FIG. 33 goes to the XACK* logic (FIG. 50). The I-Staten* signal is fed to the ROM 172 of FIG. 24 contained within the cell-select logic.

The AND gates 252 and 254 may more easily be understood by considering them jointly as OR gates. In other words, when W2CLK+ goes low OR W2-ACC* from the ROM 250 goes low, then the preset of the flip-flop 256 goes low thus enabling the Window 2 address to be placed on the IF bus. The W2-ACC* is required to force the Window 2 address to the I-WA0 to I-WA11 lines. The W2CLK+ also is used for the following reason: If the software writes a rule processor number to the WINDOW 2 port, then one can assume that an actual window 2 access will follow; thus, the hardware goes ahead and puts the Window 2 address on the I-WA0 to I-WA11 line.

The network address decode logic 28 of FIG. 5 is shown in greater detail in FIG. 36. The circuit is seen to comprise a read decoder 260, a write decoder 262 and a pulse output decoder 264. The host read and write signals are fed as inputs to the read and write decoders, respectively, which are both fed with the I/O Enable* signal from ROM 250 of FIG. 33. Both the read decoder 260 and write decoder 262 provide port select signals to input ports and control latches (for example, the Reset port of FIG. 32). The pulse output decoder 264 provides control pulses to the IF board circuitry--for example, the IF-RST* pulse to FIG. 31. The timings of the read decoder, write decoder, and pulse output decoder are similar but have different functions. Both the read and write decoders further receive the host address lines H-A 3 through H-A 5. The read decoder 260 provides a programmable interface timer read signal, PITRD*, and the write decoder 262 provides a similar write "programmable" interface timer signal PITWR*. These signals are fed to the refresh timing circuit 30 of FIG. 5 as explained more fully below. The W2CLK+ and WICLK+ from the write decode 262 are provided to the upper inputs of AND gates 252 and 254, respectively of FIG. 33. These signals are utilized to condition the AND gates for generation of the window write enable signals W1G* and W2G*. The pulse output decoder 264 provides the software reset strobe IF-RST* as an input to AND gate 228 of FIG. 31. This reset signal is provided as a decode on the host data lines D8-D12.

The RSTCLK+ signal from the write decoder 262 is fed as the clock input to the flip-flop 240 of FIG. 32.

The data buffer 52 of FIG. 5 may simply comprise 74LS640 inverting tri-state buffers for connecting the host data bus (prefixed by H-) to the local data bus on the interface board (prefixed by L-). Further, the window ports 34 and 36 of FIG. 5 may simply comprise 74LS374 latches which are connected at the output control (terminal 1) thereof to receive the W1G* for the window 1 port and the W2G* for the window 2 port. The clock input (pin 11) is connected to receive the WICLK+ signal for the window 1 port and the W2CLK+ signal for the window 2 ports. These signals are supplied by the write decoder 262 of FIG. 36. Thus, the window 1 ports merely latch the local data lines L-D0 through L-D15 to the window address lines W0 through W11 (although 16 bits are latched, only 12 bits are used for the window address lines). The window address lines W0 through W11 are buffered in the buffer 62 of FIG. 5 and the resulting output is denoted by the interface window address lines I-WA0 through I-WA11.

The interrupt control register 40 of FIG. 5 is illustrated in FIG. 37 and is seen to comprise a Quad D flip-flop for providing the three interrupt output lines I-INT0* through I-INT2* latched from the local data lines L-D0 through L-D3. The local data lines are in turn derived from the host data bus by the data buffer 52. The clock and clear inputs to the flip-flop 270 are provided respectively by the INTCLK+ signal from the write decoder 262 of FIG. 36 and the L-RESET2* signal from the board reset logic of FIG. 31.

The buffered output of flip-flop 270 provides the I-INT0* through I-INT2* signals to the local rule processors CPU. Normally, these signal links are high and are driven low when the host needs to interrupt all rule processors. It is noted that all rule processors are interrupted simultaneously and in parallel. In contrast, memory transfer can take place either in a network fashion or on a per-rule processor basis.

The status input port 38 of FIG. 5 may simply comprise one or more data buffers in the form of 74LS245 chips to permit reading of any number of plurality of lines determinative of the status of the system. Such lines may include the bus error line, BERR*, the completion line, the L-RESET2* line, etc. The status input port is enabled by the status read signal STATRD* from the read decoder 260 of FIG. 36.

The timer 200 of FIG. 28 is illustrated in FIG. 38. The timer 200 is seen to comprise a programmable interval timer (PIT) 8254 which is programmable by means of the host CPU via the data lines L-D0 through L-D7. The PITRD* and PITWR* signals come from the read decoder 260 and write decoder 262 of the I/O decode logic of FIG. 36. Timer 0 of the PIT timer is utilized to provide the time interval between the refresh pulses Timer 1 of the PIT timer is utilized to actually count the refresh acknowledge signals, RF-ACK+. The outputs of the timer 0 and timer 1, namely PIT-OUT0 and PIT-OUT1 are provided to the refresh control circuit 202 of FIG. 28 which itself is further illustrated in FIG. 39. The refresh control circuit 202 is seen to comprise a latch 280 and a ROM 284. The purpose of the refresh control circuit is to generate the refresh request signal, RF-REQ. The latch 280 and ROM 284 are configured to implement a finite-state machine. The ROM table for ROM 284 is set forth in FIG. 40 and the state machine diagram is illustrated in FIG. 41.

During the time period in which the refresh request, RF-REQ, signal is high, the PIT timer 200 counts the refresh acknowledge signals RF-ACK+ until 16 such signals are counted. After this time, the finite state machine of FIG. 39 transitions from state 2 to state 3, thus removing the refresh request signal.

The refresh request signal, RF-REQ is fed to the arbitration control circuit 204 of FIG. 28. The arbitration control circuit 204 is shown in more detail in FIG. 42 and is seen to comprise a latch 290 and a ROM 294. The host network and window signals are also latched by means of the latch 290 and fed to the ROM 294. The ROM table for ROM 294 is illustrated n FIG. 43. In this ROM table, it is noted that the inputs designated "X" and "Y" correspond to "I-NETWRK*" and "Host*" in FIG. 28. The purpose of the arbitration control circuit 204 within the interface board is to provide arbitration between a refresh and a host transfer state. The refresh cycle is performed while the refresh request signal is asserted (high), and during this time the host must wait until the 16 refresh acknowledge, RF-ACK+, signals are counted in the PIT timer 200. After the refresh has completed, the host may initiate a memory transfer either to a selected processor via a window transfer or to all processors via a network transfer. Thus, the X-NETWORK* signal provided by the board select logic of FIG. 33 is transformed in FIG. 24 to the I-NETWRK* signal subsequently fed to the cell select logic of FIG. 24 for each of the cell boards. Similarly, the X-WINDOW* signal from the board select logic of FIG. 33 is transformed in FIG. 42 to the I-WINDOW* signal which in turn is fed to the cell select logic of FIG. 24. The refresh signal as an output of the ROM 294 of FIG. 42 is fed to several places in the interface 20 including the reset port of FIG. 32 and the memory sequencer 208 of FIG. 28. The refresh signal is further provided to the cell boards as the C-REFRESH signal fed to the cell select logic of FIG. 24. The Access 1 signal from the ROM 294 is fed as an input to the memory ready control 206 of FIG. 28.

The Access 1 signal from the arbitration control circuit 204 of FIG. 42 is fed to the memory ready control circuit 206 of FIG. 28. The memory ready control circuit 206 is further illustrated in FIG. 44. Memory ready control circuit 206 is seen to comprise a flip-flop 300, ROM 302 and a shift register 304. The shift register 304 is made up of a plurality of 74 ALS 174 flip-flops arranged in a one-shot configuration. The Access 1 signal is fed to the clear input terminal of the flip-flop 300 and to each flip-flop within the shift register 304. Flip-flop 300 receives the wire OR'ed "Complete" signal which is the composite complete signal derived from each of the rule processors cell disable logic circuitry as shown in FIG. 14. (See also FIG. 49 below.) The MReady signal is similarly derived for each rule processor from the arbitration control logic circuit of each cell as shown in FIG. 13 (and FIG. 49). The Complete signal is high if no rule processor is running, and the MReady signal is high when the rule processor memories are ready to receive a new data transfer. The ROM table for ROM 302 is set forth in FIG. 45. The output of ROM 302 is the ACCESS 2 signal which indicates to the host that a new memory transfer is now possible since no rule processors are running and the memory ready condition for all rule processors is asserted. The Access 2 signal is fed to the timing control circuit 208 of FIG. 28.

The timing control circuit 208 is further illustrated in FIG. 46. The timing control circuit 208 is seen to comprise a state machine made up of flip-flop 310 and ROM 312, and is further seen to comprise a sequence ROM 314, flip-flop 316 and multiplexer 318. Instead of ROM tables for the ROMs 312 and 314, use is made of the timing diagrams set forth in FIGS. 47 and 48. ROMs 312 and 314 may be thought of as a single ROM chip with bytes below (10)hex govern a host access as shown in FIG. 47 and bytes above (10) hex governing a refresh access as shown in FIG. 48. Thus, the signal Refresh is fed to the fifth bit of the F/F 310, and when Refresh is asserted (logic 1), the upper bytes, beginning at address (10)hex, of ROMs 312 and 314 are addressed resulting in the timing diagram of FIG. 48. It is further noted that the inputs to the ROM 312 and sequence ROM 314 are the same. In both FIGS. 47 and 48 the waveforms illustrated correspond to the output of the sequence ROM 314, and the numbers at the bottom of each graph in FIGS. 47 and 48 correspond to numbers stored in the ROM 314 and ROM 312, respectively. For example, in state 0 for the host access of FIG. 47 the number "FA" is stored in the ROM 314 whereas the number "01" is stored in ROM 312. State 09 of the ROM 312 for the host access of FIG. 47 loops back around on itself and cycles indefinitely in state 9 until the host is finished with accessing any one or all of the rule processors. The first 3 cycles, namely states 01 and 2, are dead-time cycles designed to permit signal levels to settle down prior to host access.

It is further noted for the host access of FIG. 47 that the reading and writing time for the dynamic RAM are different and that if one wants to read it is necessary to wait an extra 3 cycles (states 6, 7, and 8) in relation to the write timing. In the implementation provided, separate read and write cell acknowledge signals are provided and selected by means of multiplexer 318 utilizing an OR'ed Host*/WR* condition for the select terminal thereof. The output of the multiplexer 318 provides the cell transfer acknowledge (cell XACK*) signal which may either be the read or write transfer acknowledge signal, depending upon whether the host is performing a read or write operation. The write cell acknowledge signal is generated immediately after the CAS* signal is asserted as compared with waiting an extra 3 cycles for the read transfer acknowledge signal. This increase in speed for a write operation is possible by taking advantage of the DRAM chip operation in which one may write data into memory on the falling edge of CAS*. For a read operation, however, one must wait the extra 3 cycles for the data to become available.

The FIG. 48 corresponds to a RAS only refresh. Only 7 states of the state machine defined by ROM 312 are present and the system would normally cycle around the 7 states but is terminated by means of the negation of the RF-ACK+ signal sent to the PIT timer 200 of FIG. 38.

The output signals of the timing control circuit 208 shown in FIG. 46 provide the RAS and CAS strobes for the dynamic RAM memory at the appropriate timing as shown in FIGS. 47 and 48. The host may access any of the rule processors in a read or write mode for a window access or all of the rule processors in a write mode for a network access. The network access is a write only access whereas the window access may be either read or write. For example, in a network access, the host generates an appropriate address code on the address lines H-A18 through H-A23 together with the appropriate write signal H-WR* signal which is fed to the ROM decoder 250 of the interface as shown in FIG. 33. The output of ROM 250 is the X-NETWORK* signal which is provided to the arbitration control circuit of the interface as shown in FIG. 42. The output of the arbitration control circuit 204 generates the I-NETWORK* signal which goes to the cell board logic and in particular the cell select logic of FIG. 24. The I-NETWORK* signal then generates the cell select signals for all of the rule processor cells on the board, namely, C-SELECTn* is asserted for n 0,1,2,3. In this manner, the I-NETWORK transmission accesses all processors on all boards at the same time. Moreover, the host network address accesses the same memory location in all of the rule processors which may be any location within the 512 K memory space of the rule processors starting at the host address C00000 (hex) as shown in FIG. 2. If any rule processor is running during the time the host wishes to assert a network access the Complete signal is low providing a zero input to the flip-flop 300 of the timing control circuit 206 of FIG. 44. It may be recalled that the Complete signal is derived from the cell disable logic of FIG. 14 (via FIG. 49) and is driven low if any of the rule processors on any circuit board are running.

The complete signal is the inverted signal of the run state signal. The presence of the complete signal being negated in FIG. 44 indicates that the memory ready control circuit 206 must await receipt of the appropriate memory ready signal which will occur only after all rule processors have stopped running and the DRAM memory of each rule processor cell is ready to receive a bus transmission. The cell select signal, C-SELECTn* is fed to the cell board arbitration control logic circuit as shown in FIG. 13 which arbitrates within each rule processor cell. If the particular rule processor is not running, the arbitration circuit asserts C-MREADY> indicating that a memory transfer is permitted. However, if any particular rule processor is running, the arbitration circuit negates C-MREADY> and, thus, by pulling memory ready low, indicates to the memory ready control circuit 206 of FIG. 44 that a delay time will be needed prior to a memory access. As far as the interface board is concerned, the open collector nature of the memory ready (MReady) signal means that the MReady signal is negated even though only one rule processor is running. In this sense it does not matter to the interface whether one or more processors are running at this time. When all rule processors have stopped running, each MREADY> signal in FIG. 13 is asserted (one for each RP) which results in the MReady signal of FIG. 44 being asserted. The shift register 304 of FIG. 44 forces a certain delay time to insure that there is enough time to get the C-SELECTn* out to each RP so they can pull MReady low if they are not ready to release their own (local RP) bus. The shift register 304 forces a delay in this case to insure MReady is valid.

When the ACCESS2 signal is generated, it is fed to the state machine comprising the flip-flop 310 ROM 312 of FIG. 46. The generation of the ACCESS2 signal basically initiates the generation of all of the row and column strobes for the dynamic RAM memory of all of the rule processors and provides the upper inputs to the local memory control logic as illustrated in FIG. 11.

The refresh count signals, RF-CNT- is provided as an output to ROM 314 of FIG. 46. The waveform for the refresh count signal is shown in FIG. 48. The refresh count signal is fed to the refresh counter 32 of FIG. 5 which comprises an eight bit counter fabricated for example from 74LS393 chips. The output of the refresh counter 32 provides refresh address lines RA0-RA7 to the address multiplexer 44 of FIG. 5. The address multiplexer 44 may comprise 74ALS253 chips and selects between the refresh address and the host address fed by the host address bus and the swap plug 46. One of the select terminals for the multiplexer 44 is provided by the refresh signal generated from the arbitration control circuit 204 of FIG. 42, and the other select terminal for the multiplexer 44 is provided by the Row/Column* signal generated by the timing control circuit 208 of FIG. 46. The address swap plug 46 simply insures that the interface bus address lines correspond to the correct local bus address lines and cell bus address lines. The swap plug may be a simple 40 pin DIP socket used to provide an address swap jumper.

FIG. 49 illustrates the conversion of the open collector interface signals to the corresponding TTL signals utilized on the interface board itself. For example, the open collector I-COMPLETE> from FIG. 25 is converted to TTL logic to become the "Complete" signal utilized, for example, in FIG. 44. Simple pull up resistors, buffers and inverters are utilized to convert the other signals as shown in FIG. 49. Further, a RUN state indicator signal may be provided by means of an LED as shown in FIG. 49. This LED comes on whenever any RP is running.

FIG. 50 shows the circuit diagram of the transfer acknowledge control circuit 48 of FIG. 5. The circuit is seen to comprise simply a ROM 330 for which the ROM table is illustrated in FIG. 51. The purpose of the circuit is to provide the host with the requisite transfer acknowledge signal to complete a memory transfer cycle. The cell XACK* signal is provided as an output to multiplexer 318 of FIG. 46. The "I/O Enable*" signal is derived as an output from ROM 250 of FIG. 33 as well as is the Cell Bd Access signal. Also, the "X-STATEN*" signal is derived from ROM 250.

One of the primary features of the system described herein is the provision for parallel processing of the left hand sides of the various rules while the right hand sides are fired by means of the host processor which transmits the results of this firing in a network transmission to all of the rule processors. The results of a rule firing are either to make new working memory elements or to remove old working memory elements. The modify command is simply a combination of make and remove and thus need not be considered separately. Typically, vector commands for make, modify and remove are transmitted to the rule processors utilizing small numbers which may then be indexed by the rule processors utilizing a vector table.

As a simple example of a network transmission format reference is made to FIG. 52. It is assumed that the program has previously literalized the element class "GOAL" defining three attribute, namely, WANT, ID and STATUS. As a result of firing, a particular rule, a value may be associated with the attribute WANT, in particular the value "HOUSE". The right hand side firing may then call for the making of the new "Goal" working memory element defined by the attribute-value pair WANTHOUSE. The host processor will then transmit this new working memory element as well as the command for making same to all of the rule processors in a network transmission. Although the format for the transmission of the new working memory element may take many forms, it is advantageous to simplify the amount of data transmitted to reduce transmission time and complexity of coding and decoding the transmitted results. Thus, as shown in FIG. 52, the transmitted message 500 is composed of a command (CMD) field 502, an RHS number field 504, an element class or class number field 506, a time tag field 508, and three attribute fields, 510, 512 and 514 corresponding respectively to ATT1, ATT2 and ATT3. The RHS number field 504 may be used to uniquely identify the RHS's of all the rules and is useful for building the network links between RHS actions and LHS conditions affected by each RHS action. (It is noted, however, that in the programs set forth in the appendix, the RHS number field is not used, as this feature is currently not implemented.) The class number field 506 is used for defining the element class, in this case GOAL. The attribute fields are preassigned, position dependent fields such that it is not necessary to transmit the actual attribute itself but only the token or value of the attribute as called for in the "MAKE" command. In other words, field 510 is always reserved for the value of attribute 1, field 512 for attribute 2 and field 514 for attribute 3. These attributes are assigned in the literalize command for the class "GOAL. " Thus, in transmitting the new working memory element for the pair WANT HOUSE, it is only necessary to put the token for HOUSE within the ATT1 field 510. Fields 512 and 514 are assigned the nil token (0-hex) since no values have been assigned to these attributes in the "MAKE" command of the example.

The rule processor receives the message 500 and responds to same only if it has a left hand side which can be affected by any of the attributes of the class element GOAL. If no left hand sides within the rule processor utilize the class element GOAL, the rule processor simply ignores the message and waits for another message which contains an element class for which the particular rule processor has a defined left hand side.

FIG. 53 illustrates yet another message format 520 which contains a command field 522 for removing a WME, RHS number field 524 and time tag field 526. The time tag field stores the time tag of the working memory element. The time tag is a unique integer associated with a working memory element, so generated that the most recently created WMES bear the largest numbers. The time tag may be utilized for conflict resolution purposes in the event that more than one set of combinations of working memory elements satisfies a particular rule left hand side during the recognize part of the recognize-act cycle.

The time tags may be utilized for conflict resolution in the sense of a rule processor having a single rule with multiple combinations of working memory elements satisfying the left hand sides thereof and also for purposes of selecting among multiple rules within a particular rule processor where the particular rule processor stores the LHS of more than one rule. Conflict resolution is of course, applied over all rule processors. The message for "MAKE. " in FIG. 52 has 2 constant length header with the number of attribute fields determined by the LITERALIZE statement for given class. Each attribute field is four bytes in widths the message for "Remove" in FIG. 53 is always a constant length. In the implemented embodiment, four bytes are utilized for each field, i.e., a 32 bit message length, with the details of the stream codes set forth in FIG. 59 discussed below. It would also be possible to utilize a message length designation field at the beginning of each message to specify the number of bytes or to utilize an end of message designator as alternate mechanisms to tell the rule processors when the end of a message occurs.

The various programs described below and set forth in the appendix represent examples of the codes stored both in the host and rule processors. The language used for implementation of the software is the FORTH Inc. version of FORTH known as PolyFORTH. A version of the PolyFORTH has been modified to run on top of the CP/M-68K operating system from Digital Research The CP/M-68K provides a simple file structure for reading source code files and user OPS files. CP/M-68K is a single-user/single-tasking system and does not interfere with the operation of the parallel processing implementation of the OPS language. Thus, while running OPS, CP/M-68K is only used for file I/O and character I/O to the console and printer. Also, CP/M-68K does not have any "knowledge" of the parallel processors or the status display that is used within OPS. For more details on the OPS language, the reader is referred to the Brownston et al reference and the OPS User's Manual mentioned above. For the FORTH language, reference is made to the PolyFORTH II Reference Manual, FORTH, Inc., Ray Vn DeWalker et al, 1983, and to the publications of Leo Brodie, Thinking FORTH and Starting FORTH (Prentice-Hall, Inc.), all of which are incorporated herein by reference.

The programs POLY.PF and RPPOLY.PF are the host and RP PolyFORTH codes respectively.

The program FILES.PF was developed to allow the POLYFORTH program to run under CP/M-68K and to permit access to various source files.

The program PFEDIT.PF contains the original POLYFORTH line editor and is part of the commercially available POLYFORTH system.

The file FSEDIT.PF contains the sources for a full screen editor and is designed to run on top of the POLYFORTH program.

BDOS.PF allows OPS to access the character and disk I/O of the CM/P-68K operating system.

The file TIME.PF contains time and date format routines.

The program TERMINAL.SCR allows the video terminal (for example, VT100 terminal) to be accessed for various display purposes.

The program SBE.PF contains initialization parameters for the SBE M68K10 multibus single board computer. This code is provided also time and date information, accessing the printer, etc.

The program MAC.PF contains the initialization parameters for the MacIntosh running IQ Software's CP/M-68K implementation.

The program XFER.SCR contains a code for a simple file server system to allow the MacIntosh and the SBE system to exchange files.

The program TOKEN.PF contains the token package that allows each string argument to be converted into a single 32 bit token.

The program HOST.PF contains the port definitions of the interface board, system initialization and rule processor support.

The proggaa DISPLAY.PF contains a display server that acts as a status display and a server to a selected rule processor. This program permits efficient debugging of code within the rule processors.

The program PARSER.PF contains the OPS parser and command line interpreter utilized for compiling the OPS program.

The programs OPSVAR.PF and OPSCMD.PF give the OPS variable and command codes respectively.

The program MM.PF is the memory management package program.

The program WME.PF is the management program for the host work memory elements.

The program RHS.PF sets forth the RHS parser and execution codes.

The program RPVAR.PF gives the RP variables and support code.

The program RPWME.PF gives the RP working memory management program.

The program FILTER.PF is the code for the RP LHS filter.

The program LHS.PF gives the LHS evaluation code.

The program CONRES.PF sets forth the conflict resolution code package.

The program COUNTER.PF gives the OPS counter statement support code, an extension to the OPS language.

As an example of some of the features of the software, reference is made to the program HOST.PF. The left hand screens represent the actual FORTH program with the right hand screens being the "shadow" screens utilized for comment statements. Screen 1 the load screen and screen 2 simply defines various constants. The constants defined in screen 2, for example, correspond to the memory map addresses as shown in FIG. 2 as well as the addresses for the PIT timer, status port, etc. Screen 3 translates words by adding a network address to the offset generated by the host processor. Thus, if the offset is 20, the network address is added to 20 in order to get the proper address within the network space. Screen 4 is utilized for initializing and refreshing the system. The element COLD is utilized to provide a cold boot to the POLYFORTH program. PULSE-INIT is the software reset that forces generation of the reset signal IF-RST* of FIG. 36 which is in turn fed to FIG. 31 for performing the software reset function.

Screen 5 allows low level support to turn the rule processors on and off. Screen 6 provides the necessary words for allowing interrupts to be sent to the rule processor. Screen 7 defines the timer words to the PIT timer and reads the timer 2 signals. Screens 8-11 are used to load the software from the disk onto the various rule processors. Screen 12 is simply a utility screen, and Screen 13 initiates the blink display test. Screens 14 and 15 are utilized for request service and debug support respectively. The HOST.PF program provides the first level of access to the rule processor hardware for the rest of the system.

FORTH runs on both the host processor 4 and the parallel rule processors 6. On the host, the polyFORTH runs under CP/M-68K. It is pointed out that polyFORTH is multitasking but CP/M-68K is not. The polyFORTH multitasker is used to provide a status and server task. This server task communicates with the display terminal (for example, a VT-100 type terminal) through a serial link. This task normally shows a status screen to allow the user to see how the OPS program is running. However, this same task can be placed into a server mode, allowing a debugging environment for the rule processors. Only a single rule processor can be debugged at a time.

On the rule processors, the polyFORTH is the only operating environment. Character and file I/O for the rule processors is done through the server task that runs on the host and is used for program development and debugging. Since there is no ROM on the rule processors, the host loads the RP FORTH from a disk file. It then determines which processors are available. All normal communication between the host and the RP's goes through a reserved area at the very top of the RP memory. This is done mainly to prevent the host from having to know about the internal memory structure of the rule processors.

A token package (TOKEN.PF) has been implemented on the host to allow all strings and numbers to take on a 32 bit token. In this manner, comparisons on the RP's can simply be a 32 bit comparison as opposed to a full string comparison. During normal OPS execution, only tokens (created in the host) are passed between the host and the rule processors. This procedure cuts down on the system complexity and the amount of information passed between the host and the rule processors. The token package is passed a string and then determines if it is numeric or not. If a string is numeric, then the number is converted into a 32 bit token that has the upper bit set. Therefore only 31 bits of numeric precision are maintained. If a string is found to be non-numeric by the token package, then it is converted into a string token with the upper bit forced to O. String tokens are simply the address of the string within the host token memory area. Since equality and inequality comparisons must be done on string tokens by the RP's, string tokens must be unique and not duplicated. In other words, tokenizing a particular string will always return the same token for a particular run. This is done by searching the existing strings being held by the token package. If a string exists already, then the address is returned as the token. If a string does not exist, then it is added to the token package and the address is returned. Note that the address of the string in the token package is returned as the token. This is not essential, but is convenient to the host in converting the token back into a string. The token package consists of multiple linked lists to reduce search time. Experience with the system shows that most of the tokens are created at compile time when a new OPS program is being loaded. Also, new tokens are usually added when the user is asked to enter something from the keyboard. In either case, speed is not very critical, so the search time to add a new string to the token package is not a limiting factor.

The next paragraphs will show a general sequence of operations required for the parallel processing OPS initialization and program compilation. When OPS is first started from CP/M, the rule processors are loaded with their operating environment from the disk file RPFORTH.IMG, which is a machine language version of the programs set forth in the appendix. The "IMG" signifies binary image file. The RP's are then started and return a flag to tell the host that they exist and are operational The RP's also initialize their own variables and memory arrays. The RP's then stop because there is nothing else for them to do. The host also does some initialization.

The host then prints the "OPS>" prompt and waits for user commands. As commands are entered, they are executed when the user enters a carriage return. The user can also load commands from a file with the "(LOAD filename.ext)" command. This simply redirects the input to come from a file. The user will generally load a file with an OPS program. The host does all of the parsing for the system. This is important since tokens are being added at compile time and only the host can perform the tokenizing task. Also, error messages will be printed by the host. The parsing starts with the host determining which RP will receive the rule LHS's. This is done by checking the exist on each RP. The RP that currently has the smallest number of LHS's is selected for receiving the new rule. Other algorithms may be used, but the above algorithm is advantageous since it does not require a look ahead approach. The OPS parser is a one pass compiler As each rule is parsed, the host reads the LHS's, checks for proper syntax, then adds a simple command to the RP stream and stores the stream in a host stream buffer. It is this stream that concisely defines the LHS's for the RP's. After all of the LHS's of a rule are compiled, the host sends the stream in the host stream buffer to a selected RP which converts this stream into executable code for later evaluation. Also, if the host stream buffer is filled before all LHS's are parsed, then as much as possible is given to the RP. The host will then clear the stream buffer and continue to fill it from the beginning. The host will then start reading the RHS's of the rule. Executable FORTH code is placed in the host memory as the RHS's are compiled. After the last RHS is compiled, the host has completed parsing for a particular rule. This process repeats until all rules have been loaded.

During the compile phase, the RP's are responsible for accepting the command stream from the host. This stream is sent only to a single processor during the compile phase using a window transition mode. A RP reads the stream and compiles executable FORTH code into "filters" to be described shortly. The "filters" may also be executable machine code which will speed the system up noticeably. After a RP has finished with the stream sent to it by the host, it simply stops.

The next paragraphs describe the operations that take place during the actual execution of an OPS program. The Recognize-Act cycle consists of three main parts: the recognize part that takes place in parallel on the rule processors, the conflict resolution part that takes place both in the rule processors and the host, and the act part that takes place on the host.

The recognize code resides on the rule processors. Basically, this code has to find all fireable instantiations (self-consistent sets of working memory elements) that can satisfy each rule given the current state of the working memory. This code is split into two parts - a "counter" and the filter The counter has to go through all reasonable combinations of working memory elements that may satisfy a rule. Each LHS is assigned a list of WME's that satisfy the literal conditions. This is done by checking the literal conditions through the LHS filter for each LHS. The counter has to go through all reasonable combinations of WME entries on each of these LHS lists. There are many combinations that are not reasonable. For example, if the second LHS variable bindings did not match the first, there is no reason to check the third, fourth, etc. LHS for any matches. Therefore, the counter code goes on to try to find another WME entry in the second LHS list that will match the variable bindings that were assigned by the first LHS. By eliminating this extra work, the rule filter has to go through only hundreds of possible matches instead of millions. Another thing that the counter code does is to enter the rule filter in such a way as to eliminate unnecessary work. For example, if a particular WME did not match the third LHS as far as variable bindings from the first and second LHS is concerned, then another WME from the third LHS list must be tried. The counter code will reenter the rule filter at the third LHS. This will speed the filter up since it is known at this point that the first and second LHS's are self-consistent. The details of the counter code are found in the program LHS. PF.

The "filter" is a very important concept to the AI Machine. Basically, a rule LHS set is compiled into several filters Each filter returns a single flag that indicates a pass or no-pass condition. There is a filter for each LHS of a rule. This filter deals only with the literal comparisons that have to be executed in order to accept a new WME to match a single LHS. There is a precheck filter that checks to make sure that there is at least one WME to match each non-negated LHS for a rule. Also, it checks to make sure that any negated LHS's that have no variable bindings have no WME matches. The precheck filter is simply a convenience and makes the rule filter code simpler The rule filter is a single filter for each rule that binds variables and checks for conditions on previously bound variables. Each rule filter has as many entry points as there are LHS's. This is to allow efficient scanning through the lists without starting at the top each time. The 15 filters are described in more detail below, and the filter code is set forth in detail in the program FILTER.PF.

Conflict resolution takes place both on the rule processors and the host. Since each RP may have several rules, they perform conflict resolution on the rules contained within them. Only the most fireable rule will be passed back to the host by each RP, and the host, in turn, performs conflict resolution on these fireable rules. In this manner, the host only has to perform conflict resolution over the number of RP's, not the number of rules, which may be much larger in a complex expert system.

After the host determines which rule to fire, it then performs the actual firing of the rule. This consists of executing the RHS code that was previously compiled into the host memory. Parts of this code may look into the RP that contains this rule to get variable bindings and the conflict set. The act of firing a rule will usually require sending changes to the working memory to each of the rule processors. The types of changes are MAKE, MODIFY and REMOVE After the host has executed all of the RHS code, the Recognize-Act cycles starts over again.

The memory management routines in MM. PF run on both host and RP's and serve several useful functions. Basically, the memory manager allows variable sized arrays to be defined in the system. These arrays can be resized at any time. There are two different kinds of arrays or "frames" known to the memory manager--static frames and dynamic frames. Both kinds of frames can be resized or removed at any time, however the static frames are reserved for the type of data that does not require very much resizing. Therefore, static frames are kept next to each other without any free memory between them. Dynamic frames are the ones that need to grow and shrink quickly Therefore, dynamic frames are kept spread out in memory with some free memory above each of them to allow each one to grow quickly. When there is not enough free room above a dynamic frame that needs to grow, the system will reallocate so that there will be enough room. This takes some time, but occurs fairly infrequently.

On the host, the static frames are used for holding the RHS code of all of the rules. Literalize definitions are also held in static frames as well as pointer tables to rules and literalize definitions. Dynamic frames on the host are used for holding the WME list and WME definitions. These need to grow and shrink rapidly during the execution of an OPS program.

The RP's use static frames to hold LHS and rule filters as well as a few pointer tables to the LHS's and rules. Dynamic frames are used to hold the local working memory as well as the pointer table to allow quick access to any local WME.

Since all frames must be relocatable in memory, handles are used to hold the actual address of the frame. The handles never change location, therefore code can always gain access to the frame required. Handles also hold other information required internally to the memory manager. Basically this information assists the memory manager when a reallocation is required. The size of the frame is kept as well a doubly linked list. The doubly linked list is used for reallocation. This list is kept in the same order as the frames in memory, even though the handles may not be in order. There are separate lists for static frames and dynamic frames. When a reallocation occurs, frames are moved to one end of memory and then moved back to the proper place. Static frames are always kept together, while dynamic frames are kept spread apart for the most part. Sometimes, dynamic frames are kept together during such processes as creating a new dynamic frame and creating a new handle, both of which would occur during the system compilation and therefore are not critical conditions.

FIGS. 54A and 54B show a simple organizations of the memory for the host and RP's, respectively. In both the host and RP's, the memory management package consists of three main parts--the handles 550, dynamic frames 552 and static frames 554. In addition to the area of memory that is controlled by the memory management package, there are such things as the system software 556 that resides in low memory and memory area 558 which contains the FORTH stacks, disk buffers and other items These areas of memory are not managed by the memory management package.

The frame handles 550 are stationary in memory once created. In other words, they never move once assigned The frame handles 550 always point to the actual dynamic (552) or static (554) frame in memory. Therefore a double fetch is required to get the actual address of the frame given the handle address.

Static frames 554 are kept at the bottom of the memory managed by the memory management package. There is no room left above each static frame because it is assumed that it will not grow or shrink rapidly.

Dynamic frames 552 may grow or shrink rapidly and therefore are given free memory above each dynamic frame. When a dynamic frame shrinks, it will never cause a reallocation. When a dynamic frame grows, it may cause a reallocation. This reallocation will occur only when the amount to grow is larger than the free space above the dynamic frame. In most instances, the amount to grow is relatively small and the system will not have to reallocate memory often. Experience with the system shows that once the initial reallocation forces the dynamic frames to be spread apart for the first time, memory reallocation occurs very infrequently. Only when the available memory goes down does the memory manager start to become a problem and reallocate fairly frequently. Experience shows that this only becomes a problem when more than 100 rules are placed in each processor.

Although the overall layout of the memory for the host (FIG. 54A) and RP (FIG. 54B) is the same, the actual data stored within the dynamic and static frames are different as summarized in the table below:

An important further difference between the host and RP memory arrangement is seen by the presence of a reserved area 560 which is positioned at the top of the RP memory (FIG. 54B) and is not required in the host memory (FIG. 54A). Reserved area 560 is the same address space for all of the RP's and is used by the host for both window transmissions (LHS stream communication) and for network transmissions (i.e., transmission of WME's). Such information is stored in the RP network buffer. Also part of the reserve area 560 is utilized to store the RP system variables as set forth in screens 2-8 of RPPOLY.PF. Of these variables, the variable <BEST-RULE> in screen 7 of RPPOLY.PF provides an indication of which rule "owns" the conflict set array <CONFLICT-SET> and the sorted conflict set <SORTED-CS> is the most fireable rule within the particular RP as determined, for example, by standard recency and complexity criteria. If only one rule is stored within a particular RP, the <BEST-RULE> variable stores a 0 (for the rule number within the RP) if the rule is fireable and a -1 if the rule is not fireable. Thus, the <BEST-RULE> variable serves as a match flag indicating to the host that particular RP has or has not determined the existence of a self-consistent set of WME (<SORTEDCS>) and thus has a fireable rule.

The conflict set is the set of self-consistent working memory elements ordered per the LHS of each rule and is used by the RP in connection with host rule firings. The sorted conflict set is the same grouping of WME's but ordered with the most recent time tags first as an aid in conflict resolution.

After the completion flag (FIG. 1 indicative of the RUN state signal from each RP) indicates to the host that all RP's have finished the recognize or match phase of the Recognize-Act Cycle (RAC), the host polls in turn each RP accessing the variable <BEST-RULE> to determine if a match condition is satisfied, (i.e, <BEST-RULE> set to other than a -1) thus indicating the existence of a fireable rule. If a rule is found to be fireable, the host reads the sorted conflict set array stored in the variable array <SORTED-CS>.

FIG. 55 shows the organization of the frame handles. Each frame handle actually contains four long-words of information. The first is the pointer to the frame itself. The second and third are doubly-linked lists used by the memory manager only. The fourth is the size of the frame, used both by the operating code and the memory manager.

The doubly-linked list exists only for the use of the memory manager. These lists allow the memory manager to scan both up and down the dynamic and static frames in the order that they exist in memory. When a reallocation is required, this ordered list is required. For a dynamic frame reallocation, the memory manager is designed to move all frames to one end of memory and then move them again them out. A zero word is at the end of each linked list.

In any multiprocessor system, the communication between processors is a very important factor. For the parallel AI machine, there are several types of communication between the host and the RP's. They are:

RP Reset

RP Interrupt

Server Commands

RP Stream Codes

Of these, the RP Stream codes are the most important. The other functions are support functions.

FIG. 56 is a table of the reset codes that the host sends to the rule processors upon hard reset of the RP's. The code is placed in the location <BOOT-CMD> within the rule processors. Note that the code offset is in increments of 4 bytes corresponding to a 32 bit word for the 68000 microprocessor. Of interest are the CONFIG-CHK which is used by the host in order to determine which processors are available. The RP-COLD is used to initialize the OPS operating code in each RP. The RP-MTEST is used to check memory in the RP's.

FIG. 57 shows a table of the interrupt codes that are used by the host to start an interrupt service routine on the RP's. The code is placed in the location <INTR-CMD> within the rule processors. The 0 code is special. If a RP encounters an interrupt with a 0 code placed in the <INTR-CMD> location, then it will simply return from the interrupt. The host interrupts a single processor by placing a zero in every other processor's <INTR-CMD> location and the non-zero interrupt vector code in the RP that it wishes to interrupt. This is used primarily for compiling rule LHS's into a selected RP's. It is to be recalled that all RP's receive an interrupt at the same time. This software trick allows some simple control by the host as to whether only one RP get interrupted or if all RP's get interrupted.

The INTERPRET-STREAM is the main interrupt routine for the compilation and execution of OPS programs. In this mode, stream codes are placed in the network buffer by the host and are executed by the RP's.

FIG. 58 is a table showing a list of the server commands from the RP to the host. The commands are used for a debug function only, and thus, only one RP can be served at a time. The SERVER task on the host continually reads the <SERVER-CMD> location and executes the command found there. Most of the time, this command is zero and nothing is done. Disk I/O is implemented for debugging on the RP itself as well as the rebuild function that allows the RP to build a new FORTH system from the stripped-down kernel. Several TOKEN print commands are implemented to allow the RP to print the value of tokens without having to know the token string itself. This is used within debugging of a particular RP during either compilation or execution.

FIGS. 59 and 60 list and describe all of the "INTERPRET-STREAM" RP Stream Codes that are sent from the host to the RP during LHS compilation and main execution. The network buffer can hold many stream codes, one after another, in memory. In this manner, "chunks" of data can be sent to the RP's at once. Typically, only one network transmission is required to send the RHS actions to the RP's. If more are required, then two or more network transmissions are sent. The stream codes are used for both actual LHS compilation and main program execution. Examples will be given of the RP Stream Codes in use.

The parser on the host reads the source OPS file from the disk, parses it, and sends rule LHS's to the rule processors. The RHS code stays in the host itself. The main parser code is in the file "PARSER.PF". Additional RHS parsing coding is in the file "RHS.PF".

The lowest level routine for the parser is the "get character" routine. This routine gets a single character from the keyboard buffer or the disk file that has been selected. There is a simple file stack in the file "BDOS.PF" that will allow files to be nested. In other words, files can load files. This is a convenient "batch" support system. The system will start off by getting characters from the keyboard. Only when the user tells the system to load a file will it open the specified file and redirect the input to come from the file instead of the keyboard. When the "get character" routines see a control-Z, the file stack will be "popped" and the input will be redirected to the previous input, whether it be another file or the keyboard input.

At the next level of complexity, there is the GET-ATOM routine. The GET-ATOM routine scans the input stream for valid OPS "atoms". An atom can be thought of as a legal keyword to the OPS system. The GET-ATOM routine also strips comments from the input. A comment starts with a semi-colon ";" and continues until the next carriage return. Below are some examples of legal atoms:

)

HOUSE

<VOLTAGE>

.fwdarw.

{

}

The GET-ATOM routine itself is built around a software finite state machine. This state machine technique is used extensively in the parser. One important point is that atoms with reserved characters may be next to each other without any spaces in between. The state machine approach allows only the correct characters to be picked up, leaving remaining characters for the next atom

When the host reads the input and sees that a new rule is to be compiled, it has to determine which processor the new rule's LHS's must enter. This is done by determining which rule processor has the smallest number of LHS's although other selection algorithms may also be employed. This is a simple form of load balancing. The number of LHS's is used because this is a better measure of the load that each rule processor has to handle than the number of rules in each processor. Once a rule processor is selected for the LHS's, the LHS compilation can proceed.

The LHS compilation requires that each LHS be parsed for syntax errors. As each LHS is being parsed, the host adds to the rule processor stream using the stream code mechanism discussed above in connection with host <> RP protocols. By sending a reduced representation of the rule LHS's to the rule processor, and by checking for the proper syntax at the host level, several important benefits are realized. First, the rule processor has a simplified representation, and is required to do no more parsing of the LHS. Second, the rule processor does not have to do any more syntax or error checking. The rule processor does have to read the input stream from the host and set it's own memory organization. This is important because the host has no knowledge about the internal memory organization of the rule processors. By using the "stream", complexity can be reduced by having a single interface between the host and the rule processors. It is important to note that this does not compromise speed in any way. During the actual execution of the OPS program, the host is sending information to all rule processors in parallel, and therefore cannot be responsible for slightly different location requirements in each processor. By sending the "stream" to the network buffer locations, which are identical for all rule processors, the host has no need to interfere with individual locations within each rule processor.

After the host reads the ".fwdarw." delimiter between the LHS's and the RHS's, it will make sure that all information has been sent to the selected rule processor. It then reads each RHS and executes the compiler word for each RHS. This is done because different RHS's types will have different syntax. Each RHS compiler word, for example the code that parses MAKE statements, will parse the appropriate RHS and add code to a static frame within the host. All RHS code is kept within the host, and, thus, the rule processors are not concerned with the RHS code at all. The RHS execution code is added to the frame within the host for later execution when the rule fires. This code currently is executable FORTH code, but could alternately be machine code for enhanced speed.

The rule processors are responsible for taking the reduced representation of the rule LHS's and actually converting it to executable code. This code is high-level FORTH code but may alternatively be machine coded for maximum speed. Keep in mind that the host has already done the syntax and error checking on the LHS's and no more checking is required by the rule processors

The representation sent to the rule processors by the host is a tokenized representation. This is because the rule processors cannot assign tokens, as this is done only by the host. Also, if the rule processors did assign tokens, then conflicting token values might exist when several rule processors tried to assign different tokens to the same alphanumeric string. Another point to keep in mind is actually very simple. One of the reasons that the host does the error checking is that it has to send error messages to the user anyway.

The rule processors take the coded representation from the host and build multiple code filters for later use. There is one LHS filter for each LHS in a rule. These filters deal only with the literal (constant) items specified by the LHS. There is one rule filter for each rule in the system. It deals only with the variable bindings specified by the LHS. There are multiple entry points to the rule filter, one per LHS, that allow the counter code to efficiently execute the rule filter code without any wasted computation. A third filter type exists for convenience only. This is the precheck filter for each rule. The precheck filter will quickly check to see if the rule filter is even required. For example if there are not any entries on the list of a non-negated LHS, the rule cannot fire and it is unnecessary to go any further in the evaluation. Also, if there are any entries on the list of a negated LHS that has no variable bindings, then the rule cannot fire and there is no reason to pursue matters any further.

Examples of the filter code will be given later.

The run-time code that executes on the host is responsible for actually firing the rules and then resolving the conflict between multiple processors that may have fireable instantiations.

When the recognize-act cycle starts, the host sends a message to all rule processors to "evaluate rules". This is done through the RP stream code mechanism discussed above. (See code B4 in FIG. 59.) Normally, stream codes are placed in a buffer local only to the host so that a double buffering arrangement can effectively allow the host and the rule processors to work simultaneously during large rule firings. However, the buffer is sent to the rule processors at this time and all on-line processors will start processing the information that has been sent by the host.

After the host sends the stream to the rule processors, it has nothing to do except to wait for the rule processors to complete their evaluation. Instead of simply waiting, the host will use it's time to speed the system up. When a rule fires, it may print messages on the display. This takes a certain amount of time at 9600 baud and therefore is buffered in the host memory during the rule firing. Only when the host knows it has nothing to do will it actually send the contents of this character buffer out the display device. So when a rule fires, any messages that it produces will not be printed until the next evaluation cycle. This is not an inconvenience to the user since the act of firing a rule is very quick and the next recognize cycle will immediately follow. This trick has given a noticeable speed improvement over a non-buffered character output.

After the host types any characters that were in the RAM buffer, then it simply waits for the rule processors to complete. Although not implemented herein, it is possible for the host to be scanning the rule processors to see if there were any that couldn't complete processing due to memory shortage or even a catastrophic hardware failure. The host could also be evaluating rule processor loads to see if the rules needed to be redistributed in any way to speed evaluation.

After the rule processors stop, then the host scans through the rule processors to resolve the conflicts between fireable rules. This is known as conflict resolution. Note that the host has to scan only through the number of rule processors and not the number of rules in the system since the rule processors perform local conflict resolution on the rules that they contain. Therefore the host is able to read from a designated area of each rule processor the most fireable rule of the potentially many rules that it may contain.

After the most fireable rule is found from among all the RP's, the host then executes the rule RHS code that was laid down by the RHS parser statements. The rule processors are affected by the MAKE, MODIFY, and REMOVE statements as they are executed on the host. The host also sends a message (code B8 in FIG. 59) to the rule processor that contains the LHS's for the rule that is about to fire. The rule processor interprets this message and takes the most fireable instantiation from the fireable list and places it on the not-fireable list. All other rule processors do not respond to this message. Any text that is output by the RHS firing actually goes to the host RAM character buffer. These characters will actually be output when the next recognize-act cycle begins or when the character buffer gets full. The actual firing of the rule currently runs the FORTH code that was laid down by the RHS compiler. Alternatively, machine code can be generated by the RHS compiler statements to give a faster execution time.

This now completes the part of the OPS recognize-act cycle that runs on the host. The rule processors exist for the speed improvement of the recognize portion of the cycle. Once the cycle is completed, it starts again. However, the next rule processor evaluation will evaluate the conflict set as affected by the actions of the previously fired rule. When all of the rule processors are not affected by the RHS actions and no rule has any fireable instantiations, then no more rules can fire and the system halts.

The rule processors are responsible for accepting changes to the working memory in the form of MAKE's, MODIFY's, and REMOVE's from the host and determining the new conflict set for each rule. Since each rule is truly independent in this fashion, the parallel architecture can provide a significant speed advantage over a conventional serial computer architecture. Keep in mind that a MODIFY is a MAKE and REMOVE combined. Therefore, the rule processor code does not have any specific MODIFY code, but relies on the host to send the MAKE and REMOVE code, as specified, for example, in respective codes 90 and 98 of FIG. 59, to actually modify a working memory element.

For a MAKE command, the rule processor has to go through every LHS of every rule that it contains and determine whether or not the rule needs to accept the new working memory element. Most of the cases will be trivial and fail due to the class numbers not matching, but many LHS's will have to be evaluated further. This is done by using the LHS filter that was previously compiled when the rule was first loaded. The output of the LHS filter is a flag (see LHS.PF, screens 42) that signifies whether or not a particular working memory element satisfied the literal (constant ) bindings specified by the rule LHS code. When the filter fails, nothing else needs to be done for a particular LHS and the evaluation code goes on to the next LHS in the rule processor. If the filter passes, then a working memory element identifier is added to the LHS list for a particular LHS. There is one list for each LHS in the system and each list contains entries that identify the working memory elements that match each LHS. The WME identifier is not the time-tag of the working memory element, but is the offset into the working memory element frame to uniquely identify where the working memory element is actually stored within the RP memory. This is done to achieve faster access to the working memory element.

Once a working memory element is added to the LHS list for a rule, the rule must be evaluated to determine whether or not any new instantiations have been created due to the new WME. For negated LHS's, instantiations may possibly be deleted from the fireable list. This is the reason for the "not-fireable" list. The not-fireable list exists in to permit quick additions back to the fireable list when the WME that prevents firing or matching a negated LHS is removed. When a new WME is added to a LHS list, then the counter code will "pivot" over this new WME. This means that only the new WME for a particular LHS will be examined for possible new matches. The other LHS's are not bound by this pivot position. In other words, all WME's on other LHS lists are examined for possible matches against the newly added WME. This can lead to millions of possible searches, which can take a long time. Fortunately, most of these matches are discounted for the following reason. If a WME does not match the bound variables of the combined WME's of the previous LHS' s, then there is no need to go through possible combinations below it. This simple fact alone is a central key to other shortcuts. For example, the rule filter has an entry point for each LHS in the rule. If a match fails for a WME on a particular LHS, then the code can re-enter the filter at the same LHS but for another WME that may be on the list. An example of the counter-code rule-filter relationship will be shown later.

When a WME is deleted from a non-negated LHS list, it is simply removed from the list and both the fireable and not-fireable lists are scanned to determine if the WME was there also. If so, those entries with the WME to be deleted are removed.

Negated LHS's pose a very different problem. WME's that match a negated LHS are still added to the LHS list as in the non-negated LHS. However, the rule filter and the counter code are very different. When the counter gets to a negated LHS, it must scan through all entries in the list to make sure that there are not any WME's that match the rule to this point. If there are WME's that match, then these partial instantiations are added to the not-fireable list because they cannot fire. When the WME is deleted from the negated LHS, then this partial instantiation can possibly be added back to the fireable list without having to go through a full evaluation. The special case of negated LHS's will be shown in the example.

FIGS. 61-64 show some simple flowcharts of the rule processor run-time code. FIG. 61 shows a simple representation of the INTERPRET-STREAM word. This flowchart shows the INTERPRET-STREAM in relationship to MAKE and REMOVE commands. This word is actually table driven for speed. This following table is useful for locating the actual code in the program listings:

In FIG. 61, for example, the scanning over the stream codes is done by using screen 3 of LHS.PF which basically corresponds to FIG. 59. The MK-WME routine is illustrated in FIG. 62. The steps illustrated in FIG. 62 are found primarily in screen 42 of LHS.PF. Only a WME which can be used in a given LHS is stored and each LHS is scanned in turn in the scanning step. For each LHS, various pointers are set up in the OPEN-LHS step to speed-up memory access. Subsequently the class of each new WME is compared to classes present in the LHS, and if no classes match, the WME is not stored. If the new WME class does correspond to a class used in the rule LHS, then the LHS filter is executed and if passed, the WME is added to the rule processor LHS list. The treatment for WME's used in negated and non-negated LHS's is shown in FIG. 64.

The flowchart for removing a WME is illustrated in FIG. 63 and is similar to that of FIG. 62. Screen 42 in LHS.PF shows the applicable program and again FIG. 64 applies to WME's used in rejected and non-negate LHS's.

A simple example is set forth to illustrate the AI machine details. The example is a single rule that is to find all blocks known to the system of a particular color and size that are not identical to any other block in the system. In other words, find all unique blocks in the system. The OPS literalize statements that may be used to define the WME structures are shown below:

(LITERALIZE GOAL

WANT

ID

STATUS)

(LITERALIZE BLOCK

COLOR

SIZE

NUMBER

WEIGHT

The first literalize statement indicates that a GOAL may have three attributes, WANT, ID, and STATUS. The second literalize statement indicates that a BLOCK may have four attributes, COLOR, SIZE, NUMBER, and WEIGHT. The WEIGHT attribute will not be used in this example, but has been included to emphasis the memory organization for working memory elements.

The rule that will find all unique blocks known to a system is as follows:

Note that this rule does not really do anything in the RHS except for printing a message. Normally, when a rule fires, it will affect working memory elements in the system by MAKE, MODIFY or REMOVE statements. In this manner, incremental facts can be found and subsequently acted upon.

Now assume that some other rule in the system has made certain working memory elements to be used in this example. Actually, the working memory elements can be made by a rule, loaded from a file, or made by the user from the keyboard. The working memory elements are listed below and include time-tag information (specified by the number before the colon).

FIG. 65 gives a simple representation of how the filters are set up by the rule processors. The LHS #1 filter checks for the literals and returns a false flag if the literal conditions are not met. FILTER.PF, screens 17, 32 and 33 are the relevant compilation codes whereas LHS.PF, screen 42 is the relevant execution code. In this example, the value of WANT must equal "TEST". If it does not, then the filter exits with a false flag. Likewise, the value for STATUS must equal "ACTIVE" or the filter will also exit with a false flag.

Note that the LHS #2 and LHS #3 filters are both trivial since the second and third LHS's did not specify any literal comparisons. Therefore, both filters will accept any working memory elements that are of the proper class.

The precheck filter is simply a convenience for allowing a quick check to be performed to allow the code to determine if the rule filter needs to be executed. In this example, the precheck filter makes sure that the first and second LHS's have at least one entry on their lists (see FIG. 67). If there were not any entries, then the rule simply could not fire and therefore the code will not go any further on this rule. Negated LHS's are different for two reasons. Notice that there is no check for the third LHS because it is negated. The rule could still fire even though there are not any WME's on the third LHS list. Another reason for the negated LHS difference is that the precheck filter can check negated LHS's that have no variable bindings. A WME that is on the list of a negated LHS with no variable bindings will also keep the rule from firing.

It is in the rule filter that variable bindings and thus the relationships between WME's will become important As stated before, the rule filter has as many entry points as there are LHS's in the rule. In the example, notice that the first entry point opens the WME for the first LHS. This means the counter position for this LHS is read and the address of the actual WME (shown in FIG. 66) is stored for quick access. Since the rule has no variable bindings on the first LHS, nothing else is done. The second LHS is then opened to allow the variables specified to be bond. Notice that no variable names are kept on the rule processors. Only variable numbers are kept within the rule processors and these numbers actually represent the offset from the variable binding table. Each variable entry in the table takes four bytes since everything is kept as a four byte token. Notice that LHS #3 is different because it is negated. Its structure allows the counter to know that the LHS is negated because the counter has to go through all entries of a negated LHS to make sure that there are no WME's that satisfy the negated LHS for currently bound variables. The codes 1, 2 and 3 shown in the rule filter are set forth in screen 77 of LHS.PF.

FIG. 66 shows the representation of the working memory elements. This structure exists both on the host as the global working memory and on the rule processors as the local working memory. The main LHS list contains four bytes for each working memory element that has ever been made. If a working memory element is deleted, then it's entry is filled with -1 ( FFFFFFFF hex ) to signify that it has been deleted. When a WME does exist in the table, the most-significant byte contains the class number of the WME. Since GOAL was literalized first, then it 1 since it was literalized next. The next three bytes in the main WME list are the 24 bit offset within the WME frame. Once a WME is placed in the WME frame, it can never be moved within the frame. Otherwise this offset within the WME frame would have to be changed. The WME list is a dynamic frames since it grows dynamically during system operation.

The WME frames for GOAL and BLOCK are shown at the top of FIG. 66. The first four byte cell is used to keep the WME number, otherwise known as the time-tag. Then the values for the attributes are listed in the order defined by the literalize statement. If a WME does not have a value assigned to a particular attribute when it is made, then it is assigned a token value of 0, which is NIL. As multiple WME's are added to a given class, the WME frame is extended to allow more room for the simple array. When a WME is deleted, the code checks to see if it was the top WME of the frame. If so, then this memory is returned to the memory manager. If not, then a linked list is created where the WME# would normally be. The links are offsets to other blank WME entries. When a new WME is created, then the link is checked to see if there are any free entries. Only when there are not any free entries will the system add more WME entries to a WME frame. Notice the single four byte cell at offset 0. This exists primarily for tee linked list code to make sure that there are not any WME's that have an offset of 0. The WME frames are dynamic frames to the memory manager since they grow and shrink dynamically.

One can now examine a single WME. WME #11 says that there is a BLOCK of COLOR RED, SIZE MEDIUM and NUMBER 10. Looking at the main WME list, at position 11, we see the hex number 010000CC. The 01 refers to the BLOCK class and the 0000CC is the offset within this class. Now looking at the 0000CC offset in the BLOCK WME list, we see an 11 for the WME number. This is a redundant reference to the WME number that exists for coding convenience only. Scanning across the 0000CC row, the COLOR position is listed as being RED, the SIZE position is listed as being MEDIUM and the NUMBER is listed as being 10. Notice that the weight attribute was not specified, so this position is given the value NIL, represented by 0.

FIG. 67 shows the LHS lists for each of the three LHS's in this example rule. The static frames show how the filter code is stored. There is an eight byte header that comes before the filter code. Of this header, the first four bytes are used to hold a handle to the actual LHS list. The symbols to the left of the LHS lists signify that this is a double indirect memory reference as mentioned in the explanation of the memory management routines. FIG. 65 shows that LHS #2 and LHS #3 have trivial filters. Thus the filter code diagram in FIG. 67 is shorter for the last two LHS's in the rule. An important point is that the filter code need be only as long as required by the associated LHS's. With the WME's as given in the example, the upper portion of FIG. 67 shows the LHS lists for each LHS. Notice that the WME offsets shown in FIG. 66 allow fast access to the actual WME. Again the lists for LHS #2 and LHS #3 happen to be the same since there were no literal conditions placed on the WME's for the last two LHS's. It is noted that FIGS. 66 and 67 show the memory organization as it occurs in memory. For example, LHS #1 was defined first, so it comes lower in memory. Thus the drawing is consistent with what the code actually does.

FIG. 68 shows an abstract representation of what the counter code has to do. Notice that LHS #1 is at the top of these diagrams. A, B, and C refer to the block example set forth above. D will be used to make a general point that is not otherwise covered in this block example. When the counter first starts, it begins at the head of each list as shown in A. For negated LHS's, the counter must cover all entries. B shows the counter at a later time. The counter here must also go through all negated LHS's. The counter continues, as shown in C and keeps on going until the end is reached.

Letter D in FIG. 66 does not relate to the "block" example, but suggests other points. In this diagram, the code "pivots" over a newly added entry (WME) in the second LHS. All other LHS's must be checked against this LHS. The light, wider arrows indicate where a self consistent match has been found between working memory elements and the LHS's while the dark, thinner arrows indicate where tests had to be made but the working memory elements were found to be inconsistent. When the counter first starts, its checks the first WME on the list for LHS #1 against the single WME at the end of LHS #2 that is being pivoted upon. Neither the first or the second entries on the list for LHS #1 consistently satisfy the variable bindings implied by the WME on LHS #2, so the counter code knows not to go further down the filter. The counter finally finds that the third entry on the list of LHS #1 does satisfy the bindings at the pivot point of LHS #2, so the filter can examine the next LHS. On LHS #3, the counter starts at the first entry and continues across finding that the forth entry is the only one that matches with the established variable bindings. Therefore, the filter continues to LHS #4, forcing the counter to start at the head of the list and continue to the right until all entries are tested. In this example, three entries are found to match on LHS #4. Since this is the end of the rule, three self consistent sets are added to the fireable list. Note that after these three sets are found, the counter starts working its way back up. For example, it would then test the last two entries on LHS #3 and finally the last entry on the list for LHS #1.

At this point one can see where the filter and counter complexities give a speed benefit. The counter and filter code are invoked 19 times in this simple example. If the counter code and filter code were not as versatile and only had one filter entry point for example, then the code would have been executed 4 * 6 * 9 times, or 216 times to pivot on the last entry for LHS #2.

Going back to the simple "Find Unique Block" example, one can see the fireable and not-fireable list for the sample rule in FIG. 69. Both the fireable list and the not-fireable lists are dynamic frames to the memory manager. Again, this is to allow the frames in memory to grow and shrink dynamically. The fireable list has to contain the time tags for the set of WME's that match the rule. This list is in the order of the WME's. The second half of the fireable list is a sorted version of the instantiation time-tags. This is used by the routine that sorts the instantiations as they are entered on the fireable list. The fireable list width is the number of LHS's in the rule times 8 bytes. Note that the fireable list is sorted in order of fireability. Therefore the instantiation at the top of the list is the most fireable instantiation.

Looking at the fireable list for the example, one can see that the instantiation on the top is the ordered set (18 16--). This means that the WME that matches the first LHS has a time-tag of 18. The WME that matches the second LHS has a time-tag of 16. Note that since the third LHS is negated, nothing can match the third LHS if the rule is to be fireable.

The not-fireable list is kept only for rules that have a negated LHS. The main function of the not-fireable list is to facilitate the quick return of instantiations to the fireable list when a WME is deleted from a negated LHS list. The sorted time-tags are not kept for the not-fireable list for two reasons. One is to save memory The other is because an entry in the not-fireable list may be a partial instantiation. For example, if an instantiation could not fire because the filter found a WME on a negated LHS list that satisfied the variable bindings, then this partial instantiation is added to the not-fireable list. Thus, LHS's lower than this are not checked, forming an incomplete instantiation. Only when the WME is removed that prevented the rule from firing will the counter pick back up from this point and find possible instantiations.

Looking at the not-fireable list for the example, one can see that there are 10 partial instantiations that are not-fireable. In order for a partial instantiation to be put on the not-fireable list, a WME has to exist that can match a negated LHS. This list is not sorted as the fireable list and always represents the order in which the not-fireable partial instantiations are found. The fifth entry from the bottom on the not-fireable list in this example is (18 10 17). Since a 17 is in the negated LHS #3 position, this instantiation cannot fire because a WME with a time-tag of 17 exists. The entire purpose of the not-fireable list is to be able to quickly transfer an instantiation back to the fireable list when the WME that satisfies the negated LHS is removed. Thus in this example, when WME #17 is removed, the (18 10--) instantiation will go back to the fireable list.

When the rule processors are told to evaluate the rules, (code B4 of FIG. 59) they scan through all of the fireable lists of all rules that they contain. The rule processors perform a local conflict resolution on all fireable rules and then store the most fireable instantiation of the most fireable rule for access by the host.

The architecture described herein permits a fault monitoring system by the host of all of the rule processors. The host may simply transmit a unique code in a network fashion to all of the rule processors and then subsequently read the code to determine if it has been received and stored correctly. The BOOT command in screen 106 of the program RPPOLY.PF is utilized for this purpose wherein the code is simply "1 2 3 4". This technique provides the lowest level of fault tolerance wherein if a processor is not connected, the processor will simply be ignored when the host allocates rules to the various processors which are connected. In the RPPOLY.PF program, the test utilizing the boot command is made only during start up but the program could alternately be modified to periodically check operation of each rule processor.

In the following appendix, each program listed in the beginning of the software description above is identified by its name appearing at the bottom of the page. Within each program, the screen numbers in the lefthand column inc in ascending order beginning at one, with the shadow screens, used for comments, also increasing in ascending order but beginning with the next integer after the highest lefthand column screen number. ##SPC1##