Cross-process design state verification method and related device

Abstract

Embodiments of the present application disclose a cross-process design state verification method and related equipment; the method comprises the following steps: in response to a design change operation of a first process on a design, updating an operation timestamp of the design; in response to a check result of the first process on the design being passed, writing the operation timestamp into a check completion attribute of the design; in response to a second process accessing the design, reading the operation timestamp and the check completion attribute; and if the operation timestamp is the same as the check completion attribute, allowing the second process to perform an operation related to the design.

Description

Technical Field

[0001] This application relates to the field of electronic design automation, specifically to a cross-process design status verification method and related equipment. Background Technology

[0002] In the design process, the design process and the post-design process (such as exporting the netlist corresponding to the design) usually run in different processes, or even in independent executable programs.

[0003] Taking integrated circuit design flow as an example: schematic editing and netlist export usually run in different processes, or even in independent executable programs. After completing the design in the editor, the user needs to ensure that the design has passed the connectivity check before exporting the netlist. If the design fails the connectivity check, the netlist cannot be exported.

[0004] Therefore, the post-design process needs to be able to verify the design state of the design process in order to ensure that the post-design process can perform design-related operations. Summary of the Invention

[0005] This application provides a cross-process design state verification method and related equipment, enabling the designed process to verify the design state of the design process. Only when the design state of the design process is that the check result is passed, the designed process is allowed to perform design-related operations.

[0006] In a first aspect, embodiments of this application provide a cross-process design state verification method, the method comprising: In response to design change operations performed on the design by the first process, update the operation timestamp of the design; When the first process checks the design and the result is "pass", the operation timestamp is written to the design's check completion attribute; In response to a second process accessing the design, read the operation timestamp and check completion attribute; if the operation timestamp and check completion attribute are the same, allow the second process to perform design-related operations.

[0007] In some embodiments, in response to a design change operation on the design by the first process, updating the operation timestamp of the design includes: In response to the first process's modification operation on the design, the value of the operation timestamp is increased by a preset increment; In response to the first process's undo operation on the design, the operation timestamp value is restored to the operation timestamp value of the historical design state corresponding to the undo operation.

[0008] In some embodiments, the modification operation includes at least one of the following: Add, delete, move graphics, and modify attributes.

[0009] In some embodiments, when the first process fails to check the design, the method provided by the first aspect further includes: Keep the value of the check complete attribute unchanged.

[0010] In some embodiments, if the operation timestamp and the check completion attribute are not the same, the method further includes: Deny the second process from performing design-related operations and / or output a prompt message; wherein the prompt message indicates that the check needs to be re-executed.

[0011] In some embodiments, the design data, operation timestamps, and check completion attributes are stored in the same file in the OpenAccess database.

[0012] Secondly, embodiments of this application provide a cross-process design state verification apparatus, the apparatus comprising: The operation timestamp management module is used to update the operation timestamp of the design in response to the design change operation of the first process. The check completion attribute management module is used to write the operation timestamp into the check completion attribute of the design when the first process checks the design and the result is "pass". The design status verification module is used to respond to the second process accessing the design, read the operation timestamp and check completion attribute; if the operation timestamp and check completion attribute are the same, the design status is determined to be valid.

[0013] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory for storing a computer program capable of running on the processor, wherein, when the processor runs the computer program, it performs the method described in any embodiment of the first aspect.

[0014] Fourthly, embodiments of this application provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described in any embodiment of the first aspect.

[0015] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, causes the processor to perform the method described in any embodiment of the first aspect.

[0016] The cross-process design state verification method provided in this application verifies the validity of the current design state by comparing the value of the operation timestamp updated in response to the design change operation of the first process with the value of the check completion attribute updated when the check result of the first process is passed. If the operation timestamp and the check completion attribute are the same, the second process is allowed to execute design-related operations. This achieves rapid verification of the current design state.

[0017] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are merely embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort, and this application can be applied to other similar scenarios based on the provided drawings.

