Methods, computer programs, and computer systems (design and development of electronic circuit systems in an EDA environment)

Abstract

This invention provides a method for designing electronic circuit systems in an electronic design automation (EDA) environment. [Solution] A method for developing an electronic circuit system design in one or more EDA environments includes the steps of: receiving data indicating an event at a specific point in time during the development of the electronic circuit system design using a first software tool; determining a development action based on the event; determining a library setup describing design data that describes the state of the design at that point in time and libraries used by the first software tool to provide the design in that state; creating a design snapshot data structure including entries representing the design data and library setup; and sharing the design snapshot data structure with a second software tool to enable the execution of a development action using the second software tool.

Description

Technical Field

[0001] The present invention relates to the field of digital computer systems, and more particularly, to a method for developing the design of an electronic circuit system in an Electronic Design Automation (EDA) environment.

Background Art

[0002] In electronic circuit design, especially in the case of large-scale and complex systems, cooperation among multiple team members is important. This is often achieved using special software tools that enable designers to work simultaneously on different aspects of a project. Central to this process is the concept of hierarchical design, where the circuit is divided into modules and the topmost cell represents the highest level of the design. However, an improved process for circuit design development is needed.

Summary of the Invention

Problems to be Solved by the Invention

[0003] An improved process for circuit design development is needed.

Means for Solving the Problems

[0004] Various embodiments provide a method, a computer program product, a database, and a system for developing the design of an electronic circuit system in one or more EDA environments, as described by the subject matter of the independent claims. Advantageous embodiments are described in the dependent claims. Embodiments of the present invention can be freely combined with each other if they are not mutually exclusive.

[0005] In one embodiment, the present invention relates to a method (first method) for developing a design of an electronic circuit system in one or more EDA environments; the method comprises: receiving data indicating an event at a specific point in time during the development of the design of the electronic circuit system using a first software tool; determining a development action based on the event; determining design data describing the state of the design at the point in time and determining a library setup describing the libraries used by the first software tool to provide the design in the state; creating a design snapshot data structure including the design data and the library setup; and sharing the design snapshot data structure with a second software tool to enable the execution of the development action using the second software tool.

[0006] In one embodiment, the present invention relates to a computer program product comprising a computer-readable storage medium in which computer-readable program code is embodied, wherein the computer-readable program code: receives data indicating an event at a specific point in time during the development of the design of the electronic circuit system using a first software tool; determines a development action based on the event; determines design data describing the state of the design at the point in time and determines a library setup describing the libraries used by the first software tool to provide the design in the state; creates a design snapshot data structure including the design data and the library setup; and is configured to share the design snapshot data structure with a second software tool in order to enable the execution of the development action using the second software tool.

[0007] In one embodiment, the present invention relates to a computer system for developing designs of electronic circuit systems in one or more EDA environments; the computer system comprises a first software tool; receives data indicating events at a specific point in time during the development of the design of the electronic circuit system using the first software tool; determines development actions based on the events; determines design data describing the state of the design at the point in time; determines a library setup describing libraries used by the first software tool to provide the design in the state; creates a design snapshot data structure including the design data and the library setup; and is configured to share the design snapshot data structure with a second software tool to enable the execution of the development actions using the second software tool.

[0008] In one embodiment, the present invention relates to a database comprising a plurality of computer implementation data structures, each computer implementation data structure being adapted for performing development actions relating to the design of an electronic circuit system, the data structure having design data and library setup for opening the design, the design data describing the state of the design at the time of the development action, and the library setup describing the libraries used by the design data. [Brief explanation of the drawing]

[0009] Hereinafter, embodiments of the present invention will be described in more detail with reference to the following drawings, merely as examples.

[0010] [Figure 1] This section shows a block diagram of a collaborative electronic circuit system design system, as an example of this subject.

[0011] [Figure 2]This flowchart illustrates an example of how a design team can develop an electronic circuit system design using software tools.

[0012] [Figure 3] This is a flowchart illustrating an example of how to perform development actions related to the design of an electronic circuit system using software tools.

[0013] [Figure 4] This diagram shows an example of a design snapshot data structure for this topic.

[0014] [Figure 5] This is a computing environment based on an example of the subject matter. [Modes for carrying out the invention]

[0015] The descriptions of various embodiments of the present invention are presented for illustrative purposes only and are not intended to be comprehensive or limit the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been selected to best describe the principles of the embodiments, their practical applications, or the technical improvements to the technology available on the market, or to enable other those skilled in the art to understand the embodiments disclosed herein.

[0016] This topic can enable improved synchronization between different software tools in the same or different EDA environments. By capturing and sharing design snapshots, including design data and library setups at specific points in time, this topic can ensure that a second software tool can replicate a precise design environment and state. This can improve consistency and accuracy, and enable the seamless continuation of development actions without inconsistencies between tools. In addition, traceability is improved through event-based snapshots, allowing users to return to specific moments in the design process and ensuring better version control and error tracking. Furthermore, event-based snapshots can be automatically generated in response to major milestones or changes in the design process, ensuring they capture critical moments such as corrections, errors, or approvals. This automation of the process can reduce manual effort, improve efficiency, and minimize the possibility of errors when replicating the design environment.

[0017] In this specification, terms such as "first," "second," etc., are used as labels for preceding nouns and do not imply any type of ordering (e.g., spatial, temporal, or logical) unless explicitly defined as such.

[0018] The design of an electronic circuit system may be created and developed using a first software tool in a first EDA environment. A user or developer may control or monitor the development of the design of the electronic circuit system. This user may be referred to as the first user. For example, the first user may start running the first software tool on the first user's first computer system. An electronic circuit system may refer to a set of interconnected components designed to work together to perform a specific function, usually through the processing, control, or transmission of electrical signals. An electronic circuit system may be an integrated circuit (IC), such as a microprocessor IC.

