A code structure optimization method for synthesizing embedded software based on software IP

Abstract

The application belongs to the technical field of embedded software development and code optimization, and discloses a code structure optimization method for synthesizing embedded software based on software IP. The method is used for solving the problems of structure type redundancy and equivalent instance redundancy caused by IP encapsulation boundaries in the embedded C code generated by software IP synthesis, and sequentially completes engineering analysis index construction, structure body abstract modeling, header file merging determination, common header file generation and reference rewriting, instance equivalence modeling, equivalent instance redirection, loop iteration verification and consistency review, so as to realize source code level structure optimization. The method does not depend on a specific compiler and does not change the IP underlying algorithm, can accurately eliminate structure redundancy, reduces code storage and memory occupation, and improves the compiling efficiency and maintainability.

Description

Technical Field

[0001] This invention belongs to the field of embedded software development and code optimization technology, specifically relating to a method for optimizing the code structure of embedded software based on software IP synthesis. Background Technology

[0002] As the complexity of embedded systems continues to increase, software IP synthesis technology has been widely used in embedded software development due to its advantages of modular reuse and rapid engineering construction. Software IP synthesis tools automatically generate embedded C language code based on independently packaged IP units. Each IP unit maintains independent header files and implementation logic, ensuring the reusability and independent maintainability of the IP, but also naturally creating structural code redundancy at the engineering level.

[0003] Existing code optimization techniques mostly focus on variable redundancy elimination, function inlining optimization, or compile-time instruction-level optimization, lacking targeted solutions for structural redundancy in software IP synthesis scenarios. Traditional code merging methods often rely on text similarity matching, failing to distinguish between differences in field naming and physical semantics, easily leading to incorrect or missed merging; conventional compiler backend optimizations can only handle redundancy within a single compilation unit, unable to cross IP encapsulation boundaries to achieve cross-file merging of structure types and instances.

[0004] Redundancy in structure types and equivalent instances directly increases the code size and runtime memory usage of embedded projects, conflicting with the resource-constrained nature of embedded systems. Furthermore, numerous repetitive type declarations and instance definitions reduce compilation efficiency and increase the costs of code maintenance, debugging, and porting. Therefore, there is an urgent need for a structure optimization method that can be executed at the source code level and adapts to the characteristics of software IP synthesis code, eliminating structural redundancy while ensuring semantic consistency. Summary of the Invention

[0005] To address the above problems, this invention provides a method for optimizing the code structure of embedded software based on software IP synthesis, comprising the following steps: Step 1: Project Input Parsing and Index Building. Read all relevant files of the project to be optimized, scan and parse all source files and header files, and build file indexes, include indexes, structure type indexes, field indexes, instance indexes, and call indexes. Step 2: Structure declaration extraction and summary modeling. Extract target structure declarations from the header files of various software IPs and generate standardized structure summaries. Step 3: Merging and grouping of multiple software IP header files. A two-stage determination mechanism based on structure digests, using hard constraint filtering and semantic constraint matching, is adopted to identify structures that meet the merging conditions and form merge groups. Step 4: Generate common header files and establish mapping relationships. Generate common header files and common structure types for each merge group, and establish type mapping tables and field mapping tables from the original structure to the common structure. Step 5: Simultaneously rewrite all project type references and field accesses, rewriting the include relationships, type references, and field accesses in all relevant files of the entire project according to the mapping relationship; Step 6: Instance relationship reconstruction and equivalence modeling. Rescan the instance information in the project and construct an instance relationship model that includes static signatures and semantic signatures. Step 7: Merge equivalent instances and redirect representative instances. Identify shared equivalent instances based on the instance relationship model, retain the representative instance, and redirect references to the remaining instances to the representative instance. Step 8: Redundancy determination and iterative loop. Verify whether there are still redundancies in the project that meet the merging conditions. If so, return to re-execute the header file merging to instance merging process. If there are no remaining redundancies, proceed to consistency review. Step 9: Consistency review and risk correction. Perform a full-dimensional consistency check on the merged project. If errors are found, roll back to the corresponding processing step for correction. Step 10: Optimize project output and delivery, output the optimization results to an isolated directory, and retain complete traceability information.

