Block diagram simulator using a library for generation of a computer program

Abstract

Method for ordering computer software procedures in an order using a computing machine for modeling each of multiple blocks of a block diagram. The block diagram is capable of having at least one feedback loop. Each block corresponds to a software procedure for performing at least one function and has at least one input or at least one output. The block diagram has interconnections between such inputs and outputs of such blocks forming a block diagram. A list of inputs for each of such blocks is generated; a list of outputs for each of such blocks is generated; a feed-through list for each of at least some of such outputs of such blocks is generated. Each feed-through list has a list of any input which directly affects the output of the same block. The input, output and feed-through lists are machine processed for ordering of such procedures in the order during modeling.

Claims

What is claimed is:

1. A method for ordering computer software procedures in order in a computing machine for modeling each of multiple blocks of a block diagram, the block diagram being capable of having at least one feedback loop, each said block corresponding to at least one of the software procedures for performing at least one function and comprising at least one input or at least one output, one or more of such block diagrams having interconnections for passage of representations between the inputs and the outputs of such blocks forming such block diagram,

the at least one software procedure corresponding to each such block comprising an update output procedure which defines the representation for at least one of said outputs for such block as a function of the representation for at least one of said inputs for such block, or an update state procedure which defines at a current time a state for such block as a function of the representation for at least one of the inputs for such block at a prior time or an update output procedure which defines at a current time the representation for at least one of the outputs of such block as a function of either the current state or the representation for at least one of the inputs of the corresponding block, the method of ordering further comprising the steps of:

a) generating a list of any said input for each of such blocks;

b) generating a feed-through list for each of at least some of such outputs of such blocks, the feed-through list comprising a list of any said input which directly affects the output of the same block; and

c) processing in the computing machine such input and feed-through lists for the one of the block diagrams for ordering of such procedures and comprising the step of determining the occurrence of a predetermined relation between any said input in the feed-through list and in the input list for one of such blocks in the one block diagram and, the step of selectively, depending on the occurrence of the predetermined relation, ordering one of an update state procedure that corresponds to the same block in the order relative to the other update state and update output procedures so that a representation of the input for such update state procedure will have been defined by one of said update output procedures previous in the order.

2. The method of claim 1 wherein the computing machine comprising a memory and wherein each of the steps of generating comprises the step of storing the respective lists in the memory and the step of processing comprises the step of using the computing machine for processing the input and feed-through lists from the memory for the step or ordering of such procedures.

3. The method of claim 1 wherein the step of determining the predetermined relation comprises the step of determining if all inputs in the input list for such one of said blocks are present in the feed-through list for the same said block.

4. The method of claim 1 wherein the step of determining the predetermined relation comprises the step of determining if no inputs are present in the feed-through list for such one of said blocks that are also present in the input list for the same said block.

5. The method of claim 4 wherein the step of determining the predetermined relation also comprises the step of determining if some inputs are present in the feed-through list for such one of said blocks that are also present in the input list for the same said block.

6. The method of claim 1 wherein such one of said blocks has more than one input and wherein the step of ordering comprises the step of ordering the update state and update output procedures in the order such that all inputs to such one of said blocks are defined by at least one update output procedure previous in the ordered procedures.

7. The method of claim 1 wherein the update state and the update output procedures each comprise a procedure call to a procedure for causing the computing machine to carry out the steps of the procedure.

8. The method of claim 7 wherein the method of machine ordering comprising ordering such procedures for modeling the block diagram and comprising the step of executing such ordered procedures for modeling the block diagram.

9. The method of claim 7 wherein the step of processing comprises the step of generating a sequence list indicative of the order in which such procedures are to be executed.

10. The method of claim 7 wherein the step of processing comprises the step of processing such procedures for each of such blocks in such order.

11. A method of claim 10 wherein the step of processing comprises the step of executing such procedures for each of such blocks in such order.

12. The method of claim 7 wherein said blocks of the block diagram comprise at least one said feedback loop and wherein the step of processing for ordering comprises the step of ordering the procedure for the block in the feedback loop in an order and determining if any such input to said block in the feedback loop cannot be defined by a procedure already in the order.

13. The method of claim 7 wherein the step of processing for ordering comprises the step of ordering procedure calls to the procedures.

14. The method of claim 7 wherein each of the steps or providing a list comprises the step of generating a list.

15. The method of claim 7 wherein there is a library of feed-through lists, at least one such feed-through list for each of a plurality of such blocks, stored in a memory and the step of providing the feed-through lists comprises the step of reading such feed-through lists from the library.

16. Means for ordering computer software procedures in an order for modeling in a computing machine, each of multiple blocks of a block diagram the block diagram being capable of having at least one feedback loop, each said block corresponding to at least one of the software procedures for performing at least one function and comprising at least one input or at least one output, one or more of such block diagrams having interconnections for passage of representations between the inputs and the outputs of such blocks forming the block diagram,

the at least one software procedure corresponding to each such block comprising an update output procedure which defines the representation for at least one of said outputs for such block as a function of the representation for at least one of said inputs for such block, or an update state procedure which defines at a current time a state for such block as a function of the representation for at least one of the inputs for such block at a prior time or an update output procedure which defines at a current time the representation for at least one of the outputs of such block as a function of either the current state or the representation for at least one of the inputs of the corresponding block, the means for ordering, comprising:

a) means for generating a list of the inputs for each of such blocks;

b) means for generating at least one feed-through list for each of at least some of the such outputs of such blocks, the feed-through list comprising a list of any said input which directly affects the output of the same block; and

c) a computing machine for processing each of such input and feed-through lists for the one of the block diagrams for ordering of such procedures and comprising means for determining the occurrence of a predetermined relation between any said input in the feed-through list and the input list for one of such blocks in the one block diagram and, means for selectively, depending on the occurrence of the predetermined relation, ordering one of the update state procedures that corresponds to the same block relative to the other update state and update output procedures in the order, so that a representation of the input for such update state procedure will have been define by one of said update output procedures previous in the order.

17. A method for ordering in a computer for machine processing, procedures representing each of multiple blocks of a block diagram, the block diagram being capable of having at least one feedback loop, each such block corresponding to at least one of the procedures for performing at least one function representative of such block and comprising at least one input or at least one output, said blocks having interconnections between the inputs and outputs of the blocks forming the block diagram, at least one such block being a delay block for use in the feedback loop having an input that directly effects an output of such block and at least one such block having an input that effects an output of such block after a delay, one of such block diagrams having interconnections for passage of representations between the inputs and outputs of such blocks forming such block diagram,

the at least one procedure corresponding to each such block comprising an update output procedure which defines the representation for at least one of said outputs for such block as a function of the representation for at least one of said inputs for such block or, in the case of a delay block, an update state procedure which defines at a current time a state for such block as a function of the representation for at least one of the inputs for such block at a prior time or an update output procedure which defines at a current time the representation for at least one of the outputs of such delay block as a function of either the current state or the representation for at least one of the inputs of such delay block, the method of ordering comprising the steps of:

a) providing a list of each of any said input for each of such blocks;

b) providing in addition to the list of inputs, at least one feed-through list for each such delay block, the feed-through list comprising a list of each of any said input for such delay block which directly affects such output of the same delay block; and

c) processing, in the computer, such input and feed-through lists for the one of the block diagrams for ordering of such procedures in an order for machine processing and comprising the step of determining the occurrence of a predetermined relation between any said input in the feed-through list and the input list for one of such blocks in the one block diagram and, the step of selectively, depending on the occurrence of the predetermined relation, ordering one of an update state procedures that corresponds to the same block in the order relative to the other update state and update output procedures so that a representation of the input for such update state procedure will have been defined by one of said update output procedures previous in the order.