[0019] An EDA environment can refer to a software ecosystem that provides tools, methodologies, and frameworks for the design, simulation, verification, and optimization of electronic circuits and systems. It encompasses software solutions that support various aspects of the design flow of integrated circuits and electronic systems, from conceptual design and schematic capture to layout, physical implementation, verification, and final approval. Software tools can be components of an EDA environment, providing functionality for interactive layout design and verification. For example, a software tool within an EDA environment might be an IC development tool for creating, editing, and verifying integrated circuit designs. An instance of a software tool can refer to a specific event or running copy of that software tool on a particular system. Each instance of a software tool can operate independently. Multiple instances of a software tool can exist simultaneously, each potentially performing different actions or working on separate tasks. For example, if a software tool is open on two different computer systems, each may represent a separate instance of the software tool, operating with its own state and data.

[0020] A design can refer to a representation of an electronic circuit system within a computer system. Designs developed using software tools can be further utilized in other stages within the EDA environment. These other stages may include physical verification, performance validation through simulation, simulation to evaluate the design after the completion of the physical layout, and timing analysis. The design may provide views that capture specific aspects of the design. For example, a schematic view of a design may represent a logical or functional diagram of the electronic circuit system, showing how components such as transistors, resistors, and capacitors are electrically connected. A layout view of a design may be a physical representation that shows in detail the actual geometric arrangement of components and wiring on a chip or printed circuit board (PCB), which may be important for manufacturing. A symbol view of a design may simplify complex components or circuits into a single block symbol for higher-level design. A netlist view of a design may be a list of the elements of the electronic circuit system and their connections in a text-based format, often used for simulation or verification. These views work together to ensure that the design is functionally accurate, optimized for performance, and ready for manufacturing. By using any of these views, the design can serve as the foundational framework from which the final product or solution can be developed.

[0021] Events related to a specific point in time during the development of an electronic circuit system design using a first software tool may be received by a first computer system. An event can refer to a significant event, while a "point in time" can indicate when it occurs in the development timeline. In one example, an event may be triggered by time. For example, an event may be defined by a pre-scheduled milestone such as a design review or test deadline. Additionally or alternatively, an event may be triggered by an action, initiated by a specific action or change such as a design modification, error detection, or approval of a design element. Additionally or alternatively, an event may be triggered by an external condition such as the completion of a simulation, resource availability, or feedback from one or more users, such as a first user. In all cases, a "specific point in time" can function as a precise marker, ensuring accurate recording of events, improving traceability, and aligning it within a broader development timeline for better development management.

[0022] Receiving an event may include receiving a description of the event. This description may be provided as an input by a first user, in which case the event is triggered by the first user. Alternatively, the event may be automatically detected by an event detection module within a software tool, for example, through an action-triggered or time-triggered mechanism. In this scenario, the description of the event may be received from the event detection module. The description may be provided in a format that can be processed by a first computer system. The format of the event description may vary according to the needs of the system. The event description may be provided as a structured text file such as XML or JSON, providing main details such as event type, timestamp, user ID, and associated changes or actions taken. Alternatively, the description may be a log entry within a database, storing information such as a unique ID of the event, the time of the event, and specific parameters or actions involved. Each format is designed to ensure that the event description can be easily read, processed, or referenced by the first computer system for further action or analysis.

[0023] Development actions may be determined based on the received event. Development actions may be determined by a first computer system using the description of the received event. Development actions may be consistent with the nature of the event trigger. For example, in the case of a time-triggered event such as a design review or test deadline, development actions may include starting a formal review process or executing an automated test. In the case of an action-triggered event such as a design modification, error detection, or approval, development actions may include executing a corrective action or debugging an error. In the case of an externally-triggered event such as an action requested by a user, development actions may include the action requested by that user. These actions may ensure that the development process progresses efficiently and maintains consistency with project goals.

[0024] The first computer system can automatically determine development actions based on event descriptions, for example, by using predefined rules and event-action mappings within a software tool. For example, the first computer system can analyze an event description to identify key details such as the event type (e.g., design modification, error detection, or simulation completion), and match it against corresponding actions based on pre-programmed logic. For example, if an error is detected, the first computer system can trigger debugging or alert relevant team members. Development actions can include, for example, one or more computer-executable instructions. Alternatively, the development actions can be presented as user prompts such as notifications or alerts within the software tool, providing details regarding the development actions.

[0025] After determining a development action, design data describing the state of the design at that point in time, and a library setup describing the libraries used by a first software tool to provide the design in that state, may be determined. For example, once a development action is determined, the next action may be to capture design data describing the state of the design at that particular point in time, including all relevant information such as the components used, their interconnections, and other design parameters. Capturing this design state allows developers to save a complete record of what the design looks and functions at that point in time, providing a useful snapshot that can be used for debugging, rolling back, or further development without losing track of previous design versions. In addition to the design data, this method involves identifying a library setup that references libraries on which the design depends, such as component libraries, IP blocks, or other reusable assets. The library setup can document which libraries were used and in what configuration. By explicitly recording this information, developers can ensure that the design remains portable and can be accurately reconstructed on different systems. Because all dependencies are clearly identified and traceable, this method can also help avoid compatibility issues.

