A multi-party cooperative SoC top-level integration method, device, equipment and storage medium

Abstract

The application relates to the technical field of chip design automation, in particular to a multi-party cooperation SoC top layer integration method and device, equipment and a storage medium. The method comprises the following steps: obtaining a local hardware code, inputting the local hardware code into a version control module, and matching remote hardware code corresponding to the local hardware code in the version control module; performing semantic script conversion on the local hardware code and the remote hardware code respectively to obtain a first semantic script and a second semantic script; comparing the first semantic script and the second semantic script to extract difference element pairs; obtaining a baseline semantic script, and judging change attributes of the difference element pairs; determining corresponding execution modes according to the change attributes, processing corresponding elements in the difference element pairs based on the execution modes, and obtaining an integrated semantic script; and generating a top layer hardware code according to the integrated semantic script and submitting the top layer hardware code to the version control module. The application can improve the collaborative development efficiency.

Description

Technical Field

[0001] This application relates to the technical field of chip design automation, and in particular to a multi-party collaborative SoC top-level integration method, apparatus, device and storage medium. Background Technology

[0002] In the top-level integration development of System-on-Chips (SoCs), as the design scale continues to expand, parallel collaboration among multiple teams has become the mainstream development model. Different design teams are typically responsible for different functional modules, each developing and maintaining hardware description language (such as Verilog) code on their local branches. Ultimately, a version control system is needed to merge the scattered code into the main branch to complete the construction and verification of the top-level integration.

[0003] When handling concurrent modifications by multiple users, the system primarily relies on line-level difference comparison algorithms for conflict detection and merging. When different users modify the same top-level file, the version control system can only identify the addition, deletion, and modification status of character lines. Once text lines overlap, the system determines it as a conflict and stops automatic merging, forcing a switch to manual reconciliation mode.

[0004] This text-based processing mechanism leads to low collaboration efficiency. Designers must analyze code conflicts line by line and manually refactor the logic. Whenever a merge conflict occurs, the entire integration process is forced to stop until it is resolved manually. This frequent waiting and repeated iterations significantly lengthen the closed-loop time from code submission to integration verification, becoming a key bottleneck restricting the extension of SoC design iteration cycles. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this application provides a multi-party collaborative SoC top-level integration method, apparatus, device, and storage medium, which raises the granularity of conflict detection from character lines to the hardware design semantic level, enabling code modified in parallel by multiple users to be resolved and merged through semantic resolution, thereby improving the efficiency of collaborative development.

[0006] The technical solution adopted by this application to solve its technical problem is:

[0007] Firstly, this application provides a multi-party collaborative SoC top-level integration method, the method comprising:

[0008] Obtain the local hardware code, input the local hardware code into the version control module, and match the remote hardware code corresponding to the local hardware code in the version control module;

[0009] Semantic script conversion is performed on the local hardware code and the remote hardware code respectively to obtain a first semantic script corresponding to the local hardware code and a second semantic script corresponding to the remote hardware code.

[0010] The first semantic script contains local elements of various types, and the second semantic script contains remote elements of various types, with the element types of the local elements and the remote elements corresponding one-to-one.

[0011] By comparing the first semantic script and the second semantic script, at least one pair of differing elements is extracted; each pair of differing elements includes a local element and a remote element of the corresponding type.

[0012] Obtain the baseline semantic script, and determine the change attributes of each pair of differing elements based on the baseline semantic script;

[0013] Based on each of the changed attributes, the corresponding execution mode is determined, and the corresponding elements in each of the difference element pairs are processed based on the execution mode to obtain the integrated semantic script;

[0014] The top-level hardware code is generated based on the integrated semantic script, and the top-level hardware code is submitted to the version control module.

[0015] Optionally, before the step of comparing the first semantic script with the second semantic script, the method further includes:

[0016] Perform a reference compatibility check between the local hardware code and the remote hardware code;

[0017] If the reference compatibility check fails, a reference error message is generated and the top-level integration method is terminated.

[0018] Optionally, the step of performing semantic script conversion on the local hardware code and the remote hardware code respectively includes:

[0019] The current hardware code is compiled and parsed to identify the module instances, signal ports, configuration parameters, and macro definitions of the current hardware code; wherein, the current hardware code is the local hardware code or the remote hardware code;

[0020] The identified module instance, signal port, configuration parameters, and macro definition are mapped to programmatic entities; wherein, the programmatic entity is a class object or a data structure;

[0021] Based on the programmatic entity, a current semantic script corresponding to the current hardware code is constructed; wherein, the current semantic script is either the first semantic script or the second semantic script.

[0022] Optionally, the step of determining the change attributes of each pair of differing elements based on the baseline semantic script includes:

[0023] Based on the baseline semantic script, extract the baseline elements corresponding to the currently processed difference element pair; wherein, the currently processed difference element pair is any of the difference element pairs;

[0024] The existence and content states of the baseline element are compared with the existence and content states of the local elements in the current processing difference element pair and the existence and content states of the remote elements in the current processing difference element pair, respectively.

