Method and system for a unified process automation software system

[0002] The invention relates generally to software automation tools for controlling design and manufacturing processes. More particularly, the invention is a software method and system that automates the design and manufacturing process by driving multiple software application products though each application's graphical user interface. The system automates the design decision process and controls multiple software application products, running either sequentially or simultaneously and executing locally or remotely. The method and system can be used to automate any software application represented in a graphical user interface. In its present embodiment, the system and method automates design and manufacturing processes that use software application programs having a graphical user interface. In an alternative embodiment, the system and method automates the design and manufacture of electronic circuits.

[0003] Designing and manufacturing electronic circuits is a complex process. Because it is complex, the process is time consuming and costly. Rapid advances in materials and manufacturing technology require constant changes in design and manufacturing techniques. It is desirable to speed up the process to bring advanced technology products to market faster, while minimizing cost. Part of speeding up the process involves automation. While there currently exist a number of software application programs that automate individual parts of the design process, the overall design process is not automated and still requires constant manual intervention by the circuit designer. In addition, there is no automated way of building a model that represents the design process and also provides a means of executing the model to build the actual design. Being able to build a model that captures the overall resulting design can help speed up the process because it can be reused by other designers and used to educate others in the design process.

[0004] Automating design and manufacturing processes, in particular, automating the design electronic circuits is also an iterative process. First, the requirements are developed and input to one or more software design tools to create a functional description of the electronic circuit to be created. Next, the output of this step is input to tools that “implement” the circuit, that is, produce the circuit configuration of the functional description of the circuit. The functional description of the design is first synthesized to its logical elements and then to its physical implementation. The output from each phase for each part of the design can be used to run simulations to test the adequacy of the logical and physical aspects of the design with regard to function, speed, timing, size, or other criteria that are important to the operation of the circuit. Information from each phase of this process can also necessitate changes or corrections to previous steps in the process that may impact one or more subsections of the design. This process involves many individual designers and individual design tools to complete one pass of the product.

[0005] Design flow development and automation is an important way to speed up and improve the design process. Many types of software programs currently exist to automate aspects of the design process as much as possible. Most of these programs operate independently, on different computer platforms and have different operator interfaces. The data output from one tool often needs to be input to another tool and the input data needs to be precisely formulated and formatted before the parameters are passed from one tool to another. This process of capturing the data output from one tool and formatting it for use by another tool can be done by the designer either manually or by writing batch scripts that capture the data output from one software tool, convert the data to the correct format and input the converted data to another software tool. This process has to be repeated for each software tool used in the design and manufacture process. Even using batch scripts, these tools still remain stand-alone applications that execute independently and are not part of a formalized, centralized design process. Because of this, even though the existing tools may be individually automated, the overall design process model, along with the individual designer's knowledge and experience, is not automated. The process is further complicated because often many designers work together on one design, all of whom may gain their own knowledge and experience, but have to relearn other parts of the process.

[0006] Using conventional scripting to automate the actions of a software tool requires the user to learn the macro or scripting language, which are often custom or proprietary languages, associated with the tool. Because the composed scripts are textual rather than graphical, it is more difficult to understand their functionality and to make modifications. Therefore, the designer must understand and be knowledgeable not only in the design and manufacturing process, but also in the programming of multiple scripting languages. In the case of designing electronic circuits, for example, the parameters of the electronic circuit must first be defined, the software tools chosen to design the circuit, the batch script written, the input data parameters selected to be input to the tool by the batch script, and finally initialization of the script and software tool. This same process must then be repeated for each software tool used in the design process. In addition, if multiple tools are to be automated in sequence, another overall command script that invokes each software tool and its own batch script must then be constructed.

[0007] Automation of the individual software tools and the sequential activation of multiple software tools to create a “design process” is also limited because not all tools have a scripting language. Of those that do, generally only a subset of the functions of the tool may be controlled by the scripting or programmatic method of control. Often, conditional constructs to allow for different responses based on variations in input data are not available. Scripts normally initiate a process, and then operate in the background. As the user has no further control after initiation, scripts are usually run with the graphical mode of the application turned off, and no exchange of knowledge or interaction with the user occurs. Depending upon the compatibility of the software tools used, it may be impossible to use scripts to sequentially run the design process.