[0019] Figure 1 A flowchart illustrating a cross-process design state verification method provided in an embodiment of this application; Figure 2 A flowchart illustrating another cross-process design state verification method provided in this application embodiment; Figure 3 A schematic diagram of a cross-process design state verification device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. The described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0021] It should be noted that the terms "system," "device," "unit," and / or "module" used in this application are methods of distinguishing different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they can be replaced by other expressions.

[0022] Hereinafter, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include one or more of that feature.

[0023] In the design process, the design process and the post-design process (such as exporting the netlist corresponding to the design) usually run in different processes, or even in independent executable programs.

[0024] Taking the integrated circuit design flow as an example: the design process is executed by the schematic editor, while post-design processes, such as the netlist export process, are executed by the netlist exporter. The design process and the netlist export process are independent of each other and do not interfere with each other. After the user completes the integrated circuit design through the design process, when exporting the netlist corresponding to the integrated circuit design through the netlist export process, the netlist export process needs to determine whether the current status of the design in the design process has passed the connectivity check. If the design fails the connectivity check, the netlist export process cannot export the netlist.

[0025] To determine whether the current state of the design process has passed the connectivity check, the following three methods are commonly used in related technologies: First, there's the issue of redundant checks. Specifically, after opening a design, the netlist export process cannot determine whether the design has already passed connectivity checks during the design process, thus it can only "blindly" re-execute the check. For large-scale designs (such as the top-level System-on-Chips (SoC) containing millions of instances), a complete check can take several minutes or even longer, severely slowing down design iteration efficiency. Furthermore, if the checker version or configuration used is inconsistent, it can lead to different check results from the design process and the netlist export process for the same design, causing confusion.

[0026] Second, external lock / flag files; specifically, after the design process passes checks, it writes design status flags to a separate lock file or flag file (such as the registry); the netlist export process reads these design status flags upon startup. However: First, the lock file is separate from the database containing the design data, which can easily lead to inconsistencies between the lock file and the design; for example, the design may be rolled back but the lock file may not be updated. Second, the lock file requires additional file system operations and permission management, increasing complexity and potential points of failure. Third, the lock file cannot naturally follow the version management of the design database, requiring additional lock file synchronization logic with the design.

[0027] Third, Inter-Process Communication (IPC); specifically, design state is transferred between the design process and the netlist export process through IPC mechanisms such as sockets and shared memory. However, IPC implementation is complex, requiring both the design process and the netlist export process to be online simultaneously and the network / shared memory channel to be unobstructed; in batch simulation or remote server scenarios, maintaining the IPC channel is very costly. Moreover, if either process restarts, the design state is lost.

[0028] To address at least one of the aforementioned technical problems, embodiments of this application provide a cross-process design state verification method and related equipment.

[0029] Figure 1 This is a flowchart illustrating a cross-process design state verification method provided in an embodiment of this application.

[0030] like Figure 1 As shown, the cross-process design state verification method provided in this application embodiment can be executed by an electronic device. Electronic devices include, but are not limited to, servers, personal computers, laptops, tablets, and other devices with data processing capabilities. The cross-process design state verification method includes the following steps: Step 101: In response to the design change operation of the first process, update the operation timestamp of the design; In one embodiment, the first process is a process for performing circuit design. The user can input design change commands to the first process through a user interface using a human-computer interaction device (such as a mouse, keyboard, etc.).

[0031] Design change operations include modification and undo operations. Modification operations include at least one of adding, deleting, moving graphics, and modifying attributes. Undo operations restore the design to the historical design state corresponding to the undo operation.

[0032] For example, a design change operation can be triggered in the following ways: The user clicks the add button on the user interface and selects the graphic to be added and the location to be added. The first process adds the graphic to the location according to the add command. The user drags the target graphic on the user interface, and the first process moves the target graphic to the target position according to the graphic movement command; When a user clicks the undo button on the user interface, the first process executes the undo command, restoring the design to the historical design state corresponding to the undo command.

[0033] In one embodiment, the electronic device responds to a design change operation on the design by the first process, triggering an action to update the operation timestamp of the design.