18. The method of claim 17 wherein the step of processing comprises the step of generating a sequence list indicative of the order in which such procedures are to be executed for modeling.

19. A method of claim 18 wherein the procedures each comprise a procedure for causing a computing machine to carry out the step of the procedure and the step of processing further comprising the step of ordering the procedure calls to the procedures in the order specified by the sequence list.

20. A method of claim 19 comprising the further step of executing the procedures in such order, to determine representations for such inputs and outputs.

21. The method of claim 17 wherein the step of processing comprises the step of modeling the block diagram.

22. The method of claim 17 wherein the step of processing further comprises the step of processing such procedures for each of such blocks in the order.

23. The method of claim 17 wherein the step of determining in the step of processing comprises the step of determining if any such input in the feedback loop cannot be defined by such a prior procedure in the order.

24. The method of claim 17 wherein each of the steps of providing a list comprises the step of generating the corresponding list.

25. The method of claim 17 wherein there are memory storage areas accessible to the computer and wherein there is a library of said feed-through lists for each of a plurality of such blocks stored in the memory storage areas and the step of providing the feed-through lists comprises the step of reading such feed-through lists for each such delay block from the library.

26. The method of claim 25 wherein the step of providing such input lists comprises the step of reading a list of such input lists from the memory storage areas.

27. The method of claim 17 wherein the step of determining the predetermined relation comprises the step of determining if all inputs in the input list are present in the feed-through list for the same said block.

28. The method of claim 17 wherein the step of determining the predetermined relation comprises the step of determining if no inputs are present in the feed-through list that are present in the input list for the same said block.

29. The method of claim 28 wherein the step of determining the predetermined relation comprises the step of determining if some inputs are present in the feed-through list that are present in the input list for the same said block.

30. The method of claim 17 wherein the step of processing for ordering comprises the step of ordering such update output procedure for the delay block such that the update output procedure for such delay block is ordered previously in the order to the update state procedure for such delay block.

31. The method of claim 17 wherein at least one of the update state procedures and at least one of the update output procedures are each a function of more than one input to the corresponding block and wherein the step of processing for ordering comprises the step of ordering such update state and update output procedures in the order such that all inputs of which they are a function are defined by a prior said procedure in the order.

32. The method of claim 17 wherein the step of processing ordering comprises the step of adding to the order any said procedure after all of any such inputs of which such procedure is a function is defined by one said procedure already in the order.

33. The method of claim 32 wherein said blocks comprise at least one combined block having a corresponding combined procedure, said combined procedure having at least one such input that indirectly affects such an output of the combined block and at least one such input that affects one such output of the combined block after a delay, the method of processing for ordering procedures comprising the step of

adding the feed-through procedure to the order after each of any such inputs of which said feed-through procedure is a function is defined by at least one said procedure that is already in the order, even though an input of which an update state procedure is a function for the same block has not been defined by a procedure in the order.

34. The method of claim 33 comprising the step of adding the update state procedure to the order after all of any such inputs of said update state procedure are defined by a procedure already in the order.

35. The method of claim 1 or 17 wherein the method comprises the step of assembling the procedures for subsequent processing by a computing machine.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to an apparatus and/or method for assembling and executing a software computer program representative of a block diagram having none, one or more feedback loops.

2. The Prior Art

Over the past two decades, there has been a growing interest in the use of simulation-based techniques for the analysis and design of signal processor systems, communication systems and control systems. Indeed, a number of systems have been developed for simulation-based analysis to determine performance, criteria and trade-off analysis of proposed systems, Shanmugan et al., "Block-Oriented Systems Simulator (BOSS)," IEEE (1986); Shanmugan, et al., "Computer-Aided Modeling, Analysis and Design of Communication Systems," IEEE, Journal on Selected Issues in Communications, (Jan. 1984).

There are many situations where an explicit performance evaluation of a proposed system cannot be performed without creating an actual prototype. This approach is generally cumbersome, expensive, time-consuming and relatively inflexible; whereas, a computer simulation of the proposed system can be more easily generated and can be used to guide the analysis, testing and documentation of the proposed system.

Simulators are now available for generating models and/or software computer programs for simulating and verifying the performance of prototype or existing systems on a Computer Aided Engineering (CAE) Workstation Platform. A CAE workstation typically includes a programmable microprocessor and a graphics terminal which is a Cathode Ray Tube (CRT) display. The simulators provide the designer with user-friendly environments and easy-to-use design tools for configuring the systems. Typically, a simulator contains four basic components; a system configurator, a function block library, a simulation program builder, and a signal display editor.

The system configurator allows a user to specify the topology of the proposed system in terms of interconnected functional blocks. In some simulators, the system configurator uses interactive graphics, Modestino, et al., "Interactive Simulation of Digital Communication Systems," (Jan. 1984), Wade, et al., "Interactive Communication Systems Simulation Model," (Jan. 1984), while in others, the system configurator uses high level computer oriented software languages, Fashano, "Communication Systems Simulation Using SYSTID," (Jan. 1984), Poza, et al., "A Wideband Datalink Computer Simulation Model," Computers and Electrical Engineering, (1978).

Today, a typical simulator for a workstation platform includes a system configurator called a Block Diagram Editor (BDE). The BDE is a software package which enables a designer to construct a block diagram of the system to be simulated. A high resolution graphics terminal is used to display the block diagram to help the user design, edit, and interact with the block diagram. An extensive library of function block symbols is also provided to enable the designer to pick and choose from existing blocks instead of having to design them on his own.

The library contains information about each block, including its submodules, connections, documentation and high-level program code, all of which can be made available to the designer through on-line windows. Function blocks span a wide range of complexity, starting with "primitive" blocks such as summers, and multiplier blocks to blocks which perform high level functions. The user can connect the blocks together with interconnecting lines and provide required parameter information for each of the blocks. The configuration defined by the designer can then also be used to define a new block which can be stored in the library and which can be later recalled as a single block at a higher level in a hierarchic system design.

Once a block diagram has been defined by the designer the BDE then condenses and represents the block diagram as a network list or "netlist". The netlist is a computer-readable form of the block diagram, containing all the required information about the block diagram, such as how the blocks are connected together, the software procedure call the block represents, parameter lists, etc. The simulator converts the netlist version of the block diagram into a high-level computer program by use of a Simulation Program Builder (SPB). The high level computer program is essentially a model of the proposed system which had been previously described by the block diagram.

The high-level code can then be executed to perform and display a simulation of the block diagram. Typically, the simulation will be carried out without any user intervention. During the simulation execution, selected signal values can be collected and saved in various signal files. These signal files can then be accessed by a Signal Display Editor (SDE) that allows the designer to generate, manipulate and analyze the signals.

The signal display editor uses a variety of signal plotting and processing techniques to analyze the results of a simulation. The designer can select from a variety of commands, such as selecting a portion of a signal and displaying it as a function of time and performing spectral analysis.

Simulators are known which have the capability of simulating block diagrams representative of systems which have "feedback." Feedback is the reversion of the output of a system or process to a preceding stage in the same system or process for the purpose of allowing the system or process to perform self-correcting actions based on its output.

