DE4310615C2 - Designing electrical devices with multiple design tools that are at least partially incompatible with each other - Google Patents

Description

The invention relates to a system for designing electrical Devices with several design tools, one of which at least some design tools are incompatible with each other are.

The present invention further relates to a method for Coordinate different, at least in part mutually incompatible design tools during development electrical devices with an automated system.

In "Software Engineering", Gewald, Haake, Wegler, R. Oldenbourg Verlag, Munich, Vienna 1982 , pp. 221-232, general principles for the subject area "software engineering" are described, in particular the implementation of different computer source programs and the techniques used . For example, procedures such as simulation, emulation and decompilation are described. There is also a reference to cross-compilers, assemblers, microprocessors and language conversion aids.

Nowadays, computers are commonly used in designing the Production preparation, manufacturing and at Examination of numerous products used. Examples on 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 can 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 perform that compiles in a separate operation 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.

The object of the invention is Creation of a design system and an associated one Procedure for the design of electrical devices, at the use of several incompatible design tools possible as part of a fully automated design process is.

This object is achieved in the context of the present invention a system for designing electrical devices with the Features of claim 1 solved.

The task is also coordinated through a process different, at least partially among themselves incompatible design tools with the features of Claim 19 solved.

Thus, in the context of the present invention Operating sequence of several different tasks and Software tools integrated and managed.  

Some of these tools may not be compatible with the system, on which the tools are to 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 be.

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.

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 a display of various files that a preferred embodiment of the invention may be stored in accordance with;

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 20, a system in which the method and apparatus of the invention can be made according to, a processor 22 for realizing a computing, test, and conversion means having sufficient capacity to perform the various functions of the present To implement 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 each as an input device, which can be operated by a user. A storage device or 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 (CRT) display, may interface with the processor 22 in a conventional manner connected 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 arises during step 70 that it is not possible to arrange wiring paths, the process flow can return to step 66 to redefine the board so as to overcome the problem. If problems continue to occur, it may be necessary to return to step 56 to revise the original design so that a simpler arrangement and structure are achieved. Ideally, completing each of steps 66 through 72 will result in the appropriate subsequent steps being called.

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 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 has not extracted correctly, then the user is appropriately informed of the signal network list extractor error. As with the simulator, the system can suggest possible corrections for the error or undertake to correct the error itself. Accordingly, if the design verification has not been successfully completed, the user is informed of violations of the electronic design rule and the system can again provide an indication of possible corrections or try to correct the problem itself using rules. When the verification process is complete, the system returns to the schematic editor, proceeds to 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" variable is set to "YES" (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 if "hi _- type" is not set to "sim" is, another message is sent with the involvement of the "Wavedit" routine. If "schedit _- 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 that is returned by "pkgr" contains the word "error", a variable with the name "pkgr _- status" is 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, close the window in which Packager ran and send a message to the calling process that everything went well.
• 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.

When the process is finished, the software tool that runs the function provides an input to Epic that is recognized during step 118 .

This causes the operation to proceed to step 120 , during which a determination is made as to whether anything else was stored in the suspended task list for that particular process. If nothing was saved, nothing else needs to be done about this process and operation returns to step 114 and waits for the next entry. If there is anything in the suspended task list for this process, operation proceeds to step 122 to save material in the current execution queue. The current execution queue is stored in a predetermined location in the processor's RAM. During step 124 , the next step in the instruction flow, the execution queue is loaded from the suspended task list for the process and then operation proceeds to step 126 to 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 to perform the particular input process, is loaded into the main execution queue during step 126 . The queue is also considered during this step. All steps that are to be performed during the Epic operation are loaded into the main execution queue and are carried out from this queue according to the "first in, first out" (FIFO) principle. Therefore, if this queue is empty, it means that Epic does nothing else. Therefore, the process makes a determination during step 136 whether the queue is empty. If the queue is empty, operation continues to step 137 to determine if the execution queues have been saved. Therefore, if an execution queue was saved during, for example, step 122 or step 132 , an output "YES" is obtained during step 137 , which causes the flow of operations to proceed to step 139 to load the saved execution queue into the main execution queue. Then operation returns to step 126 to check the main execution queue. If it is determined during step 137 that no queue has been saved, operation returns to step 114 to wait for the next entry.