[0026] A design snapshot data structure can be created that includes design data and library setup. For example, after capturing design data and library setup, a design snapshot data structure can be created, serving as a record of the design at that specific point in time. This data structure may contain entries representing both design data and library setup, encapsulating the complete state of the design at a particular point in time. Creating this snapshot can make it possible to easily share, store, and retrieve the design state later. It can function as a backup, allowing the team to revert to a previous state if necessary, or to transfer the design to other tools or collaborators without losing any fidelity.

[0027] A design snapshot data structure can be a data structure. A design snapshot data structure can be a representation that captures and stores the state of a design at a specific point in time. It may include all relevant information such as configuration, components, and any dependencies or libraries in use. The term "snapshot" may indicate that the data structure allows developers or users to save a precise state of the design, enabling them to later review, share, or revert to that particular version without losing any data or context. Examples of design snapshot data structures may include arrays, linked lists, trees, and graphs, each of which may be suitable for different types of operations and applications depending on factors such as data organization, access speed, and memory usage. A design snapshot data structure can be formatted in a way that allows both a first and second software tool to decode and read it. A design snapshot data structure may have a predefined format that can be called a standardized format because it ensures consistency and compatibility across different software tools and different EDA environments. This standardization can enable seamless integration, data exchange, and collaboration between various software tools.

[0028] The design snapshot data structure may be shared with a second software tool in a second EDA environment to enable the execution of development actions using the second software tool. For example, the design snapshot data structure may be shared with a second software tool, which may involve transferring the design snapshot data structure to another developer or team working on a different machine or performing development actions on a different server or environment. For example, a second user may start running the second software tool on their second computer system. The second user may be, for example, a contributor or debugger to the design of an electronic circuit system. Sharing snapshots ensures that all collaborators have access to the same design version, which can reduce errors and improve synchronization in large teams or distributed environments. The first and second EDA environments may be the same or different, and if they are the same, they may represent one instance or separate instances of the EDA environment.

[0029] A second software tool may be used to perform development actions based on the design snapshot data structure. In one example, the development action may be automatically executed on a second computer system using the second software tool as soon as the design snapshot is shared. Alternatively, the second computer system may prompt a second user to perform the development action, which can then be completed by the second user using the second software tool.

[0030] In one example, the first and second software tools are two instances of the same software tool in the same EDA environment; that is, the first and second EDA environments are identical. Alternatively, the first and second software tools are different tools in different EDA environments; that is, the first and second EDA environments are different. When the first and second software tools are instances of the same software tool and the same EDA environment, seamless integration and direct interoperability can be ensured, potentially reducing the risk of data conversion errors and improving consistency in the design process. Alternatively, when the first and second software tools belong to different EDA environments, this flexibility can enable broader compatibility and collaboration across multiple platforms.

[0031] According to one example, development actions include at least one of the following: addressing detected bugs and / or bugs in a first software tool that represent design rule violations, or incorporating contributions to the design. For example, a bug may first manifest on a first computer system due to a particular configuration or design state. Alternatively, the first software tool may continue development of a design initially started by another software tool. In this case, a bug may occur when the transferred design is opened or during further development, potentially due to compatibility issues, differences in interpretation of design data, or inconsistencies introduced during a handover between tools. Addressing detected bugs or bugs in a first software tool that represent design rule violations may involve identifying and resolving them in the EDA environment. A design rule violation may occur when a design fails to adhere to specific guidelines or constraints set by the design process in the EDA environment, such as spacing requirements, minimum dimensions, or maximum dimensions. In contrast, a bug may refer to an error or defect in a software tool, such as an unexpected crash or a command execution error. Resolving these issues may involve modifying the design to comply with design rules, or updating and debugging software tools.

[0032] In one example, the design snapshot data structure may further include metadata describing a first software tool. This metadata might include, for example, the version or configuration of the first software tool. This could enable precise bug tracking and debugging by linking issues to specific software tool versions.

[0033] In fact, development actions in the context of electronic circuit system design may involve tasks such as addressing detected bugs or incorporating contributions. For example, addressing or fixing bugs can ensure the integrity and reliability of the design, preventing it from failing in real-world applications. Addressing bugs also helps maintain consistency in design functionality and can prevent regressions. In another example, debugging a problem may require a deeper investigation into specific issues that may relate to timing, functionality, or physical layout. For example, in complex systems, debugging may be necessary because problems can arise from unexpected interactions between design components. Debugging can, for example, allow for the isolation of the root cause of a problem and ensure that the design operates within its required parameters. In yet another example, incorporating contributions may involve merging new design elements or improvements from a second user. This can streamline collaborative development and ensure that the design can benefit from improvements, optimizations, or additional features contributed by others.

[0034] According to one example, sharing a design snapshot data structure involves either: storing the design snapshot data structure in shared memory between a first software tool and a second software tool; or sending the design snapshot data structure to the second software tool using a workplace messaging platform.

[0035] A workplace messaging platform can be a digital communication tool designed to enable real-time messaging. Workplace messaging platforms can streamline workflows by enabling features such as text-based chat, file sharing, and integration with other tools and software. They can support both direct messaging (one-on-one communication) and group conversations (team channels or group chats).

[0036] Both sharing methods can enable smooth collaboration by ensuring that the design snapshot data structure is transferred consistently, but the choice may depend on factors such as the proximity of the software tools, the need for speed, and whether the collaboration is synchronous or asynchronous. For example, one option might be to store the design snapshot data structure in shared memory accessible by both the first and second software tools. This can enable fast access and minimal data transfer overhead, particularly in environments where both tools are running on the same system or network. Shared memory allows both tools to directly access the design snapshot data structure, ensuring synchronous updates and real-time collaboration. An alternative option might involve sending the design snapshot data structure to the second software tool via a workplace messaging platform. This approach may be motivated by the need for remote collaboration or when the tools are running on different machines, for example, in different geographical locations. Sending the design snapshot data structure via a workplace messaging platform can enable easy sharing in distributed work structures where team members may not have direct access to the shared memory environment. This method can also provide a record of design snapshot data structures within the platform, which can be useful in facilitating change tracking, version control, and asynchronous development workflows.