[0025] The change attributes of the currently processed difference element pairs are determined based on the obtained state comparison results.

[0026] Optionally, the step of determining the change attribute of the currently processed difference element pair based on the obtained state comparison result includes:

[0027] If the existence status representation of the baseline element exists, the existence status representation of the remote element exists and its content status is consistent with the content status of the baseline element, and the existence status representation of the local element does not exist, then the change attribute is determined to be a local deletion attribute.

[0028] If the changed attribute is a local deletion attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding element based on the execution mode includes:

[0029] The execution mode is determined to be the removal execution mode;

[0030] In the removal execution mode, the local elements are excluded when constructing the integrated semantic script.

[0031] Optionally, the step of determining the change attribute of the currently processed difference element pair based on the obtained state comparison result includes:

[0032] If the existence status representation of the baseline element does not exist, but the existence status representation of the remote element exists, then the changed attribute is determined to be a remotely added attribute.

[0033] If the changed attribute is a remotely added attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding element based on the execution mode includes:

[0034] The execution mode is determined to be the add execution mode;

[0035] Based on the aforementioned execution mode, the content of the remote element is integrated into the integrated semantic script.

[0036] Optionally, the step of determining the change attribute of the currently processed difference element pair based on the obtained state comparison result includes:

[0037] If the existence status representation of the baseline element exists, and the existence status representation of either the local element or the remote element does not exist, while the existence status representation of the other element exists and its content status is inconsistent with the content status of the baseline element, then the change attribute of the currently processed difference element pair is determined to be a modification / deletion conflict attribute.

[0038] If the changed attribute is the modified / deleted conflict attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding conflicting element based on the execution mode includes:

[0039] The execution mode is determined to be an intervention execution mode;

[0040] Based on the intervention execution mode, a conflict alarm signal containing the corresponding currently processed difference element pair is generated.

[0041] Secondly, this application provides a multi-party collaborative SoC top-level integrated device, including:

[0042] The same-name code matching module is used to obtain the local hardware code, input the local hardware code into the version control module, and match the remote hardware code corresponding to the local hardware code in the version control module.

[0043] The semantic script conversion module is used to perform semantic script conversion on the local hardware code and the remote hardware code respectively, to obtain a first semantic script corresponding to the local hardware code and a second semantic script corresponding to the remote hardware code.

[0044] The first semantic script contains local elements of various types, and the second semantic script contains remote elements of various types, with the element types of the local elements and the remote elements corresponding one-to-one.

[0045] The difference element extraction module is used to compare the first semantic script and the second semantic script to extract at least one difference element pair; a difference element pair includes a local element and a remote element of the corresponding type.

[0046] The change attribute judgment module is used to obtain the baseline semantic script and judge the change attributes of each of the difference element pairs based on the baseline semantic script;

[0047] The difference element processing module is used to determine the corresponding execution mode according to each of the changed attributes, and process the corresponding elements in each of the difference element pairs based on the execution mode to obtain the integrated semantic script.

[0048] The top-level code generation module is used to generate top-level hardware code based on the integrated semantic script, and submit the top-level hardware code to the version control module.

[0049] Thirdly, this application provides an electronic device, comprising:

[0050] One or more processors;

[0051] One or more memory units;

[0052] And one or more computer programs, wherein the one or more computer programs are stored in the one or more memories, and the one or more computer programs include instructions that, when executed by the one or more processors, cause the electronic device to perform the methods described above.

[0053] Fourthly, this application provides a computer-readable storage medium, characterized in that the storage medium stores a program or instructions that, when the program or instructions are run, implement the above-described method.

[0054] In summary, this application first obtains local and remote hardware code through a version control module, and then converts them into a first semantic script and a second semantic script, respectively, containing structured information such as module instances and signal ports, thereby mapping unstructured text code into programmatic elements with one-to-one correspondence between types.

[0055] Subsequently, the difference element pairs composed of local and remote elements are extracted, and a baseline semantic script is introduced as a reference benchmark. By comparing the existence and content states of the baseline, local and remote elements, the change attributes of each difference element pair are determined. Then, these elements are automatically processed according to the preset execution mode to generate an integrated semantic script, which is finally restored to the top-level hardware code and submitted.

[0056] The beneficial effects of this application are: because it can identify the specific design intent of modules, signals and parameters behind the code, even if the modifications of different users overlap in the text line position, as long as the semantic element objects they operate on are different or the change logic conforms to the preset rules, it can be automatically distinguished and merged. For logical conflicts that do exist, the three-way comparison results can be accurately classified into specific change attributes and trigger the corresponding intervention mode, avoiding the blindness of manually checking the code line by line.

[0057] Therefore, this application eliminates frequent manual merging bottlenecks caused by line-level misjudgments, significantly reducing the workload of manual intervention and the risk of human error for designers during code integration. Code modified in parallel by multiple users can be semantically and automatically decomposed and merged, significantly improving the smoothness of collaborative development. This ensures that the top-level integration process is no longer a bottleneck, effectively shortening the overall iteration cycle of chip design and achieving efficient multi-party collaborative integration. Attached Figure Description