If the queue is not empty, operation proceeds to step 138 to determine if this entry results in a macro being called. If it is determined during step 138 that this input is a task or process that results in a macro being called, then operation proceeds to step 140 to save the current contents of the main execution queue and the macro for the given task or load the given function from the correct task list into the main execution queue during step 142 . Then the operation continues by looking at the main execution queue. Since a macro was loaded into the queue, it would not be empty and would not contain any further task list entries. Therefore, operation would proceed to step 144 , in which a determination is made as to whether the next item from the main execution queue is an internal command. If it is not an internal command, the operational flow issues a corresponding error message to the system and / or user during step 145 and returns to step 126 to view the next 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 may take a few hours to complete. Therefore, while step 146 is being performed, operation continues to step 148 to determine if the system wants to wait for a process output. This would occur when a Whilexec tool expires, requiring it to receive output from the tool when execution is complete, and interpreting such output before it can work as valid input for Epic . If there is an "YES" output at step 148 , operation transfers to step 150 to move the execution queue to the process whilexec task list in the process list for the process, and then returns to the main execution queue to perform other functions while waiting for output from the Whilexec tool. When output from the Whilexec tool is complete, it represents input to the system and comes in through step 114 . This is recognized during step 130 and causes the saved execution queue to be reloaded during step 134 . As explained above, this saved execution queue contains the interpretation rules required by the tool's encapsulation to cause outputs from the tool to be valid inputs to Epic.

At the same time, a check is also made during step 152 to determine whether to wait for the process being performed to end. If there is to be a wait, the execution queue is moved to the suspended task list in the progress files for the process being performed and operation returns to the main execution queue. Since the main execution queue was cleared during step 154 , the queue is found to be empty during step 136 and operation returns to step 114 to wait for a new input. When the process performed finally ends, an input is received from Epic which is detected during step 118 and results in the saved suspended task list being reloaded into the main execution queue during step 124 .

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

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 have not been previously stored on a screen, operation proceeds from step 172 to step 180 to perform various management functions required to open the new screen. Operation then proceeds to step 182 , where the rules are read from the file and, if necessary, converted to a form that can be used by GRM or the application program. For example, if the screen containing the rules is to be used by an application program, some interpretation of the rules may be required to be compatible with such a program. The modified rules are then saved during step 184 and displayed on the screen that was set up in step 176 . Then operation proceeds to step 178 to save the screen and provide information regarding the address where the screen is stored for appropriate 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) requests a particular name or screen, step 202 , the system checks to see if the screen exists, step 204 , and generates an error signal, step 194 , if the screen does not exist. If the screen exists, operation proceeds to step 206 to determine if the name request is being made. If the request relates to a specific name, the data previously stored with this name are retrieved and transferred under control of the application program to a suitable storage location for the application program, together with any name generated for the original name, during step 208 . If the request is for the screen and not for the specific name, the data stored in step 200 are retrieved during step 210 and transferred to this program under the control of the application 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 obtained, or from step 224 , operation proceeds to step 226 to determine if the name is on the screen. This usually means that the name was previously created and that the original and generated names were stored on the screen for future reference. However, as mentioned above, such a name translation list with the rules can be provided and originally stored on the screen. If the name is on the screen, operation proceeds to step 228 to return the previously created name, generally to the requesting application program. If the name is not on the screen, the operation proceeds to step 230 , in which the original name is brought on the screen and is originally marked as "unique". From step 230 , operation proceeds to step 232 , in which each of the rules in the file is checked sequentially until all rules have been viewed. For each rule, operation proceeds to step 234 to determine if the rule relates to the particular name. For example, a rule could indicate that all uppercase letters should be converted to the corresponding lowercase letters. Therefore, if the name is in uppercase, the rule would apply, would output "YES" at step 234 , and would result in step 236 being performed. During step 236 , the rule is applied to perform a name conversion. Either from step 234 if an "NO" output is obtained, or from step 236 , operation proceeds to step 238 where the next rule is retrieved.

Rules 232 , 234 , 236 and 238 are performed sequentially for each rule stored on the screen until it is determined during step 232 that all rules have been performed on the screen. At this point, the translation of the name was completed, except for various administrative functions that will be performed during the following steps.

In particular, when all the rules are in place, operation proceeds from step 232 to step 240 where the generated name is checked to determine if it contains any characters that are invalid in the receiving tool. If such characters are found, they will be removed. Operation then proceeds to step 242 to determine if the length of the generated name exceeds a maximum length set by the user for names in the receiving program. If the length of the generated name exceeds the maximum, the name will be shortened using suitable cutting rules. Usually this is done by simply removing the excess number of characters from the end of the name. However, more complicated cut-off rules can be used, for example the removal of vowels in a first cut-off step. Finally, during step 244, any required prefixes or suffixes defined by the user can be added to the name. If step 244 is carried out, a root can be shortened during step 242 so that the final name does not exceed the maximum length.