One example of a system having feedback is a simple signal processing filter which requires continuous evaluation of the output of the filter in order to determine which corrective measures to take. Systems having feedback are not limited to the signal processing environment. Indeed, any system having self-correcting type measures needs to be designed and modeled with some form of feedback arrangement. Present simulators do not have the capability of adequately simulating systems with feedback because they inefficiently model and simulate blocks in a feedback environment which have a "delay" property; the delay property requires the blocks to have a "state." A "state" is a predefined vector of parameters which are called state variables. State variables are defined by the following conditions:

1) For any time, say T.sub.1 (time), the state at T.sub.1 (that is the state variables) and the input waveforms determine uniquely the state at any time T>T.sub.1 ; and

2) the state at any time T and the inputs at any time T determine uniquely the output value at time T of the block. Desoer et al., Basic Circuit Theory 198, 508 (1969). Essentially, "state" enables a block to process and generate defined outputs without having to have defined inputs. The principal of "delay" comes from the fact that the input values are not immediately required to process the function of the block in order to produce defined information. These concepts are discussed in greater detail in the Detailed Description portion of this application.

One such example of a present simulator which inefficiently models and simulates block diagrams having feedback loops is described in an article by David G. Messerschmitt entitled, "A Tool for Structured Functional Simulation," IEEE Journal, Selected Areas On Communication, Vol. SAC-2, No. 1, (Jan. 1984). In this article, a system called "BLOSIM," for simulating block diagrams, is described. In order to accommodate for the "delay" property of blocks which occur in feedback loops, the BLOSIM system provides a buffering type system for ensuring proper synchronization of the delay blocks. More particularly, for each delay block there is provided an input "FIFO" (first-in, first-out) buffer and an output FIFO buffer. The BLOSIM system provides a single software procedure representative of each delay block. The software procedure contains conditional statements for evaluating the status of the buffers. These statements are executed during the simulation of the block diagram in order to determine when particular portions of the routine representative of the delay block need to be performed.

Additionally, to improve efficiency, a sequencer routine presequences the software procedures for the blocks such that they are executed in the order of "signal flow," which is determined by the particular topology of interconnections of the blocks in the block diagram. The presequencing procedure alone, however, will not correctly sequence the software procedures representative of block diagrams which have one or more feedback loops. By repeatedly executing the software procedures in the order determined by the presequencing operation, BLOSIM provides available samples to the input FIFO buffers. When the output FIFO buffer for a particular delay block is not full and the input FIFO buffer is not empty, the software procedure representative of the block removes an input value from the input FIFO buffer and directs the necessary operations representative of the block. Outputs are provided to the output FIFO buffer for the corresponding block until the output FIFO buffer is full. The simulation "deadlocks" (terminates) when each software procedure representative of the block does not attempt to access a FIFO buffer or has an empty input FIFO buffer or a full output FIFO buffer, see, Messerschmitt, "BLOSIM, A Block Simulator," Version 1.1, University of California, Berkeley, internal memo (Jun. 7, 1982).

The BLOSIM simulator uses inefficient software programs and as a result causes inefficient execution because parts of the program are repetitively executed until each block has an empty input FIFO buffer or a full output FIFO buffer or does not attempt to access a FIFO buffer. Additionally, each software program representative of a delay block contains at least one conditional statement which is repetitively executed in order to determine when the input FIFO buffer is empty and/or when the output buffer is full. During simulation, such re-execution of the program slows down simulation. Furthermore, BLOSIM does not organize or sequence the procedures for storage so that the procedures can later be loaded into the memory of a chip for control of that chip.

U.S. Pat. No. 4,677,587 to Zemany discloses a simulator for generating a computer program representative of a block diagram having one or more feedback loops. Specifically, the system forms a table into which the user inserts block identifiers for each block of the block diagram. The user also specifies each block's interconnections with the other blocks of the block diagram. The information for each block is entered into the table in the order that they appear, from left to right, in the block diagram, except for blocks having a delay property which are entered last. The system provides a test function for ensuring that the block identifiers and interconnections have been entered by the operator in the proper order.

The Zemany simulator inefficiently constructs a computer program representative of a block diagram because the user of the system must construct a table of procedure calls representative of the block diagram. When the block diagram is complex, the operator's task becomes very time consuming and cumbersome. In sum, the simulator disclosed by Zemany is an unautomated workstation for assisting the user in designing computer programs representative of block diagrams.

Another example of a present simulator which inefficiently models block diagrams having one or more feedback loops is described in a user's manual entitled, "BOSS (Block Oriented Systems Simulator)," University of Kansas and TRW, BOSS version: Star 1.1 (1986). In this manual, a system called "BOSS," for simulating block diagrams is described. In order to accommodate blocks which have delay property, the BOSS system provides specific delay elements which must be present in the simulation. The BOSS system does not provide a mechanism for allowing a user of the system to design and identify his own blocks which have a delay property. For this reason, the user's task of designing systems which have feedback loops can become cumbersome because the user is constrained to use only the delay elements provided by the system.

SUMMARY OF THE INVENTION

The present invention seeks to provide a method and apparatus that reduces or eliminates the disadvantages referred to above.

Briefly, a method according to the present invention is for ordering computer software procedures in an order in computing machine for modeling each of multiple blocks of a block diagram. The block diagram is capable of having at least one feedback loop. Each block corresponds to a software procedure for performing at least one function and has at least one input or at least one output. The block diagram has interconnections between such inputs and outputs of such blocks forming a block diagram. The method of ordering in a computing machine is as follows. A list of any input for each of such blocks is generated; a list of any output for each of such blocks is generated; a feed-through list for each such output of such blocks is generated. The feed-through list has a list of any input which directly affects the output of the same block. The input, output and feed-through lists are machine processed for ordering of such procedures in the order during modeling.

According to the invention, a programmed computer machine is disclosed for ordering computer software procedures in an order for modeling each of multiple blocks of a block diagram. The block diagram is capable of having at least one feedback loop. Each block corresponds to a software procedure for performing at least one function and has at least one input or at least one output. The block diagram has interconnections between inputs and outputs of the blocks forming the block diagram. The provision is made for generating a list of the inputs for each of the such blocks. Provision is made for generating a list of any outputs for each of such blocks. Provision is made for generating at least one feed-through list for each such output of the blocks. The feed-through list has a list of any input which directly affects any output of the same block. Provision is made for processing, in the computing machine, the input, output and feed-through lists for ordering of the software procedures in the order for execution during modeling.

Also disclosed is a method for assembling in a computer for subsequent machine processing each of multiple blocks of a block diagram. The block diagram is capable of having at least one feedback loop. Each block corresponds to a procedure for performing at least one function and has at least one input or at least one output. The blocks have interconnections between inputs and outputs of the blocks forming the block diagram. At least one of the blocks is a delay block having an input that directly effects an output of such block. At least one of the blocks has an input that effects an output of such block after a delay. The method involves providing a list of each of any of the inputs for each of the blocks, providing a list of the interconnections between the inputs and the outputs, providing an addition to the list of inputs, at least one feed-through list for each delay block. The feed-through list has a list of each of any input for the delay block which directly affects the output of the same delay block. In the computer, the input, interconnection and feed-through lists are processed for ordering of the procedures in an order for subsequent machine processing.