[0058] Figure 1 This is a flowchart illustrating the multi-party collaborative SoC top-level integration method provided in the embodiments of this application;

[0059] Figure 2 This is a schematic diagram of the virtual structure of the multi-party collaborative SoC top-level integrated device provided in this application;

[0060] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0061] The present application will be further described below with reference to the accompanying drawings and embodiments.

[0062] The following will clearly and completely describe the concept, specific structure, and resulting technical effects of this application in conjunction with embodiments and accompanying drawings, so as to fully understand the purpose, features, and effects of this application. Obviously, the described embodiments are only a part of the embodiments of this application, not all of them. Other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are all within the scope of protection of this application. Furthermore, all connections / linkages involved in the patent do not simply refer to direct contact between components, but rather to the ability to form a better connection structure by adding or reducing connecting accessories according to specific implementation conditions. The various technical features in this application can be combined interactively without contradicting each other.

[0063] Existing SoC top-level integration technologies primarily rely on traditional text comparison tools or general code merging algorithms to handle merging requests from multiple code sources. These existing technologies are typically based on line-level or character-level difference detection mechanisms, treating hardware code as plain text strings for line-by-line comparison, lacking the ability to understand the semantics of hardware design. When multiple branches modify the same module instance, signal port, or configuration parameter, existing tools can only identify changes in text content, unable to distinguish the specific type of change (such as addition, deletion, or modification), let alone automatically determine whether there are logical conflicts between changes in different branches. Once overlapping modifications at the text level are detected, existing technologies often directly mark them as merge conflicts and abort the process, forcing designers to manually intervene, checking code differences line by line and manually editing to resolve conflicts.

[0064] Due to the lack of an automated conflict resolution mechanism at the semantic level, existing technologies force designers to spend a significant amount of time on manual code review and merging when facing complex multi-person collaborative scenarios. This inefficient manual intervention not only easily introduces human error, causing functional anomalies after integration, but also severely hinders the automated flow of code merging. Whenever a merge conflict occurs, the entire integration process is forced to halt until it is resolved manually. This frequent waiting and repeated iterations significantly lengthen the closed-loop time from code submission to integration verification, making collaboration difficulties a key bottleneck restricting the extension of SoC design iteration cycles.

[0065] To address the aforementioned technical deficiencies, refer to Figure 1 , Figure 1 This is a flowchart illustrating the multi-party collaborative SoC top-level integration method provided in the embodiments of this application. Figure 1 This paper demonstrates several key steps involved in the SoC top-level integration method provided in this application, which are described in detail below:

[0066] In step S1, the local hardware code is obtained and input into the version control module, where the remote hardware code corresponding to the local hardware code is matched.

[0067] Local hardware code refers to the collection of hardware description language source files that the current designer has written or modified in the local workspace and is to be submitted for integration. Specifically, it is represented by Verilog or SystemVerilog code files containing module definitions, instantiation statements, and signal connection relationships. Remote hardware code refers to the corresponding code version stored in the version control module, maintained by other collaborative teams or branches, and belonging to the same project baseline as the local hardware code. Its file format is also Verilog or SystemVerilog code.

[0068] In addition, the Version Control System (VCS) is a software system used to record changes in file content and support multi-user collaborative management. It is responsible for storing historical versions of code, managing branch structures, and performing code matching operations.

[0069] Specifically, the local hardware code is first obtained and then passed to the version control module as input. Inside the version control module, based on preset matching rules (such as file path, module name, or branch identifier), remote hardware code that has a common origin with the local hardware code is searched and located in the remote repository.

[0070] In step S2, semantic script conversion is performed on the local hardware code and the remote hardware code respectively to obtain a first semantic script corresponding to the local hardware code and a second semantic script corresponding to the remote hardware code.

[0071] Semantic script conversion refers to the process of parsing unstructured hardware description language text into a structured, machine-readable intermediate representation. Based on this, the first semantic script is a set of structured data generated by the local hardware code after semantic script conversion, while the second semantic script is a set of corresponding structured data generated by the remote hardware code after the same conversion process.

[0072] It is also worth noting that the first semantic script contains various types of local elements, while the second semantic script contains various types of remote elements. Local elements and remote elements refer to logical units with the same semantic attributes in the first and second semantic scripts, respectively. For example, both contain element types such as "module instance", "input port" or "parameter configuration", and these element types maintain a one-to-one correspondence in the two scripts to ensure that subsequent comparisons can be performed on the same logical dimension.

[0073] Specifically, local and remote hardware code are read separately. A built-in parser performs lexical and syntactic analysis on the Verilog or SystemVerilog code, stripping away functionally irrelevant textual formatting information to extract logical entities with practical circuit meaning. These extracted entities are then encapsulated into standard object structures, generating a first semantic script and a second semantic script. During this process, a type mapping mechanism between local and remote elements is established to ensure that every local element type in the first semantic script can find a corresponding remote element type in the second semantic script.

[0074] More specifically, in the embodiments of this application, the step of performing semantic script conversion on the local hardware code and the remote hardware code respectively includes:

[0075] The current hardware code is compiled and parsed to identify the module instances, signal ports, configuration parameters, and macro definitions of the current hardware code.

[0076] The current hardware code refers to the source code file being processed in the semantic script conversion step. Its specific identity depends on the processing stage; it can be either local hardware code to be integrated or remote hardware code.

[0077] The identified module instance, signal port, configuration parameter, and macro definition are mapped to programmatic entities.

[0078] Among them, programmatic entities refer to objects or data structures that are formed by abstracting the syntactic elements in hardware code and can be directly manipulated by the computer in memory, such as class objects or structures.

[0079] Based on the programmatic entity, construct the current semantic script corresponding to the current hardware code;

[0080] The current semantic script is a structured intermediate representation file built on the above-mentioned programmatic entities. It fully records the logical topology and parameter configuration of the current hardware code and serves as a standardized data source for subsequent comparison and analysis. It corresponds to the first semantic script or the second semantic script in the process.

[0081] Specifically, the compilation and parsing engine is activated to perform lexical and syntactic analysis on the current hardware code, extracting key logical units such as module instances, signal ports, configuration parameters, and macro definitions, while ignoring irrelevant information such as comments and whitespace. Subsequently, these extracted logical units are mapped one by one to programmatic entities; that is, a class object or data record with specific attributes and methods is created for each module, port, or parameter, making it a data node that can be directly read, written, and compared by the algorithm. Finally, based on the original hierarchical structure and connection relationships of the code, these discrete programmatic entities are assembled into the current semantic script.

[0082] It is worth noting that, in order to avoid meaningless consumption of computational resources on an invalid basis, this application embodiment also proposes that, before performing subsequent steps, the method further includes:

[0083] Perform a reference compatibility check between the local hardware code and the remote hardware code;

[0084] If the reference compatibility check fails, a reference error message is generated and the top-level integration method is terminated.

[0085] Reference compatibility verification refers to the consistency check of the external resource environment on which the local hardware code and the remote hardware code depend before executing the core script comparison and merging logic. Reference error information is a specific error report generated by the system when the verification finds an irreconcilable dependency conflict (such as referencing a non-existent module, a library file with a mismatched version, or a circular dependency). It lists in detail the source of the conflicting reference, the name of the missing resource, and the type of conflict.

[0086] Specifically, before converting the local and remote hardware code into semantic scripts and comparing them, the static analysis engine is first launched to scan all reference declarations in both code segments. Then, it is checked whether all external entities referenced by the local code can be found with compatible definitions in the context of the remote code, and vice versa.

[0087] If any reference points to a resource that does not exist or is of a different version in the other party's environment, or if the references from both parties cause a namespace conflict, the reference compatibility check is deemed to have failed. At this point, all subsequent processing steps are immediately blocked. Semantic analysis and difference comparisons are no longer performed; instead, the exception handling process is directly triggered, generating a reference error message containing detailed diagnostic information, and the current top-level integration method is forcibly terminated to prevent the error from propagating downstream.

[0088] In step S3, the first semantic script and the second semantic script are compared to extract at least one pair of differing elements.

[0089] In this context, a difference element pair refers to a pair of units identified by the system as having inconsistent states or contents during the comparison process between the first semantic script and the second semantic script. Each difference element pair strictly consists of a local element and a remote element of the corresponding type. The local element originates from the first semantic script and represents a specific logical entity in the local hardware code, while the remote element originates from the second semantic script and represents a logical entity of the same type in the remote hardware code.

[0090] Specifically, a mapping index is established between the generated first and second semantic scripts, traversing all predefined logical unit types. For each type, an attempt is made to find local elements in the first semantic script and remote elements with the same identifier (such as module name, signal name) in the second semantic script. When two elements are found to be of the same type and have matching identifiers, but inconsistent in attribute values ​​(such as bit width, connection target, initial value), or when one element exists while the other is missing, these two elements are bound as a pair of differing elements.

[0091] More specifically, by constructing pairs of differing elements, the differences are isolated at the level of independent logical units, making each difference clearly identifiable. Since each pair of differing elements explicitly contains a local element and a remote element of the corresponding type, the system can immediately know the specific object of the change and the specific values ​​before and after the change. This not only reduces the complexity of subsequent automated merging algorithms but also enables the system to independently determine whether to perform automatic overwrite, intelligent fusion, or report conflicts for a single element pair, thereby improving the automation level and processing efficiency of the integration process.

[0092] In step S4, a baseline semantic script is obtained, and the change attributes of each of the difference element pairs are determined based on the baseline semantic script.

[0093] The baseline semantic script refers to the structured semantic representation file corresponding to the common ancestor version of the project before local and remote modifications occur. It records the original logical state of the code at the point of divergence, including the attribute values ​​of all logical entities at that time, and serves as an objective reference for judging the source of the change.

[0094] Change attributes refer to the specific behavioral characteristics determined by analyzing the state changes of each difference element pair relative to the baseline semantic script. They typically include categories such as "local modification only", "remote modification only", "both parties modified and conflicting", or "neither party modified".