[0006] Preferably, in step 2, when generating the structure summary, the field type is processed using type alias normalization technology, the array dimension is processed using array length normalization technology, the field semantics is processed using physical meaning normalization technology, and the field order constraint attributes are marked; the field order constraint attributes include two types: forced consistency and unified sorting.

[0007] Preferably, in the two-stage determination mechanism of step 3, the verification conditions for the first-stage hard constraint filtering include consistent field quantity, compatible field type families, consistent array dimension and length, consistent pointer attributes, compatible field read and write attributes, no mutual exclusion condition compilation conflict, and no external binary layout constraint conflict; the verification conditions for the second-stage semantic constraint matching include consistent port category, consistent physical meaning or reaching the configured semantic matching threshold, field order represented by a common order, and annotation differences not changing the business meaning.

[0008] Preferably, the naming of common structure fields in step 4 includes three strategies: using field names representing IP, using physical meaning specification names, and using user-configured field name mappings; the original IP header file supports three processing methods: retaining the original header file and deleting duplicate structure declarations before adding a common header file include, retaining the original structure type name as a typedef alias for the common structure type, and directly removing duplicate type declarations in the original header file and uniformly using the common structure type.

[0009] Preferably, in step 5, the include relationship rewriting follows the principle of minimum necessity; the type reference rewriting scope covers the main control C file, main control header file, IP header file, and IP implementation file, and the rewritten objects include type declarations, function parameters, variable declarations, sizeof expressions, and type casting; the field access rewriting covers dot access, arrow access, array instance access, and simple pointer alias access.

[0010] Preferably, the static signature of the instance relationship data in step 6 includes the merged structure type, instance declaration location, initialization method, calling function, and calling parameters; the semantic signature includes the port binding set, parameter binding set, state member set, external resource set, debug observation set, and timing isolation marker.

[0011] Preferably, in step 7, the equivalent instances that meet the merging conditions must simultaneously satisfy all of the following conditions: the merged structure types are consistent, the port binding set and the parameter binding set are consistent, the state member set is empty, there are no independent caches, peripheral handles, random number seeds, time accumulation and fault latches, no debugging observation requirements and timing isolation requirements, and there are no alias write conflicts in the call references.

[0012] Preferably, in step 7, the representative instance is determined according to the order of appearance, naming stability, number of calls, or user configuration, and the instance that appears for the first time in the main control program and has a stable name is selected; during the merging execution, the declaration and initialization statements of the representative instance are retained, the corresponding statements of the merged instance are commented out or deleted, and all calling parameters of the merged instance are replaced with those of the representative instance.

[0013] Preferably, the consistency verification content in step 9 includes: the correctness of public header file references, the residual status of semantic references to the original structure type, the residual status of access to the original field name members, the residual status of calls to the original instance name, the update status of IP port information, the consistency between function declarations and call parameters, and the integrity of references to each conditional compilation path.

[0014] Preferably, the output of step 10 includes common header files, rewritten project files, type and instance mapping tables, updated IP port information, merge logs, and skip logs; after the project is output, it is recommended to perform three levels of verification: preprocessing check, compilation check, and reference residue check.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: By employing a two-level determination mechanism of standardized structure summary modeling and hard constraint filtering and semantic constraint matching, it can accurately identify equivalent structures by breaking through IP encapsulation boundaries and generate a unified public header file to reduce duplicate type declarations. At the same time, it establishes a complete type and field mapping traceability relationship, taking into account merging efficiency and code auditability, and effectively compressing the size of the project header file.

[0016] Based on the dual-dimensional determination of instance equivalence using static signatures and semantic signatures, strict boundaries are set for state members, peripheral handles, alias writing, etc., which do not meet the merging conditions. Representative instances are selected to complete the full-project reference redirection. While ensuring that the semantics of the code functions completely remain consistent, the memory usage of duplicate instances is reduced, which is suitable for embedded application scenarios with limited resources.

[0017] The iterative cyclic mechanism eliminates the new redundancy generated during the merging process. Combined with full-dimensional consistency verification and step-by-step error rollback mechanism, it fully guarantees the correctness of code compilation and semantic consistency by adhering to the conservative merging principle. The method does not depend on a specific compiler and does not require modification of the underlying IP algorithm. It can be adapted to various software IP synthesis projects and has a low implementation threshold. Attached Figure Description