This application also discloses a method for machine assembling at least one block having at least one input and at least one output connected in a feedback loop of a multiple-block diagram. The at least one block is characterized in that the at least one input does not directly affect the at least one output and the at least one input is connected in the feedback loop. The at least one block in the feedback loop corresponds to a software procedure for performing at least one function representative of the block. The software procedure has at least one input corresponding to the at least one input of the block, at least one output corresponding to the at least one output of the block and a state. The state is a function of at least one input of the software procedure occurring at a prior time step to a current time step in the execution of such procedure. The method for assembling involves machine processing the software procedure for calculating the output of the software procedure as a function of the state, and subsequent to the preceding step, machine processing the software procedure as a function of the at least one input thereof for calculating the state for use during subsequent processing of the software procedure.

Further, a programmed computing machine is disclosed for assembling at least one block having at least one input and at least one output connected in a feedback loop of a multiple-block diagram. The at least one block is characterized in that the at least one input does not directly affect the at least one output. The said at least one input is connected in the feedback loop. The at least one block in the feedback loop corresponds to a software procedure for performing at least one function representative of such block. The software procedure has at least one input corresponding to the at least one block, at least one output corresponding to the at least one output of the block and a state. The state is a function of at least one input of the software procedure occurring at a prior time step to a current time step in execution of such procedure. Means is provided for processing the software procedure for calculating the at least one output of the software procedure as a function of the state. Means is operative, subsequent to the processing of the first named means., for processing the software procedure as a function of at least one input thereof for calculating the state for use during subsequent processing of the procedure.

Also disclosed is a method for machine assembling in an order a plurality of procedure for processing where the procedures each perform at least one function and represent multiple blocks of a block diagram. The block diagram is capable of having at least one feedback loop. At least one procedure corresponds to each block for performing at least one function. Each block and the corresponding procedure has at least one input or at least one output. The blocks have interconnections between inputs and outputs of the blocks forming the block diagram. Each of at least some of the blocks and the corresponding procedure have an input that directly affects an output thereof. Each of at least some of the blocks and the corresponding procedure have an input that affects an output of such block after a delay. The method of machine assembling involves providing a list of such interconnections between the inputs and outputs and, in addition to the list of interconnections, at least one feed-through list for each of at least some of the blocks. Each feed-through list has a list of any input which directly affects an output of the same block. The interconnection and feed-through lists are processed in the machine for ordering of the procedures during assembling.

Applicant discloses a method for building in a memory, for subsequent machine processing, a machine readable data base representing a block. The block has at least one input or at least one output for connection in a feedback loop with other blocks in a block diagram. The at least one input does not directly affect the at least one output and is connected in the feedback loop. The at least one block in said feedback loop corresponds to a procedure for performing at least one function representative of the block. The procedure has at least one input corresponding to the at least one input of the block, at least one output corresponding to the at least one output of the block and a state. The state is a function of the at least one input of the procedure occurring at a prior time step to a current time step. The software procedure is separated into first and second software procedure portions. The method involves storing in the memory, a representation of the first procedure portion for calculating the output of the procedure as a function of the state, and storing in the memory a representation of the second procedure portion for calculating the state for use by the first procedure portion.

Disclosed herein is a method for building in a memory, for subsequent machine processing, a machine readable database of each of multiple blocks of a block diagram capable of having at least one feedback loop. Each block corresponds to a procedure for performing at least one function. Each block and the corresponding procedure comprise at least one input or at least one output. The blocks and corresponding procedures having interconnections between inputs and outputs of the blocks forming the block diagram. Each of at least some of the blocks and the corresponding procedure have an input that directly affects an output thereof. Each of at least some of the blocks and the corresponding procedure having an input that affects an output thereof after a delay. The method for building the database involves storing in the memory, for each block, a machine readable list of all of any such inputs for such block. Storing in the memory, for each block, a machine readable list of all of any such outputs for such block. Storing in the memory for each block, at least one machine readable feed-through list having a list identifying all of any inputs which directly effect any output of the same block.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a schematic block diagram of a simulator for assembling a software computer program representative of a block diagram in accordance with the present invention;

FIG. 1 depicts a schematic block diagram of computer programs for operation of the simulator of FIG. 1A;

FIG. 2 is a simple block diagram having a feedback loop which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 3 is a block diagram of a signal processing filter arrangement which is formed on the display and in the simulator of FIG. 1A;

FIG. 3A depicts a representative netlist stored in a memory of the system of FIG. 1A containing information which used by the simulator of FIG. 1A to interpret the block diagram of FIG. 3;

FIG. 3B depicts a representation of a sequence list of procedure calls stored in a memory of the system of FIG. 1A, including update output procedures and update state procedures which are executed by the simulator of FIG. 1A to simulate the block diagram of FIG. 3;

FIG. 3C depicts a representation of a library of the procedures stored in a memory of the system of FIG. 1A, which are referenced by the procedure calls in FIG. 3B and are representative of the function of each block of FIG. 3A;

FIG. 3D depicts a representation of a compiled computer program which is stored in a memory of the system of FIG. 1A, for simulating the block diagram of FIG. 3;

FIG. 4 is a typical screen display depicting the input and output signal waveform of the block diagram in FIG. 3 being simulated by the simulator of FIG. 1A;

FIG. 5A is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the first RESTRICTED SEQUENCER method;

FIG. 5B is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the restricted ALL FEEDTHROUGH method referenced in FIG. 5A;

FIG. 5C is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the restricted SOME FEEDTHROUGH method referenced in FIG. 5A;

FIG. 6A is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the CODE GENERATOR method;

FIG. 6B is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the SYSTEM INTERPRETER method;

FIG. 7 schematically depicts a BLOCKLIST and a BLOCKLIST POINTER for keeping track of the sequence of operations of the simulator of FIG. 1A;

FIG. 8 is an alternate block diagram having a feedback loop which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 8A depicts of a representation of a NETLIST stored in a memory of the system of FIG. 1A, containing information used by the simulator of FIG. 1A to interpret the block diagram of FIG. 8;

FIG. 8B depicts a library of procedures stored in a memory of the system of FIG. 1A which are representative of the blocks in the block diagram of FIG. 8;

FIG. 8C schematically depicts another block diagram having a feedback loop which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 8D depicts a representation of a NETLIST stored in a memory of the system of FIG. 1A containing information used by the simulator of FIG. 1A to interpret the block diagram of FIG. 8C;

FIG. 8E depicts a library of procedures stored in a memory of the system of FIG. 1A which are representative of the block in the block diagram of FIG. 8C;

FIGS. 9A and 9B depict intermediate results of the simulator (FIG. 1A) controlled by the first embodiment of the RESTRICTED SEQUENCER method (FIG. 5A) controlling the sequence the procedure calls representative of the block diagram of FIG. 8;

FIG. 10 depicts intermediate results of the simulator controlled by the first embodiment of the RESTRICTED SEQUENCER method failing to sequence the procedure calls representative of the block diagram of FIG. 8A;

FIG. 11A is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the first GENERAL SEQUENCER method;

FIG. 11B is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the ALL FEEDTHROUGH method referenced in FIG. 11A;

FIGS. 11C and 11D are flow diagrams which depict the sequence of operations of the simulator of FIG. 1A under control of the SOME FEEDTHROUGH method referenced in FIG. 11A.

FIGS. 12A, B, C and D are tables depicting intermediate results of the simulator (FIG. 1A) controlled by the first GENERAL SEQUENCER method of FIG. 11A sequencing the procedure calls representative of the blocks of FIG. 13;

FIG. 13 is a further block diagram having a feedback loop which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 13A depicts a representation of a NETLIST stored in a memory of the system of FIG. 1A containing information used by the simulator of FIG. 1A to interpret the block diagram of FIG. 13;

