DE4310615A1 - Method and device to provide a system which can be configured by the user, and integrates and manages several different tasks and software tools - Google Patents

Abstract

The invention concerns a method and device to provide a system which can be configured by the user, and integrates and manages several different tasks and software tools. It is designed mainly for use in design and production automation systems. The system has a main control routine, which uses macros to control each process to be carried out, including the sequencing of tasks and the encapsulation of all incompatible software tools which work with the control program. The encapsulation controls the interpretations for transfers between the incompatible tool and the control program. Additional routines are provided, to make available interfaces between different tools, including tools which have different kinds of incompatibility, and between an operator and the system, or between the various tools which are used in it. All routines are rule-based, and these rules, including the macros which are used in the control routine, are written in an interpretive expansion language, which can be read by both people and machines. Thus the system can easily be configured and reconfigured by the user.

Description

The present invention relates to design and Production automation systems and especially one Method and device for providing a user-configurable system, which is multiple different software design and production tasks and -tools unites and manages, at least some these tools ("software tools") do not interact with each other and compatible with the unify and manage system could be.

Nowadays, computers are used to design that Production preparation, manufacturing and at Examination of numerous products used. Examples in the field of electronics include integrated  Circuits, printed circuit boards, and Products that use such components including computers, electronic home appliances and the like. Similar approaches are used at Products, such as household appliances, Cameras, motor vehicles and the like are used. Therefore the computer-controlled automation of the design, the making and examining in everyone Industry are used in which several Steps in creating and making one Finished product are necessary.

Typically, several can be different Equipment used to do the various Carry out design manufacturing and testing processes, and the user can either standardized or have specially adapted software packages or tools that he to perform the various functions used. In many cases, the languages legal strings, formats, syntax and others Factors used in the various software tools are used or to communicate with them are not fully compatible.

Nowadays the software tools are separate procedures, which are used to record, check and analyze the Performance of a design used during the design phase to represent the design during the Manufacturing design phase to carry out the various manufacturing steps during the Manufacturing stage and to study the various Components of the final product during the test stage. The separate procedures are used sequentially, where the output of a tool or process the input for the  represents the following process. The most common procedure for Using these sequential processes is waiting for a trial to be completed and one subsequent process with the output from the previous one Process through the use of an instruction sequence operate that on a keyboard or other Input device for one or more components of the system is entered. In this way, the user submits Using a terminal display and a keyboard or another input device the sequence of operations and in many cases represents the proper transfer required information from one process to the next for sure.

This separate use of individual processes can be used for Users become quite troublesome and are common additional programs required, called translators, to properly output data from one process to one to transmit to others as a result of various Incompatibilities between the programs. The user must be able to deal with the processes in one Standard operating system language to communicate, and must have a clear understanding of how the inputs and Outputs of the various processes can be controlled.

This requires that all users of the system use the Know the operation of the entire system completely, as well as each of the tools used in it. Furthermore, this requires that every time one of the software tools Change is made, for example to update it and improve, or in language or procedures a change is made by any component in system, all potential System users notified of the change  have to be, and have to understand this in order to Prevent operator errors and optimal operation of the system.

In addition, with existing systems, even one knowledgeable and experienced users a significant Time required to complete a task as a result the number of separate, sequential operations that are required and the user must be careful work to ensure that the task is working properly is ended. Because the user has little guidance in the Implementation of operational procedures may occur even with the most careful user mistakes, and the Systems are not a systematic way of determining of errors available when they are entered so that such errors get through the system can, from one process to the next, without being determined what leads to cumulative errors that - if they be discovered once - a time-consuming and expensive May require correction.

In addition, if a user specifies that one is currently New software tool not used in the system should be used, there is no systematic How to add such a tool. This can result in a new data translator designed, developed, examined and confirmed and that other procedures may be required to provide an interface for such a tool in the System, and all of these Steps require considerable experience, time and effort Costs until they are successfully completed.  

In particular with existing systems the software generally only available in the form of an object code posed, and a user cannot make changes or can only do this in the source code executing compiled in a separate process must be, usually outside the system, before it is usable for the system. It would be preferable if the User could control the system with a code that is in is written in an interpretive extension language, which are readable both by the machine and by humans is.

There is therefore a need for an improved method and an improved device (sometimes collectively as "System") for use with multiple different software design and production tools, which the use of such a system for Simplify end users significantly, and only considerably less knowledge of the system and the software tools used by the end user. In particular, such a system should be simple and systematically the interface between the System users and the various tools and operations taxes to be performed on the system should all communications between the control various software tools in the system and ensure that necessary interpretations and Translations are carried out, and the time Manage the sequence of tasks required to perform a certain goal be carried out so that the user a desired destination only by a suitable input indicates, and the system can continue to do so in the correct order, the different tasks to carry out the necessary to achieve this goal  are. Such tasks can do the transfer required information from a software tool to the next include and prompts to the user for additional entries if required. A such system should be all necessary Translations and interpretations between not perform compatible software tools, and all such translations should preferably be used for both the user or operator as well for the different Software tools that are currently running, transparent or to be understandable. Such a system should be about it Be flexible enough to use it relatively simple procedures through a System integration device configurable and again is configurable, such additions, Magnifications or other changes for the Users are transparent. In particular, everyone should Controls for such a system in one interpretive extension language are written, which is a simple change of the controls by the User allows, but still readable by machine is. Therefore, the system operator would always do that latest, enlarged version of the system with all Use the possibilities of the system and should always if appropriate, be prompted to do so Skills. As far as the user is not with the Function of a particular skill is familiar a "help" function will be provided to help to support him.

As explained above, the present relates to Invention a method and an apparatus for a User configurable system that the Operating sequence of several different tasks and Software tools integrated and managed, at least  some of these tools may not be compatible with the system where the tools should be used, and / or not compatible with each other. The System contains a list of software tools that are on or can run with the system, the list being a Display includes whether the tools are compatible with the system are or not. Multiple control macros can also be stored, with each of the macros performing of a particular process. A to be carried out Process is in the system either by a user or entered by a previous process, this one Macro corresponding to the process is retrieved. In reaction on the return of the macro are tasks that selected tools concern, in a predetermined Sequence executed. Becomes an incompatible tool executed, it is encapsulated, which leads to the fact that all transfers from and to the tool checked and, if necessary, interpreted. Several of the rules of interpretation may also apply stored in a predetermined location in a macro, which contains a software tool that is encapsulated got to. For every transfer to and from the tool a review is performed to determine whether one or more of the rules of interpretation applicable are, and the usually fixed interpretation will carried out when it is determined that a Interpretation rule a transferred object concerns. Separate rules can be used for transfers to a incompatible tool and transfers from one not compatible tool.

For certain embodiments, each item is shown in a rule macro in an interpretative Extension language written by both humans  is also understood by the machine. This includes the Interpretation rules used for encapsulation become. A macro can be rules for multiple software tools included to perform a given task (Task), the rules including the order determine in which the tools are to be executed. A macro can also contain a rule or rules which cause a new macro to be retrieved.

Macros can be used to control the order of rules Tools contain the interfaces of tools with the System, with one user and with each other. The user of the system can add rules in existing macros or change, or add new macros, all of this in the interpretive language of expansion. This leads to the rules are recognized by the system and by the System in the expansion language can be executed immediately. Therefore, the system can be reconfigured to new ones Add functions or new tools, system or Install tool extensions or other changes, errors to correct or for any other purpose.

The format for at least some of the tools can be from that Format may be different for other tools, though Transfers in at least one direction between such incompatible tools in terms of format. A rules file can be made available in is written in an interpretive language of expansion, which contains format conversion rules for tools that incompatible formats. If a transfer between tools incompatible with the format should be carried out, the appropriate ones Format conversion rules retrieved from the rules file and to control the format conversion of the material  used, which is transferred between such tools shall be.

There may also be incompatibilities with valid ones Strings (i.e. valid names) between tools exist. A rules file is also available posed in an interpretive language of expansion is written, what translation rules for tools contains such an incompatibility regarding the Show name. If there is a transfer between in the name of incompatible tools appropriate rules retrieved in the rule files and to do so used to carry out the translations necessary for this are required to make the tools compatible.

If a name in the original language is translated into a name in the generated language is translated in a Name list an entry for the original and the generated names performed. Is there such a thing? Entry for a name that requires translation so the entry is used to translate the name. If there is no entry for a name to be translated, the appropriate rules in the rules file become Translation of the name used. If a translation using rules from the rules file is carried out after the translation Verification can be done to find invalid characters remove the translated name to an appropriate one Limit maximum length, if necessary, to the add prefixes or suffixes to translated names, and to change the translated name to make it unique is in case a uniquely translated name for everyone translating name is required and if one such change is possible. An alias file can be used for  all entries are generated and saved for a specific use has been made, and the Alias file can be retrieved and used if a subsequent transfer between the same two Tools is required. It is also possible that such alias files originally along with the Translation rules are made available. Furthermore, a skill can be provided which enables an original name to be created from the Name is obtained. If the translated or generated Name is not unique, so can be generated for everyone Names provided a list of original names his.

One or more of the tools can also be one nested hierarchy of material related Components or other objects have different names for the same Object at different levels in the hierarchy be used. A rules file is provided that at least translation entries for the names of the different hierarchy levels, these Rule file is used to give the appropriate name for an object at a given hierarchical level to obtain. The rules for naming an item can also at different hierarchy levels can be different, and the rules file can also Translation rules for the hierarchy levels included.

A user can also enter information for at least some tools are required. Such Inputs can be data or control inputs or inputs regarding graphical waveforms. For data and Tax input represents a rule list that is in a  interpretive language of expansion is written, Standard inputs are available for each level at which such inputs are required for each tool. Is a tool on a level in which such inputs are required, the standard entries for this level is displayed to the user. The user can Make changes to the standard inputs, and the Standard inputs in the way modified by the user are communicated to the system or tool. The Standard input display can also refer to the user Request objects which the user inputs at a given stage of the tool, where the operation of the tool continues to be blocked until the user makes these required entries, and can also provide the user with more options Request items that the user enters as inputs can add to the given level in the tool.

For graphical waveforms or similar inputs Tables provided which the different Define digital states of waveforms to be entered and the logical rules for treatment or the Interact with such waveforms. From User entered, created or Standard waveform displays can be viewed at Use of the stored digital status information, and commands from different sources can the waveform or other graphics are executed, using, if necessary, the stored, defined states and logical rules.

The invention is illustrated below with reference to drawings illustrated embodiments explained in more detail what other goals, characteristics and advantages emerge. It shows:  

Fig. 1 is a schematic block diagram of a system in which the teaching of the invention can be used;

Fig. 2 is a diagram showing various files that can be stored according to a preferred embodiment of the invention;

Fig. 3 is a flowchart of an exemplary process that can be carried out using the teachings of the present invention;

FIG. 3A is a diagram showing more detailed steps for performing the functions shown in Fig. 3;

Figure 4 is a flow diagram of the basic Epic process that can be used for control and handling in practicing a preferred embodiment of the invention;

Fig. 5 is a diagram explaining the standard display format for a preferred embodiment of the invention;

6A and 6B together an explanatory instruction set for the Epic-rule file, including two illustrative macros, for a preferred embodiment of the invention.

Figure 7 is a flow diagram for the process of setting up a "screen" for use in a general renaming process in accordance with a preferred embodiment of the invention;

Figure 8 is a flow diagram of routines for adding certain information to and retrieving certain information from a "screen";

Fig. 9 is a flowchart of the general renaming routine;

FIG. 10 is a flowchart of a procedure for obtaining an original name from a name generated in the general rename routines;

FIG. 11A and 11B are flow charts for generating an alias file or the reading of an alias file;