[0034] Understandably, when a user's design change operation is a modification of the design, the electronic device updates the operation timestamp value each time it responds to the modification operation. When the user's modification operation is an undo operation, the electronic device responds by reverting the operation timestamp value to the operation timestamp value matching the historical design state corresponding to the undo operation. In other words, the operation timestamp is updated synchronously with the actual design state.

[0035] For example, the operation timestamp value can be preset to a natural number, such as an initial value of 0. Each time the electronic device responds to the first process's modification operation on the design, the operation timestamp value is updated accordingly, such as incrementing the operation timestamp value with each operation.

[0036] For example, if the operation timestamp corresponding to the current design state is TS=101, and the first process performs an undo operation to roll back to the previous historical state (the operation timestamp corresponding to the historical state is TS=100), then the electronic device will restore (roll back) the value of the operation timestamp from 101 to 100.

[0037] If the operation timestamp corresponding to the current design state is TS=101, and the first process performs the add operation, the electronic device will increment the value of the operation timestamp from 101 by 1, that is, update the value of the operation timestamp to TS=102.

[0038] Based on this, step 101 includes the following steps: In response to the first process's modification operation on the design, the value of the operation timestamp is increased by a preset increment; In response to the first process's undo operation on the design, the operation timestamp value is restored to the operation timestamp value of the historical design state corresponding to the undo operation.

[0039] In one embodiment, the preset increase amount can be any value, such as 1, 2, 3, etc., and this application does not limit it.

[0040] In some embodiments, the operation timestamp and the corresponding design data can be stored in the same file in the OpenAccess (OA) database.

[0041] Step 102: In response to the first process's inspection result of the design being passed, write the operation timestamp into the design's inspection completion attribute; In one embodiment, the first process has a built-in or associated inspection module for performing connectivity checks on the design. Taking the first process as an integrated circuit design process as an example, the inspection module is used to verify whether the electrical connections of the integrated circuit in the design are correct, whether there are short circuits / open circuits, and whether the component pins are matched, etc., which is a prerequisite for ensuring that the design can correctly generate a netlist.

[0042] In one embodiment, a user can trigger a check operation through the user interface, such as by clicking the "Check and Save" button on the user interface. In response to the trigger operation, the first process calls the check module to perform a check on the current design.

[0043] For example, if the inspection module finds no errors after traversing the design, the inspection result is determined to be pass; if the inspection module finds abnormalities such as connection errors, missing pins, or short circuits, the inspection result is determined to be fail.

[0044] In one embodiment, the check completion attribute is a custom attribute attached to the design. Optionally, the check completion attribute can be named "connectivityLastUpdated", and its data type is integer, used to store the timestamp value of the operation when the check was most recently successfully passed.

[0045] Understandably, when the inspection result is "passed," the electronic device obtains the current design operation timestamp value and writes it to the "inspection completion" attribute. Specifically, the electronic device can assign the operation timestamp value to the "inspection completion" attribute by calling the attribute setting interface provided by the OA database. The "inspection completion" attribute, operation timestamp, and corresponding design data are stored in the same file within the OA database.

[0046] For example, if the current design's operation timestamp value is TS=102, after the check passes, the electronic device will update the check completion attribute value to CK=102. At this time, the operation timestamp and the check completion attribute value are the same, indicating that the current design is in a valid state of "checked and error-free".

[0047] Understandably, if the inspection result is a failure (i.e., an error exists), the electronic device will not update the inspection completion attribute; that is, the value of the inspection completion attribute will remain unchanged. In this case, the operation timestamp and the inspection completion attribute will be different, indicating that there is a design error that needs to be corrected and re-inspected.

[0048] For example, if the current design's operation timestamp is TS=103 and the check completion attribute is CK=102, and the check module finds a short circuit error in the design, resulting in a failure, the electronic device will keep the check completion attribute unchanged at CK=102 and will not update it to CK=103. The check completion attribute will only be updated to CK=103 after the user fixes the error and the check passes again.

[0049] Based on this, in response to the first process's failure to check the design, the cross-process design state verification method provided in this application embodiment further includes the following steps: Keep the value of the check complete attribute unchanged.