[0095] Specifically, first, the baseline semantic script, which shares a common ancestor with the current local and remote code, is retrieved and used as a third-party reference. Then, the local and remote elements in each extracted pair of differing elements are compared with their corresponding original elements in the baseline semantic script. If the local element differs from the baseline element, but the remote element is the same as the baseline element, the changed attribute of that pair of differing elements is determined to be "local change only"; otherwise, it is "remote change only". If both the local and remote elements differ from the baseline element, and there are also differences between them, it is determined to be a "conflicting change".

[0096] Without a baseline semantic script, since only the inconsistencies between local and remote code can be seen, it is impossible to determine which party actively modified the code or both parties made modifications. This often leads to all differences being treated as conflicts, forcing manual intervention to handle a large number of scenarios that could have been automatically merged.

[0097] In this application, by introducing a baseline semantic script and judging change attributes, non-conflict scenarios can be accurately identified, and overwrite or merge operations can be automatically performed. Only when both parties have made different modifications to the same logical unit is it marked as a true conflict. This not only significantly reduces the number of conflicts requiring manual intervention and lowers the integration difficulty, but also ensures that the merge result follows the logic of "preserving valid changes and resolving real conflicts," improving the automation success rate of version integration and code security.

[0098] More specifically, in this embodiment of the application, the step of determining the change attributes of each pair of differing elements based on the baseline semantic script includes:

[0099] Based on the baseline semantic script, extract the baseline elements corresponding to the currently processed difference element pairs;

[0100] Among them, the baseline element refers to the logical unit in the original public version before the version branch diverges. It serves as a reference standard for judging the source of the change and includes the existence status (such as whether it exists) and content status (such as specific parameter values ​​and connection relationships) of the logical unit at the time of the split.

[0101] The currently processed difference element pair refers to a pair of logical units being analyzed during the comparison process, consisting of a local element from the local branch and a remote element from the remote branch, which semantically correspond to the same functional position.

[0102] The existence and content states of the baseline element are compared with the existence and content states of the local elements in the current processing difference element pair and the existence and content states of the remote elements in the current processing difference element pair, respectively.

[0103] The change attributes of the currently processed difference element pairs are determined based on the obtained state comparison results.

[0104] Specifically, the process first identifies the currently processed pair of differing elements and retrieves the corresponding baseline element from the baseline semantic script based on its unique identifier within the code structure. Then, a two-dimensional state comparison is performed: the first dimension is an existence state comparison, checking whether the baseline element, local element, and remote element are "present" or "missing"; the second dimension is a content state comparison, further comparing the internal attribute values ​​of elements that are consistent if all elements exist. Based on the results of these two comparisons, a logical decision tree is used to determine the changed attribute.

[0105] More specifically, in the embodiments of this application, if the local element and the baseline element have the same state but the remote element is different, it is determined as "remote change only"; otherwise, it is "local change only"; if the local and remote elements have undergone the same change relative to the baseline element, it is determined as "consistent change without conflict"; if the local and remote elements have undergone different changes relative to the baseline element, it is determined as "conflicting change".

[0106] In step S5, the corresponding execution mode is determined according to each of the changed attributes, and the corresponding elements in each of the difference element pairs are processed based on the execution mode to obtain the integrated semantic script.

[0107] Among them, the execution mode refers to the set of specific processing strategies preset for different change attributes of the difference element pair; while the integrated semantic script is the final structured data file generated after the execution mode is processed, which integrates all conflict-free valid changes in the local hardware code and the remote hardware code.

[0108] Specifically, it iterates through all pairs of difference elements marked with changed attributes and dynamically matches the corresponding execution mode based on the attribute type. For difference element pairs determined to be "locally changed only," the "automatically adopt local" mode is activated, directly writing the local elements in the difference element pair into the integration semantic script, ignoring remote elements. For "remotely changed only," the "automatically adopt remote" mode is activated, selecting remote elements for writing. If the changed attribute shows that neither party has modified it or the modifications are consistent, the "maintain baseline" mode is executed, including the baseline element or any consistent element in the result. When a "conflicting change" attribute is encountered, the "conflict suspension" mode is entered, simultaneously preserving both the local and remote elements in the difference element pair in a specific conflict area of ​​the integration semantic script, and marking it as requiring manual intervention.

[0109] In one possible implementation, the step of determining the change attribute of the currently processed difference element pair based on the obtained state comparison result includes:

[0110] If the existence status representation of the baseline element exists, the existence status representation of the remote element exists and its content status is consistent with the content status of the baseline element, and the existence status representation of the local element does not exist, then the change attribute is determined to be a local deletion attribute.

[0111] The local deletion attribute is used to identify situations where the currently processed difference element pair is "removed locally but retained remotely" during the evolution process.

[0112] If the changed attribute is a local deletion attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding element based on the execution mode includes:

[0113] The execution mode is determined to be the removal execution mode;

[0114] In the removal execution mode, the local elements are excluded when constructing the integrated semantic script.