[0037] According to one example, the method further comprises: a step of using a shared design snapshot data structure to create a temporary library setup that includes a library setup by adding at least one or more libraries and / or updating one or more existing libraries of a second software tool; a step of using a second software tool to open a design with the design data and the temporary library setup; and a step of performing development actions using the second software tool. This example may be run on a second computer system of a second user and optionally further run on other computer systems using their respective software tools.

[0038] In fact, using a shared design snapshot data structure can enable the creation of a temporary library setup by adding or updating one or more libraries that are associated with or accessible by a second software tool. This temporary library setup can integrate library setups from the shared design snapshot data structure, allowing the second software tool to open the design using the design data and the temporary library setup. The second software tool can then be used to perform development actions. The advantages of this process include ensuring consistency in the design environment across multiple instances, enabling collaborative work while accommodating necessary modifications, and avoiding conflicts between library versions and maintaining synchronization between different teams or systems.

[0039] In one example, creating a temporary library setup and opening a design are performed automatically using a library manager configured to connect to a second software tool through an interface.

[0040] A second software tool in a second EDA environment may be used to design and develop electronic circuit systems such as ICs and printed circuit boards (PCBs). In this scenario, the process of creating a temporary library setup and opening the design can be handled automatically by a library manager. The library manager may be specially configured to connect to the second software tool via an interface, enabling seamless integration of design data and necessary libraries with the second software tool. The library manager can ensure that the correct versions of libraries are selected, regardless of whether they need to be added, updated, or replaced in the temporary library setup. This automated management can save a considerable amount of time and reduce the possibility of human errors such as selecting or misconfiguring the wrong library version. In addition, it ensures that the second software tool operates with the most accurate and compatible libraries.

[0041] In one example, the interface is a web interface, where the shared design snapshot data structure is provided as a link to the interface, and creating a temporary library setup and opening the design is performed automatically in response to calling the link.

[0042] The fact that the interface is a web interface may mean that it operates through a browser or internet-based application. The shared design snapshot data structure may be provided as links within this web interface, simplifying access and usability. When a link is invoked (e.g., clicked), the process of creating a temporary library setup and opening the design may be automatically initiated. The advantage of using a web interface may be that it can provide platform-independent access, allowing users to easily access the design and its library from anywhere with internet access. The link-based approach can simplify collaboration by enabling teams to quickly share and open specific design states without the need to send large files or manually configure the environment.

[0043] In one example, a temporary library setup may be deleted after a development action is complete. This deletion may further involve restoring a second software tool to its state before using the shared design snapshot data structure. This ensures that unnecessary resources are not occupying storage and can prevent potential conflicts with future designs. In another example, a temporary library setup may be maintained as a permanent configuration, for example, if the library is expected to be reused in subsequent development actions. This avoids the need to recreate the setup each time and can facilitate continuous development without reconfiguring the library environment.

[0044] In one example, the design data describes a first cell representing the design, where the library setup includes a library for the first cell and one or more second cells representing the components of the design, and the design represents the physical or logical design of an electronic circuit system.

[0045] In this example, the design data represents the first cell, which can function as the core or main element of the electronic circuit system design, while the library setup may contain libraries necessary for both the first and second cells, representing the sub-components of the design. Each second cell can function as a smaller building block contributing to the overall electronic circuit system. By organizing the design into main cells and supporting component cells, this approach enhances modularity and can make complex designs easier to manage, modify, and understand.

[0046] In one example, the library is determined by navigation according to the design architecture of the first and second cells.

[0047] Libraries associated with a design cell are identified by navigating a computer directory representing the design architecture. This navigation can therefore be based on the design architecture, which outlines the structure and relationships between the first and second cells. This design architecture can guide the selection of the appropriate libraries needed for each part of the design. This approach can also streamline the process by automating the selection of appropriate resources based on the internal structure of the design, thereby improving both efficiency and consistency.

[0048] In one example, the design architecture is a hierarchical architecture, where the first cell is the top-level cell, the second cell is a sub-hierarchical cell, and navigation is a hierarchical traversal starting from the first cell.

[0049] The design architecture in this example follows a hierarchical structure, where the first cell acts as the top-level cell and the second cell acts as a sub-hierarchical cell. Navigation through the design can be achieved through hierarchical traversal, starting from the top-level cell and moving through its subcells. This hierarchical architecture can provide a clear and organized structure, with the top-level cell managing the overall system and the subcells focusing on specific components. Hierarchical traversal can systematically manage complex designs and ensure that dependencies between components are handled accurately.

[0050] In one example, a first software tool is run on a first computer system, and a second software tool is run on a second computer system, where the first and second computer systems are co-located or remotely connected.

[0051] The first and second computer systems can either be co-located and situated in the same physical location, or they can be remotely connected via a network. This setup allows the two systems to collaborate on the same design using shared data, even if they are geographically separated. The advantage of this configuration is that it can provide flexibility in the development environment. Co-located systems enable high-speed, high-bandwidth collaboration, ideal for environments where teams need to work closely together. Remotely connected systems can offer greater flexibility, enabling global collaboration across different time zones and reducing the need for physical proximity. This setup can support distributed development, allowing multiple team members to work on the same design without version conflicts. In addition, it can help with load balancing by distributing demanding tasks across multiple systems.