During step 246 , a determination is made as to whether there should be a one-to-one mapping between the original name and the generated name. If a one-to-one mapping is not required, the name of the name provided during step 230 is changed from "unique" to "non-unique" during step 248 . While the generated name may actually be unique, the name is marked as non-unique during step 248 , so if the generated name appears later and the subsequent creation also does not allow it to be unique, the system does so Allow use. If the system assumes that the original creation is unique, it would not allow the same generated name to be created later.

The above explanations are explained by step 249 , namely the next step in the operational sequence. During step 249 , a determination is made as to whether the generated name collides with a unique name that was previously generated and is contained in the name list. If the name does not conflict with a unique name, the operation proceeds to step 250 , in which the generated name with the original name is stored on the screen. The newly created name is then sent back to the application program that originally issued the request in step 252 . If it is determined during step 249 that the name collides with a unique name, operation proceeds to step 256 to determine if the name can be modified to be unique. The operations performed during step 256 and after are described in the following paragraphs.

If it is determined during step 246 that a one-to-one mapping is required, then a determination is made in step 254 as to whether the generated name is unique. If the generated name is unique, the name is remembered during step 250 and returned in 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 57724 00070 552 001000280000000200012000285915761300040 0002004310615 00004 57605en, particularly by rules implemented by the user's tool integrator generated or by 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 to be unique, such modification is done during step 260 to provide a name that is unique and also valid in the receiving tool. From step 260 , operation proceeds to step 250 to remember the generated name and return the generated name to the requesting tool. In this way, a translation mechanism based on generalized rules is provided that is very flexible and can be easily modified to accommodate any changes in the system.

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, the routine finds the original name of such a generated name during step 276 . In step 278 , a determination is made as to whether the original name is unique to the generated name (that is, whether the predetermined generated name is a generated name for more than one original name). If the original name is unique, the original name is returned to the requesting source during step 280 . If the original name is not unique, then a list of all original names pointing to the generated name is returned during step 282 .

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. 11A 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 . At 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, insofar as 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 to read various options and store them in an appropriate location in RAM, which is used to store information for the RBI routine. Options, schemes, waveforms and the like are sometimes referred to below as "objects", where objects are elements that are provided either by the system manufacturer or user (options) or by another program (schematic components, waveforms, etc.), where the conversion rules provided by RBI 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 to be converted is read into the system and also any external information required for the conversion. For example, a GRM screen created in the manner discussed above can be provided for use by the RBI program.

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 rule register is not empty, such as in a case where the first rule has been loaded into it, the operation proceeds from step 324 to step 330 to determine if this is a " Screen rule is. There are essentially two types of rules in the RBI routine called "screen rules" and "termination rules". A termination rule generally involves a single command that can be executed immediately. In contrast, a screen rule generally affects two or more instructions and can also include a branch or other factors. Any rule that is not a "screen rule" is a "termination rule". Therefore, if it is determined during step 330 that the rule is not a screen rule, then operation proceeds to step 332 to execute the termination rule's only command and then returns to step 322 to queue the next rule in the load 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 Figure 12A by the command or rule "for all (nets)" and for the rule "for all (symbols)" which follows it. Later there is also a rule "for _- bar all (ports)". These rules specify that the following rules should apply 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) is shown in Fig. 12A. These are the rules that end a sequence "for _- all".

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, the command "for _- all _- nets" next "network" is retrieved in step 334 during step 334th 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 at the step 340 from step 336 and it is determined that the object is empty, the operation proceeds to step 342 to exit the end of the "for" -Bildschirmregel move and so this rule.

Likewise, if the incoming screen rule is recognized as a starting "if" screen rule during step 330 , operation proceeds to step 344 to determine if the "if" condition is true. If the "if" condition is not true, the operation proceeds to step 346 which causes the operation to execute the first rule following the end of the "if" screen and the operation returns to step 322 , to place this rule as the next rule in the current rule register.

If the "if" condition is true, operation proceeds to step 348 to get the rule within the "if" screen and place that rule as the next rule in the current rule register. Then operation returns to step 322 to cause this rule to be executed. If the rule within the "if" screen is the rule for ending the "if screen", then operation proceeds from step 330 to step 350 to get the next rule outside the "if" screen, and this rule as the next rule in the current rule register, and then operation returns to step 322 to cause this rule to be executed.