[0115] Specifically, the system first reads the state comparison results generated in the previous step, focusing on checking three key indicators: the existence of the baseline element, the content consistency of the remote element, and the absence of the local element. When it detects that both the baseline and remote elements exist and have completely identical content, while the local element is marked as absent, the logic engine immediately determines that the change attribute of the differing element pair is a local deletion attribute. Once this attribute is confirmed, the associated removal execution mode is invoked. During the construction of the integration semantic script, the instructions of this mode are followed, actively skipping or filtering any reconstruction operations of the logical unit. This means that although the remote branch retains the element, the deletion operation of the local branch is respected, and the final generated integration semantic script will not contain the programmatic entity corresponding to the element, thus completing the formal removal of the module, port, or parameter at the logical level.

[0116] In one possible implementation, the step of determining the change attribute of the currently processed difference element pair based on the obtained state comparison result includes:

[0117] If the existence status representation of the baseline element does not exist, but the existence status representation of the remote element exists, then the changed attribute is determined to be a remotely added attribute.

[0118] Among them, the newly added remote attribute is used to identify that the currently processed difference element pair represents a separate innovation or extension of the remote branch.

[0119] If the changed attribute is a remotely added attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding element based on the execution mode includes:

[0120] The execution mode is determined to be the add execution mode;

[0121] Based on the aforementioned execution mode, the content of the remote element is integrated into the integrated semantic script.

[0122] Specifically, the first step is to examine the state comparison results, focusing on capturing the characteristic combination where the baseline element's state is "not present" while the remote element's state is "present." Once this condition is met, the logic engine can determine that the changed attribute of the differing element pair is a newly added remote attribute, meaning that this is new content independently developed by the remote branch after the baseline. Subsequently, it automatically matches and activates the add execution mode bound to this attribute.

[0123] Driven by this pattern, the complete content state of remote elements (including all programmatic entity information such as their module definitions, port connections, and parameter configurations) is extracted and incorporated into the integrated semantic script being built.

[0124] In one possible implementation, the step of determining the change attribute of the currently processed difference element pair based on the obtained state comparison result includes:

[0125] If the existence status representation of the baseline element exists, and the existence status representation of either the local element or the remote element does not exist, while the existence status representation of the other element exists and its content status is inconsistent with the content status of the baseline element, then the change attribute of the currently processed difference element pair is determined to be a modification / deletion conflict attribute.

[0126] Among them, modifying or deleting conflicting attributes is a high-risk change attribute label used to identify extreme cases where logical mutual exclusion exists in the currently processed pairs of differing elements.

[0127] If the changed attribute is the modified / deleted conflict attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding conflicting element based on the execution mode includes:

[0128] The execution mode is determined to be an intervention execution mode;

[0129] Based on the intervention execution mode, a conflict alarm signal containing the corresponding currently processed difference element pair is generated.

[0130] Specifically, for this attribute to be valid, three stringent conditions must be met simultaneously: the baseline element serving as the reference standard must have existed in the historical version; one of the local and remote elements must have completely deleted the element (existence status indicates non-existence), while the other element must not only have retained the element (existence status indicates existence), but also have substantially modified it (content status is inconsistent with the content status of the baseline element).

[0131] More specifically, when a baseline element is detected and the local branch and the remote branch show completely opposite operational intentions—that is, one side believes that the module is obsolete and removes it, while the other side believes that the module still needs to be optimized and modifies its internal parameters or connection relationships—the logic engine immediately determines that the change attribute of the difference element pair is a modification / deletion conflict attribute.

[0132] In this scenario, the correct merge direction cannot be automatically inferred as with other changed attributes. Automatically adopting the modifying version would contradict the deleting version's intent, while automatically executing the deletion would result in the loss of the modifying version's innovative contributions. Therefore, an intervention execution mode is activated, halting any automatic write operations to this element and instead generating a conflict alert signal containing detailed information about the currently processed difference element. This signal is sent to the user interface or logs, explicitly indicating a logical conflict and forcing manual review to determine whether to retain the modified version or perform the deletion operation.

[0133] More specifically, by determining the execution mode based on the change attributes, it can intelligently distinguish between "non-conflicting changes" and "real conflicts." For scenarios with numerous unilateral modifications, merging can be completed automatically without manual intervention, greatly freeing up human resources. Simultaneously, because the processed objects are structured elements rather than lines of text, the generated integration semantic script ensures logical integrity, avoiding syntax violations caused by interleaved text lines. This strategy-based execution mode ensures that each merge operation is predictable and controllable, pausing the process only in conflict scenarios that truly require designer judgment, thereby maximizing integration efficiency while ensuring code quality.

[0134] In step S6, top-level hardware code is generated based on the integrated semantic script, and the top-level hardware code is submitted to the version control module.

[0135] Among them, the top-level hardware code refers to the complete source code file that is reconstructed based on the integrated semantic script and conforms to the standard hardware description language specification (such as Verilog or SystemVerilog). It restores the readable text format of the code and contains all the logical entities, module instances, signal connections and parameter definitions after merging and adjudication. It represents the final design version after the fusion of local and remote branches and can be directly used for subsequent simulation verification or logic synthesis.