[0052] In one example, library setup includes the library's path and version. Libraries used within an EDA environment may be provided by the EDA vendor, obtained from open-source distributors, or created by users or companies working with EDA tools. Libraries in an EDA environment can function as a structured collection of design components, standard cells, process-specific technical files, and simulation models. These libraries can enable designers to access predefined elements, adhere to technology-specific design rules, and maintain consistency throughout the design and verification process.

[0053] The path can refer to the location or directory of a specific file where the library is stored, while the version can refer to a specific release or iteration of each library being used. This setup can be important to ensure that the design has access to the exact libraries and dependencies necessary to function properly.

[0054] In one example, multiple design snapshot data structures may be created at different points in time using a first software tool or another software tool. For example, multiple design snapshot data structures may be created for development actions involving detected bugs. That is, each design snapshot data structure in the multiple design snapshot data structures may provide the design state of the electronic circuit system at the time the bug was detected. That is, multiple bugs may be associated with multiple design snapshot data structures. These design snapshot data structures may be collected in a database so that, for example, other users can access them to perform development actions. For example, the database may have entries, where each entry may contain the respective design snapshot data structure.

[0055] The database can be configured to handle development query lookups, allowing the user to identify data structures corresponding to a specified development stage. Upon receiving a query, the database processes the lookup by matching the query parameters against stored data structures and their associated descriptions.

[0056] In one example, a workplace messaging platform used to share a design snapshot data structure might include a database that collects / maintains data while the design snapshot data structure is being shared.

[0057] Figure 1 shows a block diagram of an electronic circuit system design collaboration system, which is an example of this subject.

[0058] The electronic circuit system design coordination system 100 comprises a first computer system 101 and a second computer system 102. The first computer system 101 is configured to communicate with the second computer system 102 via a communication link 103. The communication link 103 enables synchronization and data exchange, allowing development actions or design updates from one system to be reflected on the other system. The communication link 103 can be any type of network connection that enables data exchange, such as a Local Area Network (LAN) or Wide Area Network (WAN) for local or remote communication, Ethernet® for wired connections, or Wi-Fi® for wireless networking. Other options may include Bluetooth® for short-range wireless communication, or optical fiber for high-speed, high-bandwidth data transfer over longer distances.

[0059] The first computer system 101 comprises memory 101b and a processor 101a. Memory 101b contains a first software tool 101c of the first EDA environment. The processor 101a may be configured to run the first software tool 101c. The second computer system 102 comprises memory 102b and a processor 102a. Memory 102b contains a second software tool 102c of the second EDA environment. The processor 102a may be configured to run the second software tool 102c. The first EDA environment and the second EDA environment may be the same or different, and if they are the same, they may represent the same instance or distinct instances of that environment.

[0060] Each user, User 1 and User 2, interacts with their respective software tools (Tool 1 or Tool 2) to perform circuit design and development actions. Users 1 and User 2 can collaborate using the software tools on their respective systems. User 1, the first user, can work with the first software tool 101c to develop the design of an electronic circuit system, while User 2, the second user, can work with the second software tool 102c to contribute, for example, to the development of the design of an electronic circuit system.

[0061] Figure 2 is a flowchart illustrating an example of a method for developing an electronic circuit system design using software tools in one or more EDA environments. For illustrative purposes, the method described in Figure 2 may be implemented in the system illustrated in Figure 1, but is not limited to this implementation. The method may be performed, for example, by a first computer system 101.

[0062] An event relating to a specific point in time during the development of an electronic circuit system design using the first software tool may be received in step 201.

[0063] The development action may be determined in step 203 based on the received event.

[0064] In step 205, design data describing the design state at that point in time, and library setup describing the libraries used by said design data may be determined.

[0065] A design snapshot data structure containing entries representing the design data and library setup may be created in step 207.

[0066] The design snapshot data structure may be shared with the second software tool in step 209 for the execution of development actions using the second software tool.

[0067] Figure 3 is a flowchart illustrating a method for performing development actions related to the design of an electronic circuit system using a second software tool, as an example of this subject. For illustrative purposes, the method described in Figure 3 may be implemented in the system illustrated in Figure 1, but is not limited to this implementation. This method may be performed, for example, by a second computer system 102.

[0068] In step 301, a design snapshot data structure containing design data and entries representing the library setup may be used to create a temporary library setup that includes the library setup. The temporary library setup may be created by adding at least one or more libraries and / or updating one or more existing libraries of a second software tool.

[0069] A second software tool may be used in step 303 to open the design using the design data and temporary library setup.

[0070] A second software tool may be used in step 305 to perform development actions.

[0071] Figure 4 shows a diagram representing a design snapshot data structure 400 in an example of this subject. In this example, software tools in the EDA environment are used to develop the design represented by the design snapshot data structure. The diagram of the design snapshot data structure 400 captures the elements of the design and their associated dependencies.

[0072] The first entry, 401, indicates that the top-level cell being referenced is CELL_NAME. The first entry, 401, further indicates that the design is being worked on in its layout view, which points to a physical representation of the electronic circuit system, and the current version is identified as 1.1, indicating a particular iteration of the design.

[0073] In addition, the second entry 403 indicates the library setup. Specifically, the second entry 403 specifies that the primary library used is LIB_NAME1 (version libLevel1), located at / full / path / to / LIB_NAME1. The second entry 403 further lists the dependent libraries required for the design's functionality: DEPENDENT_LIB_NAME2 (version libLevel2), DEPENDENT_LIB_NAME3 (version libLevel3), and DEPENDENT_LIB_NAME4 (version libLevel3), each with its defined path. These paths and version numbers ensure that the design can be accurately reconstructed or shared across different instances or systems, guaranteeing consistency and compatibility of the design and its dependencies. This snapshot technique helps protect the integrity of the design, makes collaboration and version control more efficient, and ensures that all necessary libraries are readily available. In one example, the design snapshot data structure 400 may further contain entries containing metadata describing the software tools, such as the software tool's version and its configuration settings. The design snapshot data structure 400 may further have entries that include time information, such as a timestamp, that indicate a specific point in time during the development process and capture the state of the design at that moment.