[0050] Step 103: In response to the second process accessing the design, read the operation timestamp and check completion attribute; if the operation timestamp and check completion attribute are the same, allow the second process to perform design-related operations.

[0051] In one embodiment, the second process is a post-design process, such as a netlist export process for exporting netlists. It is understood that the netlist export process is independent of the design process, running in different processes or even different executables, and there is no direct IPC between them.

[0052] After the user completes the design and ensures it passes the check, they can trigger the netlist export operation via the user interface or script. The second process responds to this trigger by opening the design file stored on disk through the interface provided by the standard OA database, and reading the operation timestamp and check completion attribute stored within it.

[0053] In one embodiment, the second process determines whether the current state of the design is valid by comparing the value of the read operation timestamp with the value of the check completion attribute. If the operation timestamp value equals the check completion attribute value, it means that the design has not been modified since the most recent successful check, and the check has passed without errors, thus the design status is deemed valid. At this time, the second process is allowed to perform design-related operations, such as exporting netlists, performing physical verification, and generating layouts.

[0054] If the operation timestamp value is not equal to the check-complete attribute value (including cases where the check-complete attribute does not exist), it indicates that the design has been modified since the last check, has never passed the check, or has an error in the check, and the design status is determined to be invalid. In this case, the second process is refused to perform any design-related operations, and a prompt message may be output to instruct the user to return to the first process to re-perform the design check.

[0055] For example, if the netlist export process reads the current operation timestamp TS=102 and checks the completion attribute CK=102, and the two are equal, then the netlist is generated directly without repeating the check, and the time consumption is almost zero.

[0056] For example, if the netlist export process reads the current operation timestamp TS=103 and checks the completion attribute CK=102, and the two are not equal, then the netlist export will be refused, and the following message will be displayed on the user interface: "The design has been modified. Please perform the check before exporting the netlist."

[0057] In one embodiment, the operation timestamp and check completion attribute are stored in the same design data file, specifically, in the design object of the OA database. The first process and the second process access the design data file on the same disk through a standard OA application programming interface (API), performing write and read operations respectively. Because the data is persistently stored on disk, the values ​​of the operation timestamp and check completion attribute are retained and will not be lost even if the first or second process restarts.

[0058] Based on this, if the operation timestamp and the check completion attribute are not the same, the cross-process design state verification method provided in this application embodiment further includes: Deny the second process from performing design-related operations and / or output a prompt message; wherein the prompt message indicates that the check needs to be re-executed.

[0059] It is understood that in the above embodiments, the first process can be the design process and the second process can be the netlist export process.

[0060] In summary, the cross-process design state verification method provided in this application verifies the validity of the current design state by comparing the value of the operation timestamp updated in response to the design change operation of the first process with the value of the check completion attribute updated when the check result of the first process is passed. If the operation timestamp and the check completion attribute are the same, the second process is allowed to execute design-related operations. This achieves rapid verification of the current design state.

[0061] Specifically, First, the second process (such as the netlist export process) only needs to read the operation timestamp and the value of the check completion attribute and make a comparison once to accurately determine whether the current design is in a valid state, which takes almost zero time. For large-scale SoC designs containing millions of instances, each design iteration can save several minutes or even longer of repeated check time, fundamentally avoiding judgment conflicts caused by inconsistent checker versions or configurations.

[0062] Secondly, the operation timestamp and the check completion attribute are stored in the same file in the OA database, without any additional file system operations, permission management, or synchronization logic, completely avoiding the consistency problems and potential failure points caused by separate storage of lock files.

[0063] Furthermore, the first and second processes do not engage in any direct IPC communication. They share storage only through the disk database file. The first and second processes do not need to be online simultaneously or maintain any communication channels. Even if the process restarts or crashes, the design state is still persistently retained on the disk, ensuring stability and reliability in complex deployment scenarios such as batch simulation and remote servers.

[0064] The cross-process design state verification method provided in this application will be further illustrated below with a specific example.