[0008] The present invention proposes to solve these problems by providing a software tool that operates the multiple design application tools needed for automating the design and manufacturing process. The method and system of the present invention automates the design process by providing a unified software automation program that initiates and runs the multiple software packages through their graphical user interface. Using the software package's graphical user interface has many advantages in automating the design process. The automation software program provides the interface to the user, which is programmed with the desired design process or steps, and initializes and runs the software packages that are used in the design and manufacture process. Any software package can be controlled independently of other packages while also being part of the overall sequential design process. The automation software program can also control multiple software applications running on multiple platforms. In particular, the automation software program can be used to automate the design and manufacture of electronic circuits.

[0009] The automation tool has two functional areas: flow automation and design management. Flow automation contains existing design processes, as represented by a design flow model and also produces new design flow models. Flow automation automates many of the repetitive tasks that previously had to be manually completed by the user. It gives the user an environment that drives all of the software applications needed in the design flow, automates as many functions as possible and tracks incremental progress. The design management function of the process automation software program captures the progress and status of the entire design process. The representation of the entire design process is output to the user in the form of a graphical interactive flow diagram that represents the design flow model. The model, which is an active sequential depiction of the design process, can be reused or modified by the designer and other design teams members to improve the design process or to correspond to advances in design and manufacturing technology.

[0010] Communicating with the software applications through their graphical user interface creates a standard interface protocol, unlike using conventional scripting languages. As a result, many software application specific dependencies are eliminated. The process automation software program itself has its own graphical user interface. The design process, as represented by a design flow model, is represented graphically on the user's screen. The process automation software program initiates the software applications and can be completely automated without requiring user intervention once the design flow model is initiated, either by a user or by a background software process. Alternatively, the process automation software program allows the designer to interact with the design process by providing status and allowing the designer to input commands through the program.

[0011] The process automation software program can control multiple software applications running on multiple platforms and supports a concurrent hierarchy of active design processes. This allows branches of the design flow that are not dependent upon each other to be executed at the same time. The process automation software program also supports a cross functional mode of interactive operation. For example, if the user wants to display different representations of a single connection in the electronic circuit, the user can select this action and the appropriate command is sent to each software application that is running. Cross functionality can be used in this way to create new solutions by combining the capability of multiple software applications. Linking software applications through their graphical user interfaces to form collaborative functions without requiring modification of the software application can increase the speed and quality of the design and manufacturing process. Because of interface problems using different tools, this has not usually been possible prior to communicating through the graphical user interface of the software application.

[0012] The present invention comprises a method for automating a design and manufacturing process, in a computer program running on a computer processor having an automation software program executing on the computer processor, programmed with a design and manufacturing process command flow. The automation software program through the command flow is allowed to initiate and monitor the execution of a plurality of design and manufacturing software application programs, each software application program having a graphical user interface. The initiating and monitoring of the execution of the software application programs is by communicating through the graphical user interface of each software application. The software application programs may be executed on the same computer processor as the automation software program. Alternatively, the software application programs may be executed on a plurality of computer processors. The software application programs may be initiated, executed and monitored in a preprogrammed sequence. A graphical user interface to the automation software program may be provided along with a visual representation of the design and manufacturing process command flow of the automation software program, through the graphical user interface of the automation software program. The user may selectively change the automation software program command flow by inserting user commands, inserting input data, changing the order of the initiation of the software application programs, deleting software application programs, and adding software application programs. Feedback to the user of the status of the operation of the process command flow and the status of each software application while it is being initiated and executing, along with the output data and status after each software application has completed running may be provided to the user. The visual representation of the process command flow may be a flowchart representing the command flow displayed on the graphical user interface. The status and output data may be displayed to the user on the flowchart. In an alternative embodiment, the design and manufacturing process is for the design and manufacture of an electronic circuit. Input and output data may be electronic circuit data.