FIG. 13B depicts a library of procedures stored in a memory of the system of FIG. 1A which are representative of the blocks in the block diagram of FIG. 13;

FIG. 14A is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the second RESTRICTED and GENERAL SEQUENCER methods;

FIG. 14B is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the PROCESS EXTERNAL NETLIST method which is referenced by FIG. 14A;

FIG. 14C is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the SEPARATE FUNCTIONALITY method referenced by FIG. 14B in the RESTRICTED CASE when there is only one update output procedure and only one feedthrough list per block;

FIG. 14D is also a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the SEPARATE FUNCTIONALITY method referenced by FIG. 14B in the RESTRICTED CASE when there are multiple update output procedures and only one feedthrough list for the block;

FIG. 14E is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the SEPARATE FUNCTIONALITY method referenced by FIG. 14B in the general case;

FIG. 14F is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the SEQUENCER DRIVER method referenced by FIG. 14A;

FIG. 14G is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the SEQUENCER method referenced by FIG. 14F;

FIG. 15A is still another block diagram having a feedback loop which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 15B depicts a representation of a NETLIST stored in a memory of the system of FIG. 1A containing information used by the simulator of FIG. 1A to interpret the block diagram of FIG. 15A;

FIG. 15C depicts a library of procedures stored in a memory of the system of FIG. 1A, which are representative of the blocks in the block diagram of FIG. 15A;

FIG. 15D is an "expanded" version of the block diagram of 15A which is simulated by the simulator of FIG. 1A;

FIG. 15E depicts a representation of an internal Netlist stored in a memory of the system of FIG. 1A containing information to be used by the simulator of FIG. 1A to interpret the block diagram of FIG. 15B.

FIG. 16 is a table depicting intermediate results of the PROCESS EXTERNAL NETLIST method controlling the expansion the netlist of FIG. 15B into the internal netlist of FIG. 15E;

FIGS. 17A, B, C and D depict intermediate results of a simulation of the block diagram of FIG. 15D controlled by the second RESTRICTED SEQUENCER method of FIGS. 14A, B, C, E, F, and G;

FIG. 18A is another block diagram having a feedback loop which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 18B depicts a representation of a netlist stored in a memory of the system of FIG. 1A containing information used by the simulator of FIG. 1A to interpret the block diagram of FIG. 18A;

FIG. 18C depicts a library of procedures stored in a memory of the system of FIG. 1A which are representative of the blocks in the block diagram of FIG. 18A;

FIG. 18D is an "expanded" version of the block diagram of FIG. 18A which is simulated by the simulator of FIG. 1A;

FIG. 18E depicts a representation of an expanded netlist of FIG. 18B containing information necessary for the simulator of FIG. 1A to interpret the block diagram of FIG. 18D;

FIG. 19, including FIGS. 19A, B and C depicts intermediate results of the PROCESS EXTERNAL NETLIST method for controlling the expansion of the netlist of FIG. 18B into the internal netlist of FIG. 18E;

FIGS. 20A, B, C, and D depict intermediate results of a simulation of the block diagram of FIG. 18D controlled by the second GENERAL SEQUENCER method of FIGS. 14A, B, D, E, F, and G;

FIG. 21 is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the first RUNTIME SIMULATOR method;

FIG. 22A is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the first NUMBER OF SUBITERATIONS method referenced in FIG. 21;

FIG. 22B is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the DETERMINE MAXIMUM CHAIN method referenced in FIG. 22A;

FIG. 23 is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the second NUMBER OF SUBITERATIONS method referenced in FIG. 21;

FIG. 24 is a further block diagram which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 24A depicts a representation of a netlist stored in a memory of the system of FIG. 1A containing information necessary for the simulator of FIG. 1A to interpret the block program of FIG. 24;

FIGS. 25A, B, C, and D depict intermediate results of a simulation of the block diagram of FIG. 24 by the first RUNTIME SIMULATOR method;

FIG. 26A is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the second RUNTIME SIMULATOR method;

FIG. 26B is a flow diagram which depicts the sequence of operations of the simulator of FIG. 1A under control of the INITIALIZE method referenced in FIG. 26A;

FIG. 27 is a block diagram which is formed on the display and is simulated in the simulator of FIG. 1A. Also depicted is a feedthrough list, output list of outputs with null feedthrough (OLNF), output list of outputs with feedthrough (OLF), and state block list (SBL), all stored in memory and corresponding to the block diagram are also shown;

FIG. 27A depicts a representation of a netlist stored in a memory of the system of FIG. 1A containing information necessary for the simulator of FIG. 1A to interpret the block diagram of FIG. 27;

FIG. 28 depicts intermediate results of the second RUNTIME SIMULATOR method simulating the block diagram of FIG. 27;

FIG. 29 is a block diagram with one block having a control input which is formed on the display and in the simulator of FIG. 1A;

FIG. 30 is a block diagram of a unit delay block with a control input for "hold" which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 31 is a block diagram of an integrator block which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 32 is a block diagram of an integrator block with a control input for "reset" which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 32A is a block diagram of a coefficient block with a control input "set" which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 33 is a block diagram of an integrator block with two control inputs, one for "hold" and one for "reset" which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 34 is a block diagram of a block diagram, having control blocks for modeling multi-rate processing, which is formed on the display and is simulated in the simulator of FIG. 1A;

FIG. 35 is a flow diagram of the operation of the multi-rate processing system in FIG. 34;

FIG. 36 depicts intermediate results of a simulation of the block diagram of FIG. 34;

FIG. 37 is a flow diagram of a system having conditional processing which might be laid out by a user on paper prior to laying out a block diagram for simulation;

FIG. 38 is a block diagram representation of the flow diagram in FIG. 37 and it is formed on the display and is simulated in the simulator of FIG. 1A; and

FIG. 39 depicts the intermediate results of a simulation of the block diagram of FIG. 38.

DETAILED DESCRIPTION

TABLE OF CONTENTS

I. AN OVERALL DESCRIPTION OF THE BLOCK DIAGRAM SIMULATOR

A. A Simple Block Diagram of FIG. 2

B. Update Output and Update State Procedures

C. An Example of the Block Diagram Simulator Simulating a Filter Diagram of FIG. 3

1) Assembly of a Computer Program Representative of the Block Diagram of FIG. 3

2) Modeling State Blocks

3) Execution of the Assembled Computer Program Representative of the Block Diagram of FIG. 3

II. SEQUENCE CONTROLLERS

A. First Embodiment of the RESTRICTED SEQUENCER Method, FIGS. 5A, B and C

1) Feedthrough List

2) The RESTRICTED SEQUENCER Method of FIG. 5A

3) ALL FEEDTHROUGH Method of, FIG. 5B

4) SOME FEEDTHROUGH Method of FIG. 5C

5) CODE GENERATION Method of FIGS. 6A and 6B

6) Detailed Example of RESTRICTED SEQUENCER Method of FIGS. 5A, B and C

7) Detailed Example of the RESTRICTED SEQUENCER Method of FIGS. 5A, B and C Failing to Sequence FIG. 8D

(a) Solution--Multiple Feedthrough Lists Per Block

B. First Embodiment of the GENERAL SEQUENCER Method of FIGS. 11A, B, C and D

1) Detailed Example of the First Embodiment of the GENERAL SEQUENCER of Method FIGS. 11A, B, C and D

C. Second Embodiment of the RESTRICTED and GENERAL SEQUENCER Methods of FIGS. 14A, B, C, D, E, F and G