[0065] Figure 2 This is a flowchart illustrating another cross-process design state verification method provided in this application embodiment. In this method, the first process is the design process, and the second process is the netlist export process, as an example. Figure 2 As shown in the figure, another cross-process design state verification method provided in this application includes the following steps: Step 201: In response to the user creating a new design, generate the initial operation timestamp of the integrated circuit design and the initial check completion attribute; For example, the initial operation timestamp is TS=100, and the initial check completion attribute is CK=100.

[0066] Step 202: In response to the design change operation of the first process, update the operation timestamp of the design; For example, a user adds a connection to an integrated circuit design through the user interface and updates the design's operation timestamp to TS=101; at this time, the check completion attribute is still CK=100.

[0067] Step 203: In response to the first process's check result for the design being passed, write the operation timestamp into the design's check completion attribute; For example, if the operation timestamp when the check result is passed is TS=101, then 101 will be written into the check completion attribute of the design, that is, the check completion attribute will be updated to CK=101.

[0068] Step 204: In response to the second process access design, read the operation timestamp and check the completion attribute; For example, the read operation timestamp is TS=101, and the check completion attribute is CK=101. The read operation timestamp and the check completion attribute have the same value.

[0069] At this point, the second process can directly generate the netlist based on the design.

[0070] Step 205: In response to another design change operation on the design by the first process, update the operation timestamp of the design; For example, if a user deletes a connection in an integrated circuit design through the user interface and updates the design's operation timestamp to TS=102, the check completion attribute will still be CK=101.

[0071] Step 206: In response to the first process's undo operation on the design, restore the value of the operation timestamp to the value of the operation timestamp of the historical design state corresponding to the undo operation; For example, if the user cancels the "delete" action through the user interface, restoring the designed operation timestamp to TS=101, the check completion attribute will still be CK=101.

[0072] At this point, the second process can still directly generate the netlist based on the design.

[0073] Understandably, in the example above, the first process and the second process can each open files in the same OA database through the OA API without any direct communication.

[0074] To implement the cross-process design state verification method provided in this application, this application also provides a cross-process design state verification device. For example... Figure 3 As shown, Figure 3 A schematic diagram of a cross-process design state verification device provided in an embodiment of this application. The cross-process design state verification device includes: The operation timestamp management module 301 is used to update the operation timestamp of the design in response to the design change operation of the first process. The inspection completion attribute management module 302 is used to write the operation timestamp into the inspection completion attribute of the design when the inspection result of the first process is passed. The design status verification module 303 is used to respond to the second process accessing the design, read the operation timestamp and check completion attribute; if the operation timestamp and check completion attribute are the same, the design status is determined to be valid.

[0075] In some embodiments, the operation timestamp management module 301 is specifically used for: In response to the first process's modification operation on the design, the value of the operation timestamp is increased by a preset increment; In response to the first process's undo operation on the design, the operation timestamp value is restored to the operation timestamp value of the historical design state corresponding to the undo operation.

[0076] In some embodiments, the modification operation includes at least one of the following: Add, delete, move graphics, and modify attributes.

[0077] In some embodiments, the completion check of the attribute management module 302 is further configured to: Keep the value of the check complete attribute unchanged.

[0078] In some embodiments, the design state verification module 303 is further configured to: Deny the second process from performing design-related operations and / or output a prompt message; wherein the prompt message indicates that the check needs to be re-executed.

[0079] In some embodiments, the design data, operation timestamps, and check completion attributes are stored in the same file in the OpenAccess database.

[0080] The above embodiments of this application describe the apparatus provided in the embodiments of this application. To implement the functions of the methods provided in the above embodiments of this application, the cross-process design state verification apparatus may include hardware structures and software modules, implementing the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. One of the above functions may be executed in the form of hardware structures, software modules, or a combination of hardware structures and software modules.

[0081] Figure 4 This is a block diagram illustrating an electronic device 400 for implementing the above-described cross-process design state verification method according to an exemplary embodiment. For example, the electronic device 400 may be a computer, a personal digital assistant, etc.

[0082] Reference Figure 4 The electronic device 400 may include a communication interface 401, capable of interacting with other devices; a processor 402, connected to the communication interface 401 to interact with other devices, used to execute the methods provided by one or more of the above-described technical solutions when running a computer program; and a memory 403, on which the computer program is stored. Specifically, the specific processing operations of the processor 402 can refer to the cross-process design state verification method described in the above embodiments of this disclosure.