[0013] In a preferred embodiment, a process automation software program may be built comprising a design flow process model, the model is programmed with a series of command steps, the steps including the execution order of the software application programs. The program includes a display interface controller that simulates the graphical user interface of the software application program and sends graphical user interface commands to a display server for the software application program and a process controller which executes the design flow process model, controls the order of the command steps and communicates the command steps to an application controller, tailored for each software application program. The application controller translates the process control commands into graphical user interface commands and sends the commands to the display interface controller for communication to the display server for the software application program. An application monitor monitors the status of the software application program being executed and communicates the status to the application controller and to the process controller. The method may include running the process automation software program by executing the design flow process model through the process controller, which initiates the design flow process, controls the order of the command steps and communicates the command steps to the application controller. The application controller translates the command steps into graphical user interface commands and sends the commands to the display interface controller. The display interface controller sends the graphical user interface commands to a display server for the software application program. The software application program is initiated and executed the by means of the graphical user interface commands. Graphical interface commands from the display server are received at the display interface controller. The application monitor monitors the status of the software application program being executed and communicates the status of the software application program to the application controller and to the process controller. The design flow process model, with its series of command steps, may be represented to the user through the graphical user interface as a flow diagram comprising selectable symbols that represent the software application programs, the command steps, input data, and output data. A new process automation software program may be built by allowing the user to selectively change the flow diagram by deleting, reordering or manipulating the selectable symbols via the automation software program's graphical user interface. The status and progress of the automation software program and the status of the software application programs is displayed to the user via the flow diagram of the flow process model. The status and progress of the automation software program and the status of the software application programs may be shown by means of colors displayed on the flow diagram.

[0014] A new process automation software program may be built by allowing the user to selectively change the flow diagram by adding software application programs from a library of stored programs via the automation software program's graphical user interface. A new process automation software program may be built by allowing the user to selectively enter design and manufacture problem parameter data into the process automation software program via the automation software program's graphical user interface. The process automation program may be run after initiation without requiring action by the user. Alternatively, while running the process automation program, the user may stop the design flow process, change the order of the process and enter input data to be used in the design flow process.

[0015] In an alternate embodiment, the system for automating the design and manufacturing process of an electronic circuit, comprises a specially programmed computer having a memory means, a processor means and a graphical user interface means. The memory means stores a plurality of design and manufacture software application programs, each having a graphical user interface; design flow process models; design and manufacture input data to be input to the software application programs; and design and manufacture output data to be output from the software application programs. The processor means builds a process automation software program comprising the design flow process model, the model is programmed with a series of command steps, the steps including the execution order of the software application programs; a display interface controller that simulates the graphical user interface of the software application program and sends graphical user interface commands to a display server for the software application program; a process controller which executes the design flow process model, controls the order of the command steps and communicates the command steps to an application controller, tailored for each software application program. The application controller translates the process control commands into graphical user interface commands and sends the commands to the display interface controller for communication to the display server for the software application program. An application monitor monitors the status of the software application program being executed and communicates the status of the software application program to the application controller and to the process controller. The processor means executes the process automation software program by executing the design flow process model, which in turn executes the software application programs by initiating and communicating with the software application program through their graphical user interface. The graphical user interface to the automation software program provides the means for displaying to the user the status and progress of the execution of the automation software program and the status of the software application programs while each program is being initiated, executing and has completed. The design flow process model is represented as a flow diagram displayed on the graphical user interface comprising selectable symbols that represent the software application programs, the command steps, input data, and output data. The user is allowed to selectively change the flow diagram by adding, deleting, reordering and manipulating the selectable symbols via the graphical user interface.

[0016] These and other features, aspects, and advantages of the present invention will become better understood with regard to the following description, appended claims, and accompanying drawings where:

[0017] FIG. 1 is a system block diagram of the system for automating the design and manufacturing process in accordance with the present inventive concept.

[0018] FIG. 2 is a preferred embodiment of process control automation software architecture of the present system for automating the design and manufacturing process in accordance with the present inventive concept.

[0019] FIG. 3 is another representation of the preferred embodiment of the process control automation software architecture of the present system for automating the design and manufacturing process in accordance with the present inventive concept.