1) SEPARATE FUNCTIONALITY Method of FIG. 14B for One Update Output Procedure and One Feedthrough List Per Block

2) SEPARATE FUNCTIONALITY Method of FIG. 14D for Multiple Update Output Procedures and Only One Feedthrough List Per Block

3) SEPARATE FUNCTIONALITY Method of FIG. 14E for Multiple Update output Procedures and Multiple Feedthrough Lists Per Block

4) SEQUENCER DRIVER Method of FIG. 14F

5) SEQUENCER METHOD of FIG. 14F

6) Example of the Second Embodiment of the RESTRICTED SEQUENCER Method of FIGS. 14A, B, C, F and G

7) Detailed Example of the Second Embodiment of the GENERAL SEQUENCER Method of FIGS. 14A, B, E, F and G

D. RUNTIME SEQUENCER Methods of FIGS. 21 and 26

1) First Embodiment of the NUMBER OF SUBITERATIONS Method of FIG. 22A

2) MAXIMUM CHAIN LENGTH Method of FIG. 22B

3) Second Embodiment of the NUMBER OF SUBITERATIONS Method of FIG. 23

4) Detailed Example of the RUNTIME SIMULATOR of FIGS. 21, 22A and 22B

5) Second Embodiment of the RUNTIME SIMULATOR Method of FIGS. 26A and 26B

6) Detailed Example of the Second Embodiment of the RUNTIME SIMULATOR Method of FIGS. 26A and 26B

E. Control Input Simulation

DETAILED DESCRIPTION

I. AN OVERALL DESCRIPTION OF THE BLOCK DIAGRAM SIMULATOR

FIG. 1A depicts a block diagram simulator for assembling and executing software computer programs representative of block diagrams. The simulator software is housed in a store 11 which is in the computer workstation platform 10. The platform 10 enables users to communicate with the simulator software. More particularly, FIG. 1A depicts a conventional platform including a microprocessor 2, display 3, keyboard entry 4, mouse 6 for communicating with the microcomputer 2 and auxiliary disk file 5. When the store 11 is loaded with software programs including the simulator's software to be described, the simulator or platform 10 is formed.

FIG. 1 depicts a combined block diagram of the computer programs, library, netlist and sequence list used by the platform 10 of FIG. 1A as well as the data flow for simulation. More particularly, BLOCK DIAGRAM EDITOR (BDE) 12 enables the designer to define a configuration of the block diagram on the screen display 3 (FIG. 1A). A BLOCK LIBRARY MANAGER 14, maintains a BLOCK LIBRARY STORE 14A which contains computer procedures, symbols and other information (to be described) representative of the blocks in the block diagram. NETLIST GENERATOR 16 is a computer program which causes platform 10 to assemble an interconnected list which is the first computer readable version of the block diagram specified by the designer and it is stored in the netlist store 16A. SIMULATION PROGRAM BUILDERS (SPB) 18 and 26 are computer programs that cause the platform 10 to construct and execute computer programs representative of the block diagrams on the screen display. SIGNAL DISPLAY EDITOR (SDE) 30 is a computer program that causes the platform 10 to edit and/or evaluate the signals generated by the simulation. Many of the computer programs listed above can also be represented as hard wired chips which separately control the operations of the platform 10. Designing logical circuit descriptions from computer programs is well known to those skilled in the art.

Platform 10 has the capability of enabling a user to maintain a large number of windows or displays for viewing on the screen so that the user can examine and obtain information from several module levels at the same time. The platform 10 also maintains a menu (not shown) of the various displays so that the user can select a particular display on the screen.

A designer specifies the topology of a proposed system in terms of blocks by using the BDE 12. The BDE 12 is a software package which enables the user to construct a block diagram with the mouse 6 and the keyboard 4 (FIG. 1A). The mouse 6 is a device used to designate blocks, make connections between blocks, etc., and is well known in the art. The LIBRARY STORE 14A is an extensive database of symbol drawings and computer procedures representative of the functions of each of the blocks. More particularly, the computer procedures are representative of functions or control functions or signal processing functions to be simulated. The execution of the computer procedures for any block causes the platform 10 to simulate the operation of the block. Execution of the computer procedures for all the blocks of a block diagram on the display causes the platform to simulate the operation of the over block diagram.

The signal processing procedures stored in the LIBRARY STORE 14A span a wide range of function complexity, starting with "primitive unit delay," summer and multiplier blocks and concluding with procedures that perform high-level functions such as adaptive processing. By way of example, a preferred embodiment of the invention includes procedures well known in the art for implementing the following types of functional blocks: DSP Kernal Blocks - Unit Delay, 2-Input Multiplier, 2-Input Adder, Constant, Coefficient; Linear Processing Blocks - Filter, Bulk Delay, Tapped Delay Line, FFT, Integrator, Differentiator, Multiple Input Summers; Non-Linear Processing Blocks-Quantizer, Clipper, Thresholder, Positive Rectifier, Negative Rectifier, Switch Out, Switch In, Max/Min Value Finder; Mathematical Blocks - 1/x, e.sup.x, ln(x), sin (x), cos(x), tan(x), atan(x,y), square root, x.sup.y, 20log.sub.10 (x), abs(x); Signal Generation/Storage/Re-Sampling - Signal Source, Signal Sink, Vector Signal Source, Vector Signal Sink, Write to Results File, Programmable Function Generator, Noise Generator, Impulse, Unit Step, File Constant; Vector Operations - Vector Sum, Vector Component Sum, Vector Dot Product, Vector Pointwise Multiply, Vector Scale, Vector Delay, Vector Reverse, Vector Split to Vectors, Vector Split to Scalers, Vector Joined to Vector, Scalers Joined to Vector; Flow of Control - Hold Value, 2-Input And, 2-Input Or, Inverter, Stop, Clock, Counter, Latch; Instruments - Tek 11400 Scope, Tek 5010 Function Generator. A more detailed description of each functional block is presented in a manual entitled "Signal Processing Worksystem User Guide-Document, Version O.O.", CAE Systems Inc. - Tektronix Inc., Chap. 4, pp. 1-281 (August 1987).

The block diagram created by the designer on the display is converted into a computer-readable form called a network list (netlist) under the control of the NETLIST GENERATOR 16. The techniques employed by the system for generating a netlist are well known in the art. Typically, the netlist contains a list of the inputs and outputs line connections and parameter values for each block. The SPB 18 and 26 cause the platform 10 to generate and execute computer programs representative of the block diagrams.

More particularly, SPB 18 contains three parts; a SEQUENCE LIST GENERATOR 20, a CODE GENERATOR 22, and a PROGRAM EXECUTOR 24. There are four different embodiments of the SEQUENCE LIST GENERATOR 20 to be discussed. The SEQUENCE LIST GENERATOR 20 controls the creation of a sequence list of procedure calls. The sequence list is maintained in a SEQUENCE LIST STORE 20A. The sequence list is then compiled into object code under control of the CODE GENERATOR 22. Either a simulation is preformed under control of the PROGRAM EXECUTOR or the compiled code is loaded in to another storage area of the platform or into storage of a separate system such as microprocessor chip 21. For example, microprocessor chip 21 can perform in a real time product environment to control the operations of the product (i.e., carburetor control, flight control, etc.)

SPB 26 is a RUNTIME SIMULATOR 28 which does not require the generation of a sequence list and it does not require code compilation. Instead, program code is preassembled and called when needed for execution.