Finally, if it is determined in step 330 that the rule is a screen break rule, operation proceeds 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, in other words, fetches the first off-screen rule during step 354 and that rule becomes the next rule in the current rule register. Then the operation returns to step 322 . Similarly, if there is no output in step 352 , the next rule is retrieved during step 356 as the next rule is loaded into the current rule register, and then operation returns 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 a channel is opened to communicate with Epic. This is a bidirectional channel. If this channel cannot be opened, the program is canceled.

Once the introductory functions described above are complete, operation continues to step 376 and waits for input. Nothing else happens until an "YES" output is obtained in step 376 indicating that an input has been received. If an input is received, operation proceeds to step 378 to determine if the input is an "exit" input. If the input is an exit input indicating that dv is to be called, operation proceeds to step 380 to determine if the user wants to save the environment. Step 380 provides the ability to either save selected tasks or rules that have been modified by the user or to save any other material that has been set in the rules or macros by the system integrator by the system operator or the manufacturer of the system in the material provided with the system. If information is to be stored, the operation proceeds to step 382 to store the specified information. From step 380 if an "NO" output is obtained, or from step 382 , operation proceeds to step 384 to exit or exit the dv routine. The surrounding material that was saved during step 382 is the material that is saved during step 372 the next time the tool runs.

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 is not to be performed by Epic, operation proceeds to step 390 to determine if the task is a dv command. If the task is neither a dv or an epic command, then there is an error that is displayed to the system and / or the user in a suitable manner during step 392 . From step 392 , operation returns to step 376 to wait for a new entry. The new input can be, for example, an input from the user that corrects the error.

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 input is a translation command, it means that a translation is to be carried out for a particular schematic element or component or on another element or component which is displayed to the user. During step 398 , the user is prompted to specify the component or other element on which the operation is to be performed. Once the user completes this process, in step 400, in response to user input dv, accesses the database that was saved during step 396 or 370 to translate the specified item. During step 402 , the translated item is sent to Epic, if appropriate, via the channel created during step 374 . Some translated items are only stored in dv or can be redirected in other ways, as indicated by dv rules, or elsewhere. Once step 402 is complete, operation returns to step 376 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 accept or change any or all of the standard input, add required input to continue the operation, and add any of the optional input. A determination is made at step 406 as to whether the user has made any changes. If the user has made changes, operation proceeds to step 408 to apply the changes to the internal environment, namely to record the changes in the appropriate location in memory. From step 406 if there is no "no changes" output, or from step 408 , operation proceeds to step 410 to determine if all of the required changes have been made. If all of the required changes have not been made, operation transfers to step 412 where the user is prompted to make necessary changes. This includes entering required information at the specified locations. The request can be made by any suitable means, such as flashing or otherwise highlighting a required change or entry that has not yet been made. From step 412 , operation proceeds to step 406 to determine if the user has made changes and to determine via steps 408 and 410 whether all of the necessary changes have now been made.

Once all of the necessary changes have been made, operation proceeds to step 414 to determine the appropriate Epic task, such as the task selected by the user. This Epic task is then sent to Epic in step 402 , if appropriate, along with information gathered by dv over the channel established during step 374 , and then operation returns to step 376 to wait for the next input.

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. With regard to dv, it is desirable that the user be prompted to provide such graphics data as necessary, that standard inputs are 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 routine may be entered in response to an input from Epic, from one of the other routines or software tools running on the system, such as a simulator that requires graphical input, or in response to an appropriate input from that 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 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 . Typically there are 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 state logic rules have been read from the area 98 of the memory 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 rules 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 read command 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 provided input, operation proceeds from step 450 to step 454 to determine if the file entered by the user requires filtering. Filtering is required when the input has been received by a third party program instead of, for example, a pre-existing Wavedit file and is incompatible with Wavedit in terms of name and format. Is a filtering is necessary, the operation proceeds to step 456 to select the appropriate filtering or interpretation / translation tool, as indicated by the filter list file that was stored during the steps 438 to 444, a required with the input Perform translation or other interpretations.

Either from step 454 if NO output is obtained or from step 456 , operation proceeds to step 458 to determine if a wavedit file exists. This step essentially consists of looking up to determine whether a file was actually created during the interpretation performed in step 456 or from the input received. If a file was created, the file is read and saved in step 460 . If no file was created, an empty file is generated in step 462 . This file can be added later when input is received.

From step 460 or step 462 , operation proceeds to step 464 to determine if there are more files to read. If there are more files to read, operation returns to step 454 to determine if 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 flow chart of 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.