[0020] FIG. 4 is a flowchart for the operation of the process automation software program in accordance with the present inventive concept.

[0021] FIG. 5 is a flowchart for building the design flow process model of FIG. 4 in accordance with the present inventive concept.

[0022] FIG. 6 is a flowchart for executing the design flow process model of FIG. 4 in accordance with the present inventive concept.

[0023] FIG. 7 is an exemplary flow model of the process automation software system for controlling one section of the design process of an electronic circuit in accordance with the present inventive concept.

[0024] FIG. 8 depicts the physical synthesis model flow of FIG. 7 in greater detail in accordance with the present inventive concept.

[0025] FIG. 9 depicts the control application execution of FIG. 8 in greater detail in accordance with the present inventive concept.

[0026] Turning now to FIG. 1, system block diagram of the system for automating the design and manufacturing process of an electronic circuit 100 is shown. The process automation software system 101 interfaces with a user 102 and is initiated and controlled by the user 102 through a graphical user interface 108. Alternatively, a background command software program can initiate and control the process automation software system 107. The process automation system 101 interfaces to the design and manufacturing software application programs 1 through N 104-106 through a pseudo graphical user interface 103. The pseudo graphical user interface 103 does not have to be displayed to a user, but operates in the background as a pseudo display interface. Communication through the application program's graphical user interface 103 provides a standard interface for communication with the process automation software system 101.

[0027] Turning now to FIG. 2, a preferred embodiment of process control automation software architecture 200 of the present system for automating the design and manufacturing process of an electronic circuit is shown. The process automation software system 101 of FIG. 1 contains a process controller 202. The process controller 202 contains the design and manufacturing process command flow which contains the software program and commands to initiate and control the design process, including the commands to activate the design and manufacturing application program 203. The process controller 202 interfaces and communicates with the application controller 204, which is tailored for each software application program. The application controller 204 stores the user events for each discrete action of the particular application 203, to be used as needed for a given process command flow initiated by the process controller 202. Each application controller 204 contains the characterization of the application, that is all of the application's discrete actions and corresponding events are logged, forming a translation table or map. An example of a discrete action would be functional calls in a programming language, such as opening a file. An example of a corresponding event for the discrete action of opening a file might be the user actions via a graphical user interface to open the file, such as selecting a pull down menu, clicking on it, selecting a file, and selecting open. Using the stored user events for discrete actions as needed, the application controller 204 translates the process control commands from the process controller 202 into graphical user interface commands and sends the commands to the display interface controller 205. The display interface controller 205 in turn sends the graphical user interface commands to a pseudo display server for the application 206. An application monitor 207 monitors the status of the application 203 being executed and communicates the status to the application controller 204 and to the process controller 202. In the architecture of FIG. 4, the application program and its display server and the process automation software system may reside within one computer processor or may alternatively reside in multiple computer processors.

[0028] FIG. 3 shows another representation of the preferred embodiment of process control automation software architecture 300 of the present system for automating the design and manufacturing process of an electronic circuit. In FIG. 3, the application program 310 and its display 313 physically reside in a different computer processor, computer B, from the process controller 304, application controller 305, process display 310 and pseudo display interface 303 which reside in computer A. The application monitor 307 may reside in either computer. In computer B, the design and manufacture software application program 314 and the application's display 313 is directed to the pseudo display server 312 running on computer B that preprocesses and sends the display output to the pseudo display client 303 on computer A. When the process automation software program is started, the desired process flow model, in the form of a graphical flow diagram is loaded and displayed. The user clicks on the graphical flow diagram, selecting to execute a function or hierarchy of functions from the flow diagram. This is a section of the process or the complete process to be done. The automation software program begins the sequence of steps in the process. The required applications and monitoring tools are started either locally or on a computer linked through a network or Internet interface. The process diagram indicates specific actions to be taken. The automation tool communicates with the pseudo display interface 303. The events are sent, as if a user were actively entering them, to the application 314. The applications response to the events is studied by the application monitor 307 and to a lesser extent by detecting that a change in the display has occurred when expected. The application monitor 307 communicates specific information regarding the state of the application in use 314 and is output to the process controller 304 to provide the necessary information to effect the next course of action to be taken in the process. The process controller 304 attempts to reconcile problems encountered. If unexpected problems arise during the process, as for example from variances in design conditions, tools, input data, they can be flagged to the user and the design process can continue under the direction of the user. If a solution path was not programmed into the flow model and a solution could not be found by the process controller 304, that branch of the process is paused and the color of the graphical element in the flow model diagram is turned red to notify the user. Other means of user notification may also be used.