[0018] Figure 1 This is an overall flowchart of the method of the present invention. Detailed Implementation

[0019] The present invention will be further described in detail below with reference to specific embodiments. It should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.

[0020] This specific implementation provides a code structure optimization method for embedded software synthesized based on software IP (intellectual property). It targets embedded C programming language (hereinafter referred to as C language) software engineering generated by software IP synthesis tools. Addressing two types of structural redundancy in the synthesized code—structure type redundancy and equivalent instance redundancy—caused by software IP encapsulation boundaries, header file independent maintenance mechanisms, and instance redundancy declaration mechanisms, it achieves source code-level structural optimization through a chained processing flow of header file merging, instance merging, redundancy determination, and iterative iteration. All steps of this method can be implemented by a program running on a regular computer, server, or software IP synthesis platform. (Refer to...) Figure 1 The following is a detailed explanation of the technical implementation details of each step in the order of execution.

[0021] Step 1: Project Input Parsing and Index Building: This step reads all relevant files of the project to be optimized, establishes a unified code mirror and multi-level index, and provides a data foundation for subsequent merging processing.

[0022] 1. The method input includes: the directory of the project to be optimized, the set of software IP header files, the set of software IP implementation files, the main control C file, the main control header file, IP port information, the previous optimization results, the type alias table, the physical meaning synonym table, the header file merging configuration, the instance merging configuration, and the skip list. The previous optimization results can come from program variable optimization methods or manual confirmation results. This method is preferably executed after the port set and structure member set are stable; previous optimization is not a necessary prerequisite.

[0023] 2. The system scans and parses all source files and header files, and builds file indexes, include indexes, structure type indexes, field indexes, instance indexes, and call indexes, recording the inclusion relationships, structure declaration locations, instance declaration locations, member access locations, and function call locations of each file.

[0024] Step 2: Structure Declaration Extraction and Summary Modeling: This step extracts the target structure declarations from the header files of each software IP and generates a standardized structure digest, which serves as the core criterion for header file merging.

[0025] 1. Locate the target structure in each IP header file, and parse the field declarations, comment text, conditional compilation areas, and include dependencies.

[0026] 2. Generate a structure summary for each structure. The summary should include at least the structure name, source header file, field names, field types, type alias normalization result, array length, pointer attributes, port type, physical meaning, field order, comment text, conditional compilation context, include dependencies, and external layout constraint tags.

[0027] 3. Use type alias normalization technology to process field types: For typedef types, expand to a unified type family according to the type alias table. For example, map the aliases of unsigned 8-bit integers such as `uint08`, `uint8`, and `unsignedchar` to the same basic type family to eliminate the interference of naming differences on type determination.

[0028] 4. Use array length normalization technology to handle array dimensions: For array lengths in the form of macro definitions, numeric constants, or equivalent expressions, parse macro values ​​or preserve symbolic expressions for equivalence judgment within the configuration limits.

[0029] 5. Use physical meaning standardization technology to process field semantics: physical meaning is taken from port information description, physical quantity name in parameter mapping table, field comments or manual configuration; perform standardization processing on physical meaning to remove differences in capitalization, underscore differences, common prefixes and suffixes and IP name prefixes, and identify synonyms through a physical meaning thesaurus.

[0030] 6. Mark field order constraint attributes: If the field order is constrained by external binary layout, communication protocol, or hardware register mapping, it is marked as mandatory consistency; if the field order is determined solely by the synthesizer generation order, it is marked as uniform sorting. This constraint is determined by external layout tags, comment keywords, skip lists, and user configuration.

[0031] Step 3: Merging and grouping IP header files from multiple software programs: This step, based on structure summarization, employs a two-stage decision mechanism of hard constraint filtering and semantic constraint matching to identify structures that meet the merging conditions and form merge groups.