If there are waveforms to be drawn in an initial drawing, operation proceeds to step 472 to perform the required operations to draw the required axis for the view and waveform, and to attach required labels to the view through the waveform.

Once step 472 is completed, operation transfers to step 474 to determine if the waveform is digital. If the waveform is not digital, operation proceeds to step 476 to draw the analog waveform using an appropriate waveform generation routine, which does not form part of the present invention, using the XY number information available for the analog waveform is posed.

If it is determined that the waveform is a digital waveform, operation proceeds to step 478 to determine if there are other states in the waveform that are to be displayed. If there are other states in the waveform to be displayed, operation proceeds to step 480 to draw the digital state in question using the appropriate state definition from the state definition table generated during steps 426-430 . Operation then returns to step 478 to determine if there are any more states to be drawn and loops through steps 478 and 480 to generate the desired waveform until it is determined in step 478 that all states of the waveform were drawn.

When drawing of a particular waveform is complete, operation returns to step 470 to determine if there are any more waveforms to be drawn in that particular view. If there are other waveforms to be drawn in the view, operation proceeds to step 472 to add an axis and / or labels to the view for the new waveform, if necessary, and then moves to steps 474 through 480 over to plot the waveform. If it is determined during step 470 that there are no more waveforms to be drawn for that particular view, operation branches to step 482 to determine if there are multiple views to appear on this graphics screen. If additional views appear on the graphics screen, the operation returns to step 470 to determine if there are waveforms for the new view, and, if this is the case, it goes with the steps 472-480 continue to labels and draw an axis for such a waveform and draw the waveform. This sequence of operations continues until all waveforms have been drawn for an additional view, and then operation returns to step 482 to determine if there are more views to be drawn. If all views have been drawn, a NO output is obtained in step 482 , causing the operation to exit display step 468 for drawing.

If the operation exits the drawing display step 468 , it then proceeds to step 486 to wait for input. If an input is received in step 486 , operation proceeds to step 488 to determine whether the input was received from the keyboard (a user input) or from Epic (socket). If the input was received as a key input from the user or from Epic, operation proceeds to step 490 to find the command that was requested from the input. A command can be found either in the macros that were entered during step 448 or in internal commands that were stored as part of the Wavedit routine, first searching for commands in a macro, and then in the internal commands. If a command is found in step 492 , operation proceeds to step 494 to execute the 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 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 for display as shown in 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 operation returns to step 510 to determine if the command was executed correctly. If no command was found during step 492 , an error message is printed out in step 512 and operation continues to step 510 to determine if the command has been properly executed. If the command is not properly executed, as would be the case if one came to this step via step 512 , the operation does not look for 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 there is mouse input, the operation proceeds to step 518 to find the area on the display in which the mouse is located. In this situation, the mouse is typically in an area of a waveform that is displayed on the screen. The mouse can be provided with several buttons, for example three buttons, each button representing a different command that can be executed for the area over which the mouse is located. During step 520 , the next step in operation, the command to be executed as a result of the mouse button operation is determined and the command is executed. For example, such an instruction could be to place a point on the waveform to allow measurements to be made at the point and recorded. Measurements can also be taken in response to a command between the displayed point and a previously displayed point.

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 if the execution of a command in step 526 has ended, operation returns to step 486 to wait for additional entry. The operations described are repeated for additional entries until an exit command is detected as a result of either a keyboard or epic entry or a 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, the 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 (23)

1. A system for designing electrical devices with multiple design tools, at least some of which are incompatible with one another, comprising:

• a) an input device ( 24 , 26 ) for specifying the electrical device to be designed by the system,
• b) a memory device ( 28 ) for storing control macros, each relating to a specific design process ( 52 , 64 , 76 ) and indicating the properties of associated design tools ( 54-60 , 66-72 , 78-82 ), and
• c) a computing device ( 22 ) for automatically executing the design tools ( 54-60 , 66-72 , 78-82 ) specified in a control macro in the specified order, with
  • 1. a test device ( 22 ) for checking the system compatibility of each design tool ( 54-60 , 66-72 , 78-82 ) and
  • 2. a conversion device ( 22 ) for encapsulating incompatible design tools in such a way that all transfers from and to the incompatible design tool are checked and implemented.