After either SPB 18 or 26 is executed, the SDE 30 has a variety of editing commands that are used to analyze the resulting signals from a simulation. The SDE 30 is capable of performing; linear or non-linear processing, and spectral and statistical analysis of the signals. The SDE 30 is also capable of generating and manipulating signals that can be used as input signals to a simulation run. Although a detailed description of the SDE 30 is not provided, various embodiments of the SDE 30 are well known and available to those skilled in the art.

Briefly, what is disclosed is a method and apparatus using an automatic program generation computer for assembling a computer program representative of a functionally interactive and interconnected block diagram. The assembled program can either be executed for simulation of the block diagram or it can be processed for storage.

In the alternative, the method and apparatus may execute the program as it is assembled on a run-time basis and, thereby, simultaneously assemble and execute the program.

The block diagram created by a user on the screen display is a functional system, which has a plurality of interactively connected first and second system blocks or functionality blocks, forming the overall block diagram. Some of the blocks have an input, some have an output and some have both inputs and outputs. Some of the system blocks have at least one input which is functionally defined by an output of a system block. Some of the system blocks are second system blocks with delay or state blocks, each of whose operation, at one time, is dependent on the condition of the input at a prior time than the current time. Stated differently, the output is dependent on a prior input signal rather than the current input signal.

The LIBRARY STORE 14A includes a stored update state procedure corresponding to each second or state system block, which defines a "state" of the second or state system block as a function of its inputs. Also, each library block includes at least one stored update output procedure, which defines its output as a function of any of its inputs, and/or the state, if the system block is a second or state systems block. An example of the procedure calls and procedures are shown in FIG. 3C.

The LIBRARY STORE 14A also includes in each library block certain other information which is representative of the characteristics of the system block. This information includes, by way of example, a system block type, a list of all inputs to the system block, a list of all outputs from the system block and a feed-through list which lists all inputs which directly affect the output of the system block. More particularly, the feed-through list identifies all inputs to the corresponding system block and therefore update output procedure, which directly affects the output of the system block and are used as input to the update output procedure of the corresponding library block.

In operation, the platform 10 processes the representations of the characteristics of each of the blocks. The block diagram is converted into a sequence list of procedure calls, i.e., a list of the procedure calls for update state procedures (i.e., representations of update state procedures), if any, and separately, procedure calls for update output procedures (i.e., representations of update output procedures). When the procedure calls are compiled, the corresponding procedures are obtained from the library and expanded into object code ready for execution. Execution of the object code in the order depicted by the sequence list effectively simulates the operation of the block diagram.

The SEQUENCE LIST GENERATOR 20 is used for sequencing the procedure calls and storing them in the sequence list which is stored in the SEQUENCE STORE 20A. The stored sequence list in STORE 20A is subsequently used by the platform for obtaining the corresponding procedures (source code) from the STORE 14A which is processed by the CODE GENERATOR 22 for compiling object code. The object code may be executed by the microprocessor to simulate the operation of the block diagram using digitally coded representations of signals and to form output signals which may be displayed on the screen as depicted in FIG. 4. In the alternative, the object or machine code may be output, processed and then stored in the memory of another system such as a mainframe computer or a microprocessor chip 21 for controlling the operation of the respective system so as to simulate the operation of the block diagram.

In the RUNTIME SIMULATOR, a sequencer executes, for each of the blocks in a data dependent sequence, on the update state procedures (i.e., representations of update state procedures) , if any, and update output procedures (i.e., representations of update output procedures). Additionally, each update state procedure is included in the sequence separate from the update output procedure for the corresponding state block.

The procedure calls are executed on a real-time basis to simulate the operation of the block diagram on the display.

A. A Simple Block Diagram of FIG. 2

FIG. 2 represents a simple block diagram having one feedback loop that has been created on the display by a user. Each block corresponds to a particular function to be performed by a software procedure which is stored in LIBRARY STORE 14A. The blocks 52, 54, and 56 are connected by lines 58, 60 and 62 and these interconnecting lines represent the transfer of data between the blocks. The output 58 of block 52 becomes the input 58 to block 54, and the output 60 of block 54 becomes the input 60 of block 56. The input 62 to block 54 is also an output of block 54. Data flows through the system f rom block 52 to block 56 when a simulation of the block diagram is performed.

The order in which each procedure representing each block is carried out must be carefully considered, to guarantee that the input data to each procedure representing a block is defined before the block's procedure can properly process the data. When a procedure for a block's output is produced by processing defined inputs for the block's procedure, the output is said to be "updated." Essentially, the term "updated" means that the signal information in the output of the particular block is defined.

Simulation of the block diagram in FIG. 2 in one prior art system involves calling the software procedures representative of the blocks in an order from the left most block to the right most block. This procedure is called "next block simulation." Assuming that "next block simulation" is used to simulate the block diagram, the procedure representative of source block 52 is called first, to produce output 58. Then the procedure for block 54 is called, however, this procedure could not be properly processed because input 62 is still not yet defined. Input 62 is part of a feedback loop and it will not be defined until block 54's output is updated. Stated differently, the only way the simulator could define input 62 is by processing the procedure for block 54. However, the procedure for block 54 cannot produce defined outputs until inputs 58 and 62 are both defined. Thus, the procedure for block 54 can never produce defined or updated outputs because input 62 will never be defined using this approach.

A solution to this dilemma would be to examine the delay properties of the blocks involved in the system. If block 54 had a delay property, the output to block 54 could be generated without having to have defined data at input 62. If block 54 has delay, i.e., is a second system block, then it must have memory, or a state. One way of adding a delay property to a block would be to add memory or a "state" to the block. (Blocks having delay are often called a "delay blocks" or "state blocks".) The procedure for the block can then process "state" information which had been previously stored and used generate defined or updated outputs for the first time step and before the state is updated.

B. Update Output and Update State Procedures

In the preferred embodiment, two computer procedures are provided for maintaining and processing the state of a block having a delay property. First, a computer procedure is provided for processing the inputs and/or the state of the block to produce defined outputs. This computer procedure, regardless of its function, is called the "update output" procedure for the output. The second procedure is solely for updating the state of the block once its inputs are defined. This procedure is called the "update state" procedure. Both procedures effectively model the operation of a state block which has a state. The designer of the "update output" and "update state" procedures must consider the function of the block in order to determine how the procedures should be represented. A more detailed discussion on the designer's design consideration will be provided in section I[C(2)]).

A significant portion of the invention relates to an apparatus and method for determining the proper sequence of software procedure calls to be made so that defined data is processed during a simulation, particularly when the block diagram (as in FIG. 2) to be simulated has delay blocks. The computer procedure calls control the steps performed by the computer for simulating the operation of a block. An update output procedure processes the inputs signals to a block to determine output signals from the block. For example, an update output procedure might be the procedure for multiplying a coefficient `y` by an incoming signal to produce an output. Whereas, an update state procedure is for updating the state of a block. For example, the update state procedure for a unit delay block updates the state of the block with the current input signal to the block. The update output procedure for this block is a procedure for outputting the input signal stored in the state from the prior time step. For the purpose of providing background to the reader, the following discussion illustrates the procedure a hypothetical simulator would follow in order to model and simulate a more complex example which has state blocks by using the update output and update state procedures.

C. An Example of the Block Diagram Simulator Simulating a Filter Diagram of FIG. 3