[0032] 1. First stage: Hard constraint filtering: Hard constraint checks are performed on all structure summaries. Structures that meet all hard constraints are included in the candidate group. Hard constraints include: consistent number of fields, compatible field type families, consistent array dimensions and lengths, consistent pointer attributes, compatible field read / write attributes, no mutual exclusion compilation conflicts, and no external binary layout constraint conflicts.

[0033] If there are cases where the number of fields is significantly different, array length conflicts occur, pointers and non-pointers are mixed, bit fields differ, or conditional compilation is mutually exclusive, it is directly determined that the merging condition is not met, the original state is retained, and the reason is recorded.

[0034] 2. Second stage: Semantic constraint matching: For candidate groups filtered by hard constraints, semantic constraint validation is performed. Structures that satisfy all semantic constraints are formed into the final merged group. Semantic constraints include: consistent port category, consistent physical meaning or reaching the configured semantic matching threshold, field order represented by a common order, and annotation differences not changing the business meaning.

[0035] If the field names are the same but the physical meanings are different, they will not be merged; if the field names are different but the physical meanings are the same, the merging conditions are met and the field name mapping relationship is established synchronously.

[0036] 3. A two-level grouping execution logic is adopted: the first level generates candidate groups based on the number of fields, type family sequence, and array dimension; the second level performs precise matching within the candidate groups based on port category and physical meaning. If a structure can enter multiple merge groups simultaneously, a unique merge group is selected based on the matching score, common field coverage, and user configuration; if a unique selection is not possible, the original structure is retained.

[0037] Step 4: Generate common header files and establish mapping relationships: This step generates a common header file and a common structure type for each merge group, and establishes a complete mapping relationship from the original structure to the common structure.

[0038] 1. Generate a common header file. The file content includes header file protection macros, necessary include dependencies, typedef declarations of common structures, and optional field comments. Header file protection macros are generated based on the common header file name to avoid naming conflicts with the original IP header file; necessary include dependencies are determined by field type dependencies, with priority given to header files containing basic type definitions.

[0039] 2. Public structure field naming supports three strategies: using field names representing IP addresses, using physical meaning-based canonical names, and using user-configured field name mappings. Regardless of the strategy used, the mapping from the original field names to public field names is saved for subsequent member access rewriting.

[0040] 3. The original IP header file supports three processing methods, determined by project configuration and review requirements: Retain the original header files, only remove or comment out duplicate structure declarations, and add include to common header files; Retain the original structure type name as a typedef alias for the common structure type to reduce the scope of rewriting in the main control file; Remove duplicate type declarations from the original header file and use the common struct type in all reference locations.

[0041] To facilitate review, the original structure declaration comments can be retained to indicate that it has been replaced by a public structure.

[0042] 4. Establish a complete mapping relationship, record the correspondence between each original header file, original structure type, original field name and common header file, common structure type, common field name, and generate a type mapping table and a field mapping table.

[0043] Step 5: Simultaneously rewrite all project type references and field accesses: This step involves rewriting the include relationships, type references, and field accesses in all relevant files across the entire project based on the mapping relationships, ensuring consistent code references after merging.

[0044] 1. Rewriting the include relationship: File inclusion relationships are handled according to the principle of minimum necessity: for files that still require function declarations or other type declarations from the original header file, the original header file's `include` directive is retained; for files that only include the original header file because of a structure type, a common header file is included instead. The system records the reasons for rewriting `include` directives to avoid accidentally deleting necessary declarations.

[0045] 2. Type reference rewriting: The rewrite scope covers the main control C file, main control header file, IP header file, and IP implementation file. The search objects include type declarations, function parameters, local variable declarations, global instance declarations, sizeof (storage space size calculation operator) expressions, type casting, and traceable markers in comments.

[0046] Perform actual rewriting on type references at semantic locations in the code, replacing the original struct type name with a public type name or an alias of the original type; for comment locations, the original text can be retained or supplementary explanations can be added according to the configuration. The rewriting process avoids blindly replacing strings to prevent accidental modification of function names, macro names, or ordinary comment content.

[0047] 3. Field access rewriting: If the public field name differs from the original field name, all member access expressions are rewritten synchronously, including dot access, arrow access, array instance access, and simple pointer alias access. For field access generated by complex macro concatenation, processing is only performed when macro expansion rules are provided in the configuration.