[0074] This subject matter may include the following clauses:

[0075] [Clause 1] A method for developing a design of an electronic circuit system in one or more electronic design automation (EDA) environments, comprising: receiving data indicating an event at a specific point in time during the development of the design of the electronic circuit system using a first software tool; determining a development action based on the event; determining design data describing the state of the design at the point in time and determining a library setup describing libraries used by the first software tool to provide the design in the state; creating a design snapshot data structure including the design data and the library setup; and sharing the design snapshot data structure with a second software tool to enable the execution of the development action using the second software tool.

[0076] [Clause 2] The method according to Clause 1, wherein the development action includes at least one of the following steps: addressing detected bugs and / or bugs in the first software tool that represent violations of design rules, or incorporating contributions to the design.

[0077] [Clause 3] The method described in any one of the preceding clauses 1 to 2, wherein the first software tool and the second software tool are two instances of the same software tool in the same EDA environment, and the first software tool and the second software tool are different tools in different EDA environments.

[0078] [Clause 4] The design snapshot data structure further includes metadata describing the first software tool, as described in any one of the preceding clauses 1 to 3.

[0079] [Clause 5] The method according to any one of the preceding clauses 1 to 4, wherein the sharing step comprises: storing the design snapshot data structure in shared memory between the first software tool and the second software tool; and transmitting the design snapshot data structure to the second software tool using a workplace messaging platform.

[0080] [Clause 6] The method according to any one of the preceding clauses 1 to 5, further comprising: a step of using the shared design snapshot data structure to create a temporary library setup including the library setup by adding at least one or more libraries and / or updating one or more existing libraries of the second software tool; a step of using the second software tool to open the design using the design data and the temporary library setup; and a step of performing the development action using the second software tool.

[0081] [Clause 7] The method according to Clause 6, wherein the creation of the temporary library setup and the opening of the design are performed automatically using a library manager configured to connect to the second software tool through an interface.

[0082] [Clause 8] The method of Clause 7, wherein the interface is a web interface, where the shared design snapshot data structure is provided as a link to the interface, and the creation of the temporary library setup and the opening of the design are performed automatically in response to calling the link.

[0083] [Clause 9] The method according to any one of the preceding clauses 1 to 8, wherein the design data describes a first cell representing the design, and the library setup includes a library for the first cell and one or more second cells representing components of the design.

[0084] [Clause 10] The library is determined by navigation according to the design architecture of the first and second cells, as described in Clause 9.

[0085] [Clause 11] The method according to clause 10, wherein the design architecture is a hierarchical architecture, where the first cell is the top-level cell, the second cell is a sub-hierarchical cell, and the navigation is a hierarchical traversal starting from the first cell.

[0086] [Article 12] The method according to any one of the preceding clauses 1 to 11, wherein the first software tool is executed on a first computer system, and the second software tool is executed on a second computer system, wherein the first computer system and the second computer system are co-located or remotely connected systems.

[0087] [Clause 13] The library setup described above is the method described in any one of the preceding clauses 1 to 12, including the path and version of the library.

[0088] The computing environment 800 includes an example of an environment for executing at least a portion of the computer code involved in performing the method of the present invention, such as code 900 for developing the design of an electronic circuit system using software tools. In addition to block 900, the computing environment 800 includes, for example, a computer 801, a wide area network (WAN) 802, an end user device (EUD) 803, a remote server 804, a public cloud 805, and a private cloud 806. In this embodiment, the computer 801 includes a processor set 810 (including processing circuits 820 and a cache 821), a communication fabric 811, volatile memory 812, persistent storage 813 (including an operating system 822 and the block 900 identified above), a peripheral device set 814 (including a user interface (UI), a device set 823, storage 824, and an Internet of Things (IoT) sensor set 825), and a network module 815. The remote server 804 includes a remote database 830. Public Cloud 805 includes Gateway 840, Cloud Orchestration Module 841, Host Physical Machine Set 842, Virtual Machine Set 843, and Container Set 844.

[0089] Computer 801 can take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device, currently known or to be developed in the future, capable of executing programs, accessing networks, or querying databases such as the remote database 830. As is well understood in the field of computer technology, and depending on the technology, the execution of a computer implementation can be distributed among multiple computers and / or multiple locations. On the other hand, in this presentation of the computing environment 800, in order to keep the presentation as concise as possible, the detailed discussion focuses on a single computer, specifically computer 801. Although computer 801 is not shown in the cloud in Figure 5, it can be located in the cloud. On the other hand, computer 801 does not need to be located in the cloud, except to any extent that can be definitively shown.

[0090] The processor set 810 includes one or more computer processors of any type currently known or to be developed in the future. The processing circuitry 820 may be distributed across multiple packages, for example, multiple coordinated integrated circuit chips. The processing circuitry 820 may implement multiple processor threads and / or multiple processor cores. The cache 821 is memory located within the processor chip package and is typically used for data or code that should be available for high-speed access by threads or cores running on the processor set 810. The cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, the processor set 810 may operate using qubits and be designed to perform quantum computing.