2. System according to claim 1, characterized in that in the storage device ( 28 ) a list of all design tools ( 54-60 , 66-72 , 78-82 ) is stored and incompatible design tools are shown in the list. 3. System according to claim 1 or 2, characterized in that the control of the conversion device ( 22 ) is carried out on the basis of interpretation rules which are stored in the storage device ( 28 ) as part of the control macros. 4. System according to claim 3, characterized in that the interpretation rules for the input and output in encapsulated design tools for the appropriate control of the test device ( 22 ) and the conversion device ( 22 ) in the memory device ( 28 ) are provided separately. 5. System according to claim 4, characterized in that a device ( 22 ) is provided with which a decision is made as to whether interpretation rules for an incompatible design tool are to be stored in the storage device ( 28 ) for repeated use. 6. System according to one of the preceding claims, characterized in that the computing device ( 22 ) the automatic execution of a design process ( 52 , 64 , 76 ) associated design tools ( 54 - 60 , 66 - 72 , 78 - 82 ) based on the order specified in the assigned control macro. 7. System according to one of the preceding claims, characterized in that the control macros, including the rules of interpretation, on the basis of an expansion language to be interpreted, which is readable both for humans and for the computing device ( 22 ), in the memory device ( 28 ) are saved. 8. System according to any one of the preceding claims, characterized in that in the storage device ( 28 ) is stored a rule file which is written in an expansion language to be interpreted, and format conversion rules for controlling the conversion device ( 22 ) when handling development tools with incompatible exchange formats contains. 9. System according to any one of the preceding claims, characterized in that the computing device ( 22 ) is provided in order to carry out necessary name translations between development tools which are incompatible with respect to names used. 10. System according to one of the preceding claims, characterized in that the computing device ( 22 ) is provided in order to store with the control file ( 92 ) a list of name translations for the development tools which are incompatible with the name. 11. System according to claim 10, characterized in that the computing device ( 22 ) is provided for removing all invalid characters after a name translation. 12. System according to claim 10 or 11, characterized in that a computing device ( 22 ) is provided for cutting off a translated name to a suitable maximum length. 13. System according to one of claims 10 to 12, characterized in that the computing device ( 22 ) is provided for adding any required prefixes or suffixes to a translated name. 14. System according to one of claims 10 to 13, characterized in that the computing device ( 22 ) is provided for modifying a translated name such that the translated name is unique. 15. System according to one of claims 10 to 14, characterized in that the translated names can be stored in an alias file as a list of names in the storage device ( 28 ). 16. System according to any one of the preceding claims, characterized in that the computing device ( 22 ) translates names hierarchically depending on the development tools. 17. System according to any one of the preceding claims, characterized in that the input device ( 24 , 26 ) is also provided for the input of digital graphic information and digital states are stored in the storage device ( 28 ) for displaying digital graphic information. 18. System according to claim 17, characterized in that the digital states in the memory device ( 28 ) correspond to individual waveforms. 19. A method of coordinating different, at least partially incompatible, design tools when developing electrical devices with an automated system, according to which:

• a) control macros are stored in a memory device ( 28 ), each relating to a specific design process ( 52 , 64 , 76 ) and specifying the properties of assigned design tools ( 54-60 , 66-72 , 78-82 ),
• b) control macros are read out from the memory device ( 28 ) as a function of the electrical devices to be developed and the underlying design process ( 52 , 64 , 76 ), and
• c) a computing device ( 22 ) automatically activates the design tools ( 54-60 , 66- 72 , 78-82 ) specified in the control macro in the predetermined order, encapsulating incompatible design tools such that all transfers from and to the incompatible design tool when the design tool is activated be checked and implemented.

20. The method according to claim 19, characterized in that the encapsulation step comprises the following steps:

• a) checking several interpretation rules contained in the rule macro to determine whether a development tool requires encapsulation,
• b) Applying the interpretation rules in response to the transfer of an object to an incompatible development tool.

21. The method according to claim 19 or 20, characterized in that at least one of the control macros contains a rule by which the recovery of a new control macro from the memory device ( 28 ) is triggered. 22. The method according to any one of claims 19 to 21, characterized in that the following steps are carried out in the case of development tools which are not compatible with regard to a name:

• a) determining when a name that requires conversion is transferred between the development tools that are incompatible with the name,
• b) checking whether there is an entry for this name in a name list in the storage device ( 28 ) and, if there is an entry for the name, using the entry for converting the name, and,
• c) Use the appropriate rules for translating the name if there is no entry for the name.

23. The method according to any one of the preceding claims, characterized in that

• a) digital graphic information is used to represent waveforms to simulate the electrical system to be designed, and
• b) Stored state definitions are used to control the display for each successive state of a waveform being displayed.