FIG. 12 is a flowchart of a rule-based interface routine;

FIG. 12A is an example of an entry (rbi) in a rules-based policy file;

FIG. 13 is a flowchart of a Designüberprüfungs- (dv) routine, which serves as a user interface to collect information for use in various tools;

FIG. 13A is an exemplary portion of a dv control file;

Fig. 14 is an explanatory display for use with the dv routine;

FIG. 15 is a flowchart of an interactive graphics routine, which is referred to as WAVEdit;

Fig. 16 is a more detailed flow diagram of the "Read Configuration Files" step of Fig. 15;

FIG. 17 is a more detailed flowchart of the "execute the command" step of FIG. 15, shown for an exemplary command;

Fig. 18 is a more detailed flow chart of the "Draw Display" step of Fig. 15; and

Shows a flow chart of operations that are performed in the WAVEdit routine when a "Getting Off" command is received. 19th

In Fig. 1, a system 20 in which the method and apparatus according to the invention can be carried out has a processor 22 with sufficient capacity to perform the various functions according to the present invention. A suitable processor can be, for example, a Sparc system, which is manufactured by Sun Microsystems. The processor typically has various input devices, for example a keyboard 24 and / or a mouse 26 , which can be operated by a user. A mass storage device 28 , which may be any standard mass storage device, is provided for storing various files used in the system, and a display device 30 , such as a conventional cathode ray tube display (CRT), may be interfaced with the processor 22 in a conventional manner. to provide various screens that are used by the system. Such screen displays may include menus of icons or other menus from which selections can be made using mouse 26 , keyboard 24 or other standard input devices in a known manner, and may also include alphanumeric displays of various files and data used by the system and various graphic displays including schematic diagrams.

The programs and files that form part of the present invention can be used to control and handle the timing of various computer programs, also referred to below as software tools, that run on processor 22 , as well as software that does so is configured to control or cooperate with the operation of various other devices used in the system, including, but not limited to, design devices 32 , design devices 34 , manufacturing devices 36, and inspection devices 38 . The external devices may be connected to processor 22 via one or more standard input / output buses 40 . All of the devices on bus 40 may be in a single location, or some of the devices may be located in different locations and connected to processor 22 via a network system or other suitable communication device.

Figure 3 shows a typical process that can be performed using the system shown in Figure 1 and using the teachings of the invention. In this case, the invention is used to design and manufacture a printed circuit board (PCB). The user can begin the process by selecting "Create Design" from an appropriate menu that is displayed on the display 30 (step 50). This can cause a macro to be selected from memory 28 in a manner to be described which performs certain management functions and can then result in the calling of an appropriate tool, namely "build schema". This is indicated by the dashed box 52 . The first step in this process can be to call a tool that leads to the creation of a schematic drawing (step 54). As part of this step, the user can specify the type of circuit to be designed and the system can display a circuit to perform such a function. The user can either use this circuit and proceed to step 54 to revise the schematic drawing shown, or can indicate that he wants to create his own schematic drawing, and in this case a different tool is called which allows the user to create one To build a schematic drawing from scratch.

If the user has finished creating a schematic drawing, the system can then proceed to step 56 to call a suitable macro which calls a suitable software tool or tools to allow the schematic drawing to be revised. Once an appropriate schematic has been created and revised, the process proceeds to step 58 where appropriate macros and tools are called which cause the schematic to be packaged together and then proceeds to step 60 to check the design . The checking step can include the call of suitable tools to check both the logic of the schematic drawing and its electronic components. Fig. 3A, the bit will be described later, illustrates various steps that can be performed during the verification step 60th If it is determined during verification step 60 that there is a logic or electronic component failure, the flow of operations may return to step 56 to further revise the schematic to overcome such a problem.

Once the design has been verified, the user can either be informed that the design has been verified and then guided to possible next steps, or the system can preferably proceed to step 62 to build the PCB. The dashed box 64 explains various steps that can be performed during the "PCB assembly" process. A suitable macro is called for each of these steps, which in turn means that suitable tools are called to carry out the function. The exemplary functions shown for the PCB assembly function include mounting the board, step 66, placing components on the board, step 68, routing wiring for the board, step 70, and backing, step 72, if any change is made.

If a problem in that regard during step 70 occurs that it is not possible to wire routes to arrange, the operational flow can go to step 66 return to redefining the board to overcome the problem. If If problems continue to occur, it can be done accordingly need to be returned to step 56 to complete the Revise original design so that a simpler arrangement and structure become. Ideally, the termination of each of the leads Steps 66 through 72 to call the appropriate following Steps.

Once step 64 of building the PCB is successfully completed, the operational flow can automatically invoke the first macro required to complete step 74 of manufacturing the PCB. Alternatively, completing step 64 of building the PCB can only result in an appropriate display on display 30 to notify the user that the system is ready to begin manufacturing the board. The step of manufacturing the PCB may include the steps indicated in dashed box 66 . These steps include creating the board from the drawing created during steps 64 and 78, drilling required holes in the board, step 80, and inserting or plugging the components into the board, step 82. The macros for performing the various steps 78, 80, and 82 may, at appropriate points, cause various manufacturing devices 36 to be used, including providing necessary control and data inputs for those devices so that the equipment operates properly.

Control of the devices for the automatic transport of the board between different Processing equipment can be provided as required.

If 76 prototype boards were made during step, the boards must be checked. This is carried out during step 84 and, depending on the devices used, can either be carried out with the same devices on which the board is produced, in which case the macros running on the processor 22 can then cause the system to automatically check the boards, when the manufacture of the boards is finished, however, the boards can also be checked on separate devices. In the latter case, the boards must either be automatically transported to such other devices in response to suitable macros running on the processor 22 , or the processor must be put on hold, prompting the user to move the board to test devices, and continue to call appropriate macros to control the test operations only when the user indicates that the board is in an appropriate test station. If the boards fail an attempt, depending on the problem identified, the process may go back to step 56, step 66, step 78, or any of the intermediate steps in which the test has determined that there is a difficulty that exists must be remedied. The system would then correct the problem, either using rules provided in the system or by prompting the user for input. Once the board has been successfully checked, the system can then control the shipping of the board in step 86, if so desired.

From this it becomes clear that, at least theoretically, by actuating a single control with suitable macros, the system can cause the entire sequence of processes shown in FIG. 3 to be carried out and, depending on the requirements, the user can be given certain inputs or can carry out certain activities, where necessary. Therefore, the system could be used by an operator who has little knowledge of the system or the various tools running on it, but who has good knowledge of the design and construction of PC boards. Even this knowledge need not be exhaustive, since in most cases the system can provide standard inputs in which inputs are required, so the inputs required by the user can be quite limited.

Many of the software tools required to perform the various functions shown in Figure 3 come from different vendors and may be incompatible in terms of language, name, format, and other factors. These programs may also be incompatible with the basic control programs running on processor 22 . To overcome this problem, the system has the ability to automatically perform interpretations and translations as required for information transfers between various incompatible software tools, and also to perform the required interpretations and translations for data transfers between the system software running on processor 22 . and various software tools that are incompatible with this. All of these data transfers are performed in a manner which is described below and which is transparent to both the user of the system and the various software tools.

The system also points as below explained in more detail the ability to the user Prompt for input when input for a software tool required, which one is executed. It is possible, in many cases standard inputs are available to be used by the system when the User does not change these entries, which causes the Data entry process essential for the user is simplified.

FIG. 3A illustrates a more detailed operational sequence that can be performed when review step 60 of FIG. 3 is performed. In Fig. 3A, the first such step is to perform a "design rule check" on the electronic schematic drawing generated during steps 54, 56, and 58. "Design Rule Check" is a software tool available to the system to check the logic or electronics of the schematic drawing. The macro that is called in connection with the design rule checking process would also control the acquisition or provision of required input for this software tool, to the extent that such input is required, and would also control any translations required for information or commands that are made available to this software tool.

When the design rule review process is complete, the system checks to see if the design review was successfully completed. If it is determined that the design check has been successfully determined, the system calls the software tool with the title "Signal network list extractor for a digital simulator". Again, inputs are provided and translations are carried out as required. If the extractor extracts correctly, the system calls a software tool called "digital simulator". The "simulator" tool is run using a behavior control macro, which may be one of the control system macros running on processor 22 or a separate software tool. The results of the simulator are displayed using a separate software tool called "Electronic Signal Wave Editor". Any errors found in the verified electronic schematic drawing design file are highlighted. This can be done using a macro in the base system, or a separate software tool can be called up for this purpose. The highlighting, which can be done, for example, by the line, the component or another circuit element in which a problem has been identified flashing, notifies the user of this potential problem.

The user can then take steps to do this Correct problem, or the system itself can be under Use rules provided in a macro either the user has possible solutions to the problem propose or follow provided rules make a suitable correction in the schematic drawing, to correct the problem.  

If the extractor did not extract correctly, then the user is appropriately informed about the Signal network list extractor error informed. Like that Simulator, the system can also make possible corrections here suggest for the mistake or undertake the mistake correct yourself. Accordingly, if the Design verification failed, the Users about violations usually for the electronic Design informs, and the system can turn one Provide display of possible corrections or using rules try to solve the problem yourself to correct. When the verification process is finished, so the system returns to the schematic editor, goes continue with step 62 to build the PCB or takes another suitable exit action.

According to the teachings of the invention various functions under control of one on rules based management and tax system or program performed, which is sometimes referred to below as "Epic" referred to as. As below with more details explained, this program uses a rules file, which contains macros for each process. Control the macros the call of suitable software tools in the appropriate one Order and also control the collecting and the Transfer of information between different tools as well as between the system and various tools. Furthermore, the macros control the performance more necessary Interpretations / translations for transfers between Tools and for transfers between tools and the System control software. In particular, Epic has the Ability to encapsulate incompatible software tools, so that all data transfers from the tool to Epic are checked and appropriate rules of interpretation are applied,  before Epic is used, and so that all editions of Epic the tool also checked and required Interpretations are made before material is sent to the Tool is returned. The encapsulation is for both the software tool as well as for the user completely transparent.

Epic uses various additional programs to help him do this help the interpretation and the Perform data compilation functions. This Programs include a program called "GRM" is what is an abbreviation for "General Renaming Module "(general renaming module). This Program has different files generally at least one file for each pair incompatible programs or software tools is provided. Each GRM file includes several rules that are used to implement it of translations for names from the original language too a generated language can be used. A File can also be a listing of translations of Names in the original language in names in the generated Have language. For example, this may indicate will be that with an input "A" the output will be "a" should. Such translation lists could be in the file be included, which the originally provided Contains rules, or could be using the rules generated while translations are in progress, and as alias files for future use get saved. GRM can also be used Translations between different hierarchical levels a design from the same or different tools perform when the on these different Names used in the levels are incompatible.  

Translation files would then be such for each Hierarchy transformation provided.

A second program that can be used with Epic , is sometimes referred to as "RBI", which is a Abbreviation for "Rools Based Interface" (on rules based interface). This program will used to perform format translations when Program tools do not have compatible formats. This can occur, for example, when a software tool Provides information in a schematic form, while the other software tool information in Netlist form used (a list of components in the Circuit and the node or other components to which each of these components is connected). A set of RBI rules files is used to perform this function intended.

A third program that can be used with Epic can, is the dv routine ("Design Verification": Design review), which is used at the Gathering required information from that Users or other sources for the different To help software tools that run on the system. Certain rule files are also provided for dv, and their functions will be explained later.

A fourth program to be used with Epic is the wavedit routine that can help with Compile, create and edit graphic Entries in general and in particular from Waveform data is used. For Use With This Various digital state definitions and are routine Logic rules provided.  