[0091] Computer-readable program instructions are typically loaded onto computer 801, causing the processor set 810 of computer 801 to execute a series of operational steps, thereby enabling the computer implementation method. As a result, the instructions thus executed instantiate the method specified in the flowcharts and / or descriptions of the computer implementation method contained herein (collectively referred to as the "Method of the Invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 821 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 810 to control and direct the execution of the Method of the Invention. In the computing environment 800, at least some of the instructions for executing the Method of the Invention may be stored in block 900 in persistent storage 813.

[0092] The communication fabric 811 is a signal conduction path that enables various components of the computer 801 to communicate with one another. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and similar components. Other types of signal communication paths may be used, such as optical fiber communication paths and / or wireless communication paths.

[0093] Volatile memory 812 is any type of volatile memory currently known or to be developed in the future. Examples include dynamic random-access memory (RAM) or static RAM. Typically, volatile memory 812 is characterized by random access, but this is not mandatory unless explicitly stated. In computer 801, volatile memory 812 is located in a single package and resides inside computer 801, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally to computer 801.

[0094] Persistent storage 813 is any form of non-volatile storage for a computer, currently known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is supplied to computer 801 and / or directly to persistent storage 813. Persistent storage 813 may be read-only memory (ROM), but typically at least a portion of persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 822 can take multiple forms, such as various known proprietary operating systems or open-source portable operating system interface type operating systems employing a kernel. The code contained in block 900 typically includes at least a portion of computer code involved in performing the method of the present invention.

[0095] The peripheral device set 814 includes a set of peripheral devices for computer 801. Data communication connections between computer 801's peripheral devices and other components can be implemented in various ways, including Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cables (such as universal serial bus (USB) type cables), insertable connections (e.g., secure digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, the UI device set 823 may include components such as a display screen, speaker, microphone, wearable devices (such as goggles and smartwatches), keyboard, mouse, printer, touchpad, game controller, and haptic devices. Storage 824 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 824 may be persistent and / or volatile. In some embodiments, storage 824 may take the form of a quantum computing memory device for storing data in the form of qubits. In embodiments where computer 801 is required to have a large amount of storage (for example, computer 801 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 825 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0096] The network module 815 is a collection of computer software, hardware, and firmware that enables computer 801 to communicate with other computers via the WAN 802. The network module 815 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the internet. In some embodiments, the network control and network forwarding functions of the network module 815 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control and forwarding functions of the network module 815 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for performing the method of the present invention can typically be downloaded to computer 801 from an external computer or external storage device via a network adapter card or network interface included in the network module 815.

[0097] WAN802 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances using any currently known or future-developed technology for transmitting computer data. In some embodiments, WAN802 may be replaced and / or supplemented by a local area network (LAN), such as a Wi-Fi network, designed to transmit data between devices located in a local area. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0098] An end-user device (EUD) 803 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 801) and can take any of the forms discussed above in relation to computer 801. EUD 803 typically receives useful and valuable data from the operation of computer 801. For example, in a hypothetical case where computer 801 is designed to provide recommendations to an end-user, these recommendations would typically be communicated from computer 801's network module 815 to EUD 803 via WAN 802. In this way, EUD 803 can display or otherwise present the recommendations to the end-user. In some embodiments, EUD 803 may be a client device such as a thin client, heavy client, mainframe computer, desktop computer, and the like.

[0099] The remote server 804 is any computer system that provides at least some data and / or functionality to computer 801. The remote server 804 may be controlled and used by the same entity that operates computer 801. The remote server 804 represents a machine that collects and stores useful and valuable data for use by other computers, such as computer 801. For example, in a hypothetical case where computer 801 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 801 from the remote database 830 of the remote server 804.

[0100] Public Cloud 805 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computer functions, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of Public Cloud 805's computing resources is performed by the computer hardware and / or software of the Cloud Orchestration Module 841. The computing resources provided by Public Cloud 805 are typically implemented by virtual computing environments running on various computers that make up the host physical machine set 842, which is the universe of physical computers within and / or available in Public Cloud 805. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine set 843 and / or containers from the container set 844. These VCEs can be stored as images and transferred between and between various physical machine hosts, either as images or after VCE instantiation. The cloud orchestration module 841 manages the transfer and storage of images, deploys new VCE instantiations, and manages active instantiations of VCE deployments. The gateway 840 is a collection of computer software, hardware, and firmware that enables the public cloud 805 to communicate through the WAN 802.

[0101] Here, some further explanation of virtualized computing environments (VCEs) is provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave like actual computers in terms of the programs running within them. Computer programs running on a normal operating system can utilize all of that computer's resources, including connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to the container; this feature is known as containerization.

[0102] Private Cloud 806 is similar to Public Cloud 805, except that its computing resources are available for use by a single enterprise only. While Private Cloud 806 is shown as being in communication with WAN 802, in other embodiments, the private cloud may be completely isolated from the internet and accessible only through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate, discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configured clouds. In this embodiment, both Public Cloud 805 and Private Cloud 806 are part of a larger hybrid cloud.

[0103] Cloud computing services and / or microservices (not shown separately in Figure 5): Private and public clouds are programmed and configured to deliver cloud computing services and / or microservices (unless otherwise indicated, the term “microservices” should be interpreted to include larger “services,” regardless of scale). Cloud services are typically infrastructure, platforms, or software hosted by a third-party provider and made available to users over the internet. Cloud services facilitate the flow of user data from front-end clients (e.g., user-side servers, tablets, desktops, laptops) to the provider’s systems over the internet and vice versa. In some embodiments, cloud services can be configured and orchestrated according to the “as a service” technology paradigm, where something is presented to internal or external customers in the form of a cloud computing service. An As-a-Service offering typically provides endpoints that various customers interface with. These endpoints are typically based on a set of APIs. One category of as-a-service offerings is Platform as a Service (PaaS), where a service provider provisions, instantiates, runs, and manages modular bundles of code that customers can use to instantiate a computing platform and one or more applications without the complexity of building and maintaining the infrastructure typically associated with them. Another category is Software as a Service (SaaS), where software is centrally hosted and allocated on a subscription basis. SaaS is also known as on-demand software, web-based software, or web-hosted software.The four technical subfields involved in cloud services are: deployment, integration, on-demand, and virtual private networks.