[0048] After the field access is rewritten, check whether the old field name still exists in the semantic location of the code; if there is a remnant, the merge group will fail the review and be returned for supplementary rewriting.

[0049] Step 6: Instance Relation Reconstruction and Equivalence Modeling: After the header files are merged, this step rescans the instance information in the project and constructs an instance relationship model, which serves as the basis for determining equivalent instance merging.

[0050] 1. Rescan the instance declarations, initialization statements, and function call parameters in the master control file and update the instance index.

[0051] 2. Generate instance relationship data for each instance, consisting of two parts: a static signature and a semantic signature. Static signature: includes the merged structure type, instance declaration location, initialization method, function call, and call parameters; Semantic signatures include port binding sets, parameter binding sets, state member sets, external resource sets, debug observation sets, and timing isolation tags.

[0052] 3. Core signature item definition: The port binding set records the master control variable or constant that each port in the instance is ultimately bound to; the parameter binding set records the source of the instance parameters; the state member set records whether the instance retains members written across cycles.

[0053] Step 7: Merge equivalent instances and redirect representative instances: This step is based on the instance relationship model, identifies shared equivalent instances, retains the representative instance, and redirects references to the remaining instances to the representative instance.

[0054] 1. Criteria for determining equivalent instances: Multiple instances are considered equivalent instances that satisfy the merge condition when they simultaneously meet all of the following conditions: After merging, the structure types are consistent; The port binding set is consistent, and the parameter binding set is consistent. The set of state members is empty, meaning there are no private states; No independent cache, no peripheral handles, no random number seed, no time accumulation, and no fault latch; No debugging or observation requirements, no timing isolation requirements; There is no alias write conflict when calling the reference.

[0055] 2. Boundary determination for non-compliance with merge conditions: If an instance is involved in an array, its address is stored, it is passed to an unknown function, or there is a risk of writing aliases, it is determined that the merging condition is not met; if the set of state members is not empty, it will not be merged by default. If the user explicitly configures a certain state member as a read-only public parameter, it can be re-evaluated.

[0056] 3. Representative instance selection rules: Representative instances can be determined by their order of appearance, naming stability, number of calls, or user configuration. The instance that appears for the first time in the main control program and has a stable name is selected as the representative instance to reduce the scope of rewriting.

[0057] 4. Merge execution operation: The declaration and initialization statements representing the instances are retained, while the declaration, initialization, and zeroing statements of the instances to be merged are commented out or deleted; Replace all call parameters of the instance to be merged with the representative instance; if the instance to be merged only appears as a function parameter, directly modify the call parameters; If the instance to be merged is saved by address or added to an array, it is necessary to determine whether the array or address table can be rewritten synchronously. If it cannot be confirmed, it should not be merged. If the merged instance name is used for log or debug identifiers, retain the independent instance or generate an alias description based on the configuration.

[0058] 5. After the merge is complete, update the IP port information, write the mapping relationship from the original instance to the representative instance into the port information, retain the traceability relationship from the original name to the new name, ensure that subsequent analysis will not continue to reference the old instance, and facilitate subsequent debugging and review.

[0059] Step 8: Redundancy detection and iterative loop: This step verifies whether there are still redundant elements in the current project that meet the merging conditions, and eliminates the newly added redundancy generated by the previous merging through iterative loops.

[0060] 1. Redundancy determination includes: whether there are still header files that meet the merging conditions, unified structure types, unprocessed type references, or equivalent instances that meet the merging conditions.

[0061] 2. If redundancy still exists, return to step 3 and re-execute the complete process from header file merging to instance merging; if no remaining redundancy exists, proceed to the consistency review stage.

[0062] Step 9: Consistency Review and Risk Correction: This step performs a full-dimensional consistency check on the merged project, following the conservative merging principle to ensure that the optimized project has semantic consistency and can be compiled normally.

[0063] 1. The consistency review includes: Whether the public header files are generated and correctly referenced; Does the original struct type still have unprocessed semantic references? Does the original field name still appear in the member access semantics? Does the original instance name still participate in initialization or function calls? Has the IP port information been updated for the public type mapping and representative instance mapping? Are the function declaration and the calling parameters consistent? Check if there are any missing references in the compilation paths for each condition.