The various control macros and control files described above are originally stored, for example, on a hard disk or a soft disk that can be inserted into or part of the memory 28 . Standard rule files are typically provided by the system provider. The macros and the rule files are written in an interpretive extension language that can be read by both humans and the machine. The macros and rules can be written in an existing expansion language, for example LISP, but are preferably written in a special language that is specially adapted for this purpose. The macros and the rules can all be written in the same language, or different interpretive extension languages can be used for different single or multiple files, so that the optimal language is used in each case. While examples of a suitable interpretive extension language are illustrated in some of the following examples, the particular language used does not form part of the invention.

However, it is essential that the different rules and macros in an interpretive language of expansion are written so that a person who acts as a "Tool Integrator" is referred to that for the user works that can check standard rules and files provided by the system, and macros and Modify, add or subtract rule files can as required to connect the system to the Customize user requirements. Such Changes can be made if the system  is received first, and may from time to time thereupon be taken to updates or System magnifications reflecting the Correction of errors made in the Operation of the system have resulted, or new ones Integrate software tools into the system. Important is here that only the tool integrator made the changes must notice. Once he made such changes in the Such built-in changes are implemented in control macros automatically performed by the system without the System operator must notice the changes, or the Fact that they were entered. To that extent Changes may require input from the user Prompts are provided to the user ensure that he has required inputs to Provides. If the operator has one Does not understand the prompt, so a menu or, according to a further goal of the system flow, a "Help" function will be available to the user with to provide necessary information.

In this way, such changes are for the user completely transparent, and all he needs to know is the process he wants to perform. By Provision of the macros and usually in the interpretive extension language can be simple Changes to a file are made by the tool integrator or another person who Makes changes, can be reviewed, and can immediately run on the system without it being necessary is that the program is sent to a compiler to to be compiled before it is entered into the system so that it can expire. This significantly simplifies the Creation and review of control macros and files and  reduces the time it takes To enter configurations into the system. A system, which is easily configurable and reconfigurable by is the user / customer in this way Provided.

Figure 2 illustrates a format in which the various control macros and other files described above can be stored on a disc or other storage medium available to the user for this system. The exact order in which the rules are stored is not critical as long as suitable addresses or other means are provided to retrieve a particular macro or file when necessary.

From FIGS. 6A and 6B taken together clear that for illustrative purposes the first stored in the disc object of a control macro section 90 is, this portion is used together with the main Epic program. This section begins with a leader, which designates this section as containing Epic rules. Then there are a number of comments including certain legal information, such as copyright notices, and comments to users. A specific comment could inform the user's tool integrator that any software tool that is to run on the system must be listed in the definition section of the epic rule file or would otherwise not be executable.

The comments are followed by a definition section for the Software tools. In this section, every software tool which should run on the system, listed, and  various information regarding this tool provided. Windows, for example, indicates whether that Software tool generates its own ads, or whether it Help from the operating system is required, in this case the Epic system to generate ads. The default state is that no help is needed, with "Window" appears when help is needed. Of the most important subject regarding the present invention is the display of "no packaging". A program, which contains "no packaging" is a program which is compatible with the Epic program and therefore not must be encapsulated (they are not interpretations for transfers between the software tool and Epic required). The default state is "packaging" what means that any software tool that is not the "No packaging" display in the definition section encapsulated. The other information which are provided in the definition section Standard command line options for the tool.

The next two sections are the "Beginning Sentences" and are essentially the standard version unless otherwise indicated what should be done. In this case, the standard version is "Epic View", namely the program that is used to control displays for Epic. "Epic View" causes a display such as that shown in Fig. 5 to appear on the screen in the standard situation.

The end of the Epic rules is the macro section, which contains several macros, generally one for each function to be performed on the system. Each macro contains an original description in English of the function performed by the macro, primarily for the tool integrator of the user, and a set of rules or commands to be executed in a predetermined order to perform the function of the macro. As explained above, these are described in an interpretive language of extension that is readable by both humans and machines. The particular macro shown in Figure 6A is for a tool called "cadat" and performs a number of functions using routines that will be explained later. The first two fetch commands set predefined variables for the first and second parameters, which are each entered in the macro. The next command specifies that if the "schedit_up""YES" variable is set (as a result of a previous operation), one of two things can happen. If the "hi_type" variable was previously set to a "sim" value, a first message is sent to the "schedit" tool with the involvement of the dv routine, while another one if "hi_type" is not set to "sim" Message is sent with the involvement of the "Wavedit" routine. If "scheidit_up" is not set to "YES", the displayed message is sent back to the macro calling process.

The macro shown in FIG. 6B is a macro for the Packager (pkgr) routine, and although a description of the routine operation is not provided in FIG. 6B in normal English, the macro would actually normally have such a description for use by included the program integrator. Packager is an external tool that is at least in some details incompatible with Epic and therefore has to be encapsulated. As discussed below, such tools are referenced in the system's "Whilexec" tools. The first three commands in this macro, like those for the previous macro, concern setting certain previously defined variables to specified values. The fourth command indicates that if the variable named "pkgr_file" is empty, one of the variables that was originally set should send an error message back to the calling process. Otherwise a message is sent to the calling process that the tool pkgr starts. The Whilexec display says that this tool should be encapsulated and that, especially when this tool is running, all output from pkgr is interpreted by the following rules:

• 1. If the line of text returned by "pkgr" If the word contains "error", then a Variable with the name "pkgr_statuis" set to "errors".
• 2. If at the end of the process "pkgr" the process with an error status, then send one Message to the calling process with an error.
• 3. If the pkgr_status is ok, then close that Window in which Packager ran and send a message to the calling process that all is well has expired.
• 4. Otherwise, leave the window open and send a message indicating an error.

As discussed above, the exact language used in the macros is not critical, and the examples have been provided primarily to explain how macros can control the sequence of operation and the encapsulation of an incompatible tool. Attached to Appendix A is a manual entitled "Schematic Design Tools - Administrative Guide - Theda Revision 1.0", which describes in section 3 in particular a specific language which is used for the macros in the preferred embodiment and further details of the operation at preferred embodiment. This document should not be printed.

While only two macros are shown in Figures 6A and 6B, there would normally be hundreds or even thousands of macros in a particular system, the number of macros depending on the number of processes that the system should be able to perform.

Section 92 of the memory contains GRM files for each translation that the system must perform. A separate GRM file is required for a translation from Tool A to Tool B and for a translation from Tool B to Tool A. There are therefore two GRM files for two language-incompatible tools that are used in the system. Each GRM file contains a sequence of rules that can be used to perform name translations between the two incompatible tools. Furthermore, a list of at least selected names in the original program can be provided together with the corresponding names in the output program.

Section 94 of the memory contains the dv control files, which are control files for the input of input or the translation of input for the system. These files contain, among other things, standard inputs for each level in every software tool, in which inputs are required. The standard display caused by these rules may include, if necessary, an indication that certain information must be provided by the user, and may also provide a display of additional optional information that the user can provide.

Section 96 contains rules files for the RBI program used by Epic. These essentially represent format translation rules for various software tools that are incompatible with regard to the format. Typically, there is a set of RBI rules, or - in other words - an RBI rules file for each pair of software tools that are incompatible with the format.

Section 98 contains files for use in the Wavedit routine. These files include state definitions, logic rules, menu files, and command source files for use by the Wavedit routine. The content and function of each of these files will be explained later in connection with the Wavedit routine.

As mentioned above, all of the files shown in Fig. 2 are written in an interpretive extension language, although it is not necessary that they are all written in the same interpretive extension language.

Figure 4 is a flow diagram of the main Epic routine used to manage and control the operation of the system. When the user calls the Epic routine by an appropriate input to processor 22 , step 100, the first step, is to read the rule macros, including definitions and other information, from area 90 of memory 28 , and to a random access memory (RAM) in the processor (step 102). This results in a process list that is formed for each defined process, the list containing the macro for such a task and further containing a space in which a Whilexec task list and a suspended task list for the given task or function can be stored . The reasons for the Whilexec and the suspended task list, the way in which they were created and their function are explained below. During step 106, a task list is created that contains the macros that were previously read into the system. A variable list is generated during step 108. This list forms the database for all variables, for example the numerous variables described in connection with FIGS. 6A and 6B that are used and stored by Epic. Steps 104, 106 and 108 therefore indicate the formation of the various lists. Either during step 102, 104, 106 or 108, or during step 110, during which other start functions are performed, various syntax checks or other checks can be made on the rule files that are read into the system to ensure that they are not errors contain. While the files, particularly those provided by the manufacturer, will normally be fine, there are several ways known in the art to introduce errors. It is therefore advisable, and this is the normal practice in the industry to do error checking before running a program.

The start step 110 may also include a call to the standard Epic View program, which includes a display, such as the display shown in FIG. 5, including a menu 112 of icons, an exemplary set of which is on the right side of the screen in FIG . shown, is caused to display on the screen of the display 30. 5 The user makes selections from menu 112 , for example, by moving a cursor (pointer) onto a selected icon using a mouse 26 . Each icon indicates a specific function that the system is designed to perform. The selection of a given icon may result in additional icons being displayed, or another type of menu being displayed from which the user can make a more detailed selection regarding the function to be performed. However, in the preferred embodiment, the user selects tasks at a relatively high level, and the system makes decisions regarding certain tasks to be performed to achieve such a function.

As soon as the start functions required in connection with Epic are finished, the operational flow moves to step 114 and waits for an input. As long as no input is received, the system remains in a hold status and waits for an input. If an input is received, the operational flow moves to step 116 to determine from which software tool or from which other source the input was received. For example, if the input was received by selecting an icon from menu 112 of the display shown in FIG. 5, the input would have passed through Epic View. The source from which input is received is essential as this allows the Epic program to check the definition section of its rules file (see Figure 6A) to determine what actions (if any) are taken on inputs from it Source are required. In particular, this allows the system to determine whether inputs from that source need to be encapsulated.

From step 116, operation continues to step 118 to determine if the process is a termination process. As discussed below, some processes can take a significant amount of time to complete, sometimes up to several hours, and it is preferable that the entire system not be busy while such processes are in progress. Such processes can, for example, run on a device other than the processor 22 . Therefore, when such processes are in progress, the system has the option to save the remaining queue of functions that must be performed in connection with that process until the process is complete. The remaining tasks to be performed are stored in the suspended task list section of the process list for the particular process.

If the process is finished, this is the function expiring software tool an input to Epic Available that is recognized during step 118.  

This causes the operation to proceed to step 120 during which a determination is made as to whether for this particular process anything else in the suspended task list was saved. Was nothing stored, then nothing has to be done regarding this process and the operation goes to step 114 back and waits for the next entry. Is for this Process anything in the suspended task list stored, the operation proceeds to step 122 Material in the current execution queue save up. The current execution queue is on a predetermined location in the RAM of the processor saved. During step 124, the next step in the command flow, the execution queue loaded from the suspended task list for the process, and then the operation proceeds to step 126 to itself view the contents of the execution queue.

If it is determined during step 118 that the input was not from a termination process, the operation proceeds to step 128 to read the input. A determination is made, either or after step 128, whether the input comes from a Whilexec process (step 130). As explained above, a Whilexec process is a process involving a software tool that is not language-compatible with Epic and therefore requires that both inputs and outputs be interpreted before they are output to the tool will. The interpretation may include translation, and may include performing other operations necessary for transfers to and from the incompatible tool to be valid. The definition list of the Epic rules ( Fig. 6) designates such a software tool as one that must be "packaged", which is indicated in the preferred embodiment by the fact that the word "No Wrapper" is not next to the program name in the definition section . If it is determined that the program is a Whilexec program or process, the current execution queue is saved during step 132 and during step 134 an execution queue that was previously saved is stored in the Whilexec in a manner discussed below -Tasklist section of the process list for the particular process loaded into the main execution queue. This execution queue contains interpretation rules for receiving material from the incompatible tool. Then operation continues with viewing the main execution queue during step 126.