[0083] Of course, in practical applications, the various components in electronic device 400 are coupled together through bus system 404. It can be understood that bus system 404 is used to realize the connection and communication between these components. In addition to a data bus, bus system 404 also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in... Figure 4 The general designated all buses as Bus System 404.

[0084] The memory 403 in this embodiment is used to store various types of data to support the operation of the electronic device 400. Examples of such data include any computer program used to operate on the electronic device 400.

[0085] The methods disclosed in the embodiments of this application can be applied to processor 402, or implemented by processor 402. Processor 402 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 402 or by instructions in software form. The processor 402 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 402 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 403. Processor 402 reads the information in memory 403 and, in conjunction with its hardware, completes the steps of the aforementioned method.

[0086] In an exemplary embodiment, the electronic device 400 may be implemented by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers (MCUs), microprocessors, or other electronic components to perform the aforementioned method.

[0087] Embodiments of this disclosure also propose a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the cross-process design state verification method described in the above embodiments of this disclosure.

[0088] Embodiments of this disclosure also propose a computer program product, including a computer program that, when executed by a processor, implements the cross-process design state verification method described in the above embodiments of this disclosure.

[0089] Embodiments of this disclosure also propose a chip including one or more interface circuits and one or more processors; the interface circuits are used to receive signals from the memory of an electronic device and send signals to the processors, the signals including computer instructions stored in the memory, which, when executed by the processor, cause the electronic device to perform the cross-process design state verification method described in the above embodiments of this disclosure.

[0090] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0091] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0092] Any description of operation or method in the flowchart or otherwise described herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or operation, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0093] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (control method), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic device, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which programs can be printed, because programs can be obtained electronically, for example, by optically scanning the paper or other media, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0094] It should be understood that various parts of the embodiments of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0095] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by instructing related hardware through an operation sequence, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0096] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc.

[0097] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A cross-process design state verification method, characterized in that, The method includes: In response to a design change operation on the design by the first process, update the operation timestamp of the design; When the first process checks the design and the result is "pass", the operation timestamp is written into the check completion attribute of the design; In response to a second process accessing the design, the operation timestamp and the check completion attribute are read; if the operation timestamp and the check completion attribute are the same, the second process is allowed to perform operations related to the design.

2. The method according to claim 1, characterized in that, The step of updating the operation timestamp of the design in response to the design change operation of the first process includes: In response to the first process's modification operation on the design, the value of the operation timestamp is increased by a preset increment; In response to the first process's undo operation on the design, the value of the operation timestamp is restored to the value of the operation timestamp of the historical design state corresponding to the undo operation.

3. The method according to claim 2, characterized in that, The modification operation includes at least one of the following: Add, delete, move graphics, and modify attributes.

4. The method according to claim 1, characterized in that, When the first process fails to check the design, the method further includes: Keep the value of the check completion attribute unchanged.

5. The method according to claim 1, characterized in that, If the operation timestamp is not the same as the check completion attribute, the method further includes: The second process is denied the execution of operations related to the design, and / or a prompt message is output; wherein the prompt message is used to indicate that the check needs to be re-executed.

6. The method according to claim 1, characterized in that, The design data, operation timestamp, and check completion attribute are stored in the same file in the OpenAccess database.

7. A cross-process design state verification device, characterized in that, The device includes: The operation timestamp management module is used to update the operation timestamp of the design in response to the design change operation of the first process. The inspection completion attribute management module is used to write the operation timestamp into the inspection completion attribute of the design when the inspection result of the first process on the design is passed. The design status verification module is used to respond to the second process accessing the design, read the operation timestamp and the check completion attribute; if the operation timestamp and the check completion attribute are the same, the design status is determined to be valid.

8. An electronic device, characterized in that, include: A processor and a memory for storing a computer program capable of running on the processor, wherein the processor, when running the computer program, performs the method of any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes a computer program, which, when executed by a processor, causes the processor to perform the method of any one of claims 1 to 6.

Images