[0064] 2. Error Correction Mechanism: If an error is found during review, the process will revert to the corresponding processing step based on the error type. For example, if an old field name is still being accessed, the process will return to step 5 to rewrite it; if a write conflict exists after instance merging, the instance merging will be reversed; if a common header file lacks necessary include, the process will return to step 4 to add the dependency.

[0065] 3. Exception and Boundary Handling Rules: If the structure contains conditional compilation fields, check each conditional compilation path separately, and do not merge if it cannot be confirmed that all paths are equivalent. If a structure field involves hardware registers, communication protocol frames, or external binary layouts, the external layouts must be completely consistent; otherwise, they will not be merged. Merge failure does not affect the execution of other merge groups. The system records the reason for the failure in the skip log, and the user can rerun the method after supplementing the configuration. The system must not ignore failure conditions in order to improve the merge rate.

[0066] Step 10: Optimize project output and delivery: This step outputs all optimization results to an isolated directory, preserving complete traceability information for easy compilation verification and difference review.

[0067] 1. The output includes: common header file, rewritten IP header file, rewritten IP implementation file, rewritten main control file, mapping table from original structure type to common structure type, mapping table from original instance to representative instance, updated IP port information, merge log and skip log.

[0068] 2. The output directory is organized into categories, including the common header file directory, the rewritten IP header file directory, the rewritten IP implementation file directory, the master control file directory, the mapping table directory, and the log directory.

[0069] 3. After project output, it is recommended to perform three levels of verification: Preprocessing checks: Confirm that the include relationships between common header files and original header files are correct; Compilation check: Confirms that the type name, field name, and instance name have all been updated correctly, and the project can be compiled normally; Reference residue check: Confirms that old types, old fields, and old instances are not left in semantic locations in the code.

[0070] The following typical scenarios illustrate the actual execution process of this method: 1. Homogeneous but Heterogeneous Field Structure Merging Scenario: The system reads two software IP header files. Both have the same number of structure fields, identical field type families, array lengths, and port categories, but their field names differ due to different IP name prefixes. The system further reads the physical meaning of the ports, confirms that each field represents the same physical quantity, adds the two structures to the same merge group, generates a common header file and a common structure type, establishes a mapping from the original field names to the common field names, and synchronously rewrites the corresponding member access expressions in the two IP implementation files.

[0071] 2. Exclusion of Structures with Similar Text but Different Semantics: The system detects two structures with similar field names, but one field represents a control command in port information, while the other represents a feedback status. Although the text similarity is high, the physical meaning is inconsistent, so the system does not merge them and records the reason in the skip log.

[0072] 3. Equivalent Instance Merging Scenario: After merging header files, the system recalculates the instance relationships in the main control program. If two instances have the same type, port binding, parameter binding, and no state members after merging, the system selects the first instance to appear as the representative instance, changes the call reference of the other instance to the representative instance, and updates the instance mapping table and port information.

[0073] This method does not rely on a specific compiler backend, nor does it require changes to the underlying algorithm of the software IP. As long as the project provides the IP header file, IP implementation file, master control file, and port information, those skilled in the art can perform header file merging and equivalent instance merging according to the above steps. For projects with incomplete field physical meanings, the structure summary information can be supplemented by configuring a thesaurus, field mapping table, or manual confirmation list, and then merging can be performed according to conservative rules.

Claims