If it is determined during step 130 that the Input is not from a Whilexec process the input, including all steps necessary for performing the particular process entered are necessary during step 126 in the Main execution queue loaded. During this The queue is also considered step by step. All Steps performed during Epic operation should be in the main execution queue loaded and will be from this queue after the Principle "First in, first out" (FIFO) executed. Therefore, if this queue is empty, it means that nothing else needs to be done by Epic. Therefore, the process adopts step 136 Determined by whether the queue is empty. Is the Queue empty, so the operation goes to the step 137 to determine if the  Execution queues were saved. So if one Execution queue during, for example Step 122 or step 132 has been saved received an output "YES" during step 137, which causes the operation to proceed to step 139 to go over to the saved execution queue load the main execution queue. Then he returns Operation returns to step 126 to complete the Check main execution queue. If during step 137 determines that none Queue was saved, so the operation goes to Step 114 back to wait for the next input.

If the queue is not empty, the operation goes to Step 138 to determine if this input is for Calling a macro leads. If during step 138 it is determined that this input is a task or a Process is that leads to the call of a macro, then goes the operation goes to step 140 to get the current content the main execution queue and to save that Macro for the given task or function during step 142 from the correct task list in load the main execution queue. Then he leaves Operation so that the Main execution queue is considered. There a Macro would have been loaded into the queue, this would not be empty and would not contain any further task list entries. Therefore, operation would proceed to step 144 in FIG which determines whether the next item an internal command from the main execution queue is. If it is not an internal command, then it gives An appropriate error message to the System and / or user during step 145 and returns to step 126 for the next one Look at the item in the queue.  

If it is determined during step 144 that the currently viewed item from the main execution queue is an internal command, operation proceeds to step 146 to execute the command. The execution of a command during step 146 can lead to the call of a further software tool which is to run on the processor 22 or should run in another device of the system. It can result in only one operation being performed, or in multiple operations. Insofar as it is determined during step 146 that an input to an incompatible tool (i.e. a Whilexec tool) is required, Epic interpretation rules for performing such a transfer appear in the macro at the point at which the transfer is carried out or through an appropriate reference. These rules of interpretation are applied to every item transferred from Epic to the tool, so that all inputs to the tool are handled in a manner that is transparent to both the tool and the user or operator.

As mentioned above, in some cases the Function performed during step 146 will take a few hours to complete. Therefore, while step 146 is being performed, the Operation also goes to step 148 to determine if the system wants to wait for a process output. This would occur when a Whilexec tool expires, an output from the tool is then required to receive when execution is complete, and a Interpretation of such output is required before it can work as valid input for Epic. Gives there is an output "YES" during step 148, so  the operation proceeds to step 150 to complete the Execution queue to process whilexec task list in to move the process list for the process, and then returns back to the main execution queue to others Functions to perform while on an output of that Whilexec tool is being serviced. Is an edition of that Whilexec tool finished, it makes an input to that System and comes in through step 114. This is recognized during step 130 and causes one Reload the saved execution queue during step 134. As discussed above, this saved execution queue contains the Interpretation rules by encapsulating the tool to be required to cause expenditure from the Tool are valid inputs to Epic.

At the same time, step 152 also becomes one Verification carried out to determine if there is any to wait for the process being performed to end. If you want to wait, then the Execution queue to suspended task list in the progress files for the process performed moves and operation returns to Main execution queue back. Since the Main Execution 71267 00070 552 001000280000000200012000285917115600040 0002004310615 00004 71148ngs queue during step 154 has been emptied, arises during step 136 out that the queue is empty and the operation returns to step 114 to start a new entry waiting. When the process ends an input is received from Epic during the Step 118 is determined and causes the saved suspended task list during the step 124 reloaded into the main execution queue becomes.  

If it is determined during step 152 that the System does not want to wait for the process to end, so the system returns to the main execution queue, to look at the next step in the queue and, if possible, perform the step. If too At this point in time the queue is empty Operation returns to step 114 to the next entry waiting.

In this way it becomes a rule based Tax system provided which the Management of tasks to be carried out and the controls the chronological sequence of the tasks. It also controls System both inputs from regarding the language incompatible software tools and expenses from them Encapsulation of such tools and implementation of the required translations for input and output a way that is for the user and software tools are transparent. Epic is also capable of software tools described below, if available this is required to be different Translation functions and data collection functions, depending on Need to perform.

A module that can be used with Epic and which depending on the requirements of different Tools or routines called is general Renaming module (GRM), which the Main translation routines included by the system for Transfers between tools are used which different strings (i.e. names) for one use certain object or other meanings (i.e. incompatible tools in terms of name). GRM can can also be used when information on multiple  different hierarchy levels in a given Tool is used, or tools with different Names for the same or a corresponding item be used at different levels. Of the Term "Tools incompatible with the name" sometimes also denotes this state. GRM includes different different routines through different application programs or by Epic depending on Requirement can be called when Name translations are required, or for others Purposes explained below.

As mentioned above, GRM files are stored in area 92 , which contains a set of rules for performing translations between two software tools that are incompatible by name and that can be used in the system. When an application is running that requires translation between an original name in a software tool, such as another program that sends data to the particular application program, and a generated name in a second program that receives such data, such as the application program itself the application program creates a "screen" that receives and stores the appropriate rules, and also provides a space in which name translations generated using the rules on the screen are stored for future use.

Figure 7 is a flow diagram of the steps involved in creating a screen for use in a particular translation. The process begins at step 170, in which a request for a screen is received by an application software tool or by one of the other tools or routines that form part of the present invention, for example RBI. If a request is received, a check is made to determine whether the user rule file is new or, in other words, whether these rules were previously used to create a screen (step 172). If the rules have previously been used to create a screen, then certain pre-operations need not be performed and operation proceeds to step 174 to get the rules and then to step 176 to create a screen and the rules in save the screen. The screen is then stored in a selected location in the RAM of the processor 22 and the application program is informed of the address in which the screen is stored (step 178).

If, as usual, the rules are not in one Operation has been saved Step 172 to step 180 for various Perform administrative functions that open the new screen are required. Then the business goes to step 182 where the rules from the file be read and, if necessary, in a form to be converted by GRM or the Application program can be used. If for example, the rules screen from an application program is to be used, a certain interpretation of the rules may be necessary, so that they are compatible with such a program. The modified rules are then generated during step 184 saved and brought to the screen that in the Step 176 has been set up. Then the company goes to  Step 178 over to save the screen and Information regarding the address is available too in which the screen is stored for suitable software tools.

Figure 8 is a flow diagram of a process that can be used to add or retrieve user-specific data from a screen. The environment in which the process of Fig. 8 can be used is, for example, such an environment that a certain type of information in the source program is scattered throughout the program while such data is maintained as a block in the receiving program. It would be desirable if such data could be transmitted as a block, and the screen provides a means to accomplish this. In particular, the system manufacturer of an application tool for the system, or possibly the user's tool integrator, can determine that when calling up a certain name or when a certain screen is called up, selected data should be transmitted to the receiving tool with the given name or through the screen.

In Fig. 8, during step 190, the party adding the data indicates that it wants to add custom data to a given name or screen for a given application tool. A check is made during step 192 to determine if the screen exists in the system. If the screen does not exist, this is an error condition and the party adding data is informed of this during step 194. Typically, this information would be provided by appropriate notification on a display, such as display 30 .

If the screen exists, operation proceeds to step 196 to determine if the material to be added is associated with a particular name. If the added material is to be assigned a specific name, it is added to the generated name that is stored within the name on the screen. Although not shown in Figure 8, it can also be an error if the data is to be saved with a given name and that name does not exist. If it is determined during step 196 that the added data does not have to be saved with a specific name, but should be saved with the screen and transmitted to the received tool, whenever the screen is accessed, then it goes Operation to step 200 to add data to the screen. In some circumstances, step 200 can also be performed in the case where the name with which the data is to be saved does not exist on the screen.

If an application program (tool) a certain name or request screen, step 202, the system performs a review to determine if the Screen exists, step 204, and creates one Error signal, step 194 if the screen is not exists. If the screen exists, the operation goes to step 206 to determine if the request regarding a name. Applies to the requirement  a certain name, so they are previously with this Saved data names retrieved and under control the application program to a suitable location transferred to the application program, along with everyone generated names for the original name during the Step 208. Is the requirement regarding the Screen and not the specific name, so during step 210, those in step 200 saved data retrieved, and under control of the Transfer application program to this program.

Figure 9 illustrates the process that follows when a name requiring translation is transferred between two software tools. The process begins at step 220, which indicates that a name translation is required. From step 220, the flow of operations proceeds to step 222 to determine if the screen exists. If the screen does not exist, operation returns to the "Get a Screen" routine shown in FIG. 7 to create a screen (step 224).

Either from step 222 if an "YES" output is received or from step 224, the operation goes to step 226 to determine if the name is in the Screen. This usually means that the Name was created before and that the original and the generated name on the screen for future Reference has been saved. However, how previously mentioned, such Name translation list with the rules available be put and originally in the screen be saved. The name is in the Screen, the operation proceeds to step 228  return the previously created name, in general to the requesting application program. The name is not in the screen, the operation proceeds to step 230, in which the original name in the screen brought and originally marked as "unique". From step 230, operation proceeds to step 232, in which each of the rules in the file are consecutive is checked until all rules have been considered. For each rule goes to step 234 to determine whether the rule applies to the specific name. For example, a rule could indicate that all Upper case letters in the corresponding lower case letters to be converted. Therefore, if the name is in Capital letters, the rule would apply, result in a "YES" output of step 234 and to cause step 236 to be performed. During the Step 236 applies the rule to a Perform conversion of the name. Either from the crotch 234 if an output "NO" is received, or from From step 236, operation proceeds to step 238, in which the next rule is retrieved.

Rules 232, 234, 236 and 238 become sequential for each rule that is performed in the screen is stored until during step 232 it is found that all the rules in the screen were carried out. At that time the Translation of the name finished, apart from various administrative functions that took place during the following steps.

In particular, if all rules have been used, the Operation from step 232 to step 240 via which the generated name is checked to see if it  contains any characters in the recording tool are invalid. As far as such characters are found, they will be removed. Operation then goes to step 242 over to determine if the length of the generated name exceeds a maximum length by the user for names in the receiving program. If the length of the generated name exceeds the maximum, this is how the name is made using suitable cutting rules shortened. Usually this is done by: simply the excess number of characters from the end of the Name is removed. However, more complicated ones Cutting rules are used, for example that Removing vowels in a first clipping step. Finally, during step 244, any required prefixes or suffixes by the user be defined, added to the name. Will the Step 244 may be performed during the step 242 a root can be shortened so that the final name does not exceed the maximum length.

During step 246, a determination is made as to whether a One-to-one mapping between original name and generated name should be available. Is a One-to-one mapping is not required, then the Name of the name used during step 230 Has been made available from "Unique" to "Not unique "changed during step 248 the name generated can actually be unique the name as not unique during step 248 marked so that if the generated name later emerges, and later generation also allows that it is not unique, the system is such Allow use. If the system assumes that the original generation is unique, so it would  no later generation of the same generated name allow.

