Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20060101368
Kind Code
A1
Kesarwani; Ravi ; et al.
May 11, 2006
Distributed electronic design automation environment
Abstract
PCB Logical design data is stored in a database according to a connectivity-based data model. Circuit functional blocks, inputs and outputs of functional blocks, and signals are stored as separate data structures. Those structures may be edited by users at separate clients during concurrent editing sessions. Profile data for each of multiple users specifies logical design data elements accessible by, and PCB design software to be provided to, that user. The PCB design software may be plug-ins executable within a web browser at a client, and the client computers may communicate with the database via the Internet. Layout data may also be stored in the database, with elements of the layout data mapped to elements of the logical design data. Constraint data may also be stored in the database, with elements of the constraint data being mapped to elements of the layout data.
Inventors:
Kesarwani; Ravi
(Worcester, MA)
, Mankin; Richard
(Medway, MA
)
, Maxwell; Ronald
(Stow, MA
)
, Mental; Kenneth
(Mendon, MA
)
, Potts; Henry
(Ft. Collins, CO
)
, Tera; Reddy
(Milford, MA
)
Correspondence Name and Address:
1001 G STREET N W SUITE 1100
BANNER & WITCOFF
WASHINGTON
DC
20001
US
Series Code:
960793
Filed:
October 8, 2004
U.S. Current Class:
716/011
U.S. Class at Publication:
716/011
Intern'l Class:
G06F 17/50 20060101 G06F017/50
Claims
1. A method for editing a printed circuit board (PCB) design, comprising: storing logical design data for a PCB in a database, wherein the logical design data is organized according to a connectivity-based data model; storing profile data for each of plural users, the profile data for each user specifying logical design data elements accessible by that user and design software to be provided to that user for accessing or editing logical design data; transmitting, in accordance with the stored profiles, elements of the logical design data and one or more PCB design software programs to clients used by at least some of the plural users; receiving logical design data edits from the clients, each of said edits comprising at least one of adding, deleting or modifying one or more logical design data elements; and applying the received edits to the logical design data stored in the database.
2. The method of claim 1, wherein the logical design data is organized according to a connectivity-based data model in which circuit functional blocks, inputs and outputs of functional blocks, and signals are stored as separate data structures, and the separate data structures may be edited by users at separate clients during concurrent editing sessions conducted at said separate clients.
3. The method of claim 1, wherein the profile data for each user further specifies the degree to which the user may modify logical design data accessible by that user.
4. The method of claim 1, wherein said storing profile data further comprises: storing a first user profile specifying a first collection of logical design data elements accessible by a first user, and storing a second user profile specifying a second collection of logical design data elements accessible by a second user, and further comprising: permitting the first user to modify logical design data elements of the first collection; and preventing the second user from modifying at least a portion of the logical design data elements of the first collection.
5. The method of claim 1, wherein said transmitting further comprises transmitting logical design data and one or more PCB design software programs to a client computer upon initiation of a logical design data editing session by one of the plural users.
6. The method of claim 1, wherein said one or more PCB design software programs comprise one or more plug-ins executable within a web browser program.
7. The method of claim 1, wherein said transmitting comprises transmitting logical design data elements and one or more PCB design software programs to clients via the internet, and said receiving comprises receiving logical design data edits from clients via the internet.
8. The method of claim 1, further comprising: receiving an indication that a first of the plural users has selected a logical design data element accessible by the first user and by a second of the plural users; upon receiving said indication, preventing the second user from deleting or modifying the selected element.
9. The method of claim 1, further comprising: caching data describing at least one of a modification or deletion of a data element selected by a first of the plural users; subsequently receiving an instruction from the first user to update the logical design data in the database to include the at least one of a modification or deletion; updating the logical design data in the database in accordance with the subsequently-received instruction; and transmitting an indication of the update to a second of the plural users.
10. The method of claim 1, further comprising: receiving from a first of the plural users a request to edit one or more logical design data elements; sending a change request message to others of the plural users identifying the requested edit and offering the others of the plural users the ability to approve the requested edit; and upon receiving approvals from at least a portion of the plural users receiving the change request message, automatically updating the database to include the requested edit.
11. A method for editing a printed circuit board (PCB) design, comprising: initiating at a first client a first session to edit logical design data for a PCB, said logical design data being stored in a database and organized according to a connectivity-based data model; receiving, in accordance with profile data for one of plural users, a first collection of elements of the logical design data and PCB design software for accessing or editing elements of the logical design data; transmitting logical design data edits from the first client, each of said edits comprising at least one of adding, deleting or modifying one or more received logical design data elements; and receiving, from the database during a subsequent editing session, a second collection of logical design data elements, the second collection reflecting application to the database of the transmitted logical design data edits.
12. The method of claim 11, wherein the logical design data is organized according to a connectivity-based data model in which circuit functional blocks, inputs and outputs of functional blocks, and signals are stored as separate data structures, and the separate data structures may be edited by users at separate clients during concurrent editing sessions.
13. The method of claim 11, wherein the profile data for each user further specifies the degree to which that user may modify logical design data accessible by that user.
14. The method of claim 11, wherein said receiving in accordance with profile data further comprises receiving the first collection of logical design data elements and the one or more PCB design software programs upon initiation of the first editing session.
15. The method of claim 11, wherein said one or more PCB design software programs comprise one or more plug-ins executable within a web browser program.
16. The method of claim 11, wherein said receiving in accordance with profile data comprises receiving the first collection of logical design data elements and the one or more PCB design software programs via the internet, and said transmitting comprises transmitting logical design data edits via the internet.
17. The method of claim 11, further comprising: receiving an indication that a user at a second client has selected a logical design data element accessible by the user at the first client; and upon receiving said indication, preventing the user at the first client from deleting or modifying the selected element.
18. The method of claim 11, wherein said transmitting further comprises transmitting data describing at least one of a modification or deletion of a selected data element, and subsequently transmitting an instruction to update the logical design data in the database to include the at least one of a modification or deletion.
19. A machine-readable medium having stored thereon data representing sequences of instructions which, when executed by a processor, cause the processor to perform steps comprising: storing logical design data for a PCB in a database, wherein the logical design data is organized according to a connectivity-based data model; storing profile data for each of plural users, the profile data for each user specifying logical design data elements accessible by that user and design software to be provided to that user for accessing or editing logical design data; transmitting, in accordance with the stored profiles, elements of the logical design data and one or more PCB design software programs to clients used by at least some of the plural users; receiving logical design data edits from the clients, each of said edits comprising at least one of adding, deleting or modifying one or more logical design data elements; and applying the received edits to the logical design data stored in the database.
20. The machine-readable medium of claim 19, wherein the logical design data is organized according to a connectivity-based data model in which circuit functional blocks, inputs and outputs of functional blocks, and signals are stored as separate data structures, and the separate data structures may be edited by users at separate clients during concurrent editing sessions conducted at said separate clients.
21. The machine-readable of claim 19, wherein the profile data for each user further specifies the degree to which the user may modify logical design data accessible by that user.
22. The machine-readable of claim 19, wherein said storing profile data further comprises: storing a first user profile specifying a first collection of logical design data elements accessible by a first user, and storing a second user profile specifying a second collection of logical design data elements accessible by a second user, and comprising further instructions for performing steps comprising: permitting the first user to modify logical design data elements of the first collection; and preventing the second user from modifying at least a portion of the logical design data elements of the first collection.
23. The machine-readable medium of claim 19, wherein said transmitting further comprises transmitting logical design data and one or more PCB design software programs to a client computer upon initiation of a logical design data editing session by one of the plural users.
24. The machine-readable medium of claim 19, wherein said one or more PCB design software programs comprise one or more plug-ins executable within a web browser program.
25. The machine-readable medium of claim 19, wherein said transmitting comprises transmitting logical design data elements and one or more PCB design software programs to clients via the internet, and said receiving comprises receiving logical design data edits from clients via the internet.
26. The machine-readable medium of claim 19, comprising further instructions for performing steps comprising: receiving an indication that a first of the plural users has selected a logical design data element accessible by the first user and by a second of the plural users; upon receiving said indication, preventing the second user from deleting or modifying the selected element.
27. The machine-readable medium of claim 19, comprising further instructions for performing steps comprising: caching data describing at least one of a modification or deletion of a data element selected by a first of the plural users; subsequently receiving an instruction from the first user to update the logical design data in the database to include the at least one of a modification or deletion; updating the logical design data in the database in accordance with the subsequently-received instruction; and transmitting an indication of the update to a second of the plural users.
28. The machine-readable medium of claim 19, comprising further instructions for performing steps comprising: receiving from a first of the plural users a request to edit one or more logical design data elements; sending a change request message to others of the plural users identifying the requested edit and offering the others of the plural users the ability to approve the requested edit; and upon receiving approvals from at least a portion of the plural users receiving the change request message, automatically updating the database to include the requested edit.
29. A machine-readable medium having stored thereon data representing sequences of instructions which, when executed by a processor, cause the processor to perform steps comprising: initiating at a first client a first session to edit logical design data for a PCB, said logical design data being stored in a database and organized according to a connectivity-based data model; receiving, in accordance with profile data for one of plural users, a first collection of elements of the logical design data and PCB design software for accessing or editing elements of the logical design data; transmitting logical design data edits from the first client, each of said edits comprising at least one of adding, deleting or modifying one or more received logical design data elements; and receiving, from the database during a subsequent editing session, a second collection of logical design data elements, the second collection reflecting application to the database of the transmitted logical design data edits.
30. The machine-readable medium of claim 29, wherein the logical design data is organized according to a connectivity-based data model in which circuit functional blocks, inputs and outputs of functional blocks, and signals are stored as separate data structures, and the separate data structures may be edited by users at separate clients during concurrent editing sessions.
31. The machine-readable medium of claim 29, wherein the profile data for each user further specifies the degree to which that user may modify logical design data accessible by that user.
32. The machine-readable medium of claim 29, wherein said receiving in accordance with profile data further comprises receiving the first collection of logical design data elements and the one or more PCB design software programs upon initiation of the first editing session.
33. The machine-readable medium of claim 29, wherein said one or more PCB design software programs comprise one or more plug-ins executable within a web browser program.
34. The machine-readable medium of claim 29, wherein said receiving in accordance with profile data comprises receiving the first collection of logical design data elements and the one or more PCB design software programs via the internet, and said transmitting comprises transmitting logical design data edits via the internet.
35. The machine-readable medium of claim 29, comprising further instructions for performing steps comprising: receiving an indication that a user at a second client has selected a logical design data element accessible by the user at the first client; and upon receiving said indication, preventing the user at the first client from deleting or modifying the selected element.
36. The machine-readable medium of claim 29, wherein said transmitting further comprises transmitting data describing at least one of a modification or deletion of a selected data element, and subsequently transmitting a separate instruction to update the logical design data in the database to include the at least one of a modification or deletion.
37. A method for editing a printed circuit board (PCB) design, comprising: storing logical design data for a PCB in a database, wherein the logical design data is organized according to a connectivity-based data model in which circuit functional blocks, inputs and outputs of functional blocks, and signals are stored as separate data structures, and the separate data structures may be edited by users at separate clients during concurrent editing sessions.
38. The method of claim 37, wherein the logical design data is organized according to an object-oriented data model.
39. The method of claim 38, wherein the data model comprises a first object type corresponding to a functional block of an electronic circuit, the data model includes a second object type corresponding to at least one of an input to and output from a first type object, the data model includes a third object type corresponding to a signal.
40. The method of claim 39, wherein the data model comprises a fourth object type corresponding to a specific connectivity representation of a functional block corresponding to a first type object, the data model comprises a fifth object type, fifth type objects being instantiations of first type objects, and the data model associates each of a plurality fourth type objects with one or more fifth type objects and with one or more third type objects.
41. The method of claim 40, wherein the data model includes a sixth object type, sixth type objects being instantiations of second type objects, and the data model associates first type objects with one or more second type objects and associates fifth type objects with one or more sixth type objects.
42. The method of claim 38, wherein said logical design data includes scripted design data objects, each of said scripted design data objects including at least one data object and at least one associated script, said associated script being executable to automatically modify said at least one data object.
43. A method of editing a printed circuit board (PCB) design, comprising: storing logical design data for a PCB in a database; and editing said logical design data at remotely located clients executing editing software within web browser software.
44. A method for editing a printed circuit board (PCB) design, comprising: storing logical design data for a PCB in a database; storing layout data for the PCB in the database, wherein elements of the layout data are mapped to elements of the logical design data; and automatically modifying layout data elements in response to edits to logical design data elements.
45. The method of claim 44, further comprising: storing constraint data for the PCB in the database, wherein elements of the constraint data are mapped to elements of the layout data.
46. A method for editing a printed circuit board (PCB) design, comprising: storing logical design data for a PCB in a database; storing lifecycle state information for elements of the logical design data; receiving from a first of plural users a request to edit one or more logical design data elements; determining the lifecycle state for the one or more logical design elements; requiring a change request based on the determined lifecycle state; sending a change request message to others of the plural users identifying the requested edit and offering the others of the plural users the ability to approve the requested edit; and upon receiving approvals from at least a portion of the plural users receiving the change request message, automatically updating the database to include the requested edit.
47. The method of claim 46, further comprising: automatically invoking a change request user interface upon determining the lifecycle state to have a specified value.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of U.S. patent application Ser. No. 10/935,749, titled "Distributed Electronic Design Automation Environment" and filed on Sep. 8, 2004, the content of which is incorporated by reference herein.
COPYRIGHT NOTICE
[0002] A portion of the disclosure of this patent document may contain material which is subject to copyright protection. To the extent that it does, the copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright.COPYRGT. 2004, Mentor Graphics Corp., All Rights Reserved.
FIELD OF THE INVENTION
[0003] This invention relates to the field of electronic design automation tools, and more specifically, to concurrent design activities distributed among multiple users.
BACKGROUND OF THE INVENTION
[0004] As used throughout this specification and claims, a "design" for an electronic device generally refers to information needed to construct that device. As can be appreciated from this broad definition, an electronic design has numerous aspects. Logical aspects of a design (sometimes known as a logical design or the "front end" design) include the identification of various functional elements. These functional elements may be specific electronic components (e.g., particular microprocessors, memory chips, and other components). These functional elements may also be more generic (e.g., an AND gate, an OR gate, a multiplexer, a resistor or capacitor having a certain resistance or capacitance value, etc.). The logical aspects of a design also include interconnections between inputs and outputs of these functional elements. Physical aspects of a design (also known as the "layout" or the "back end" design) include the actual size and location of various physical components associated with logical design elements. Notably, there is not necessarily a one-to-one correspondence between logical and physical elements. For example, a logical design element such as a gate must be implemented as an actual physical component. However, available chips and other physical components may have multiple "slots," each of which contains a separate gate or other element having its own input and output pins. A single physical component may thus correspond to multiple logical elements. There are numerous other logical and physical design elements. In many cases, a particular element in the logical domain will have no directly corresponding element in the physical domain, and vice versa.
[0005] Traditionally, the schematic diagram has been the basis for electronic design. More specifically, front end designers often record the various functional elements of the logical design and the necessary interconnections on one or more graphical schematic diagrams. After completing the logical design, the front end designers then provide one or more sheets of schematic diagrams to the back end designers. The front end designers might also include a netlist (i.e., a list of all signals in the logical design and the logical elements connected to each signal) and information regarding constraints (e.g., restrictions on the manner in which components and nets can be placed and/or connected). The netlist is typically a separate document (or computer file), and the constraint information might be annotated onto the schematic or provided as a separate document. Using this front end information, the back end designers determine the actual placement of physical components on one or more circuit boards and route the physical connections (e.g., conductive circuit board traces) between the pins of those components. Frequently, the back end designers must also assign elements from the schematic to a particular physical component (e.g., assigning a gate to a slot of a chip). In some cases, the back end designer may add a physical component (e.g., a filter capacitor) to the layout design that is not represented on the schematics, or may make other types of changes that may implicitly affect the logical design.
[0006] This traditional approach to electronic design presents numerous problems. In the past, typical designs included numerous Small Scale Integration (SSI) and/or Medium Scale Integration (MSI) parts, and perhaps a few Large Scale Integration (LSI) parts. The SSI and MSI parts would typically have a limited number of pins, and the LSI parts might have on the order of 100 pins. With such designs, a schematic can be a useful representation. As designs have evolved, however, the schematic diagram has become less valuable. For example, current designs may include LSI or Very Large Scale Integration (VLSI) parts having up to thousands of pins. Such parts can be difficult or impossible represent on a single sheet of a schematic diagram. Drawing pieces of the same part on multiple drawing sheets can be tedious, and the resulting diagram is often confusing. Similarly, modern designs often have complex patterns of interconnections which run throughout the entire design, and must thus span numerous sheets of schematic diagrams. Following such interconnection patterns across multiple sheets is also tedious and confusing.
[0007] A schematic-driven design approach has numerous other shortcomings. Using traditional schematic-driven methods, front end and back end design are generally performed as serial processes with limited communication between the two. However, the complexity of electronic designs and market pressures to rapidly complete designs are continuing to increase. In such an environment, it is beneficial (and often necessary) for front and back end design tasks to be performed concurrently. In turn, this requires rapid (and sometimes frequent) exchange of design information between front and back ends. Existing methods inhibit such a rapid exchange, as entire design files (e.g., schematics, constraint data, net lists, etc.) must be transferred and then converted to an appropriate form. For example, a back end designer receiving an updated schematic must identify what symbols and/or interconnections have changed and then determine whether a part must be added, a trace added or re-routed, etc.
[0008] Traditional methods can also inhibit collaboration among multiple front-end designers. Separating a design project into manageably-sized portions and assigning those portions to different designers can be difficult. Moreover, managing design data as a collection of design data computer files limits the granularity with which design data can be "locked" to prevent conflicting edits by multiple users. File-based systems pose additional challenges for designers wishing to collaborate on a project. For example, a designer may often be unsure whether he or she has all of the files needed for a particular project. This also makes transfer of a design between designers a time-consuming process.
[0009] Traditional electronic design methods are increasingly less valuable in other ways. In addition to often having more LSI and VLSI parts, modern designs are becoming increasingly dense. In other words, designs must fit into increasingly smaller spaces. In turn, this requires printed circuit boards (PCBs) to have more and more layers. Modern designs also have increasing numbers of high speed signals. These factors make constraints upon the physical design more and more critical. Both front and back end designers must be able to track, access and/or modify these constraints. However, existing methods for constraint management become less useful as designs become more complex. Constraint data must often be synchronized among multiple users in real time, and waiting for an updated schematic (with revised constraint annotations) or a separate constraint document can require too much time. More important, lack of an automated system for synchronizing constraint data may result in a failure to effectively communicate constraint data between front and back ends.
[0010] Traditional design methods present other challenges for numerous persons working in parallel, particularly when those persons are in widely dispersed locations. For example, logical and/or layout design may be performed by teams of engineers working in different cities (or even in different countries). Various design tasks may be outsourced to other companies. Still other groups (e.g., manufacturing, purchasing) located in other locations may have need for the information contained in the layout and/or logical design data. Ensuring that all of these groups have the appropriate software needed to edit or view design data can impose significant administrative burdens. Yet a further complication arises when trying to limit the type of information accessible by certain groups. For example, purchasing department personnel may need access to design data when determining which parts to order, but do not need the ability to edit that design. As another example, it would be highly advantageous if a company could more easily assign a design task to an outside designer working for another company, provide that designer with the necessary software tools for the assigned task, and limit the designer's access to design data relevant to that task.
[0011] For these and numerous other reasons, there remains a need for improved systems and methods for electronic design automation.
SUMMARY OF THE INVENTION
[0012] In at least some embodiments of the invention, logical design data for a PCB is stored in a database. The design data is organized according to a connectivity-based data model. Also stored are profiles for multiple users. The profile data for each user specifies logical design data elements accessible by that user and PCB design software to be provided to that user for accessing or editing logical design data. In accordance with the stored profiles, elements of the logical design data and one or more PCB design software programs are transmitted to client computers. The PCB design software may include plug-ins executable within a web browser at a client. Logical design data edits are received from the clients and applied to the logical design data stored in the database.
[0013] Additional embodiments of the invention include storing PCB logical design data which is organized according to a connectivity-based data model. In some embodiments, circuit functional blocks, inputs and outputs of functional blocks, and signals are stored as separate data structures. Those separate data structures may be edited by users at separate clients during concurrent editing sessions conducted at said separate clients. Still further embodiments include scripted design data objects, each of the scripted design data objects including at least one data object and at least one associated script. An associated script is executable to automatically modify a data object.
[0014] In at least some embodiments, logical design data and layout data are stored in a database. Elements of the layout data are mapped to elements of the logical design data. Edits to logical design data are automatically mapped to layout design data. Constraint data may also be stored in the database, with elements of the constraint data being mapped to elements of the layout data.
[0015] Yet other embodiments of the invention include automated change requests. A request to edit one or more logical design data elements is received from a first of plural users. A change request message is then sent to others of the plural users. That message identifies the requested edit and offers the other users the ability to approve the requested edit. Upon receiving approvals from at least a portion of the users receiving the change request message, a database is automatically updated to include the requested edit. Still further embodiments include filtering notifications, received by a user, of logical design data edits by other users.
[0016] These and other features and advantages of the present invention will be readily apparent and fully understood from the following detailed description of preferred embodiments, taken in connection with the appended drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
[0018] FIG. 1 is a schematic diagram for a hypothetical circuit used to illustrate at least some embodiments of the invention.
[0019] FIG. 2 is a diagram showing description of the circuit of FIG. 1
using the concepts of cells, ports and nets.
[0020] FIG. 2A is a modified version of the design of FIG. 2.
[0021] FIGS. 3A-3D show an example of storing electronic design data using relational database tables.
[0022] FIG. 4 is an object diagram for a Design Data Object Model (DDOM) according to at least some embodiments of the invention.
[0023] FIG. 5A is a diagram showing relationship among individual objects.
[0024] FIGS. 5B-5E are block diagrams explaining, according to at least some embodiments, the interaction of Cell, CellInstance, Representation and Configuration objects in connection with establishing design hierarchy.
[0025] FIGS. 6A-6T are drawings of projects trees according to at least some embodiments of the invention.
[0026] FIG. 7 is a block diagram showing an Electronic Design Automation (EDA) system architecture according to at least some embodiments of the invention.
[0027] FIGS. 8A-8J show access and editing of design data according to at least some embodiments of the invention.
[0028] FIG. 8K is a drawing of a libraries tree according to at least some embodiments of the invention.
[0029] FIG. 9 is a user interface, according to at least some embodiments of the invention, displaying an uncommitted design data change.
[0030] FIGS. 10A-10C illustrate communications between clients and a design object server according to at least some embodiments of the invention.
[0031] FIG. 11A shows a transaction manager user interface according to at least some embodiments of the invention.
[0032] FIG. 11B shows an interface, according to at least some embodiments of the invention, displaying applied but unaccepted changes from a transaction.
[0033] FIG. 12 shows a filter dialog user interface according to at least some embodiments of the invention.
[0034] FIGS. 13A-13C show user interfaces, according to at least some embodiments of the invention, related to change requests.
[0035] FIGS. 14A and 14B are diagrams showing interaction between a Design Data Object Model (DDOM) and a Layout Logical Object Model (LLOM) according to at least some embodiments of the invention.
[0036] FIG. 15 is an object diagram for a Layout Logical Object Model according to at least some embodiments of the invention.
[0037] FIG. 16 is a diagram showing multiple slot fields of a Part object.
[0038] FIG. 17 is a diagram showing an Electrical Net object.
[0039] FIG. 18A is a flow chart showing generation of LLOM data in response to editing of DDOM data.
[0040] FIG. 18B is a flow chart showing generation of DDOM data in response to editing of LLOM data.
[0041] FIG. 18C is a flow chart showing generation of LLOM data in response to editing of DDOM data.
[0042] FIG. 18D is a flow chart showing generation of DDOM data in response to editing of LLOM data.
[0043] FIGS. 19A and 19B are a user interface, according to at least some embodiments of the invention, for selection of LLOM and DDOM objects.
[0044] FIGS. 20A and 20B are block diagrams showing communication of constraint data according to at least some embodiments of the invention.
[0045] FIG. 21 is an object diagram for a Constraint Data Object Model (CDOM) according to at least some embodiments of the invention.
[0046] FIG. 22 is a block diagram describing parameterized objects according to at least some embodiments of the invention.
[0047] FIGS. 23A and 23B are examples of user interfaces in connection with a scripted object according to at least some embodiments of the invention.
[0048] FIG. 24 is a block diagram showing loading of a design environment by a client computer according to at least some embodiments of the invention.
[0049] FIG. 25 is a block diagram showing user roles according to at least some embodiments of the invention.
[0050] FIG. 26 is a block diagram showing a user interface for opening or closing plug-ins according to at least some embodiments of the invention.
[0051] FIG. 27 is a block diagram showing distribution, according to at least some embodiments of the invention, of design data and software tools for editing design data.
[0052] FIGS. 28A-28D are an object diagram for a Combined Data Object Model (CoDOM) according to at least some embodiments of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Connectivity-Centric Data Model
[0053] In many parts of the design process (in both the front and back ends), connectivity between circuit elements is more critical than a particular graphical representation of the circuit. FIG. 1, a schematic diagram for a portion of a hypothetical circuit 10, illustrates this point. Included in FIG. 1 are two flip-flops 2 and 4, an AND gate 6 and a four-way AND gate 8. Also shown in FIG. 1 are interconnections between inputs and outputs of these circuit elements, as well as connections to various signal lines (e.g., "Clock," "Data1," etc.) connected to other circuit elements not shown in FIG. 1. Although a schematic such as FIG. 1
may assist in visualizing signal flows and in understanding other aspects of a circuit design, the specific graphical form and arrangement of circuit element symbols is generally not critical to a front end designer. For example, the logical functionality of the circuit in FIG. 1
is unaffected if AND gate 6 is reoriented and moved to a different location (shown in dashed lines). A schematic diagram is similarly not critical to a back end designer laying out a circuit represented by the schematic. The arrangement of symbols on a schematic is generally not used when determining the placement of actual physical components on a printed circuit board (PCB), and the precise arrangement of signal lines on a schematic diagram is generally unhelpful when routing PCB traces between component pins.
[0054] Accordingly, at least some embodiments of the invention implement a connectivity-based data model for electronic design. Such a data model can be stored and manipulated non-graphically, and offers numerous advantages (as described herein). In at least some of these embodiments, a connectivity-based data model describes a circuit design using the concepts of cells, ports and nets. A cell is a functional block of a circuit. A cell may be an individual circuit element (e.g., a single microprocessor, memory chip, capacitor, AND gate, etc.), or may be a collection of individual elements. A port is an input and/or output of a cell. A net is a signal communicated to or from one or more ports.
[0055] FIG. 2 shows one way in which the circuit of FIG. 1 can represented as a collection of cells, ports and nets. Referring to FIG. 2, flip flops 2 and 4, AND gate 6 and four-way AND gate 8 correspond to cells A-D, respectively. Another cell ("E") is defined to include cells A and B, and an additional cell ("F") is defined to include cells C and D. Each cell has ports, shown as small solid squares in FIG. 2 for clarity. Cell A, for example, has four ports (A_1, A_2, A_3 and A_4) corresponding to the Clock, Data, {overscore (Q)} and Q inputs and outputs, respectively, of flip flop 2. Similarly, Cell B has ports B_1 through B_4 corresponding to the Clock, Data, {overscore (Q)} and Q inputs and outputs, respectively, of flip flop 4. Cell C corresponds to AND gate 6 and has input ports C_1
and C_2 and an output port C_3. Cell D corresponds to four-way AND gate 8, and has four input ports D_1 through D_4 and an output port D_5.
[0056] Cell E is shown in FIG. 2 with a broken line surrounding cells A and B. The ports of cell E are labeled in FIG. 2 as E_1 through E_6 and represent inputs provided to, or outputs from, the functional block defined by cell E. Cell E also includes multiple nets E_a through E_f connecting ports of cells A and B and of cell E. Net E_a connects ports E_1, A_1 and B_1. Net E_b connects ports E_2 and A_2, and net E_c connects ports A_3 and E_3. Net E_d connects ports A_4 and B_2, net E_e and connects ports B_3 and E_4, and net E_f connects ports B_4 and E_5. Cell F is shown with a broken line surrounding cells C and D, and has ports F_1 through F_6 and internal nets F_a through F_g. Additional nets connecting cells E and F to each other or to additional signals include "Clock," "Data1" through "Data5," and "Net11" through "Net14." Some of these nets may be "global," i.e., they may run throughout the entire design (or throughout much of the design) and connect to numerous other cells (either single- or multi-element cells). Other nets may be "local," i.e., only connecting a few cells.
[0057] Cells E and F are arbitrarily defined for purposes of example. However, a designer might choose to define a cell to include other cells for various reasons. For example, a particular collection of logical elements may represent a functional block that the designer will use in several parts of a circuit design, or perhaps in several different circuit designs. Instead of recreating individual component cells for those logical elements (and their interconnections) in each of multiple locations, the designer simply reproduces the multi-component cell in another part of the design.
[0058] By representing a circuit design as a collection of cells, ports and nets, the design can readily be described non-graphically. For example, a circuit design can be stored as a collection of tables in a relational database. FIGS. 3A-3D show a simplified example of such storage as applied to the design of FIG. 2. FIG. 3A is a table titled "Projects." Each row in the "Projects" table corresponds to a particular design project, identified by the value in the first column. In the present example, a row corresponds to the design of FIG. 2 (renamed "Board 1" for convenience). Additional columns hold values identifying cells of the project. FIG. 3B is a table labeled "Cells," and contains a separate row for each cell. Fields of FIG. 3B hold values identifying cells within ("contained cell"), and ports of, a cell to which a row corresponds. FIG. 3C is a "Ports" table, each row of which corresponds to a port. The fields of the "ports" table rows hold values identifying the cell for which a particular port is an input and/or output, as well as nets connected to that port. FIG. 3D is a "Nets" table. Each row of FIG. 3D corresponds to a net, and has fields identifying ports to which that net connects.
[0059] Although storing data for the design of FIG. 2 in the tables of FIGS. 3A-3D may initially appear more complicated than a graphic representation, such storage offers numerous advantages. Data can be accessed more quickly and to a finer degree of granularity than is possible with a graphical representation. Moreover, adding additional design information is a relatively simple matter of adding new fields and/or tables. Use of tables also facilitates rapid identification of circuit elements of interest. For example, a user can determine all components receiving a particular signal by using the Nets table. This would generally be much faster than attempting to find the same information from a complex schematic.
[0060] Still further advantages can be obtained through use of an object-oriented design data model. An object-oriented approach offers many of the advantages of tables such as in FIGS. 3A-3D (e.g., accessing design data rapidly and to a fine degree of granularity), but simplifies development and distribution of application programs for editing and managing design data. In at least some embodiments, cells, ports and nets are stored as objects. As will be understood by persons skilled in the art, an "object" is a data structure that may contain both data values and programming routines (also known as methods). The methods within an object can be configured to access data within the object, to replicate the object, to create other objects, to modify data within other objects, and for numerous other purposes. In at least some embodiments of the invention, an object-oriented design data model is implemented using the JAVA programming language available from Sun Microsytems, Inc. of Santa Clara, Calif. Details of the JAVA programming language are well known, and available from, e.g., Sun Microsystems at <http://www.sun.com>.
[0061] FIG. 4 is an object diagram for a design data object model (DDOM) according to at least some embodiments of the invention. The DDOM is a collection of objects used to describe the logical design of one or more design projects. In particular, the objects of the DDOM hold the data corresponding to one or more front end designs that are described using the cell, port and net concepts described above. In addition to this design data, DDOM objects also contain programming instructions (e.g., JAVA methods). Using these programming instructions, DDOM objects can access, modify, create and/or delete other DDOM objects. For example, creation (or modification or deletion) of one object can generate an event. This event can be detected by other objects, which then perform various tasks based on the detected event.
[0062] FIG. 4 shows general types of objects used to describe logical design data, as well as the relationship between those object types. A line between two blocks having an arrow at both ends indicates a two-way association between the object types represented by those two blocks. In other words, a data object of the type on one end of a double-arrow line refers back to an object of the type on the other end of that line. An asterisk (*) on one end of a line indicates that there may be one or more objects of the type at the end of the line having the asterisk. For example, a "Project" object (block 22) may have one or more associated "Cell" objects (block 26). A line having an arrow at only one end indicates that an object of the type at the headless end of the line is an instance of an object of the type at the other end of the line (the "parent object"). Both an instance object and its parent object can be used to hold design data. For example, a Cell object (block 26) may describe a particular type of cell (e.g., a capacitor and resistor in parallel). That cell type may then be repeated in various portions of the design as CellInstance objects (block 38). Individual ones of those CellInstance objects may be different from one another. One CellInstance object of the parent may describe a capacitor-resistor pair having one set of capacitance and resistance values, and another CellInstance object may describe a capacitor-resistor pair having different resistance and capacitance values.
[0063] The DDOM includes a main object 20. The main object can be analogized to a container for other objects of the DDOM. Main object 20
is often the starting point from which other objects are accessed. For example, when initially loading logical data for one or more designs, main object 20 is first accessed so as to determine what other DDOM objects may be available. In some cases, main object 20 also detects various events that occur in a program for editing logical design data. By way of example, a user may select a graphically-displayed icon corresponding to a logical design element. Main object 20 would detect that selection event and pass the necessary data to one or more other DDOM objects. As another example, and as discussed more fully below, objects within various other data models could be accessed and/or modified. Main object 20 detects such events for other object model objects and then invokes one appropriate methods within one or more DDOM objects.
[0064] Associated with main object 20 are one or more Project objects (block 22). Each project object corresponds to a particular design project (e.g., an effort to develop a specific electronic device or a portion thereof). So as not to confuse the general concept of a "project" with a Project data object, a Project data object will hereinafter be called a "Project object." Each Project object has name, version and unique identification (unique id) fields. As used herein in connection with describing an object type, "field" refers generically to a type of information contained or referenced by an object. When used in this context, "field" does not require that an object contain a table or other specific type of data structure. A field within an object may be a name/value pair (e.g., name=Cell 1), a pointer or other reference to a value stored elsewhere, or may be any of various other types of data structures. The name field may hold a name that a designer has assigned to a particular project, and which will be used by (or displayed to) the designer when accessing project design data in a computerized electronic design automation (EDA) system. For example, a design for an input/output interface board for a new computer might be named "10 Interface." Each Project object also has a version. For example, one or more designers may create multiple versions of design data for a particular project in order to maintain information about alternative designs. As one illustration, a first designer may disagree with design changes made by a second designer. The first designer may therefore save a separate copy of the design data that does not include the second designer's changes. The version field for a Project object may hold a number or other alphanumeric value. The unique id for a Project object is an identifier used to reference the Project object by other DDOM objects and elsewhere in an EDA. In some embodiments, the unique id is an alphanumeric string (e.g., "ABCDEFG123456789") that is assigned automatically when the object is created.
[0065] Associated with a Project object may be one or more Attribute objects (block 28). An Attribute object represents a name=value pair used to link some type of additional information to the object associated with the Attribute object. For example, an Attribute object associated with a Project object may be used to link a lifecycle state to the object (e.g., "Lifecycle State=Under Construction"; lifecycle states are described below), to identify permission levels or roles of users authorized to access the object, etc. In addition to name, value, version and unique id fields, an Attribute object may also have context value fields, which are described below.
[0066] Each Project object may have one or more associated Cell objects (block 26). As discussed in connection with FIG. 2, a cell conceptually refers to a functional block of a circuit. That block may be a single logical element (e.g., one resistor) or may be a collection of logical elements and their interconnections. A Cell Object generally corresponds to a description of a functional block. So as not to confuse the general concept of a "cell" with a Cell data object, a Cell data object will hereinafter be called a "Cell object." As with a Project object, a Cell object also has name, version and unique id fields. Associated with a Cell object may be one or more Attribute objects (a double-headed arrow between blocks 26 and 28 is omitted for clarity).
[0067] As described in more detail below, an upper level of a design hierarchy can be represented as a single Cell Object. For example, the entire design of FIG. 2 could correspond to a single Cell Object named "Top." A CellInstance Object (block 38) corresponds to an instantiation of a Cell Object. By way of illustration, the functional block corresponding to a "Top" Cell Object of the FIG. 2 design could be replicated in other designs. Those replicated blocks (which need not be identical to each other) would correspond to separate CellInstance objects. Each of those CellInstance objects would be a separate instantiation of the "Top" Cell object. Each CellInstance object has name, version and unique id fields, and may have one or more associated Attribute objects (a double-headed arrow between blocks 38 and 28 is omitted for clarity). Additional aspects of Cell and CellInstance objects are discussed below.
[0068] Associated with a Cell object may be one or more Representation objects (block 34). As indicated above, a Cell object corresponds to a functional block of a design. That functional block can often be described using various combinations of logical sub-elements and interconnections between those sub-elements. Although alternative representations of the same cell may often correspond to blocks of sub-elements that perform identical functions, this need not be the case. Each Representation object also has name, version and unique id fields. Each Representation object may also have one or more associated Attribute objects. So as not to confuse the diagram of FIG. 4, a double-headed arrow connecting blocks 34 and 28 is omitted from FIG. 4.
[0069] As seen in FIG. 4, blocks 26 (Cell) and 38 (CellInstance) are linked directly by a single arrow line, as well as indirectly through block 34 (Representation). It should be remembered, however, that the blocks in FIG. 4 (with the exception of block 20) represent object types, not individual objects per se. Thus, FIG. 4 does not require that a CellInstance object be an instantiation of the Cell object with which it is indirectly linked via a Representation object. This is shown diagrammatically in FIG. 5A, in which the blocks do represent individual objects. For simplicity, objects of certain types described in FIG. 4 are not included in FIG. 5A. Cell object 26' has an associated Representation object 34', which has associated CellInstance Objects 38.sub.1' and 38.sub.2'. CellInstance object 38.sub.1' is an instantiation of Cell object 26'' and CellInstance object 38.sub.2' is an instantiation of Cell object 26'''.
[0070] Returning to FIG. 4, each Cell object is also associated with one or more Port objects (block 36). Each Port object corresponds to an input to and/or output of a functional block corresponding to a Cell object with which the Port object is associated. So as not to confuse the general concept of a "port" with a Port data object, a Port data object will hereinafter be called a "Port object." As with other object types, each Port object has name, version and unique id fields, and may have one or more associated Attribute objects (a double-headed arrow between blocks 36 and 28 is omitted for clarity). Each Port object further has scalar, bus and bundle fields to indicate whether the corresponding port is of a scalar, bus or bundle type. A scalar port connects to a scalar net, and receives (or outputs) a single bit signal. Examples of scalar ports include ports which receive or output a clock or reset signal, a prescribed voltage level (e.g., "VDD"), etc. A bus port connects to a bus net, and receives a multibit signal. An example includes an N-bit wide memory addressing line. A bundle port connects to a bundle net, and receives (or outputs) a combination of bus and scalar signals.
[0071] Similarly, a CellInstance object (block 38) may have one or more associated PortInstance objects (block 40). Each PortInstance object corresponds to an input to (our output from) the functional block corresponding to an associated CellInstance object. A PortInstance object has name, version and unique id fields, and may have one or more associated Attribute objects (a double-headed arrow between blocks 40 and 28 is omitted for clarity). Like Port objects, PortInstance objects also have fields to indicate whether the corresponding port is of a scalar, bus or bundle type. A PortInstance object is an instantiation of a Port object. In particular, a PortInstance object is an instantiation of a Port object associated with the Cell object from which the CellInstance object is instantiated.
[0072] Both Port and PortInstance objects are associated with Connection objects (block 44). A Connection object (which has name, version and unique id fields) links a Port or PortInstance object to a Net object (block 42). Each Net object corresponds to a net providing a signal to (or receiving a signal from) the linked Port or PortInstance object. Accordingly, each Net object also has fields indicating whether the corresponding net is of a scalar, bus or bundle type. A Net object also has name, version and unique id fields, and may have one or more associated Attribute objects (a double-headed arrow between blocks 42 and 28 is omitted for clarity). Because a single Net may be connected to many ports, the asterisk is on the block 44 side of the line connecting blocks 42 and 44.
[0073] Returning to block 26, a Cell object is associated with one or more Configuration objects. A Configuration object contains data indicating which Representation object is to be used when instantiating a cell at a particular hierarchical design level. The concept of design hierarchy can be illustrated with FIG. 2. If the entire design of FIG. 2 is treated as a single cell, that entire-design cell would be at the highest (or "top") level of the design hierarchy. Cells E and F are at intermediate levels of the hierarchy, while cells A, B, C and D are at lower levels of the hierarchy.
[0074] FIGS. 5B-5E further explain the interaction of Cell, CellInstance, Representation and Configuration objects in connection with establishing design hierarchy. In FIG. 5B, the rectangular blocks signify individual objects. The Cell 1 object is associated with Representation objects R1d and R1s and with Configuration objects Cfg1d and Cfg1s. Configuration object Cfg1d specifies that a default representation (i.e., the representation corresponding to object R1d) should be used for the Cell 1
functional block. Conversely, Configuration object Cfg1s specifies that a specified representation (i.e., the representation corresponding to object R1s) should be used for the Cell 1 functional block. The Cfg1d configuration is active in FIG. 5B. In other words, the Cell 1 functional block is currently being represented according to the R1d Representation object. Representation object R1d is associated with two CellInstance objects CI2 and CIY. CellInstance object CIY is an instantiation of a Cell object not shown in FIG. 5B. CellInstance object CI2 is an instantiation of Cell object 2. Representation object R1s is also associated with a CellInstance object CI2 (another instantiation of Cell object 2), as well as with CellInstance object CIQ (an instance of a Cell object not shown in FIG. 5B).
[0075] The Cell 2 object has a single associated Configuration object (Cfg2d) and a single, default Representation object (R2d). Associated with the R2d object are CellInstance objects CI3 and CIX. Object CIX is an instantiation of a Cell object not shown in FIG. 5B, while object CI3
is an instantiation of Cell object Cell 3.
[0076] Cell object Cell 3 has two associated Configuration objects Cfg3d and Cfg3s and two associated Representation objects R3d and R3s. Configuration object Cfg3d specifies that a default representation (i.e., the representation corresponding to object R3d) should be used for the Cell 3 functional block. Configuration object Cfg3s specifies that a specified representation (i.e., the representation corresponding to object R3s) should be used for the Cell 3 functional block. The R3d object is associated with CellInstance objects CI4 and CIW. Object CIW is an instantiation of a Cell object not shown in FIG. 5B, while object CI4
is an instantiation of Cell object Cell 4. The Cell 4 object corresponds to the lowest level of the design hierarchy (e.g., a single component such as a capacitor or resistor), and there is only one representation of the corresponding functional block. The R3s object is associated with CellInstance objects CIZ and CIT; CIZ and CIT are instances of other Cell objects not included in FIG. 5B.
[0077] FIG. 5C is a block diagram of a design corresponding to the active configurations of FIG. 5B. The top level (Cell 1) contains one cell (CI2) corresponding to the default representation (R2d) of Cell 2. Cell 1 also contains a cell corresponding to a representation of the Cell object from which CIY is instantiated (the details of which are omitted for simplicity). The cell CI2 contains a cell (CI3) corresponding to the default representation (R3d) of Cell 3. Cell CI2 also contains a cell corresponding to a representation of the Cell object from which CIX is instantiated (details also omitted for simplicity). Cell CI3 contains a cell (CI4) corresponding to the only representation of Cell 4. Cell CI3
also contains cell CIW corresponding to a representation of the cell from which CIW is instantiated (details also omitted for simplicity).
[0078] FIGS. 5D and 5E show what occurs if the Cfg1s configuration for the Cell 1 object is made active. Because configuration Cfg1s specifies representation R1s, Cell now contains cells CI2 (corresponding to the R2d representation of Cell 2) and CIQ (corresponding to a representation of another Cell object not shown in FIG. 5D). Cell instance CI2 again contains cells CIX and CI3. Although configuration Cfg3s is active for Cell object CI3 in FIG. 5D, cell CI3 of FIG. 5E still contains cells CI4
and CIW. In at least some embodiments of the invention, an active non-default configuration for a top-level Cell object supercedes an active configuration for a Cell object instantiated at a lower level. In the example of FIGS. 5D and 5E, configuration object Cfg1s specifies that default representations should be used at all lower levels. Thus, and not withstanding the active Configuration object Cfg3s for Cell 3, the Cell 3
object is instantiated using the default representation R3d. Were Cell 3
to be instantiated elsewhere as a top level, however, the Cfg3s configuration would then be used. If desired, the Cfg1s configuration for Cell 1 could be modified to specify the R3s representation of Cell 3.
[0079] Two additional blocks of the DDOM are blocks 24 (Library object type) and 30 (Variant object type). The DDOM may have one or more Library objects, each of which is associated with one or more Cell objects. In this manner, each Library object corresponds to a collection (or a library) of various Cell objects. In some cases, a library may be a database identifying actual physical components that can be used on a PCB (e.g., resistors, capacitors, memory chips, etc.); associated with those components may be Cell objects which can be added to a design (i.e., associated with a Project object). A library may also include other types of Cell objects which can be accessed by users and added to a project (i.e., associated with a Project object). For example, a Cell object may previously have been developed for a functional block used in numerous types of projects. Instead of recreating that functional block each time it is needed in a new project, the pre-existing Cell object can be associated with new Project objects. A Library object has name, version and unique id fields. Each Projects object is also associated with one or more Library objects.
[0080] A Variant object (block 30) corresponds to a particular Cell object that has been modified in some way so as to provide an alternate design. Unlike separate versions of a Cell object, which are typically used to store interim design variations before a design is complete, a Variant object often corresponds to a design that is intended for a slightly different end use. For example, a particular electronic device may require some modifications in order to be used in another country having different standards (e.g., NTIS vs. PAL video standards), but a large portion of the underlying design may be the same. A Variant object also has name, version and unique id fields, and may have one or more associated Attribute objects (a double-headed arrow between blocks 30 and 28 is omitted for clarity). A Variant object may also have a script. As discussed below, scripts can be used to specially modify an object in some way.
[0081] FIGS. 6A-6T further illustrate the relationship and use of various DDOM objects. Shown in FIGS. 6A-6T are various forms of a projects tree listing logical elements for one or more designs. In at least some embodiments, various nodes of a projects tree correspond to DDOM objects, and the tree is displayed to a designer. From this display, the designer can expand or collapse portions of the tree, select objects in the tree, add and/or delete objects in the tree, edit objects in the tree, and perform numerous other design tasks. Examples of manipulating a projects tree from such a display are provided below.
[0082] In FIG. 6A, the project tree is partially collapsed. At the first level of the tree is a node for "Projects" This node is expanded in FIG. 6A to show numerous projects (titled "Design 1," "Design 2" and "Design 3"); each node corresponds to a separate Project object. Although only three projects are shown, more or less could be present. The node for the project "Design 1" is also partially expanded. The first node ("Libraries") can be expanded to show various Library objects that are associated with, and may be used in connection with, the "Design 1" Project Object. Following the Libraries node are nodes for all of the Cell objects associated with the "Design 1" Project object. For purposes of example, the "Design 1" Project object corresponds to the designs shown in FIGS. 2 and 2A. FIG. 2A is substantially the same as FIG. 2, except that a resistor ("R") and an additional net ("E_g") have been added. The "Block E" Cell object corresponds to the functional blocks represented as cell E in FIGS. 2 and 2A. The "Block F" Cell object corresponds to the functional block represented as cell F in FIGS. 2 and 2A. The "FF," "Two_AND," "Four_AND" and "Res" Cell objects respectively correspond to a D-type flip-flop, a two-input AND gate, a four-input AND gate and a resistor. The "Top" Cell object corresponds to the function block for the entire circuit of FIG. 2 or FIG. 2A. For convenience, FIG. 6A also contains a key listing the various icons used in FIGS. 6A-6T and 8K. The icons shown are only examples, and other icons could be used.
[0083] In FIGS. 6B-6E, respectively, the nodes for Cell objects "FF", "Res," "Four_AND" and "Two_AND" have been partially expanded. The "Ports" node for each of these Cell objects lists the Port objects associated with each of these Cell objects. Cell object FF is associated with Port objects "Clo," "Dat," "Q" and "Qbar" (FIG. 6B); Cell object Res is associated with Port objects "p1" and "p2" (FIG. 6C); Cell object Four_AND is associated with Port objects "In.sub.--1" through "In.sub.--4" and "Out" (FIG. 6D); and Cell object Two_AND is associated with Port objects "In.sub.--1," "In.sub.--2" and "Out" (FIG. 6E). Although some nodes in FIGS. 6D and 6E have the same names ("In.sub.--1," "In.sub.--2" and "Out"), they correspond to different Port objects. For example, the In_1 Port object corresponding to FIG. 6D and the In_1 Port object corresponding to FIG. 6E would have different unique id values, even if their name values are the same. Included in the tree under nodes for Cell objects FF, Res, Four_AND and Two_AND are nodes labeled "Representations" and "Configurations." These nodes, once expanded, identify Representation objects and Configuration objects associated with the Cell Objects.
[0084] In FIGS. 6F and 6G, the tree node for the Block E Cell object is expanded. On-page connectors aa, bb, cc and dd link the tree portion of FIG. 6F with the tree portion of FIG. 6G. The first node under the Block E Cell Object ("Ports") is expanded to identify Port Objects (E_1 through E_5) associated with the Block E Cell object. The Representation node is also expanded. In this example, there are two Representation objects associated with the Block E object. The first, "Default," is shown in FIG. 6F. This Representation object, which corresponds to the design illustrated in FIG. 2A, includes CellInstance objects A, B and R. CellInstance objects A and B are separate instances of Cell Object FF. The "[FF]" after each CellInstance name indicates that each of the A and B CellInstance objects is an instance of the FF Cell object. CellInstance object R is an instance of Cell object Res. Identified under each of the tree nodes for CellInstance objects A, B and R are PortInstance objects associated with each of the CellInstance objects. For example, associated with CellInstance object A are PortInstance Objects A_1 through A_4. A_1
through A_4 are, respectively, instances of Port Objects "Clo," "Dat," "Qbar" and "Q" (FIG. 6B). PortInstance objects R_1 and R_2 are instances of Port objects p1 and p2 (FIG. 6C). Following the R node is a node labeled "Nets," under which are listed the Net objects associated with the "Default" Representation object for the Block E Cell object.
[0085] The second Representation object for the Block E cell is named "Alt 1" and is shown in FIG. 6G. This representation, which corresponds to the design illustrated in FIG. 2, is different than that corresponding to the Default Representation object. Associated with the Alt 1 Representation object are CellInstance objects A (having PortInstance objects A_1
through A_4) and B (having PortInstance objects B_1 through B_4), as well as Net objects E_a through E_f. The "Configurations" node is not expanded in FIG. 6G. If that node were expanded, however, it would include a default configuration that, if active, specifies the Default representation of Block E. There would similarly be a configuration that, when active, specifies the Alt_1 representation.
[0086] The Block F Cell Object is partially expanded in FIGS. 6H and 61. On-page connectors ab and ac link the tree portion of FIG. 6H with the tree portion of FIG. 61. In the present example, there is only one Representation object ("Default") associated with the "Block F" Cell object. Although the Representation object has the same name as other Representation objects (e.g., "Default" in FIG. 6F), it has a different unique id value.
[0087] The "Top" Cell object is partially expanded in FIGS. 6J-6L. Off-page connectors ee, ff, and gg link the tree portion of FIG. 6J with the tree portion of FIG. 6K. Off-page connectors hh, ii, jj and ll link the tree portion of FIG. 6K with the tree portion of FIG. 6L. Cell object "Top" has a single Representation object ("Top Board"). Associated with the "Top Board" Representation object are CellInstance objects "E" (an instance of Cell object "Block E") and "F" (an instance of Cell Object "Block F"). Net objects associated with the "Top Board" Representation object are listed under the Nets node, which is not expanded in FIG. 6J.
[0088] The Configurations node and the node for Configuration object "Top Config" are expanded in FIGS. 6K and 6L. The "Top Config" object specifies the "Top Board" Representation object for the "Top" Cell object. As seen in FIG. 6J, the "Top Board" Representation object is associated with CellInstance objects "E" (and instance of the "Block E" Cell object) and "F" (an instance of the "Block F" Cell object). "Top Config" further specifies which representations of "Block E" and "Block F" to use when instantiating "E" and "F." In particular, and as seen in FIG. 6K, "Top Config" specifies that the "Default" representation of "Block E" should be instantiated. Similarly, and as seen in FIG. 6L, "Top Config" specifies that the "Default" representation for "Block F" should be instantiated.
[0089] A Cell object can have multiple configurations. In the present example, the "Top" object has another configuration known as "Top Config2" (shown unexpanded in FIG. 6L). In FIGS. 6M-6O, the tree node for the "Top Config2" object is made active and expanded. In at least some embodiments, only a tree node for an active configuration can be expanded. "Top Config2" specifies the "Alt.sub.--1" representation of "Block E" should be instantiated instead of the "Default" representation of "Block E." Off-page connectors ad, ae and af link the tree portion of FIG. 6M with the tree portion of FIG. 6N. Off-page connectors ag, ah and ai link the tree portion of FIG. 6N with the tree portion of FIG. 6O.
[0090] Only three hierarchical levels are included in the example of FIGS. 6A-6O. However, additional levels of design hierarchy are possible. For example, "Design 1" could be modified to include multiple representations of Cell object "FF." FIG. 6P shows the "FF" node further expanded (after such modification) to reveal two representations of Cell object "FF." The first Representation object ("Default") corresponds to a representation in which an instance of FF would be a leaf node (i.e., the lowest level of a branch in the projects tree). For example, the "Default" representation of Cell object "FF" could correspond to a discrete component bought from a vendor. The second Representation object ("Alt_a") corresponds to an implementation of a flip flop using 4 NAND gates and an inverter (such an implementation is shown in FIG. 6P for convenience). FIGS. 6Q-6R show the tree node for "Block E" expanded to show (via a different type of icon) that CellInstance object A is no longer the lowest level of design hierarchy in that branch of the projects tree. On-page connectors aj, ak, al and am link the tree portion of FIG. 6Q with the tree portion of FIG. 6R. FIG. 6S shows the "Top Config" node expanded to now reveal four levels of design hierarchy: "Top," "E," "A" and "N1" through "Inv." On-page connectors an and ao link the separated tree portions of FIG. 6S. In the example of FIG. 6S, "Top Config" specifies that that the "Default" representation for "Block E" should be instantiated, that the "Alt_a" representation of Cell object FF should be instantiated for CellInstance A, and that the "Default" representation of FF should be instantiated for CellInstance B.
[0091] In FIG. 6T the Block E Cell object has been instantiated twice (CellInstance objects E1 and E2) under the "Top Board" representation for the Top Cell object. In other words, there are now three CellInstance objects associated with the "Top Board" Representation object for the Top Cell object (E1, E2 and F). Although there are now two CellInstance objects which are instantiations of the Block E Cell object, there are still only 2 instantiations of the FF Cell object ("A" and "B") and only one instantiation of the Res Cell object ("R"). Stated differently, the "A" node under the "El" node and the "A" node under the "E2" node refer to the same CellInstance object; the same applies to the two "B" nodes and to the two "R" nodes. Although the two "A" nodes refer to the same object, the object has a different context in each tree location. This context can be used to vary the behavior of the object based on its location in the design hierarchy. For example, CellInstance object "R" could have associated attributes that depend upon context. One attribute may specify a first resistance value in one position of the design hierarchy (e.g., under "E1"), and another attribute may specify an different resistance value in a second position within the design hierarchy (e.g., under "E2"). As shown in FIG. 4, an Attribute object (block 28) may have multiple values ("context values") that depend upon context. A context string of a Configuration object (block 32) defines the context values to be used at various locations within the hierarchy (i.e., when the CellInstance object is in different contexts).
[0092] Although CellInstance objects have been discussed in connection with FIG. 6T, PortInstance, Connection and Net objects can also have context. For example, if the A nodes under E1 and E2 were expanded to identify ports of A, A_1 under A on the E1 branch and A_1 under A on the E2 branch would refer to the same PortInstance object, but with different contexts. If the Nets node under E1 and the Nets node under E2 were expanded, E_a under E1 and E_a under E2 would refer to the same Net object, but have different contexts values. The Connection object linking A_1 and E_a in the E1 context is the same Connection object linking A_1
and E_a in the E2 context, but likewise has a separate context value in each case.
Example System Architecture
[0093] In at least some embodiments, and using objects according to the DDOM of FIG. 4, design data is stored in an object-oriented database. Client computers (operated by front end designers) download a set of DDOM objects, via a Design Objects Server (DOS), from the object-oriented database. The downloaded DDOM objects include methods that act as application programming interfaces (APIs) for application programs executing on a client computer. Those client APIs are used by one or more application programs to edit and/or create design objects.
[0094] FIG. 7 is a block diagram showing an architecture for an EDA system according to at least some embodiments of the invention. Design database 50 is located at the bottom of FIG. 7. Design database 50 stores data objects for one or more designs. Object-oriented databases are known in the art, and thus details of the operation of database 50 are not further described herein. Data in database 50 is accessed through a collection of data APIs 56. In at least some embodiments, design database 50 and data APIs 56 are implemented using the DMS design data management system and DATAFUSION APIs available from Mentor Graphics Corporation of Wilsonville, Oreg. Design database 50 is accessed through Design Object Server (DOS) 58. DOS 58, in turn, is accessed via network 60 by multiple clients 62 (for convenience, only a single client is shown in FIG. 7). Network 60 includes, in at least some embodiments, the Internet. However, network 60 may also include (or consist of) one or more Wide Area Networks and/or Local Area Networks. Client 62 may be any of numerous types of computer. Typically, a client computer will have one or more processors, memory, and some form of visual display (e.g., a video screen), as well as various devices for user input (e.g., a keyboard, a mouse, etc.). Such computers are well known, and thus not further described herein. Similarly, various aspects of the invention can be embodied as programming instructions on a medium readable by a computer or other device.
[0095] Executing on client 62 are various design applications 66-74. In at least some embodiments, these applications are implemented as plug-ins running within a container application 65. In at least some embodiments, the container application is written in the aforementioned JAVA programming language and can be run in three different modes: as an applet within a browser (such as the INTERNET EXPLORER browser program available from Microsoft Corporation of Redmond, Wash.); by invocation using JAVA WEB START (described at <http://java.sun.com/products/javawebstart/architecture.html>); or as a standalone application (at, e.g., a thick client). These plug-ins, also written using the JAVA language, are designed to address different design and data management tasks. The creation of JAVA-based applications and plug-ins and execution of such applications and plug-ins in one of the above-described modes are well known in the art, and therefore not further described herein.
[0096] In the present example, plug-in 66 is a Design Data Manager (DDM). DDM 66 allows a designer to display a logical design element listing (such as the projects tree described above) and to edit those design elements. Plug-in 68 is a viewer application, and allows the designer to view the contents of (or other information about) one or more design elements (or other objects) selected in another application. Plug-in 70
is a schematic editor. Schematic editor 70 allows a designer to generate a schematic diagram from design data contained in DDOM objects, as well as to modify DDOM objects by manipulating graphical images on a displayed schematic. Plug-in 72 is a transaction manager, which is discussed in more detail below. Other plug-ins 74 could include an attribute editor (which allows a designer to edit one or more attributes of a design object), a constraint editor (which allows a front end designer to specify constraints for physical components that a back end designer may use to implement the logical design elements), a parts selector (which allows a designer to access one or more libraries), an output window (which displays status information from other plug-ins or scripts), and a scripting plug-in (which allows a user to write, paste and edit scripts; scripts are discussed below). Plug-ins 66-74 are only a few examples of the types of plug-ins executable by client 62 in connection with embodiments of the invention. Also stored in memory of client 62 are local copies of DDOM objects for one or more design projects.
Client Editing of Design Data
[0097] FIGS. 8A-8J provide illustrations of how a designer may use various client applications to modify, create and otherwise act upon various DDOM objects. It should be noted that the various user interfaces shown in FIGS. 8A-8J have been adapted for printed illustration and to comply with U.S. Patent and Trademark Office drawing requirements. Actual displays could include additional plug-in windows and/or show more information in a particular window. The size, number and content of windows shown in the drawings has been limited so as to, e.g., avoid use of very small type fonts.
[0098] Shown in FIG. 8A is a user interface for DDM 66. A first pane 90 of DDM 66 contains selectable folder tabs labeled "projects" and "libraries." By selecting the projects tab, and as shown in FIG. 8A, the user is able to see a projects tree 80 displayed in pane 90. In at least some embodiments, DDM 66 includes a second pane 92. Pane 92 also includes various selectable tabs, such as "Connectivity," "Attributes" and "Packaged Data." As discussed in more detail below, selection of various tabs in pane 92 allows a user to obtain additional details about an object selected in pane 90. All of the tabs shown for pane 92 may not be present in a particular case. The available tabs in panes 90 and 92 can vary based on program configurations and/or the currently loaded project data. In at least some embodiments, selecting the "Change Split" command causes panes 90 and 92 to re-orient relative to one another (e.g., from pane 90 over pane 92 to panes 90 and 92 being side by side, or vice versa).
[0099] Also shown in FIG. 8A is a viewer plug-in 68. In at least some embodiments, viewer plug-in 68 performs various functions. When the front end design environment is initially loaded onto a client computer, viewer 68 provides a "welcome" screen as shown in FIG. 8A. The welcome screen can provide a portal by which a user may access administrative and other screens. The welcome screen can also be used to provide system messages (e.g., "database will be down for maintenance from 12:00 to 4:00 a.m."), to summarize design projects for the user, to summarize pending change requests for the user (change requests are discussed below), and to provide numerous other types of information. Viewer 68 also allows a user to view information about objects that may be selected in DDM plug-in 66. In some cases, that information may be in the form of a textual description of the selected object. In other cases, that information may be a schematic diagram or HDL code associated with the object.
[0100] The projects tree in pane 90 can be expanded in a manner similar to that described in connection with FIGS. 6A-6T. When expanded, different parts of projects tree 80 may be seen by manipulating and on-screen scroll bar or other user interface. In FIG. 8B, HDL code for a selected Representation object is shown in viewer 68. In FIG. 8C, a schematic diagram for a selected Representation object is shown.
[0101] FIGS. 8D-8J further illustrate selection of elements in projects tree 80. In FIG. 8D the user has selected a node for CellInstance object A. Upon selection, details of object A are displayed in viewer 68 and in pane 92 of DDM 66. As shown in FIG. 8D, the "Connectivity" tab is selected in pane 92, and indicates the "port instances" and "nets" associated with CellInstance object A. The third column ("pin number") is used to provide information regarding the number assigned by a back end designer to a pin of a physical component that will implement cell instance A. Physical design data (or layout data) is discussed in more detail below. Additional details are also shown in the "Object Details" view of viewer plug-in 68. The displayed information includes the name of the selected object ("Cell Instance: A"), a description of the object ("D-Type Flip-Flop"), version information ("Version 1"), an unique identification number ("UID *********"; throughout this description and drawings, multiple asterisks indicate an arbitrary collection of characters) and whether or not the object is locked. As explained in more detail below, an object in a design is locked by DDM 66 when another user selects that object. Locking an object prevents other users from editing the object. Viewer 68 may also provide the lifecycle state for a selected object. In the example, the selected object is "under construction," meaning that the design incorporating this element is still being developed. If the design was complete, the lifecycle state might indicate that the design is "in production." In that case, and as described in more detail below, a user could be required to undertake additional steps to modify a design element. Viewer 68 further indicates a technology type for the selected element. In the example, the technology is "PCB Technology." In FIG. 8E, the Attributes tab is selected in pane 92, and shows various attributes of another selected object.
[0102] FIGS. 8D and 8E merely provide some examples of the types of information that might be displayed in viewer 68 and/or in pane 92. In other embodiments, some of the information shown in FIGS. 8D and 8E might not be displayed, and/or other types of information provided (e.g., manufacturer name and part number for a corresponding component, special warnings regarding a long purchase lead time for a part, identification of parts libraries containing the part, etc.). In at least some embodiments, the user may also configure DDM 66 and/or viewer 68 to display only desired information. Of course, the type of information displayed by viewer 68 and/or pane 92 may also change based on the type of design element selected. In at least some embodiments, additional information about a particular object may be included in the projects tree (e.g., as parentheticals beside the object name, as an additional "information" node, etc.). For example, a version of an object could be shown in the object name portion of the tree (e.g., "A[FF(1)]," where "(1)" indicates version number 1).
[0103] Using DDM 66 and/or other plug-ins executing on a client, a designer can make changes to a design in various manners. FIGS. 8F-8I illustrate ways in which a designer can make design modifications using DDM 66. In at least some embodiments, a designer may select a design element in the projects tree using a computer mouse. When the designer selects a node on the tree (using, e.g., a "right click"), the designer is provided a context menu presenting various options. For example, as shown in FIG. 8F, the designer has right-clicked upon a projects tree node for a Cell object, bringing up a context menu 94. The first selection in context menu 94 ("Make Reusable") makes the selected cell accessible by other users and/or projects, and may cause the selected cell to be added to one or more libraries (i.e., associated with one or more Library objects). The "Change Description" menu option allows a designer to add, delete or modify textual information used-to describe the Cell object. The "Delete Cell" option permits a designer to delete the object. The "Change Lifecycle State" option allows a designer to change the lifecycle state for the object. The "Script" option allows a designer to execute one or more scripts with regard to the selected object. For example, a script may be selected and executed for a Cell object to automatically perform certain tasks applicable to that object. The "View Datasheet" option allows a user to see information for a particular electronic component associated with a particular design object. For example, a datasheet for the Res Cell object (FIG. 6A) could include information such as manufacturer name, part number, tolerances, etc.
[0104] In FIG. 8G, the designer has right-clicked a Representation object to display another context menu 96. The "Delete Representation" option allows a designer to delete the object. The "Rename" option allows renaming of the object. The "Set Default" option allows the designer to make a particular representation the default representation for its associated Cell object. The "Edit Schematic," "Edit Block Diagram" and "Edit Verilog" permit a designer to edit these types of views of the object.
[0105] Editing of a schematic for a selected object is shown in FIG. 8H. After selecting "edit schematic" in context menu 96, a separate schematic editor 98 is invoked. Using schematic editor 98, the user can move symbols in the schematic, add or delete symbols, etc. In some embodiments, viewer 68 can also operate as an editor. Changes made to the schematic are back-propagated to the selected representation object, and any necessary changes to the project tree automatically made. In at least some embodiments, graphics for a schematic are automatically generated in real-time based on the connectivity information for a selected element in the DDM projects tree. A specific graphical symbol for a particular type of component may be associated with a Cell object (e.g., as an attribute). Even if a specific symbol is not associated with a Cell object, a block or other graphic having the proper number of ports can be automatically generated. As another example of automatic schematic generation, a group of Net objects can be selected in the DDM and a graphic automatically generated to show components receiving the signals corresponding to those Net objects.
[0106] Returning to FIG. 8G, "edit block diagram" in menu 96 allows a user to edit (using a separate block diagram editor or viewer 68) a block diagram for the selected object. In at least some embodiments, a block diagram is similar to a schematic diagram, but may not use conventional schematic symbols. "Edit Verilog" in menu 96 allows a user to edit (using a separate HDL editor, a text editor, or viewer 68) Verilog or other HDL code for a selected object. As with the "edit schematic" option, changes made to a block diagram or HDL code for an object are back propagated to the object, and the projects tree updated automatically.
[0107] In FIG. 8I, the designer has right-clicked a representation node within a hierarchy shown under the Configurations node to invoke a context menu 98. If the selected Representation object is not currently specified by the active Configuration object for the top level Cell object in the hierarchy, the "configure" command causes the Representation object to be specified by the active Configuration object. If a Representation object is already specified by the active configuration of the top level Cell object, "unconfigure" will cause the Representation object to no longer be specified.
[0108] DDM user interfaces for editing a design can be invoked in other manners. In at least some embodiments, a designer may first select an element in the projects tree (by, e.g., clicking once with a left mouse button), and then select various pull-down menus from a tool bar or other menu. Changes to a design can also be made using other plug-ins in combination with the DDM plug-in. For example, a designer may select a design element listed in another plug-in window (e.g., a window for a parts library database viewer) and then drag and drop that element into a particular location on the projects tree. Upon doing so, a dialog (not shown) can be automatically displayed to obtain any additional information needed from the designer to complete the modification. In some embodiments, a separate interconnect table plug-in (not shown in the drawings) can be invoked. Upon selection of a Representation object in the projects tree, for example, a table is displayed. Rows of that table may correspond to Net objects, with columns corresponding to CellInstance objects. An appropriate symbol in a row/column intersection signifies a connection between a Net object and a specified PortInstance object. By selecting a field of the table and modifying the entry (e.g., "B" for bidirectional connection), connectivity between Nets and CellInstances is changed. These changes are then back-propagated to the appropriate objects and the projects tree updated. The interconnect table (or other spreadsheet) can also be used to initially populate a projects tree.
[0109] FIG. 8J shows the "Library" tab of DDM pane 90 selected. Displayed in pane 90 is a "libraries" tree 82. For convenience, tree 82 is shown in FIG. 8K in a more expanded form. The first node under the Libraries node is labeled "Scripts." As explained in more detail below, scripts are used in at least some embodiments of the invention to automate manipulation of various design data objects, to configure front end design program(s), and for various other purposes. Users may select these scripts from the projects tree and then edit and/or execute those scripts. Some scripts are "global," i.e., applicable to all (or many) system users. Other scripts may be specific to a particular user ("User"). Various scripts and script folders are identified generically in FIG. 8K as <script name> or <other scripts>. A node for "Cells" follows the "Scripts" node. Listed under the Cells node are nodes for various Library objects (the first is called "Technology A"). Under each Library object node are entries for one or more Cell objects which a user can add to a design (i.e., associate with a particular Project object). Various Cell objects and Library objects are also identified generically in FIG. 8K.
[0110] Projects tree 80 also contains a node for "libraries" (see, e.g., FIG. 8A). A libraries node in the projects tree lists Library objects associated with a particular Project object. For example, the libraries node in FIG. 8A would contain Library objects associated with the "Design 1" Project object. The libraries tree 82 under the "Libraries" tab lists Library objects accessible by a particular user. This will often (though not necessarily always) include more Library objects than are listed under a projects tree libraries node.
Communicating Design Changes
[0111] In FIG. 9, a user has modified the "Design 1" Project object by adding a new Cell object ("New"). The associated design data changes have not been incorporated into design database 50 (FIG. 7) at this point, and are thus shown in a different color in projects tree 80. If the user wishes the changes to be incorporated into design database 50, the user can select the "Commit" command. Upon doing so, a transaction containing the requested changes is sent from the client to DOS 58, as described below. If the user wishes to save the changes, but does not yet wish to make those changes part of design database 50, the user can select the "Save" command. Saved changes are stored by DOS 58 and can be retrieved by the user for further consideration and/or modification. Upon later retrieval of the saved changes, the user can commit those changes, further edit those changes, or discard those changes. The "Change Request" button is described below.
[0112] In at least some embodiments of the invention, each editing action by a user at a client is tracked by DOS 58. When a first user at a first client selects an object for editing, DOS 58 detects that selection and sends a message to other clients. DDM plug-ins at those other clients then lock the object. Users at those other clients are prevented from editing the selected object while it is locked. As the first user makes design data edits pertaining to the selected object, each edit is detected by DOS 58 and cached in a temporary memory. When the first user decides to incorporate those edits into design database 50 and selects the "Commit" command, a transaction manager plug-in on the first client forwards a transaction to DOS 58 instructing that those changes (which have been cached by DOS 58) be updated to design database 50. After DOS 58 does so, DOS 58 sends transactions to other clients instructing the DDM plug-ins at those clients to release the locked object, as well as providing information to the other clients about the changes made by the first client. The other clients may then update their local copies of the design data to reflect those changes.
[0113] FIGS. 10A-10C are a sequence of diagrams illustrating these events. In FIG. 10A, the user at client 1 has selected an object in a projects tree. Although this selection is made within the DDM plug-in, the selection is also detected by a transaction manager plug-in (e.g., the mouse click event is detected by both the DDM and the transaction manager plug-ins). The transaction manager then sends a message to DOS 58
indicating the object has been selected. In response, DOS 58 sends messages to clients 2 and 3 indicating that the selected object should be locked. The DDM plug-ins at clients 2 and 3 lock the selected object and indicate this locked status with an icon adjacent to the object in the projects tree (shown as a boxed "L" in FIG. 10A) or in another suitable manner. If a user at client 2 or client 3 selects one of the locked objects, the user will be informed (via a document viewer plug-in, via a pop-up dialog, or otherwise) that the object is locked (i.e., read-only) and cannot currently be edited.
[0114] In FIG. 10B, the client 1 user has made a first edit ("edit 1") using the DDM plug-in. The user may have added a new object that is associated with the selected object, may have modified the connectivity or an attribute of the selected object, or may have performed numerous other types of editing tasks. The user does not yet wish to incorporate the edit into design database 50. The client 1 transaction manager plug-in also detects the edit, notes same, and sends a message advising DOS 58 of the edit. DOS 58 caches the edit in temporary memory, but does not notify other clients or attempt to update the edit to design database 50. Activity then proceeds in a similar manner with regard to additional edits. In alternate embodiments (not shown in FIGS. 10A-10C), modifications to DDOM objects are not transmitted to DOS 58 until a user decides to incorporate those changes into the design database.
[0115] In FIG. 10C, the client 1 user has made n edits ("edit 1" through "edit n"). If the client 1 user had decided not to incorporate edits 1
through n into design database 50, but still wanted to save those edits for future consideration, the client 1 user could have selected the "Save" command. The edits cached by DOS 58 would then be saved to a file storage system or other non-volatile storage (not shown in FIG. 10C), and would be available for future retrieval by the client 1 user, but would not be incorporated into design database 50. In the current example, the client 1 user decides to incorporate edits 1 through n into design database 50. Upon selecting the Commit command in the client 1 DDM plug-in, the client 1 transaction manager plug-in sends a transaction to DOS 58 instructing that edits 1 through n be incorporated into design database 50. DOS 58 does so via data APIs 56. DOS 58 also sends transactions to clients 2 and 3 containing edits 1 through n (e.g., copies of objects modified or added, scripts containing instructions to delete objects that may have been deleted, etc.), as well as an instruction to release locked objects.
[0116] Upon receiving the transaction from DOS 58, the transaction manager plug-ins executing at clients 2 and 3 provide information about the transaction to users of clients 2 and 3. The information may include a description of the transaction and the changes made, as well as the identity of the user submitting the transaction. However, the transaction managers at clients 2 and 3 do not automatically incorporate edits 1
through n into the local design data at clients 2 and 3. Instead, the client 2 and client 3 users may choose to apply the design changes made by the client 1 user to the local design data at client 2 and at client 3. FIG. 11A shows, according to at least some embodiments of the invention, a user interface for a transaction manager application executing on client 2 after the transaction of FIG. 10C has been received. The transaction manager user interface has a button or tab for each currently active user. By selecting a tab for a particular user, the client 2 user is able to see the transactions submitted by other users, as well as the individual design changes in each transaction. In FIG. 11A, for example, the client 2 user has selected the button for the client 1 user ("User X") and sees information regarding the transaction of FIG. 10C submitted by user X. Listed below that transaction are the individual design changes included in the transaction. For simplicity, those changes are depicted generically in FIG. 11A as "edit 1" through "edit n." In at least some embodiments, a description of the changes would be included (e.g., "add Cell New"). If the client 2 user presses the "Apply" button, the changes in the transaction are shown in the projects tree of the DDM plug-in. Those changes are shown in a different color or otherwise differentiated from other parts of the design (FIG. 11B). Fur purposes of example, FIG. 11B assumes that one of "edit 1" through "edit n" is addition of a Cell object named "New." If the client 2 user is satisfied with those changes, he or she can select the "Accept" command in the DDM plug-in. Upon doing so, the selected changes are incorporated into the local copy of the design data stored at client 2. If the user selects the Reject command, the changes are not made to the local design data copy at client 2, and the projects tree is returned to its previous condition.
[0117] Although only a single transaction is submitted to clients 2 and 3
in FIG. 10C, this need not be the case. If client 1 had submitted additional transactions, for example, each of those transactions could be displayed in the client 2 (or client 3) transaction manager (e.g., as separate "transaction" nodes in the transaction manager window). If the client 2 user chooses not to accept changes from the transactions regarding the client I user, the client 2 user may still accept those changes at a later time. The client 2 user may also save the local design data stored at client 2 in design database 50 as a separate version, which separate version may not include some or all of the changes made by other users. Even if the client 2 user does not accept all changes made by other users, the design data loaded by the client 2 user at the next logon will include those changes. If the client 2 user has saved a separate version lacking those changes, however, the user may retrieve that version.
[0118] In at least some embodiments, a transaction manager is configurable to filter design changes reported to a client. For example, one user may only be concerned with other users' changes to specific areas of the design data, and may not care what is occurring in other areas. As another example, a user may be concerned with changes to certain types of design elements, but less concerned about changes to other types of design elements. By appropriately setting a filter within the transaction manager plug-in, the transaction manager will only report transactions (or changes within transactions) affecting design elements within the filter settings. In at least some embodiments, a user may also set the transaction manager to automatically apply the filtered changes (i.e., the changes excluded by the filter settings) to the local design data copy at the user's client.
[0119] FIG. 12 shows a filter dialog according to at least some embodiments of the invention. A user may have multiple filter "templates," each of which permits different types of design data transactions to be reported and excludes reporting of other types. When creating a new template (or modifying an existing template), the user may specify an "action type" for design data changes to be reported. The user may further specify, in the "object names" column, particular objects for which transactions should be reported. By selecting "show only committed transactions," the user would only receive transactions that other users have committed to design database 50. Conversely, selecting "all transactions" results in a user being notified of changes cached by DOS 58 but not yet updated to database 50 (see FIG. 10B). "Enable sound" allows the user to receive a beep or other audible alarm when a new transaction is received.
[0120] In at least some embodiments, some or all of the data for a design can be subject to additional restrictions regarding who may edit the data, and/or under what circumstances that data may be edited. For example, a company may not wish to change a design (or portions thereof) for a device currently being produced without taking additional steps to ensure the change is warranted. In such a circumstance, the corresponding data in design database 50 is assigned a lifecycle state of "In Production." If a user selects design elements having an In Production state, the DDM application at the user's client will not allow the user to submit a normal transaction regarding those elements. Instead, the user must initiate a Change Request. Only after the Change Request obtains required approvals can the requested design changes proceed. In at least some embodiments, a Change Request user interface is automatically invoked when a user attempts to edit a design element having a specified lifecycle state value (e.g., "In Production").
[0121] In FIG. 13A, a user has selected a design ("CPU Board") having a lifecycle state of In Production. If the user invoked a context menu, all of the editing options would be shown in gray, indicating those options are not currently available. If the user attempts to edit the object in another manner (e.g., dragging and dropping an object from a parts viewer), the user is notified that the design can only be modified using a Change Request. Accordingly, the user initiates a Change Request dialog, shown in FIG. 13B. Upon initiating the Change Request, the user may then minimize or move the Change Request dialog and proceed to edit the selected object. As such changes are made, a description is automatically added to the description field. The user may also modify that description by restoring the dialog window and typing in the description field. When all of the desired changes have been made, the user can then cause the change request to be transmitted to other users by selecting "Ok." As seen in FIG. 13B, the Change Request dialog can include a listing of other users. The listed users may not currently be connected to DOS 58. The change requestor may select from the listed users the persons to which the Change Request should be forwarded. Those selected users' names will be copied to the Selected Users field. In some embodiments, the permission of certain users (e.g., department managers, etc.) may be required for a particular change order and automatically included in the Selected Users field. In some embodiments, the user may also specify a voting threshold of the selected users required to approve the Change Request, or indicate (by checking the required checkbox under "Selected Users") that the Change Request should not be approved unless specific users approve.
[0122] After the initiating user presses the "OK" button, and as shown in FIG. 13C, an e-mail message is sent to the selected users indicating that the initiating user has sent a Change Request. If a receiving user wishes to approve the change request, he or she may select the "Yes" hyperlink. In at least some embodiments, and as shown in FIG. 13C, the e-mail recipient is also provided a hyperlink ("Click here") to a web page (not shown) containing information about other pending change requests. The web page may also include additional details of those change requests, as well as a check box or other UI that can be used to indicate approval or rejection of the Change Request.
[0123] Once the required approvals are received, the Change Request is automatically processed similar to the transaction of FIG. 10C. In this case, however, the notification of the changes (i.e., the transaction containing the new/modified objects and information about the changes) is also sent to user initiating the Change Request. Because the initiating user does not know if the desired design changes would be allowed until other users respond to the Change Request, those design changes are not made to the initiating user's local design data copy at the time of preparing a Change Request. If the Change Request is not approved (e.g., a required user rejects the change, a sufficiently large number of optional users reject the change, etc.), the initiating user is notified via an e-mail (not shown).
[0124] Although the preceding description of change requests has focused upon "In Production" designs, the invention is not limited to this particular context. For example, a user may be able to edit a design or a portion thereof, but no