[0136] Specifically, the process begins by reading the integrated semantic script. The code generation engine then iterates through each logical element in the script, reversing abstract logical objects (such as module names, port lists, and attribute values) into concrete hardware description language statements based on preset code templates and formatting rules. During this process, indentation, line breaks, and comments are automatically handled to ensure that the generated top-level hardware code is not only logically correct but also conforms to coding standards. Subsequently, the application programming interface (API) of the version control module is called to load the generated top-level hardware code as a new file version into the staging area and execute a commit operation. This operation writes the current merged code state as a new commit node into the repository's history and updates the pointer of the current branch, making the merged code officially part of the project's main line for use in subsequent development processes.

[0137] Reference Figure 2 , Figure 2 This is a virtual structural diagram of a multi-party collaborative SoC top-level integration device provided in this application. A second aspect of this application provides a multi-party collaborative SoC top-level integration device, comprising:

[0138] The same-name code matching module 100 is used to obtain the local hardware code, input the local hardware code into the version control module, and match the remote hardware code corresponding to the local hardware code in the version control module.

[0139] The semantic script conversion module 200 is used to perform semantic script conversion on the local hardware code and the remote hardware code respectively to obtain a first semantic script corresponding to the local hardware code and a second semantic script corresponding to the remote hardware code.

[0140] The first semantic script contains local elements of various types, and the second semantic script contains remote elements of various types, with the element types of the local elements and the remote elements corresponding one-to-one.

[0141] The difference element extraction module 300 is used to compare the first semantic script and the second semantic script to extract at least one difference element pair; a difference element pair includes a local element and a remote element of the corresponding type.

[0142] The change attribute judgment module 400 is used to obtain the baseline semantic script and judge the change attributes of each of the difference element pairs based on the baseline semantic script;

[0143] The difference element processing module 500 is used to determine the corresponding execution mode according to each of the changed attributes, process the corresponding elements in each of the difference element pairs based on the execution mode, and obtain an integrated semantic script.

[0144] The top-level code generation module 600 is used to generate top-level hardware code based on the integrated semantic script and submit the top-level hardware code to the version control module.

[0145] The multi-party collaborative SoC top-level integration device described in this application embodiment can execute the multi-party collaborative SoC top-level integration method provided in the above embodiments. The multi-party collaborative SoC top-level integration device has the corresponding functional steps and beneficial effects of the multi-party collaborative SoC top-level integration method described in the above embodiments. For details, please refer to the embodiments of the multi-party collaborative SoC top-level integration method described above. The embodiments of this application will not be repeated here.

[0146] This application also provides an electronic device, please refer to... Figure 3 , Figure 3This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include a processor and a memory, which can be connected via a bus or other means. The processor may be a Central Processing Unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips. The memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the multi-party collaborative SoC top-level integration method in the embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the multi-party collaborative SoC top-level integration method in the above method embodiments.

[0147] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. The one or more modules stored in the memory, when executed by the processor, perform the multi-party collaborative SoC top-level integration method as described in the above method embodiments. Specific details of the above electronic device can be understood by referring to the corresponding descriptions and effects in the above method embodiments, and will not be repeated here. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it may include the processes of the embodiments of the above methods. The storage medium may be a read-only memory (ROM), a random access memory (RAM), a flash memory, a hard disk drive (HDD), or a solid-state drive (SSD), etc.; the storage medium may also include a combination of the above types of memory.

[0148] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0149] Similarly, it should be understood that, in order to streamline this disclosure and aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together in a single embodiment, figure, or description thereof. However, this approach to disclosure should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0150] It should be noted that the above embodiments are illustrative of this application and not restrictive of this application, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims.

Claims

1. A multi-party collaborative SoC top-level integration method, characterized in that, The method includes: Obtain the local hardware code, input the local hardware code into the version control module, and match the remote hardware code corresponding to the local hardware code in the version control module; Semantic script conversion is performed on the local hardware code and the remote hardware code respectively to obtain a first semantic script corresponding to the local hardware code and a second semantic script corresponding to the remote hardware code; including: compiling and parsing the current hardware code to identify module instances, signal ports, configuration parameters, and macro definitions of the current hardware code; wherein the current hardware code is either the local hardware code or the remote hardware code; mapping the identified module instances, signal ports, configuration parameters, and macro definitions to programmatic entities; wherein the programmatic entities are class objects or data structures; and constructing the current semantic script corresponding to the current hardware code based on the programmatic entities; wherein the current semantic script is either the first semantic script or the second semantic script. The first semantic script contains local elements of various types, and the second semantic script contains remote elements of various types, with the element types of the local elements and the remote elements corresponding one-to-one. By comparing the first semantic script and the second semantic script, at least one pair of differing elements is extracted; each pair of differing elements includes a local element and a remote element of the corresponding type. Obtaining a baseline semantic script and determining the change attributes of each pair of difference elements based on the baseline semantic script includes: extracting a baseline element corresponding to the currently processed pair of difference elements based on the baseline semantic script; wherein the currently processed pair of difference elements is any pair of difference elements; comparing the existence state and content state of the baseline element with the existence state and content state of the local element in the currently processed pair of difference elements, and the existence state and content state of the remote element in the currently processed pair of difference elements; and determining the change attributes of the currently processed pair of difference elements based on the obtained state comparison results. Based on each of the changed attributes, the corresponding execution mode is determined, and the corresponding elements in each of the difference element pairs are processed based on the execution mode to obtain the integrated semantic script; The top-level hardware code is generated based on the integrated semantic script, and the top-level hardware code is submitted to the version control module.