The foregoing is through the step 249 explains, namely the next step in Operational flow. A occurs during step 249 Determine whether the generated name has a unique Name collides that was previously created and in the Name list is included. The name does not conflict with a unique name, so the business goes to step 250 above, in which the generated name with the original name is saved on the screen. The newly created name is then sent to the application program sent back which was originally the request output, in step 252. During step 249 found that the name with a unique name collides, the operation proceeds to step 256 to determine if the name can be modified so that he is unique. The events that take place during the Steps 256 and after are performed in the following paragraphs.

If it is determined during step 246 that a One-to-one mapping is required, then done in Step 254 a determination of whether the generated name is unique. If the generated name is unique, then the name is remembered during step 250 and in Returned to step 252.

If the generated name is not unique, then operation proceeds to step 256 to determine if the name can be changed in a manner defined by the user, particularly rules created by the user's tool integrator or rules, provided by the manufacturer of the system so that the name is unique. Such a change may include adding predetermined additional characters to the beginning or end, preferably the end, of the name to make it unique. For example, the numbers 0 through 9 can be added sequentially at the end of non-unique names to make such names unique. If it is not possible to make the name unique, then a translation of this name is not possible. This is an error condition, step 258, and the user is given an appropriate display of this error, typically on display device 30 .

If it is possible to modify the name so that it is unique, such a modification takes place during step 260 to provide a name make that unique and also in the receiving tool is valid. From step 260, the operation goes to step 250 over to remember the generated name and the return the generated name to the requesting tool. On this way one becomes on generalized rules based translation mechanism available provided that is very flexible and easily modified can be to make any changes in the system to meet.

There are situations in which a tool that uses a generated name desires to determine what the original name of such a generated name was, or in which a system operator desires such information. Figure 10 is a flow diagram of a routine for providing such a facility.

In Fig. 10, if a source name request is generated, step 270, operation proceeds to step 272 to determine if the generated name is on the appropriate screen. If the generated name is not on the appropriate screen, which can mean, for example, that there was no translation request that led to the generated name, then the request cannot be met and an error message is made available to the requesting tool, which also can be made available to the user in step 274.

If the generated name is on the screen, it finds the routine generated the original name of one Name during step 276. In step 278 is done a determination of whether the origin name for the generated Name is unique (i.e. whether the given one is generated Name a generated name for more than one original Name is). If the original name is unique, so the original name is displayed during step 280 returned the requesting source. Is the original name is not unique, then during step 282 lists all original names returned, which points to the generated name.

Since the same two programs can communicate with each other in numerous cases, it is desirable that once a list of original and generated names has been created for a given screen, that list is cleared so that it can be used in a subsequent screen for the same two tools is available. Fig. 11A is a flowchart of a name list rescue routine created for a given screen as a name file, and Fig. 11B is a flowchart of a routine for reading such a stored name file into a new screen, for transfers between the same software tools is available. In Fig. 11A, the routine requires that for each name in the original screen, step 290, output is generated that is formatted in a user-specified manner or in a standard format specified by the system manufacturer, and that this output be written to a selected file for storage (step 292). When all the names have been output on the screen, the operation proceeds from step 290 to step 294 to return to the previous program that was running. The file created as a result of Fig. IIA is sometimes referred to as an alias file.

If a request is made in FIG. 11B to read a previously stored alias file, the first step is step 300, in which every entry (ie every name) in the file is retrieved. The retrieved entry is broken up into pieces of predetermined size or otherwise treated in a manner determined by the user or system during step 302. In step 304, the treated name is then added to the new screen. Steps 300, 302 and 304 are repeated until all entries in the alias file have been saved on the screen and then the operation branches from step 300 to step 306 and causes the operation to return to the original tool.

In addition to the requirement to translate inconsistent names between software tools, there are also situations where the format is incompatible between two programs and must be modified to be compatible. For example, a tool can present information in a schematic graphic diagram, such as shown in FIG. 14. Another program may wish to use the same data in a netlist form, in which components and nodes are defined, and in which for each component an indication of the nodes and / or other components between which it is connected is provided. The system according to the invention provides a routine, which is referred to as a rule base interface routine (RBI), which carries out such transformations, and can also be used to carry out standard transformations, if this is necessary, for example between incompatible commands for performing the same function in the two languages . Figure 1 is a flow diagram of the RBI routine.

In Fig. 12, operation is started by the RBI routine called by Epic or another program running on the system or as a result of user input. This is referred to as the start step 310 in FIG. 12.

The first step in operation, step 312, is that various options are read and an appropriate one Location to be stored in RAM, which is for storing of information is used for the RBI routine. Options, schemes, waveforms and the like will be sometimes referred to below as "objects", where  Objects are elements that are either from the manufacturer of the Systems or users (options) or from another Program (schematic components, signal forms, etc.) for Be provided, in which the by RBI provided conversion rules are used.

During step 314, the next step in operation, the appropriate RBI rules file or files stored in area 96 of memory 28 are read into a suitable portion of processor memory. During step 316, the rules are checked to ensure that they use correct characters in the correct locations and are valid in the context of the RBI routine. The rules should be valid, but it is always possible that an error will develop for a number of reasons, and it is therefore advisable to do a semantic check before using the rules.

During step 318, the next step in Operation, the requested database is converted to be read into the system and also each external information required for conversion is necessary. For example, a GRM screen that is on the manner explained above was generated for Use provided by the RBI program become.

As soon as these preliminary operational steps have been carried out, the program proceeds to step 320, in which it begins with the processing of rules, starting with the first or top database object and the first rule. As discussed above, the database objects represent the schematic characters, waveforms, netlist entries, or options that have been entered by the user or others and the conversion of which is required. From step 320, operation proceeds to step 322, in which the next rule, in this case the first rule, is transferred to a "current rule" register. During step 324, a check is made as to whether the current control register is empty. If the current rule register is empty, this means that all rules have been viewed and the process has ended. This causes the operation to branch to step 326 to print out the result of the RBI operation, or a portion thereof, or other material to be printed out by the routine. Alternatively, this material can also only be stored, for example at a suitable location in the memory 28 , without being printed out. Once step 326 is completed, the system exits the RBI routine through step 328 and notifies Epic or another program that requested RBI to run and / or the user that the process has ended.

If it is determined during step 324 that the current control register is not empty, for example in a If the first rule has been loaded into it, so the operation proceeds from step 324 to step 330 to determine if this is a "screen" rule. There is essentially two types of rules in the RBI routine, which as "screen rules" and "termination rules" be designated. One termination rule applies to general a single command that is executed immediately can be. In contrast, one concerns Screen rule generally two or more commands and can also include branching or other factors. Any rule that is not a "screen rule" is one  "Termination Rule". Therefore, if during step 330 it is determined that the rule is not a screen rule then the operation proceeds to step 332 to which to execute only the termination rule command, and then returns to step 322 to find the next rule in load the queue into the current control register.

If it is determined in step 330 that the rule in the current rule register is a "screen" rule, then operation proceeds to one of several steps, depending on the type of screen rule that has been received. There are basically five types of screen rules that can be received. Two of the types of screen rules relate to the beginning and end of a sequence of four. These are indicated in FIG. 12A by the command or rule "for all (nets)" and for the rule "for all (symbols)", which follows this. Later there is also a rule "for_bar all (ports)". These rules indicate that the following rules should be applied to all objects in parentheses, and an all-ending rule is indicated by the ports command "thin_for_all bracket" and the similar exit command for (symbols) and (networks) in Fig . 12A displayed. These are the rules that end a "for_all" sequence.

Two other types of instructions arise from an "if" sequence, two of which are shown in Figure 12A. Each "if" sequence begins with the word "if", followed by the object to which "if" is to be applied and which is given in parentheses. Then one or more rules follow and the "if" sequence is ended by the rule "fin_if", which also includes the object.

The final type of rule is a screen break rule. This is a rule that examines whether a certain condition is met and, if the condition is met, bypasses the remaining commands on the screen; or, in other words, prevents the rest of the rule from being carried out. A break rule is not particularly indicated in Fig. 12A.

In Fig. 12, if it was determined in step 330 that the screen rule is a start of a screen rule, the operation proceeds to step 334 to fetch the next object of the type specified in the "for" rule. For example with the command "for_all_nets", the next "network" is retrieved in step 334 during step 334. From step 334, operation proceeds to step 336 to determine if all of the objects of the specified type have been viewed. If all objects have not been viewed, the next rule within the "for" screen is obtained during step 338, and that rule is loaded into the current rules when operation returns to step 322. During the next cycle, the object is viewed by this rule and processed by the rule. If "fin_for_all" is reached in step 338 for a given object, this rule is recognized during step 340 and is caused to bring the next object of the type defined in the last "for" rule back. A determination is then made as to whether the object is empty, and the "for" screen rules are applied to the new object if it is not empty by cycling through the appropriate steps and ending by the termination and screen rule. Once step 340 from step 340 is reached and it is determined that the object is empty, the operation proceeds to step 342 to proceed to the end of the "for" screen rule and so exit.

Similarly, if the incoming screen rule during step 330 as an beginning "if" screen rule is detected, the operation to step 344 to determine if the "if" condition is true is. If the "if" condition is not true, the Operation to step 346, which is the operation to do so caused to execute the first rule, which is the end of the "if" screen follows, and operation returns to step 322 back to this rule as the next rule in that to arrange the current control register.

If the "if" condition is true, the operation goes to Step 348 over to the rule within the to get "if" screen, and this rule as the to arrange the next rule in the current rule register. Then the operation returns to step 322 to Get this rule to run. Is the Rule within the "if" screen the rule for Termination of the "if screen", the operation starts from Step 330 to step 350 for the next rule to pick up outside the "if" screen, and this rule as the next rule in the current rule register and then the operation returns to step 322 back to cause this rule to run.

Finally, if it is determined in step 330 that the The rule is a screen break rule, so the operation goes to step 352 to determine if the Break condition is true. If the break condition is true, then operation goes to the end of the screen or fetches in other words, the first rule outside the  Screen, during step 354, and this rule becomes the next rule in the current rule register. Then the operation returns to step 322. Accordingly, if there is no output in step 352 the next rule occurs during step 356 retrieved as the next rule in the current one Control register loaded, and then operation returns to Return to step 322 to execute this rule.

As explained above, the RBI rules control Format conversions between the two considered Programs so that objects in one of the tools in that appropriate forma to be converted for the other tool. The rules can also be applied to objects that Standard commands or other items in one of the tools are that have to be converted in such a way that they other tool work.

Another requirement for a system that the Control the operation of a large number of software tools, is the ability to collect information interactively required by these tools at every stage of their operations become. Such information can by the user of the Systems, by the operator or by other tools in the system can be obtained. The information is provided by the operator obtained, it is preferable that the operator do so little Provides information as possible, where Standard inputs for most of the required inputs are available and that the user is prompted to do so will provide all required inputs. The user can also make all optional entries that are available at this level. Preferably the system does not go with the one displayed Process continues until the user has requested all  Has provided inputs and these inputs are valid.

The routine that provides the functions described above for control, other non-graphical inputs and possibly for certain types of graphical inputs is referred to as the design check or dv routine. Fig. 13 is a flowchart of this routine, and Fig. 14 is an explanatory display obtained using this routine.

In FIG. 13, the program starts with the start step 360 from Epic or another suitable software tool that runs on the system. dv can be called up whenever it is necessary to enter interactive data or other suitable material into the system.

The next step in the operational flow, step 362, is to read in graphic and menu information for dv stored in a suitable location in area 95 of memory 28 and display the basic dv icon display. The dv icons are shown in area 364 in FIG. 14, and this portion of the display shown in FIG. 14 is what would originally appear on the screen of display device 30 .