[0104] Various aspects of this disclosure are described by explanatory text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than those shown in a given flowchart. For example, also depending on the technology involved, two operations shown in consecutive blocks of a flowchart may be performed in reverse order, as a single integrated step, simultaneously, or with at least partial time overlap.

[0105] Embodiments of a computer program product ("CPP Embodiment" or "CPP") are terms used in this disclosure to describe any set of one or more storage media (also called "Multiple Media") that collectively comprise a set of one or more storage devices and collectively comprise machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. "Storage Device" is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media may, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any preferred combination thereof. Some known types of storage devices, including these media, include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disk read-only memory (CD-ROM), digital purpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices (such as pits / lands formed on the main surface of punch cards or disks), or any suitable combination of those described above. When the term "computer-readable storage medium" is used in this disclosure, it shall not be construed as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals communicated through wires, and / or other transmission media. As will be understood by those skilled in the art, data is normally moved at several intermittent points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection; however, data is not transient while it is stored, and this does not mean that a storage device is transient.

Claims

1. A method for developing the design of an electronic circuit system in one or more electronic design automation (EDA) environments; A step of receiving data indicating an event at a specific point in time during the development of the design of the electronic circuit system using a first software tool; The stage in which development actions are determined based on the aforementioned events; A step of determining design data that describes the state of the design at the aforementioned point in time, and determining a library setup that describes the libraries used by the first software tool to provide the design in the aforementioned state; The step of creating a design snapshot data structure including the aforementioned design data and the aforementioned library setup; and A step in which the design snapshot data structure is shared with the second software tool in order to enable the execution of the development action using the second software tool. A method for providing this.

2. The aforementioned development action is: A step of addressing detected bugs and / or bugs in the first software tool that represent violations of design rules, or a step of incorporating contributions to the design. The method according to claim 1, comprising at least one of the following.

3. The method according to claim 1 or 2, wherein the first software tool and the second software tool are two instances of a software tool in the same EDA environment, and the first software tool and the second software tool are different tools in different EDA environments.

4. The method according to claim 1 or 2, wherein the design snapshot data structure further includes metadata describing the first software tool.

5. The aforementioned sharing stage is: A step of storing the design snapshot data structure in a shared memory between the first software tool and the second software tool; and Steps to transmit the design snapshot data structure to the second software tool using the workplace messaging platform. The method according to claim 1 or 2, comprising either one of the above.

6. A step of using the shared design snapshot data structure to create a temporary library setup that includes the library setup by adding at least one or more libraries and / or updating one or more existing libraries of the second software tool; The step of using the second software tool to open the design using the design data and the temporary library setup; and The step of performing the development action using the second software tool described above. The method according to claim 1 or 2, further comprising:

7. The method according to claim 6, wherein the creation of the temporary library setup and the opening of the design are performed automatically using a library manager configured to connect to the second software tool through an interface.

8. The method according to claim 7, wherein the interface is a web interface, the shared design snapshot data structure is provided as a link to the interface, and the creation of the temporary library setup and the opening of the design are performed automatically in response to calling the link.

9. The method according to claim 1 or 2, wherein the design data describes a first cell representing the design, and the library setup includes a library of the first cell and one or more second cells representing components of the design.

10. The method according to claim 9, wherein the library is determined by navigation according to the design architecture of the design of the first cell and the one or more second cells.

11. The method according to claim 10, wherein the design architecture is a hierarchical architecture, where the first cell is a top-level cell, the one or more second cells are sub-hierarchical cells, and the navigation is a hierarchical traversal starting from the first cell.

12. The method according to claim 1 or 2, wherein the first software tool is executed on a first computer system, and the second software tool is executed on a second computer system, wherein the first computer system and the second computer system are co-located or remotely connected systems.

13. The method according to claim 1 or 2, wherein the library setup includes the path and version of the library.

14. A computer program for developing the design of an electronic circuit system using software tools in one or more EDA environments, wherein the computer: A procedure for receiving data indicating events at a specific point in time during the development of the design of the electronic circuit system using a first software tool; Procedure for determining development actions based on the aforementioned events; A procedure for determining design data that describes the state of the design at the aforementioned point in time, and for determining a library setup that describes the libraries used by the first software tool to provide the design in the aforementioned state; A procedure for creating a design snapshot data structure including the aforementioned design data and the aforementioned library setup; and A procedure for sharing the design snapshot data structure with the second software tool in order to enable the execution of the development action using the second software tool. A computer program designed to execute something.

15. A computer system for developing designs of electronic circuit systems using software tools in one or more EDA environments, wherein the computer system comprises a first software tool; the computer system: The first software tool receives data indicating events at a specific point in time during the development of the design of the electronic circuit system; Based on the aforementioned events, determine the development action; Determine design data describing the state of the design at the aforementioned point in time, and a library setup describing the libraries used by the first software tool to provide the design in the aforementioned state; Create a design snapshot data structure that includes entries representing the design data and the library setup; and In order to enable the execution of the development action using the second software tool, the design snapshot data structure is shared with the second software tool. A computer system configured in such a way.

Images