FIG. 3 is representative of a block diagram of a simple filter for cleaning up a signal. For example, this filter might be used to take noise out of a speech signal generated at source block 64. Sink 68 would contain a filtered version of the speech signal without the noise. Referring to FIG. 4, a screen display of the source and sink signals is shown. Signal 65 represents a speech signal prior to filtering, and signal 66 represents the speech signal after filtering.

The source block 64 generates signals and the coefficient blocks 72, 74 and 76 multiply the source signal by B.sub.2, B.sub.1, and B.sub.0, respectively. Blocks 78, 82, and 86 are summer blocks for summing the inputs connected to the blocks. Blocks 88 and 90 are also coefficient blocks which multiply A.sub.2 and A.sub.1 by the signal which is fed back over line 120. The delay blocks 80 and 84 are "unit delay" blocks, meaning that their outputs are the value of the block's input or inputs from the previous time step. The output is a function of this previous information and the previous information can be preset so that when the system "starts up," the memory or state is loaded with the proper parameters to generate a defined output on the initial time step of execution.

1) Assembly of a Computer Program Representative of the Block Diagram of FIG. 3

Consider now a general example of how the SEQUENCE LIST GENERATOR 20 creates a sequence list to be stored in the SEQUENCE LIST STORE 20A, according to the present invention. First, a designer might use the keyboard 4 and mouse 6 (FIG. 1A) to design the block diagram of the filter shown in FIG. 3. Software of the BDE 12 enables the designer to direct lines and make interconnections on the screen display. Once the block diagram has been completed a netlist representation of the block diagram can be formed by the NETLIST GENERATOR 16. The netlist is a representation of the block diagram, which characterizes the block diagram for the platform 10. The netlist representation of the block diagram for FIG. 3 is shown in FIG. 3A. Each netlist element, each row of FIG. 3A) corresponds to a different block and the element contains four categories of information; a block function type, an instance number, inputs to the block and outputs from the block. The block function type is a computer-language description of the type of function (coefficient, "unit" delay, etc.) represented by the block. The instance number corresponds to the occurrence of a particular block in the block diagram. Instance numbers differentiate the blocks which have the same block type. For example, the coefficient block type is represented five times in the block diagram of FIG. 3, at 72, 74, 76, 88 and 90. The instance numbers enable the platform to differentiate the coefficient blocks from one another. If the blocks in the block diagram were all of different function types, then only the function type for the blocks is necessary to distinguish the blocks from one another. In the preferred embodiment, the instance numbers are included in the netlist regardless of whether they are actually utilized to differentiate the blocks.

Referring to FIG. 3A, a description of some of the elements in the netlist corresponding to FIG. 3 is now discussed. Specifically, element 2040 is a netlist description of the source block. The source block has an instance number 64, no inputs and an output 0.sub.1, which is connected to line 92. The next element, 2042 in the netlist, describes the interconnection of the coefficient block, B.sub.0, in the block diagram (FIG. 3). In particular, the coefficient block, B.sub.0, has an instance number 76, an input I.sub.1 connected to line 92 and an output 0.sub.1 connected to line 104. Input I.sub.1, to the coefficient block B.sub.0, is connected to the same line as the output 0.sub.1 of the source block 64. This information enables the platform 10 to link the output of the source block to the input of the coefficient block B.sub.0 76. Referring to element 2044, the netlist description of the coefficient block, B.sub.1, is shown. Coefficient block B.sub.1 has an instance number 74, input I.sub.1 connected to Line 92 and output 0.sub. 1 connected to line 102. As in the case of the coefficient block, B.sub.0, the coefficient block B.sub.1 is also connected to line 92. The platform 10 also links up the output 0.sub.1 of the source block 64 to the coefficient block B.sub.1, 74.

The netlist information shown in FIG. 3A enables the platform to characterize the entire filter diagram. Additional information may be contained on the netlist; however, for purposes of this application, only the information shown in FIG. 3A is necessary to characterizing the block diagram of FIG. 3 for simulation purposes.

Once the netlist has been generated by the NETLIST GENERATOR 16, an ordered list or sequence list of procedure calls for simulating the filter (FIG. 3) can be generated. The sequence list contains the proper order of procedure calls for referencing computer procedures stored in the LIBRARY STORE 14A. FIG. 3C depicts the computer procedures representative of the blocks in the filter block diagram (FIG. 3) which are stored in LIBRARY STORE 14A. Referring to FIG. 3B, the sequence list of procedure calls corresponding to the filter FIG. 3 is shown. Specifically, a list of fourteen procedure calls (in the C-LANGUAGE) are shown. The formation of the sequence list (FIG. 3B) is controlled by one of the four methods executed by the SEQUENCE LIST GENERATOR 20. Representative information feedthrough list, etc. (to be discussed), of each block in the LIBRARY STORE 14A is analyzed, along with the netlist information to determine the order in which the procedure calls are placed on the sequence list.

A general description of the strategy for generating the sequence list of procedure calls (FIG. 3B) is now discussed. First, the source block 64 does not have any inputs and thus requires no input signal to be generated before it can produce an output. Thus, the update output procedure call for this block is placed on the sequence list (2064, FIG. 3B) The next update output procedure calls placed on the sequence list are for the Z-blocks or unit delay blocks 80 and 84. These blocks do not require defined input data and therefore, can generate output data as long as their states have been preset (2066, 2068, FIG. 3B). Any one of the update output procedures calls for the coefficient blocks 72, 74, 76 can then be placed on the sequence list in any order (2070, 2072, 2074, FIG. 3B). Then the procedural call for summer block 86 (2076, FIG. 3B), followed by the procedure call for the coefficient blocks 88 and 90 (2078, 2080, FIG. 3B), followed by the procedure call for the summer blocks 78 and 82 (2082, 2084, FIG. 3B), followed by the procedure call for the sink block 68 (2086, FIG. 3B) are placed on the sequence list. The last procedural calls to be placed on the sequence lists are for updating the states of the Z-blocks 80 and 84 (2088, 2090, FIG. 3B).

CODE GENERATOR 22 assembles a computer program representative of the sequence list (FIG. 3B), by expanding each procedure call into the corresponding computer procedure stored in the LIBRARY STORE 14A. For example, the update output procedure call for the Z-block 3, is:

    ______________________________________
    UO.sub.-- dly.sub.-- spb
                  (param. 80, inputs 110, outputs 112,
                  STATE 80)
    (2066, FIG. 3B).
    ______________________________________

    ______________________________________
    U.sub.-- dly.sub.-- spb
                (param., input, output, state)
                spb.sub.-- output .fwdarw. out = spb.sub.-- state .fwdarw.
                past.sub.-- value
                return
    (2094, FIG. 3C).
    ______________________________________

    ______________________________________
    UO.sub.-- dly.sub.-- spb
                (param. 80, inputs 110, outputs 112,
                STATE 80)
                spb.sub.-- output .fwdarw. out = spb.sub.-- state .fwdarw.
                past.sub.-- value
                return
    (2108, FIG. 3D).
    ______________________________________

    ______________________________________
    US.sub.-- dly.sub.-- spb
                (param. 80, inputs 110, outputs NONE,
                STATE 80)
                spb.sub.-- state .fwdarw. past.sub.-- value = (spb.sub.--
                input .fwdarw. in)
                return
    (2130, FIG. 3D).
    ______________________________________

    ______________________________________
    UO.sub.-- dly.sub.-- spb
                (param. 80, inputs 110, outputs 112,
                STATE 80)
                spb.sub.-- output .fwdarw. out = spb.sub.-- state past.sub.--
                value
    (2108, FIG. 3D).
    ______________________________________