The system then reads the epic rules suitable for this task from the area 90 of the memory 28 and stores these rules as an understood task list, the function of which will be described later (step 366). During step 368, the next step in operation, the system reads the dv rules from area 94 of memory 28 , or at least the portion of these rules that are relevant to the software tool or software tools currently running, and stores them Rules as a task command list. These rules define special commands for the tool in question and contain, among other things, standard inputs for different levels in the tool. An exemplary portion of a dv rules file is shown in FIG. 13A.

The system then reads the schematic design files during step 370. These are files that contain information regarding the scheme under consideration, including, for example, an explanation of the meaning of each box in a scheme. The schematic design files are also stored in a suitable location in the RAM of the processor 22 .

Insofar as a similar task has been previously performed and any information generated in such a previous run has been saved for future reference, such information is also retrieved and written to the processor RAM in step 372. Therefore, when steps 362 through 372 are completed, the system has accumulated a significant amount of information and rules that may be required to perform the dv function. It should be noted that although the information has been retrieved and stored in a particular order in Fig. 13, this order has been given for purposes of illustration only and that the information can be retrieved and stored in any order desired.

The next step in operation is step 374, in which opens a channel to use Epic communicate. This is a bidirectional channel. If  this channel cannot be opened, the program canceled.

Once the introductory ones described above Functions are completed, operation continues with the step 376 and waits for an entry. Nothing more happens until an output "YES" is obtained in step 376 indicating that an input has been received. If an input is received, the operation goes to step 378 to determine if the input is an input in terms of "alighting". If the input is a Exit entry indicating that dv is being called , the operation proceeds to step 380 to determine whether the user wants to save the environment. Step 380 provides the ability either save selected tasks or rules that modified by the user, or any other Save material that is used by the system integrator in the rules or macros, by the system operator or the manufacturer of the system in the material provided with the system. If information the operation goes to step 382 to save the specified information. From Step 380 if an output "NO" is obtained, or from step 382, operation transfers to step 384 get out of the dv routine or leave it. The surrounding material, which during step 382 is then the material that was saved during of step 372 is saved when the tool expires next time.

If an "NO" output is received in step 378, as is normally the case, operation proceeds to step 386 to determine if the input is such an input as that shown by Epic (i.e., that shown in FIG. 4) Program) should be carried out instead of by dv. This is determined using the Epic rules that were saved during step 366. If the program is a program that is to be carried out by Epic, the task is sent to Epic (step 388) through the channel that was set up during step 374. From step 388, the system returns to step 376 to wait for a new entry.

If the task should not be performed by Epic, the operation proceeds to step 390 to determine whether the task is a dv command. If the task is neither a DV or an Epic command, then there is an error that the System and / or the user during step 392 appropriately displayed. From step 392 the Operation returns to step 376 to start a new entry waiting. The new entry can be, for example Input from the user, which is the error corrected.

If the command is a dv command, operation proceeds to step 394 to determine the type of dv command that was received. There are three basic types of dv commands, commonly referred to as "information gathering", "translation" and "design reading". It is initially assumed that it is determined during step 394 that the command is the design read command. Under this condition, operation proceeds to step 396 to read and save the specific schematic diagram generated at that point in the tool's operation, such as the schematic diagram shown on the screen in FIG. 14, and also the GRM Read and store alias information for such a tool, and for a tool to which the schema is to be transferred, or the GRM alias information between the schema at its hierarchical level and a higher or lower hierarchical level to which the Scheme to be transferred. The information stored during step 396 is used by later commands to perform the desired conversion. From step 396, operation returns to step 376 to wait for a new entry.

If it is determined that the entry is a Is a translation command, it means that a Translation for a specific schematic element or Component or on another element or Component should be exercised, which the user is shown. During step 398, the User prompted for the ingredient or that specify other item on which the operation to be carried out. Once the user has this Process completed, intervenes during step 400 Response to the user input dv to the database, saved during step 396 or 370, to translate the specified subject. During the Step 402 becomes the translated item to Epic sent, if appropriate, through the Channel created during step 374. Some Translated items are only saved in dv or can be redirected in a different way than that is indicated by dv rules, or somewhere else. As soon as step 402 is completed, the operation returns to step 376 back to wait for a new entry.  

If it is determined that the dv command is an information gathering command, operation proceeds from step 394 to step 404 where the user is shown a standard task command setting on the screen of display device 30 which may include the following three elements:

• 1. A list of standard information required for the given level in the operation of the software tool is suitable. These are done by the system integrator of the user or provided by the manufacturer of the system.
• 2. A display of entries where it is required that it is available from the user be put. For example, this can be certain Values for components, for example resistance or Capacity values.
• 3. Optional inputs by the user in this Level of operation of the software tool available can be put, but the system also without can continue these inputs. For example an advertisement from a manufacturer for a component or Color coding of wires that are at that point in the Design could be introduced, but not required are.

The user can use one or all of the standard input accept or change them, must be entered for the progress of operations and can add add any of the optional inputs. During the Step 406 determines whether the user made any changes. Has the user If changes are made, the operation goes to step  408 over to the changes in the internal environment take over, namely the changes in the appropriate place to record in memory. From step 406 if one Output "No changes" is present, or from step 408 off, operation continues to step 410 to determine whether any required changes were carried out. Were not all required If changes are made, the operation goes to step 412 in which the user is prompted to make any necessary changes. This includes the Entry of required entries at the specified locations. The request can be made by any suitable way be carried out, for example by flashing or another highlighting a necessary change or input that has not yet been made. From the step 412, operation proceeds to step 406 to determine if the user made changes and to determine via steps 408 and 410 whether all necessary changes have now been made.

If all the necessary changes have been made, then Operation transfers to step 414 to determine the appropriate one Identify Epic task, such as that of the user selected task. This epic task is then in step 402 sent to Epic together, if appropriate with information collected via dv through the channel set up during step 374, and then operation returns to step 376 to to wait for the next entry.

The dv program described above is designed to collect alphanumeric and other control information from a user. However, when designing electronic circuits and in particular when carrying out simulation programs in connection with such designs, it is often necessary to enter selected graphic data and in particular certain analog or digital signal forms into the system. Regarding dv, it is desirable that the user be prompted to provide such graphic data as necessary - that standard input be available to the user in most situations, and that the overall operation be as simple and foolproof as possible for the operator . It is also essential that the routine be designed to work with software tools from different different sources, which can provide waveforms in different languages, use different names and / or use different formats, and that translations or interpretations are made by the system provide a way that is transparent to both the user and the simulator or other software tool for which information is collected. The operator should have the choice of either selecting existing waveforms or drawing other graphics or his own waveform on the screen of display 30 , for example using mouse 26 .

The routine according to the invention, which provides the various abilities specified above, is referred to as "Wavedit". While the explanation of "Wavedit" is for waveform inputs, it is obvious that the procedures described could be used for other types of graphical inputs. A flow chart of the Wavedit routine is shown in FIG. 15, and flow charts of various subroutines of this routine are shown in FIGS . 16 to 19.

As is apparent first from Fig. 15, leads to the routine through the step 420. The input to the routine may be in response to an input from Epic, of one of the other routines, or any other software tools that run on the system, for example, a simulator that requires graphical input or in response to an appropriate input from the operator. Typically, Wavedit comes in response to a command from a macro of the epic routine that is running to perform a simulation function.

After entering Wavedit, the first step, step 422, is to initialize internal data. This is done automatically in response to commands that form part of the Wavedit routine and results in the necessary data being read into the system from the Wavedit files 98 to cause the generation of a standard initial display, including a standard waveform or waveforms and menu. The standard display can be overridden, as explained below, namely by user input.

During step 424, the next step in the operational flow, various configuration files are read into the system. Fig. 16 illustrates a more detailed flow chart of the operations performed in connection with step 424. In Fig. 16, the first step 426 is the opening of a state definition file. The state definition file provides values that are to be displayed for each digital state that can appear in a digital signal form to be generated. At least two digital states, 0 and 1, are defined. However, various rise and fall states, as well as other digitally defined states known in the art, can be used in the system. Each state that is to be used in conjunction with a particular flow of the Wavedit routine must be defined during step 424. There are typically standard definitions for at least binary states 0 and 1 . additional standard definitions can be provided. These are available when a state definition file is opened in step 426 and are read into the system during steps 428 and 430. Each definition in the state definition file specifies what the state looks like when drawing, how the system identifies the state, and how the system should pass on information relating to the state. The user can either accept the standard definitions or enter their own definitions in a suitable manner. During step 428, a determination is made as to whether all definitions for the specific sequence of the Wavedit routine have been entered, and an additional definition is read into the table in step 430 if all definitions have not yet been read. Steps 428 and 430 are repeated until all definitions have been entered that are required for the particular flow of the routine.

Once all of the state definitions have been entered, operation proceeds to step 432. During step 432, a determination is made as to whether all the state logic rules from the area 98 of the memory have been read into the RAM of the processor 22 . State logic rules are, for example, rules for performing Boolean algebra, or other rules that define potential interactions between signal forms. If it is determined during step 432 that all of the state logic rules have not yet been read, operation proceeds to step 434 to read additional logic rules into an internal logic rule table in a suitable wavedit area of a processor 22 RAM. Steps 432 and 434 are repeated until it is determined that all of the logic state rules have been read in, and at that point operation transfers to step 436 to close the definition files.

Then operation proceeds to step 438 to open a filter list file. The filter list file contains information which allows Wavedit to receive inputs from or transmissions to its outputs to software tools, generally simulator tools, which are incompatible with Wavedit in terms of language or format. In particular, the filter list file specifies a software tool that can be used to carry out suitable translations between Wavedit and the external tool. Such a translation routine can be RBI or any other translation tool available in the system. Once a filter list has been opened in a suitable area in the RAM of processor 22 , the operational flow performs steps 440 and 442 to determine if there are other filter specifications that should be read from area 98 or from another suitable location , namely in the filter list file, and to read the filter specifications into the internal filter list file until all filter specifications have been read into this file. If this occurs, the filter file is closed during step 444.

From step 444, operation proceeds to step 446 to read menu files into an appropriate area in the processor RAM for Wavedit. These are various menus that may appear on the display of the display device 30 while the Wavedit routine is running. The menus are typically menus made up of icons. The read menu file step typically also includes opening the file, determining if there are more menus to read, reading the menus, and closing the file as in the previous two files, but this operation has been considered only as one for the purpose of simplifying the diagram only step shown in FIG. 16.

Accordingly, the leeward source file step 484 was also shown as a single step, although it would include four separate steps. The command source file defines macros for use when Wavedit runs. These macros, like those for Epic, contain a sequence of steps to perform a specific function and are described in an interpretive extension language.

After step 448 is completed, the read configuration file step is complete and operation proceeds to step 450 ( FIG. 15) to determine if there are any data files to be read. This step generally determines whether the user has provided a waveform definition that he wants to display. If the user has not defined a display, operation proceeds to step 452 to set the system ready to edit without a file. This means that if a display is generated under these conditions, the display will be a display of the standard waveforms and menus that were entered during step 422.

If the user has made entries available, then go operation from step 450 to step 454 to determine whether the file entered by the user filtering required. Filtering is required if the input from the third party program was received instead of, for example, from a previous one existing wavedit file and regarding the name and format is incompatible with Wavedit. Is a Filtering required, so operation goes to step 456 over to the appropriate filter or Call interpretation / translation tool as it is by the filter list file specified during the Steps 438 to 444 have been saved to input a required translation or other Perform interpretations.

Either from step 454 if a NO output is received or from step 456, the operation proceeds to Step 458 over to determine if there is a Wavedit file exists. This step essentially consists of by looking to see if actually during the Interpretation that was performed in step 456 a file was created, or from the received one Input. If a file was created, the file is read and saved in step 460. Was not a file an empty file is generated in step 462. This file can be added later when inputted be received.  