1. A method for optimizing the code structure of embedded software based on software IP synthesis, characterized in that, Includes the following steps: Step 1: Project Input Parsing and Index Building. Read all relevant files of the project to be optimized, scan and parse all source files and header files, and build file indexes, include indexes, structure type indexes, field indexes, instance indexes, and call indexes. Step 2: Structure declaration extraction and summary modeling. Extract target structure declarations from the header files of various software IPs and generate standardized structure summaries. Step 3: Merging and grouping of multiple software IP header files. A two-stage determination mechanism based on structure digests, using hard constraint filtering and semantic constraint matching, is adopted to identify structures that meet the merging conditions and form merge groups. Step 4: Generate common header files and establish mapping relationships. Generate common header files and common structure types for each merge group, and establish type mapping tables and field mapping tables from the original structure to the common structure. Step 5: Simultaneously rewrite all project type references and field accesses, rewriting the include relationships, type references, and field accesses in all relevant files of the entire project according to the mapping relationship; Step 6: Instance relationship reconstruction and equivalence modeling. Rescan the instance information in the project and construct an instance relationship model that includes static signatures and semantic signatures. Step 7: Merge equivalent instances and redirect representative instances. Identify shared equivalent instances based on the instance relationship model, retain the representative instance, and redirect references to the remaining instances to the representative instance. Step 8: Redundancy determination and iterative loop. Verify whether there are still redundancies in the project that meet the merging conditions. If so, return to re-execute the header file merging to instance merging process. If there are no remaining redundancies, proceed to consistency review. Step 9: Consistency review and risk correction. Perform a full-dimensional consistency check on the merged project. If errors are found, roll back to the corresponding processing step for correction. Step 10: Optimize project output and delivery, output the optimization results to an isolated directory, and retain complete traceability information.

2. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, In step 2, when generating the structure summary, the field type is processed using type alias normalization technology, the array dimension is processed using array length normalization technology, the field semantics is processed using physical meaning normalization technology, and the field order constraint attributes are marked; the field order constraint attributes include two categories: forced consistency and unified sorting.

3. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, In the two-stage determination mechanism of step 3, the verification conditions for the first-stage hard constraint filtering include consistent field quantity, compatible field type families, consistent array dimension and length, consistent pointer attributes, compatible field read and write attributes, no mutual exclusion condition compilation conflict, and no external binary layout constraint conflict. The verification conditions for semantic constraint matching in the second stage include consistent port categories, consistent physical meanings or reaching the configured semantic matching threshold, field order represented by a common order, and annotation differences not changing the business meaning.

4. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, In step 4, the naming of common structure fields includes three strategies: using field names that represent the IP, using physical meaning specification names, and using user-configured field name mappings. The original IP header file supports three processing methods: retaining the original header file and deleting duplicate structure declarations before adding a common header file include, retaining the original structure type name as a typedef alias for the common structure type, and directly removing duplicate type declarations in the original header file and uniformly using the common structure type.

5. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, In step 5, the include relationship rewriting follows the principle of minimum necessity; the type reference rewriting scope covers the main control C file, main control header file, IP header file, and IP implementation file, and the rewritten objects include type declarations, function parameters, variable declarations, sizeof expressions, and type casting; the field access rewriting covers dot access, arrow access, array instance access, and simple pointer alias access.

6. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, The static signature of the instance relationship data in step 6 includes the merged structure type, instance declaration location, initialization method, calling function, and calling parameters; the semantic signature includes the port binding set, parameter binding set, state member set, external resource set, debug observation set, and timing isolation flag.

7. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, In step 7, an equivalent instance that meets the merging conditions must simultaneously satisfy all of the following conditions: the merged structure type is consistent, the port binding set and the parameter binding set are consistent, the state member set is empty, there is no independent cache, peripheral handle, random number seed, time accumulation and fault latch, no debugging observation requirements and timing isolation requirements, and there is no alias write conflict in the call reference.

8. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, In step 7, the representative instance is determined according to the order of appearance, naming stability, number of calls, or user configuration. The instance that appears for the first time in the main control program and has a stable name is selected. During the merging execution, the declaration and initialization statements of the representative instance are retained, the corresponding statements of the merged instance are commented out or deleted, and all call parameters of the merged instance are replaced with those of the representative instance.

9. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, The consistency review in step 9 includes: the correctness of public header file references, the residual status of semantic references to the original structure type, the residual status of access to the original field name members, the residual status of calls to the original instance name, the update status of IP port information, the consistency between function declarations and call parameters, and the integrity of references to each conditional compilation path.

10. The code structure optimization method for embedded software based on software IP synthesis according to claim 1, characterized in that, The output of step 10 includes common header files, rewritten project files, type and instance mapping tables, updated IP port information, merge logs, and skip logs. After the project is output, it is recommended to perform three levels of verification: preprocessing check, compilation check, and reference residue check.

Images