[0029] FIG. 4 shows a flowchart for the operation of the process automation software program 400. Upon user initiation, the program checks to see if a new design flow model is to be built, or if an existing model will be used 401. If a new model is to be built, the program allows the user to build a design flow process model 402 and stores the model in a model library 403. The design flow process model is then executed 404 using either the design flow process model just built 402 or an existing model. The status of the execution is output to the user via the user's graphical user interface 407. If execution is not complete 405, and an error has occurred 408, an error message is displayed to the user 409. In either case, if the user reinitiates the design flow process model 410, step 404 is repeated and the process continues. If execution of the process model is complete 405, the results are output to the user via the graphical user interface 406.

[0030] Turning now to FIG. 5, the Build Design Flow Process Model 402 of FIG. 4 is shown in greater detail. If the model is a new one 501, command flows to initiate and monitor software application programs for designing and manufacturing electronic circuits are built 502 and the commands are stored for execution by the process controller in a library of design flows 504. For new software applications, a map is built of discrete actions for the software application 503 and stored in the application controller 505. If the model is not a new model 501, then changes are made to an existing model 506. If the change is to an operator command 507, input data 508, order of the command execution 509 or adding a new software application 510, the changes are made in the command flow 511-513 and the new command flow is stored in a library of flows 504. If a new software application has been added 510, the new software application is inserted into the command flow 514 and processing continues at step 503.

[0031] Turning now to FIG. 6, the Execute design Flow Process Model step 404 of FIG. 4 is shown in more detail. The process controller, application controller and application monitor are initialized 601. The display interface controller, pseudo display server, application display and application are initialized 602. The process controller executes the command flow by sending commands to the application controller 603. The application controller translates the commands and discrete actions from its map into graphical user interface commands 604. The application controller sends graphical user interface commands to the display interface controller 605. The display interface controller sends commands to and receives output from the pseudo display server 606. The pseudo display server interfaces with the software application which executes 607. As this is occurring, the application monitor monitors the status of the application and if its detects that the application is not executing 608, it sends an error message to the process controller and the application controller 609.

[0032] FIG. 7 shows an exemplary flow model of the process automation software system for controlling one section of the design process. Creating a functional specification for a chip usually begins with the customer and supplier creating the chip specification 700 by determining the functionality needed, size and cost constraints. The next step is determining the chip's logical and physical implementation 701. Size and timing estimations are done 702. The design task is rationally divided, a design hierarchy is created, and the team begins working on the more detailed implementation in individual sections. To translate large amounts of the desired function into the discrete logical elements efficiently, the functional description is described in a programming language at the register transfer level 706, which can be process independent, and is then synthesized into its process specific logical components or block 707.

[0033] Turning now to FIG. 8, the primary output from the logical synthesis software is a schematic or net list 708 which describes all of the logical components and how they are connected. The net list file along with timing constraints 709 is used to physically synthesize the design. This is done by a physical synthesis software application, often referred to as “Place and Route” software, where the physical elements referenced by the logical elements are positioned, placed, and the devices connected.