From step 460 or step 462, the operation goes to Step 464 over to see if there are any more reading files there. If there are other files to be read, then so Operation returns to step 454 to determine whether these files require filtering.

If there are no more files to read in step 464, or if step 452 is performed, the operation proceeds to step 466. Step 466 causes certain operations to initialize the waveform display system to be performed. Operation then proceeds to step 468 to draw the waveforms. Fig. 18 is a more detailed Flußdigramm the steps that take place when the drawing display step 468.

FIG. 18 is step 470, the first step in this operation to determine is whether there are more in one view to drawing waveforms. At this point it should be mentioned that a Wavedit representation contains a hierarchy of representations. At the highest level of the hierarchy is the graphics screen on which everything is drawn. One or more views can be provided on the single graphics screen, each view having an axis and containing one or more waveforms or tracks. Therefore, step 470 originally queries whether waveforms should be drawn in the original view.

Is there to be drawn in an initial drawing Waveforms, the operation proceeds to step 472 the operations required to draw the required axis for the view and the waveform  perform, and required labels on the view by attaching the waveform.

Once step 472 is completed, the operation goes to Step 474 to determine if the waveform is digital. If the signal form is not digital, then it goes Operation to step 476 to remove the analog waveform draw using an appropriate Waveform generation routine that is not part of the forms the present invention using the X-Y number information required for the analog waveform Is provided.

It is found that the waveform is digital Is waveform, the operation proceeds to step 478, to determine if there are other states in the waveform which are to be displayed. There are more States in the waveform that are displayed , the operation proceeds to step 480, around which to use the digital state in question the appropriate state definition from the State definition table created during steps 426 until 430 was created. Then the operation returns to the step 478 back to determine if there are more to be drawn States, and loops through the steps 478 and 480 to generate the desired waveform until it is determined in step 478 that all states the waveform were drawn.

When drawing of a certain waveform is finished, so operation returns to step 470 to determine if there is any more in that particular view waveforms to be drawn. There are more Waveforms to be drawn in the view  so the operation proceeds to step 472 to view an axis and / or labels for the new signal form add if necessary and then go to steps 474 through 480 to obtain the waveform to draw. It is determined during step 470 that there are no more, for that particular view drawing signal forms, so the operation branches to step 482 to determine if there are multiple views that should appear on this graphic screen. Want more views on the graphics screen appear, the operation returns to step 470, to see if there are waveforms for the new view there, and if so, the Steps 472 through 480 continue to add labels and an axis to draw for such a waveform, and the Draw waveform. This sequence of operations continues until all waveforms for an additional view have been drawn, and then the operation returns to step 482 back to determine if there are more to draw Views there. If all views were drawn, so a NO output is obtained in step 482, plus causes the operation to display step 468 for the Drawing leaves.

The operation exits the display step 468 for the Drawing, he then proceeds to step 486 to to wait for an input. An input is made in step 486 received, the operation proceeds to step 488 to determine whether the input was received from the keyboard (user input) or from Epic (socket). Was the Input as a key input from the user or from Received Epic, the operation proceeds to step 490, to look for the command requested by the input has been. A command can either be found in the macros  that were entered during step 448, or in internal commands that are part of the Wavedit routine were saved, initially in a macro is searched for commands, and then in the internal commands. In step 492, a command is issued found, the operation proceeds to step 494 to Execute command.

Fig. 17 is a more detailed flow diagram of instruction execution step 494 for an example instruction, in this case an evaluation instruction. The evaluation command can, for example, lead to the formation of a third signal form from a combination of two other signal forms. If it is determined during step 496 that an evaluation command has been received for certain waveforms, operation proceeds to step 498 to determine if the waveforms are digital. If the waveforms are not digital, operation proceeds to step 500 to combine the waveforms using standard mathematical functions such as variance or covariance, and using existing software tools that are not specifically part of the present invention.

If the waveforms are determined to be digital, operation proceeds to step 502 to determine if all of the digital states of the waveforms to be combined have been combined. If there are other digital states to be combined, operation proceeds to step 504 to combine the corresponding states of the two waveforms using the appropriate logic rules from the logic rules table stored during steps 432 and 434 ( Fig. 16 ). Such a combination can include a single step or multiple steps, depending on the complexity of the combination logic. From step 504, operation returns to step 502 to determine if there are other digital states to be combined, and the operation loops through states 502 and 504 until all of the digital states of the two waveforms to be combined have actually been combined . If the combination of the two waveforms has ended, either as the result of an analog combination using step 500, or as the result of a digital combination through steps 502 and 504, operation proceeds to step 506 to output a new waveform of the combined waveforms and to step 508 where the new waveform is added to the display. The waveform should be added using the same steps to initially add a waveform to the display of FIG. 18, with appropriate input being received regarding the view in which the waveform is to appear.

Once step 508 is complete, the command is finished, and the operation returns to step 510 to determine whether the command was executed correctly. If no command was found during step 492, then an error message is printed out in step 512, and operation also proceeds to step 510 to determine if the command executed properly has been. If the command does not run properly, like this would happen if you go to the step above If step 512 arrives, the company does not search any other keyboard or epic entries, but proceeds to step 514 to determine if it is gives a mouse input.  

If it is determined during step 514 that a If there is mouse input, the operation goes to step 518 over to the area on the display device find in which the mouse is located. In this Situation typically lies the mouse in an area a waveform that appears on the screen. The mouse can have multiple buttons, for example three buttons, each button having one represents a different command for the Area can be executed, over which the mouse located. During step 520, the next step in operation, the command is determined as a result the button pressed on the mouse is to be executed, and the command is executed. Such an order could be, for example, a dot on the Attach waveform to make measurements at the point and allow their recording. Measurements may also respond to a command between the displayed point and a previously displayed point be performed.

If there is no mouse input in step 514 or step 520 is ended, operation proceeds to step 522 to determine if there is a menu command input. A menu command input is obtained when, for example, the mouse is over an icon on a menu that is being displayed and an appropriate key is pressed. If there is menu command input, operation proceeds to step 524 to find the command, either in the stored macros or in Wavedit's internal command set, and then proceeds to step 526 to execute the command. The command is executed in essentially the same manner as the command in step 494, as shown for an exemplary command in FIG. 17.

If no menu entry is found in step 522, or when execution of an instruction ends in step 526 If so, the operation returns to step 486 to waiting for an additional input. The described Operations are repeated for additional inputs, until an exit command is found, as a result either a keyboard or epic input, or one Menu entry.

Fig. 19 explains the sequence of operations that occurs when this command is detected. In Fig. 19, if an exit command is determined during step 530, operation proceeds to step 532 to determine if all of the changed data has been saved. If all of the saved data has not been changed, then operation proceeds to step 534 to inform the user that used, changed data has not been saved and to prompt the user to confirm that the Wavedit routine is allowed to be closed leave, which would lead to the loss of such changed data. If the user indicates that it is unacceptable to exit, and all changed data is not saved, then operation branches to step 536 to exit the exit command and returns to Wavedit to allow the changed data to be saved. If an "YES" output is received either during step 532 or step 534, operation continues by exiting the Wavedit routine, thereby completing the operation.

A system was therefore made available which the use of automated design systems and automated manufacturing systems essential simplified while maintaining a high level  Configurability provides to special Meet requirements of a given user and cope with changes in such requirements, as soon as they occur. The system allows use of tools related to language, name and / or of the format are incompatible, in a way that both for the user as well as the software tools completely is transparent, all of this using a single integrated system.

While the invention has been described above with reference to a preferred embodiment shown and described, however, it is noted that the embodiment only for the purpose of explanation, and that numerous changes to the various specified Perform steps and the order of these steps leave, and that other changes in shape and details are made by a person skilled in the art could, while still within the essence and The scope of the invention remains.

Claims (69)