2. The multi-party collaborative SoC top-level integration method according to claim 1, characterized in that, Before the step of comparing the first semantic script with the second semantic script, the method further includes: Perform a reference compatibility check between the local hardware code and the remote hardware code; If the reference compatibility check fails, a reference error message is generated and the top-level integration method is terminated.

3. The multi-party collaborative SoC top-level integration method according to claim 1, characterized in that, The step of determining the changed attributes of the currently processed difference element pair based on the obtained state comparison results includes: If the existence status representation of the baseline element exists, the existence status representation of the remote element exists and its content status is consistent with the content status of the baseline element, and the existence status representation of the local element does not exist, then the change attribute is determined to be a local deletion attribute. If the changed attribute is a local deletion attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding element based on the execution mode includes: The execution mode is determined to be the removal execution mode; In the removal execution mode, the local elements are excluded when constructing the integrated semantic script.

4. The multi-party collaborative SoC top-level integration method according to claim 1, characterized in that, The step of determining the changed attributes of the currently processed difference element pair based on the obtained state comparison results includes: If the existence status representation of the baseline element does not exist, but the existence status representation of the remote element exists, then the changed attribute is determined to be a remotely added attribute. If the changed attribute is a remotely added attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding element based on the execution mode includes: The execution mode is determined to be the add execution mode; Based on the aforementioned execution mode, the content of the remote element is integrated into the integrated semantic script.

5. The multi-party collaborative SoC top-level integration method according to claim 1, characterized in that, The step of determining the changed attributes of the currently processed difference element pair based on the obtained state comparison results includes: If the existence status representation of the baseline element exists, and the existence status representation of either the local element or the remote element does not exist, while the existence status representation of the other element exists and its content status is inconsistent with the content status of the baseline element, then the change attribute of the currently processed difference element pair is determined to be a modification / deletion conflict attribute. If the changed attribute is the modified / deleted conflict attribute, then the step of determining the corresponding preset execution mode based on the changed attribute and processing the corresponding conflicting element based on the execution mode includes: The execution mode is determined to be an intervention execution mode; Based on the intervention execution mode, a conflict alarm signal containing the corresponding currently processed difference element pair is generated.

6. A multi-party collaborative SoC top-level integration device, characterized in that, include: The same-name code matching module is used to obtain the local hardware code, input the local hardware code into the version control module, and match the remote hardware code corresponding to the local hardware code in the version control module. A semantic script conversion module is used to perform semantic script conversion on the local hardware code and the remote hardware code respectively, to obtain a first semantic script corresponding to the local hardware code and a second semantic script corresponding to the remote hardware code; including: compiling and parsing the current hardware code to identify the module instance, signal port, configuration parameter, and macro definition of the current hardware code; wherein the current hardware code is the local hardware code or the remote hardware code; mapping the identified module instance, signal port, configuration parameter, and macro definition to programmatic entities; wherein the programmatic entity is a class object or a data structure; and constructing the current semantic script corresponding to the current hardware code based on the programmatic entity; wherein the current semantic script is the first semantic script or the second semantic script. The first semantic script contains local elements of various types, and the second semantic script contains remote elements of various types, with the element types of the local elements and the remote elements corresponding one-to-one. The difference element extraction module is used to compare the first semantic script and the second semantic script to extract at least one difference element pair; a difference element pair includes a local element and a remote element of the corresponding type. A change attribute determination module is used to obtain a baseline semantic script and determine the change attributes of each pair of difference elements based on the baseline semantic script; including: extracting the baseline element corresponding to the currently processed pair of difference elements based on the baseline semantic script; wherein, the currently processed pair of difference elements is any pair of difference elements; comparing the existence state and content state of the baseline element with the existence state and content state of the local element in the currently processed pair of difference elements, and the existence state and content state of the remote element in the currently processed pair of difference elements; and determining the change attribute of the currently processed pair of difference elements based on the obtained state comparison results. The difference element processing module is used to determine the corresponding execution mode according to each of the changed attributes, and process the corresponding elements in each of the difference element pairs based on the execution mode to obtain the integrated semantic script. The top-level code generation module is used to generate top-level hardware code based on the integrated semantic script, and submit the top-level hardware code to the version control module.

7. An electronic device, characterized in that, include: One or more processors; One or more memory units; And one or more computer programs, wherein the one or more computer programs are stored in the one or more memories, the one or more computer programs including instructions that, when executed by the one or more processors, cause the electronic device to perform the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The storage medium stores a program or instructions that, when executed, implement the method as described in any one of claims 1 to 5.

Images