[0034] In FIG. 8, the physical synthesis model flow (Step 710 of FIG. 7), is shown in greater detail. In the physical synthesis as shown in FIG. 8, the following operations are performed by the process automation software program. Available computer resources are located 811 to run the Physical Synthesis software application program. The software application program is chosen from a set of vendor programs that will physically synthesize the circuit. The computer resources selected may be the same computer on which the process automation software program is executing, or a computer specified on a network, or a computer found available on the network by checking a set of criteria such as CPU type, speed, or current load. A check is made to determine if the Physical Synthesis software application program is installed and licensed on the computer selected 812. The application monitor is started on the host machine 813 and reports the execution status of the design process to the process controller shown in FIG. 2 as 202. Any input data needed for the Physical Synthesis application program is retrieved 814. The Physical Synthesis application program is initiated 815. The process controller sends commands through the application controller and the display interface to the pseudo display server for the application and finally to the Physical Synthesis application program, thereby controlling the application's execution 816. The application's performance and output is monitored and analyzed 817 so that appropriate action can be taken by the process controller to adjust actions as needed 818. For example, if the physical synthesis software application program failed to connect all of the devices in the circuit, corrective action would be taken. But if, more than half of the devices were not connected, an error message would be sent to the operator. If the process completes without error, the output is saved 819 and the application 820 and monitor are shutdown 821.

[0035] Turning now to FIG. 9, the control application execution step 816 of FIG. 8 is shown in greater detail. Expanding the control application's execution 816, the following actions are executed to simulate user control and automate the application. Technology information is read in to the application 900. This file contains the rules required to manufacture the part in a given facility such as the allowed widths and spacing for example. Then the physical elements that the circuit is comprised of, macro blocks and functional primitives such as nand, nor, xor functions are input 901. The logical net list describing which device to use and how they are connected is input 902. The connections between the devices may have specific timing constraints that needed to be input 903. These will be translated into physical routing length in the given technology and hence influence the placement of the devices. The physical constraints are input 904 such as information from the prior full chip specification such as the locations of the connections at the boundaries, size and shape of this section of the design.

[0036] The physical constraint step 904 is now shown in further detail. Since the application believes it is interacting with an operator via a graphical user interface, appropriate display commands, such as mouse clicks and function keys, must be sent to the application. The application's position 914 must be ascertained for an offset to be applied to the display commands to be sent. The focus for the window is set so that the intended application receives the display commands 915. Then the display command, such as a mouse click may be sent 916. The applications display is updated 917 in response to many user input display commands or events. If a display update is expected, the display update is monitored for in the pseudo display interface (205 in FIG. 2) by the application controller (204 in FIG. 2). The change in display indicates the application is responding and additional mouse clicks are sent 920 and the process is repeated 922 and 923. For example, in simulating a user navigating through a pull down menu there may be several click and monitor combinations needed 916-923. If textual information is needed, text strings are sent 921 along with mouse clicks 922. Any application information written to a log file is checked by the application monitor and the information is relayed to the main process controller 924. The program status is displayed to the user. On the user's display, the color of the design flow icon is changed to indicate the status 925.

[0037] Macro cells comprising the nonstandard elements such as RAM and ROM are placed into the prescribed area 905. The distribution of power to all of the components is planned out and adjustments made to the area used for device placement 906. Further modification to that area are made as portions of the power distribution scheme are routed, physically connected 907. With this space reserved the standard devices called for in the net list may be placed in the design 908. Next buffers to insure clock performance can be inserted relative to the device locations 909. The congestion is now analyzed to see if further modifications need to be made to the placement to enable all of the connections to be made among the devices 910. If needed, the allowed area for placement is adjusted and the process back to macro placement 905 is repeated depending on the extent of the changes. After achieving a plausible placement, the power routing is completed 911 and the detailed route performed 912. If all criteria have been met, the physical geometry created by this section of the flow model process is stored in the main design's data management structure 913. This section of the design process is also graphically represented by the process automation software program to indicate the status to the user through the design flow model.

[0038] Turning back to FIG. 7, the physical synthesis of the block 710 is now completed. The block's correlation, logical to physical and its adherence to the rules of the fabrication technology is verified 711. The physical geometry is passed to another software application for timing analysis 712. Ideally all of the steps described repeat or iterate, until all conditions are met. The final phase of the process is a full verification of the design 713 by another software application and the design is then prepared for mask generation 714. Each step in the process as shown in FIG. 7 is shown graphically at a high level on the user's display. As each step executes or if the user selects a step, the more detailed process as shown in FIGS. 8 and 9 is displayed to the user.