1. System for integrating and managing the operations of several different software tools, at least some of which are incompatible with the system, characterized by :
means for storing a plurality of control macros, each relating to a particular process;
means for entering a process into the system;
means responsive to an input process for retrieving a corresponding macro;
execution means responsive to the retrieved macro to cause selected tools to execute in a predetermined sequence;
means for determining whether an executed tool is compatible with the system; and
a device responsive to the execution of an incompatible tool for encapsulating the tool, which causes all transfers to and from the tool to be checked and interpreted, if necessary. 2. System according to claim 1, characterized in that a list of those to be used in the system Software tools is provided, the list in the Storage device is stored, and a display in the list for each tool regarding the fact it is intended whether the tool is an incompatible tool. 3. System according to claim 1, characterized in that the encapsulation device several Rules of interpretation at a predetermined location in contains a macro, which is a software tool relate to encapsulation, one Facility to review every transfer to the tool and of this for an object upon which relates to one of the rules of interpretation, and one Establishment on the transfer of an object responds to which an interpretation rule relates to the implementation of the rule fixed interpretation. 4. System according to claim 3, characterized in that the rules of interpretation separate rules for Items included by the incompatible tool transferred, and for items sent to the Tool are transferred and that the facility for Check and set up to carry out a Review or implementation of the carry out appropriate rules for the directions in which an object is transferred. 5. System according to claim 4, characterized in that a facility is also provided which is operable when an incompatible tool is run is used to determine whether the interpretation rules  saved for transfer from such a tool should be a facility for storing such rules exist, as well as a Facility based on an edition of this tool responded to bring back the rules and the rules to use to spend from this tool interpret. 6. System according to claim 2, characterized in that the control macros, including the Interpretation rules, in an interpretative Extension language is written, both for the machine as well as the machine is readable. 7. System according to claim 6, characterized in that a macro rules for multiple software tools Performing a given function may include where the rules indicate the order in which the tools are to be run. 8. System according to claim 7, characterized in that at least one of the macros contains a rule which retrieving a new macro from the Storage device causes. 9. System for integrating and managing the operations of several different software tools, at least some of which are incompatible with the system, characterized by:
means for storing a plurality of control macros, each relating to a particular function, the macros being written in an interpretive language of extension that is readable by both humans and machines;
means for entering a process into the system;
means responsive to an input process for retrieving a corresponding macro;
means responsive to the retrieved macro for causing selected tools to execute in a predetermined sequence;
wherein a macro can include rules for controlling the sequence of tools and the interfacing of tools with the system, with and between users, and where a user of the system can add or change rules in existing macros, or add a new macro, all of them in the interpretive extension language, whereby the rules are recognized by the system and run immediately in this language, which means that the system can easily be reconfigured. 10. System according to claim 9, characterized in that the format for at least one of the tools is different from the format for another tool, and that a transmission can take place in at least one direction between the one and the other tool;
providing a rules file written in an interpretive extension language and containing format conversion rules for tools with incompatible formats;
a device is provided which can be operated if a transfer between tools incompatible with the format is to take place in order to retrieve the appropriate format conversion rules from the rules file; and
means for using the retrieved rules is provided to control the format conversion of material to be transferred between the tools incompatible with the format. 11. System according to claim 10, characterized in that at least two incompatible in format Tools are also incompatible with the name; and that a facility is provided to required Carry out name translations for material, which between those regarding the name incompatible tools. 12. System according to claim 9, characterized in that at least some of the tools related to the name are incompatible; and that a rules file is provided is that in an interpretive language of expansion is written, the translation rules for tools contains that are incompatible with the name; and a device that is actuable when one Transfer between regarding the name incompatible tools should be used to set appropriate rules in the rules file to use required Effect translations to make the tools compatible do. 13. System according to claim 12, characterized in that a facility is provided to work with everyone  Rules file a list of name translations for the save incompatible tools with respect to the name. 14. System according to claim 13, characterized in that the rules and the corresponding list of names in a screen are stored, a Name translation entry then each time in the list is added when a translation of a name that is not yet on the list. 15. System according to claim 14, characterized in that one on the transfer of a name, the one Translation requires between those regarding the Name incompatible tools responsive facility is provided to determine if there is an entry for this name in the list of names there is a Device is provided that responds to that an entry for the name is provided around the Use entry to translate name, and that a facility is provided which is based thereon responds that no entry is provided for the name is to follow the appropriate rules for translating the Name to use. 16. System according to claim 15, characterized in that the facility to use the appropriate rules a facility to search for any suitable Usually includes to determine if they are on the name is applicable, and means for executing appropriate rules to translate the name perform. 17. System according to claim 16, characterized in that a facility to remove all invalid ones  Character after a name translation by the Means provided for executing appropriate rules is. 18. System according to claim 16, characterized in that a device for truncating a translated Name is provided to a suitable maximum length. 19. System according to claim 16, characterized in that a facility for adding any required prefixes or suffixes to one translated name is provided. 20. System according to claim 16, characterized in that means are provided for determining whether a unique translated name for everyone too translating name is required, a Facility that is operable if one unique translated name is required whether to determine the translated name is unique, a facility that is operable when the translated name is not uniform to determine whether the translated name modified in this way can be that it is unique, and one Facility for modifying the translated name, so that it is unique when such Modification is possible. 21. System according to claim 20, characterized in that a facility for displaying each entry in the Name list is provided to indicate whether this Entry belongs to a translated name that must be unique.   22. System according to claim 14, characterized in that a device for storing the name list of a Screen is provided as an alias file. 23. System according to claim 14, characterized in that a facility for using the name list in a screen is provided to be generated from Provide original names, where not a unique name for every original name is present, and being the Deployment facility a list of Original names for each generated one used by her Provides names. 24. The system of claim 9, characterized in that one or more of the tools can comprise a nested hierarchy of material related to a component, using different names for the same item at different levels in the hierarchy; and
that a rules file is provided for translations of the names for the different hierarchy levels, and means for using the rules file to obtain the appropriate name for an item at a given hierarchy level. 25. System according to claim 9, characterized in that
User input information is required for at least some tools; and
Rule files are provided that are written in an interpretive extension language; and
a device is provided for using the rule files to enter actively requested input information. 26. System according to claim 25, characterized in that the rule files standard inputs for each level Provide what inputs from each tool be requested and that a facility is provided which is operable when a tool is at a level is in what inputs to represent the Standard inputs for this level for the user are required, a facility is provided to the user to make changes to the Allow standard inputs, and a facility is provided to be modified by the user Pass on standard inputs to the tool. 27. System according to claim 26, characterized in that a device is provided that the user Display allows him to make inputs to a tool or wants to turn it into a system. 28. System according to claim 26, characterized in that a device is provided to the user in the standard input representation for objects request which of the users as inputs on the must add the given level to the tool. 29. System according to claim 28, characterized in that one device is provided for another Operation of the tool lock until the user makes the necessary entries.   30. System according to claim 28, characterized in that a device is provided to the user in the standard input display for additional To request items which the user considers to be Add inputs at the given level in the tool can. 31. System according to claim 25, characterized in that
that means are provided for storing information relating to a design and for storing translation information relating to a selected tool or tools;
that means are provided for prompting a user to select an element of the stored design on which a selected translation is to be carried out; and
that means are provided that respond to user input to perform the selected translation on the item selected by the user. 32. System according to claim 25, characterized in that
that the required input information is digital graphic information; and
that means are provided for storing state definitions for valid digital states for the graphic information;
means for receiving graphic information to be entered and
a device for using the stored status definitions to display the received graphic information. 33. System according to claim 32, characterized in that the graphic information received either Standard graphics information from the system or from graphic information provided to a user. 34. System according to claim 32, characterized in that
the means for storing rule files comprises means for storing logic rules for operation on the graphic information;
means for receiving and recognizing commands to operate on the graphic information; and
a device for using suitable stored logic rules for executing a received and recognized command. 35. System according to claim 32, characterized in that
that the digital graphic information is waveforms; and
that the means for displaying uses the stored state definitions to control the display for each successive state of a waveform to be displayed. 36. Method for integrating and managing the operations of several different software tools, at least some of which are not compatible with the system, characterized by the following steps:
Storing multiple control macros, each relating to a particular process;
Entering a process into the system;
Retrieving a corresponding macro in response to an entered process;
Executing selected tools in a predetermined sequence in response to the retrieved macro;
Determining whether a tool that is running is compatible with the system; and
Encapsulating the tool and initiating a review and interpretation of all transfers to and from the tool as required in response to the execution of an incompatible tool. 37. The method according to claim 36, characterized in that that a list of those to be used in the system Software tools is provided, the list with the Macros is saved, and an ad appears in the list for each tool is provided whether the tool is a is incompatible tool. 38. The method according to claim 36, characterized in that the encapsulation step comprises the following steps: Review of multiple interpretation rules on one predetermined location in a macro which is a Software tool that requires encapsulation, during each transfer to and from the tool for an object to which one of the  Interpretation rules apply, and by performing the interpretation usually given in Response to the transfer of an item to which applies an interpretation rule. 39. The method according to claim 38, characterized by following steps that are carried out when a Execution with an incompatible tool takes place: Determine whether the interpretation rules for Transfer saved by such a tool should be in a facility for storage such rules, and bringing the rules back into Respond to an output from the tool, and use the rules for interpreting expenditure from this Tool. 40. The method according to claim 37, characterized in that the control macros including the Interpretation rules in an interpretative Extension language is written, both for Humans as well as machines is readable. 41. The method according to claim 40, characterized in that that a macro rules for multiple software tools may have a specific function perform, the rules the order determine in which the tools are carried out. 42. The method according to claim 41, characterized in that that at least one of the macros contains a rule which is the recovery of a new macro from the Storage device caused.   43. Method for integrating and managing the operations of several different software tools, at least some of which are not compatible with the system, characterized by the following steps:
Storing multiple control macros, each of which relates to a specific function, the macros being written in an interpretive language that is readable by both humans and machines;
Entering a process into the system;
Retrieving a corresponding macro in response to an entered process;
Executing selected tools to be executed in a predetermined sequence in response to the retrieved macro; and
wherein a macro may include rules for controlling the sequence of the tools and the interface of the tools with the system, with one user and with each other, and wherein a user of the system may add or change rules in existing macros, or add a new macro, all in the interpretive extension language, whereby the rules are recognized by the system and can run immediately in this language, whereby the system can be easily reconfigured. 44. The method according to claim 43, characterized in
that the format for at least one of the tools is different from the format for another tool, and that transmission can take place in at least one direction between the one and the other tool;
providing a rules file written in an interpretive extension language and containing format conversion rules for tools with incompatible formats; and
Steps for returning the appropriate format conversion rules from the rules file if there is to be a transfer between tools incompatible with the format; and
wherein the retrieved rules are used to control the format conversion of material to be transferred between the tools that are incompatible with the format. 45. The method according to claim 44, characterized in that
that at least two tools incompatible in terms of format are also incompatible in terms of name, and
that the step of performing the necessary name translations on material that is transferred between the two tools that are incompatible with the name is also provided. 46. The method according to claim 43, characterized in that that at least some of the tools related to the name are not compatible and that a rules file is present in an interpretative Language of expansion is written and Contains translation rules for tools related to the name are not compatible; taking the steps are feasible when a transfer between  regarding the name of incompatible tools that appropriate rules in the rules file can be used to to carry out the translations required for this are to make the tools compatible. 47. The method according to claim 12, characterized in that that a facility for storing, with everyone Rules file, a list of name translations for the tools incompatible with the name is provided. 48. The method according to claim 47, characterized in that that the rules and the corresponding list of names in a screen can be saved, where a Then name translation entry of the list each time is added when a translation for a name is performed, which is not yet on the list located. 49. The method according to claim 48, characterized in that the following steps are planned: if a transfer of a name, the one Translation requires between those regarding the Namely incompatible tools, whether an entry for that name is in the list of names, and, if there is an entry for the name, Use of the entry to translate the name, and if there is no entry for the name, Use the appropriate rules to translate the Called. 50. The method according to claim 49, characterized in that the usage steps following steps include: considering any suitable rule to  determine whether it is applicable to the name, and Establish appropriate rules for performing the Translation of the name. 51. The method according to claim 50, characterized in that continue the steps of removing each unfavorable character after a name translation during the step of implementing appropriate rules are provided. 52. The method according to claim 50, characterized in that that the steps of cutting off a translated Name are provided to a suitable maximum length. 53. The method according to claim 50, characterized in that that continue the step of adding any suitable prefixes or suffixes a translated name is provided. 54. The method according to claim 50, characterized in that the following steps are also planned: Determine whether a unique translated name for any name to be translated is required, and if a unique translated name is required is determining whether the translated name is unique and if the translated name is not unique is determining whether the translated name is modified in this way can become unique and modify the translated name so that it is unique, if this modification is possible. 55. System according to claim 20, characterized in that a facility to designate each entry in the Name list is provided in terms of whether this  Entry for a translated name that serves must be unique. 56. The method according to claim 14, characterized in that the steps of saving the name list of a Screen are provided as an alias file. 57. System according to claim 48, characterized in that the following steps are envisaged: using the Name list in a screen to provide Original names from generated names, if none unique name for each original name , the providing step being a list of Original names for each generated one Provides names. 58. The method according to claim 43, characterized in that one or more tools are nested Hierarchy of material related to a component contains or contain, with different names for the same item at different levels be used in the hierarchy. 59. The method according to claim 43, characterized in that from a user for at least some tools Input information is required, where Rule files exist in one are written in the language of extension, and further the step is provided that Use rules files interactively enter required input information. 60. The method according to claim 59, characterized in
that the control files provide standard inputs for each level at which inputs are required by each tool; and
that the steps of displaying the standard inputs for that level are intended for the user when a tool is at a level where inputs are required, thereby allowing the user to make changes to the standard inputs to reflect those modified by the user Transfer standard inputs to the tool. 61. The method according to claim 60, characterized in that the step is provided to the user Allow ad to make inputs to a tool or wants to turn it into a system. 62. The method according to claim 60, characterized in that the step is provided to the user in the Standard input representation for objects to request which of the users as inputs on the given level in the tool. 63. The method according to claim 62, characterized in that the step of blocking another operation of the tool is provided until the user makes the necessary entries. 64. The method according to claim 62, characterized in that that the step is provided to the user in the Standard input representation regarding optional To request items which the user considers to be Add inputs to the tool at the given level can. 65. The method according to claim 59, characterized in
that the steps of storing information regarding a design are provided; and
storing translation information relating to a selected tool or tools;
Prompting a user to select an element of the saved design on which to perform a selected translation; and
Carrying out, in response to user input, the selected translation on the item selected by the user. 66. The method according to claim 59, characterized in
that the required input information is digital graphic information; and
that the following steps are provided: storing state definitions for valid digital states for the graphical information;
Receiving graphical information to be entered; and
Use of the saved status definitions to display the received graphic information. 67. The method according to claim 66, characterized in that that the graphic information received is either Standard graphics information from or through the system provided a user Graphic information is. 68. The method according to claim 66, characterized in that the following steps are provided: storing logic rules for operating on the graphic information;
Receiving and recognizing commands to operate on the graphic information; and
Use appropriate, stored logic rules to execute a received and recognized command. 69. The method according to claim 66, characterized in that that the digital graphic information waveforms represents, and that the saved State definitions are used to that Display representation for each successive State of a waveform to be displayed Taxes.