An implementation method for automatically generating register array code

Abstract

The present application relates to the technical field of code generation, and particularly relates to an implementation method for automatically generating register array code. Register information of a register is read; a register design digital twin is constructed, early risk assessment is performed on structured definition information, a risk report and an optimization strategy are output; a formal guarantee engine is run to verify design logic, verification results, counterexample information and a first credibility score are obtained; an intelligent optimization engine is run to output optimization suggestions, a second credibility score and a consistency identifier; based on the verification results and the optimization suggestions, final register hardware code, embedded assertions and an address mapping table are generated, and a total credibility score is generated based on the first credibility score, the second credibility score and the consistency identifier; and the digital twin and the intelligent optimization engine are iteratively updated according to verification data and performance data. The present application can realize automatic and high-credibility generation of register array code.

Description

Technical Field

[0001] This invention relates to the field of code generation technology, and in particular to a method for automatically generating register array code. Background Technology

[0002] Currently, register array code generation mainly relies on manual writing, semi-automatic tools based on Excel and scripts, or generic hardware description templates. These methods can only generate basic functional code, lacking formal verification of design logic, forward-looking prediction of performance and reliability, and multi-objective intelligent optimization of the design scheme. The accuracy and quality of the code are highly dependent on the engineer's experience and are difficult to adapt to the design iteration requirements of complex SoCs. Summary of the Invention

[0003] This invention addresses the shortcomings of existing technologies, such as the lack of formal verification of design logic, forward-looking prediction of performance and reliability, and multi-objective intelligent optimization of design schemes, by providing an automated method for generating register array code.

[0004] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0005] This invention provides a method for automatically generating register array code, comprising: reading the structured definition information, attribute specifications, and target process constraints of registers as register information; constructing a digital twin of register design based on the acquired register information, and performing an early risk assessment on the structured definition information, outputting a risk report and optimization strategy; deriving register hardware design logic based on the structured definition information and the digital twin, running a formal assurance engine to verify the design logic, and obtaining verification results, counterexample information, and a first credibility score; running an intelligent optimization engine to perform multi-objective optimization based on the risk report, optimization strategy, historical access patterns, and design constraints, and outputting optimization suggestions, a second credibility score, and a consistency identifier; generating the final register hardware code, embedded assertions, and address mapping table based on the verification results and optimization suggestions, and generating an overall credibility score by combining the first credibility score, the second credibility score, and the consistency identifier; and iteratively updating the digital twin and the intelligent optimization engine according to verification data and performance data.

[0006] Optionally, the structured definition information, attribute specifications, and target process constraints of the registers are read as register information, including: the register address, bit fields, operation type, default value, local signal direction, and comment information of the registers, forming structured definition information; the formal attribute specification tabs attached to the registers are read as attribute specifications, which are used to define the constraints that the register group must satisfy in a declarative language; and the target process node, operating frequency, and power budget of the registers are read as process constraints.

[0007] Optionally, constructing a register design digital twin based on the acquired register information includes: generating a high-level abstract functional model based on the structured definition information for early algorithm verification and hardware / software co-simulation; invoking a timing power consumption prediction algorithm based on the target process constraints to estimate the critical path delay and dynamic / static power consumption of the register array; building a testability analysis module based on register access patterns and structural insertion of testability design checkpoints, and generating testability analysis results, which at least include test coverage; and associating the functional model, timing power consumption prediction algorithm, and testability analysis module to construct a unified and traceable register design digital twin.

[0008] The process includes: conducting early risk assessments on structured definition information and outputting risk reports and optimization strategies; performing lightweight formal checks on the high-level abstract functional model to verify address conflict-free operation and correct reset behavior; using the timing and power consumption prediction algorithm to identify potential high fan-out signals and unbalanced paths, and proposing register grouping or buffer insertion suggestions; suggesting the insertion of test observation points based on the testability analysis results of the testability analysis module for production testing; and generating an early risk report and proposing structural adjustment strategies by combining the results of the lightweight formal checks, timing and power consumption predictions, and testability analysis.

[0009] Optionally, based on the structured definition information and the derivation of register hardware design logic using the digital twin, a formal assurance engine is run to verify the design logic, obtain verification results, counterexample information, and a first credibility score. This includes: deriving the register hardware design logic to be implemented based on the structured definition information; encoding the design logic, explicitly declared formal attributes, and implicit attributes automatically generated based on a general attribute rule base into an assertion language recognizable by the formal verification tool; using the formal assurance engine to call the formal verification tool to perform mathematical proof on the encoded assertion set, verifying whether the design logic satisfies all attributes; outputting the verification results, which include the proof status of each attribute; generating counterexample information containing specific violation scenarios for attributes that fail to be proven; and calculating and outputting a first credibility score reflecting the credibility of this formal verification based on the completeness of the attribute proof, the complexity of the counterexamples, and the consistency of the early risk assessment of the digital twin during the verification process. The consistency of the early risk assessment of the digital twin and the first credibility score are directly proportional to the completeness of the attribute proof and inversely proportional to the complexity of the counterexamples.

[0010] Optionally, the intelligent optimization engine is run, including: acquiring historical register access logs for static correlation analysis, extracting access frequency, module correlation, and signal dependency as static correlation features, i.e., the historical access pattern; loading a pre-trained graph neural network optimization model, using the static correlation features and user-defined physical timing constraints as input; running the optimization model to generate optimization suggestions for register physical grouping, address space layout, and interface configuration parameters, while generating the prediction confidence of the optimization model and estimating access latency and power consumption gains; calculating a second confidence score based on the prediction confidence of the optimization model; and comparing the optimization suggestions with the design constraints to generate a consistency identifier characterizing their degree of compliance.

[0011] Optionally, based on the verification results and optimization suggestions, the final register hardware code, embedded assertions, and address mapping table are generated. An overall credibility score is then generated by combining the first credibility score, the second credibility score, and the consistency flag. This includes: adjusting the register address offset and grouping structure according to the optimization suggestions; generating core Verilog code containing register instantiation, read / write logic, and signal connections as the final register hardware code; embedding key formal attributes into the core Verilog code as comments or synthesizable assertion statements; generating an address mapping table reflecting the final address layout, along with corresponding C header files and software driver frameworks; and calculating the overall credibility score by weighted average of the first credibility score, the second credibility score, and the consistency flag, and embedding the overall credibility score and the consistency flag into the generated code comments or a separate credibility report.

[0012] Optionally, based on verification and performance data, the digital twin and intelligent optimization engine are iteratively updated as follows: Formal verification counterexamples, simulation test results, and post-silicon performance data are collected; the timing power prediction algorithm parameters in the digital twin are calibrated using the collected real timing power consumption data; the actual optimal address mapping scheme is used as a new sample to incrementally train the machine learning model in the intelligent optimization engine; newly discovered design error patterns are summarized as new implicit attributes, and the general attribute rule base and the dynamically accumulated optimization strategy base at runtime are updated; when the overall credibility score is lower than a preset threshold, the reinforcement training of the machine learning model in the digital twin and intelligent optimization engine is triggered; and the weights of the optimization strategies are adjusted based on the consistency identifier.

[0013] Optionally, it also includes: selecting a scheme with an overall credibility score higher than a threshold from multiple optimization suggestions output by the intelligent optimization engine as a candidate scheme; visually displaying the candidate schemes through a human-machine collaborative decision-making interface, with each scheme associated with its address mapping, verification status, optimization benefits, overall credibility score, and consistency identifier; and outputting a scheme package containing the final register hardware code, formal verification environment, digital twin model file, and complete credibility report after receiving the user's selection instruction.

[0014] This also includes providing a solution comparison function in the human-machine collaborative decision-making interface, supporting users to perform multi-dimensional filtering and sorting based on multi-dimensional data, and automatically generating traceable decision records and compliance documents after determining the final solution, wherein the decision records contain a detailed analysis of the overall credibility score and consistency identifier.

[0015] By implementing this invention, it is possible to read the structured definition information, attribute specifications, and target process constraints of registers as register information, ensuring that the input data is comprehensive and structured, providing a unified and accurate data source for the construction of digital twins, logical deduction, and optimization verification, and avoiding deviations in subsequent processes due to missing or non-standard data.

[0016] By implementing this invention, it is possible to construct a digital twin of register design based on the acquired register information, conduct early risk assessment of structured definition information, output risk reports and optimization strategies, identify potential problems such as address conflicts and high fan-out signals in advance, output targeted optimization strategies, avoid large-scale rework in later design iterations, shorten the development cycle and reduce costs.

[0017] By implementing this invention, it is possible to run a formal assurance engine to verify the design logic based on the structured definition information and the hardware design logic of the digital twin derivation register, obtain verification results, counterexample information and a first credibility score, ensure the correctness of the design logic in a mathematical way, clarify the attribute satisfaction state, accurately locate problems with counterexample information, and intuitively reflect the degree of verification credibility with the first credibility score, thereby improving the reliability of the design logic.

[0018] By implementing this invention, an intelligent optimization engine can be run to perform multi-objective optimization based on risk reports, optimization strategies, historical access patterns, and design constraints. It outputs optimization suggestions, a second credibility score, and a consistency identifier, achieving multi-objective optimization such as access latency and power consumption. The optimization suggestions are tailored to actual application scenarios, and the second credibility score and consistency identifier ensure the feasibility and compliance of the optimization scheme, thereby improving design performance.

[0019] By implementing this invention, it is possible to generate final register hardware code, embedded assertions, and address mapping tables based on verification results and optimization suggestions. Furthermore, an overall credibility score is generated by combining the first credibility score, the second credibility score, and the consistency identifier. This directly outputs a complete and implementable design result. Embedded assertions enhance code verifiability, and the overall credibility score provides a quantitative reference for design quality, simplifying subsequent application processes.

[0020] By implementing this invention, the digital twin and intelligent optimization engine can be iteratively updated based on verification and performance data, enabling the continuous evolution of core tools, improving the accuracy of risk prediction, optimization effect, and verification efficiency of subsequent designs, and adapting to the iterative design needs of complex SoCs.

[0021] In summary, by implementing this invention, the generation of register array code can be automated and highly reliable, while ensuring the correctness of the design, superior performance, and scientific decision-making, thus significantly improving the efficiency, quality, and reliability of chip design. Attached Figure Description

[0022] Figure 1 A flowchart illustrating an implementation method for automatically generating register array code provided by the present invention;

[0023] Figure 2 This is a flowchart illustrating the process of running the intelligent optimization engine in the method for automatically generating register array code provided by the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the stated features. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0026] In the description of this invention, the term "for example" is used to mean "used as an example, illustration, or description." Any embodiment described as "for example" in this invention is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use the invention. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that the invention can be made without using these specific details. In other instances, well-known structures and processes will not be described in detail to avoid obscuring the description of the invention with unnecessary detail. Therefore, the invention is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed herein.

[0027] Example 1, as Figure 1 As shown, this embodiment of the invention provides a method for automatically generating register array code, including:

[0028] S100: Read the structured definition information, attribute specifications, and target process constraints of the register as register information;

[0029] S200: Constructs a digital twin of register design based on the acquired register information, performs early risk assessment on structured definition information, and outputs risk reports and optimization strategies;

[0030] S300: Based on the structured definition information and the hardware design logic of the digital twin derivation register, run the formal assurance engine to verify the design logic and obtain the verification results, counterexample information and the first confidence score;

[0031] S400: Runs the intelligent optimization engine to perform multi-objective optimization based on risk reports, optimization strategies, historical access patterns and design constraints, and outputs optimization suggestions, second credibility scores and consistency indicators;

[0032] S500: Based on the verification results and optimization suggestions, the final register hardware code, embedded assertions and address mapping table are generated, and the overall credibility score is generated by combining the first credibility score, the second credibility score and the consistency identifier.

[0033] S600: Iteratively update the digital twin and intelligent optimization engine based on verification data and performance data.

[0034] In step S100 of this embodiment, the structured definition information, attribute specifications, and target process constraints of the register are read as register information, including:

[0035] Read the register address, bit fields, operation type, default value, local signal direction and comment information of the register to form structured definition information;

[0036] Read the formal attribute specification tab attached to the register, which serves as the attribute specification and is used to define the constraints that the register group must satisfy in a declarative language.

[0037] The target process node, operating frequency, and power consumption budget for reading registers are used as process constraints.

[0038] In this embodiment of the application, the purpose of step S100 is to provide complete and accurate basic data support for the subsequent construction of the digital twin of the register design, derivation of hardware design logic, formal verification and intelligent optimization, so as to ensure that the generated register array code meets the design requirements, attribute constraints and process limitations.

[0039] To achieve the above objectives, it is first necessary to read the register address, bit fields, operation type, default value, local signal direction, and comment information of the register to form structured definition information.

[0040] This involves using automated programs such as Perl scripts to parse table files, extract information according to preset field rules, and perform format validation, such as address uniqueness verification and numerical format correctness verification. If a validation error occurs, a log is generated to record the error information. The table file is a standardized carrier for storing the structured definition information and attribute specifications of registers in this application. Its function is to organize the scattered information such as register addresses, bit fields, and operation types into an intuitive and easily editable table in a unified format, which is convenient for engineers to fill in configurations and allows automated tools to accurately parse and extract information.

[0041] The register address is a unique identifier for the register and must be filled in hexadecimal format. Different register addresses cannot be repeated to avoid address conflicts. For example, 16'H0001 corresponds to the first register, 16'H0002 corresponds to the second register, and subsequent registers are assigned addresses sequentially according to their functional modules, such as 16'H0003, 16'H0004, etc.

[0042] Bit fields are used to define the bit range of each functional field within the register, supporting flexible configuration from 0 to 32 bits. Bit ranges without assigned functions are marked as reserved. For example, [31:1] indicates that bits 1 to 31 of the register are one functional field, [2:0] indicates that bits 0 to 2 are another functional field, and [31:21] marked as reserved indicates that the bits in this range are not currently in use.

[0043] The operation type is used to specify the read and write permissions of a field and determine the access logic of the register. For example, RW indicates that the field is readable and writable, and is used for functions that require dynamic configuration, such as bits [2:0] of signal B in control module A; R indicates read-only, and is used to store module status, such as bits [10:0] of the ESM status of module A; W1C indicates that the field value is cleared when written to 1, and is often used for interrupt flags; RC indicates that the field is automatically cleared after reading, and is suitable for temporary state storage; unused fields are marked as reserved to avoid accidental operations.

[0044] The default value represents the initial state after register reset, filled in hexadecimal format, and directly affects the initial configuration after chip power-on. For example, 1'h0 means that the field is 0 after reset, 31'h2222_3333 means that the initial value of the 31-bit wide field is hexadecimal 2222_3333, and 11'h456 means that the initial value of the 11-bit wide field is hexadecimal 456.

[0045] The local signal direction is used to determine whether a signal is from an input chip or an output chip, supporting only two types: input and output, and determining the subsequent port connection logic. For example, the output type signal addr1_bit0 is used to control signal B of external module A, and the input type signal addr2_bit10_0 is used to receive the ESM status of module A.

[0046] Comments are used to describe the function of a field in detail, facilitating subsequent code maintenance and debugging. They must accurately correspond to the actual purpose of the field. For example, "the signal is used to control signal F of model D" clearly indicates that this field is used to control signal F of module D, and "the signal is the counter from module D" means that this field stores the counter value of module D.

[0047] Next, the formal attribute specification tab attached to the register needs to be read as an attribute specification, which is used to define the constraints that the register group must satisfy in a declarative language.

[0048] This involves using an automated program to read the formal attribute specification tabs attached to the table file. These tabs are written in a declarative language, requiring no description of the implementation process, only specifying the constraint results. All rules directly apply to the register set, serving as the core basis for subsequent formal verification.

[0049] In this context, the declarative language directly defines the underlying constraints that the register set must satisfy. For example, the address conflict-free constraint clearly states that all register addresses are unique; the correct reset behavior constraint clearly states that all registers must conform to the default value configuration after reset; and the access permission matching constraint clearly states that read-only fields cannot be written to, and read-write fields can be read and written normally. These constraints do not require additional logical derivation and are directly used as verification standards.

[0050] Then, the target process node, operating frequency, and power budget of the registers need to be read as process constraints.

[0051] This involves extracting process parameters related to the register array from design requirements documents or process specifications. These parameters are determined by chip manufacturing processes and system design requirements, and serve as boundary conditions for subsequent timing and power consumption estimations and physical implementation. The automated program standardizes and stores these parameters for use by the digital twin and intelligent optimization engine.

[0052] Among them, the target process node is the process precision of chip manufacturing, which directly affects the area, speed and power consumption of registers. For example, the 28nm process node is suitable for mid-to-high-end chips, while the 14nm process node is more inclined to high-performance and low-power scenarios. The smaller the process node, the higher the integration of registers, but the greater the design difficulty.

[0053] The operating frequency is the upper limit of the operating speed of the register array. For example, 1GHz means that the register needs to support 1 billion access operations per second, while 500MHz means 500 million operations per second. The higher the operating frequency, the more stringent the timing performance requirements of the register, and access errors caused by signal delays must be avoided.

[0054] The power budget is the maximum power consumption allowed when the register array is running. For example, 100mW is suitable for low-power IoT chips, and 200mW is suitable for high-performance computing chips. The power budget directly limits the circuit design of the register and needs to balance performance and power consumption.

[0055] In step S200 of this application embodiment, constructing a register design digital twin based on the acquired register information includes:

[0056] A high-level abstract functional model is generated based on the structured definition information, which is used for early algorithm verification and software-hardware co-simulation.

[0057] Based on the target process constraints, a timing power consumption pre-estimation method is invoked to estimate the critical path delay and dynamic and static power consumption of the register array.

[0058] Based on register access patterns and structure insertion testability design checkpoints, a testability analysis module is built and testability analysis results are generated, including at least test coverage.

[0059] By associating the functional model, timing power consumption prediction method, and testability analysis module, a unified and traceable digital twin of register design is constructed.

[0060] In this embodiment of the application, the purpose of step S200 is to construct a digital twin that is completely mapped to the physical register design, to simulate the design’s functionality, timing, power consumption and testability performance in advance, to provide a simulation basis for early risk assessment, and to provide a traceable unified analysis model for subsequent formal verification and intelligent optimization, so as to avoid rework caused by functional or performance failures in the later stages.

[0061] To achieve the above steps, a high-level abstract functional model needs to be generated based on the structured definition information for early algorithm verification and hardware-software co-simulation.

[0062] This involves using automated tools to extract core parameters such as register address, bit fields, operation type, default value, and local signal direction from structured definition information. By stripping away specific circuit implementation details, it focuses solely on the register's functional logic and external interaction behavior, constructing a high-level abstract functional model. This model does not involve gate-level circuit design; it focuses on simulating register read / write responses, reset behavior, and signal input / output logic. It supports rapid algorithm verification and hardware / software co-simulation in the early stages of design, such as verifying whether the software configuration algorithm can correctly control the register and whether the interaction between the software driver and the register hardware is smooth, without waiting for the physical circuit design to be completed.

[0063] For example, based on parameters such as address 16'H0001, bit field [31:1], operation type RW, default value 31'h2222_3333, and local signal direction output in the structured definition information, the high-level abstract function model will accurately simulate the core function of this register. When the software writes hexadecimal 3333_4444 to address 16'H0001, the high-level abstract function model will update the stored value of bit field [31:1] to 3333_4444; when the software reads this address, the high-level abstract function model will return the currently stored value; when the system is reset, the high-level abstract function model will automatically restore the register value to the default value 31'h2222_3333. At the same time, according to the local signal direction output, the high-level abstract function model will simulate the logic of the register signal output to external modules. Through this simulation, it is possible to verify in advance whether the software configuration algorithm can correctly control the register and whether the data interaction between the software and hardware meets expectations. For example, the register with address 16'H0002, bit field [10:0], operation type R, and local signal direction input, will be simulated by the high-level abstract functional model to only receive the status data input by the external module. The software can only read the data but cannot write it, which helps to verify the effectiveness of the algorithm for the software to read the status data.

[0064] Next, based on the target process constraints, a timing power consumption prediction method needs to be invoked to estimate the critical path delay and dynamic and static power consumption of the register array.

[0065] This involves using the target process node, operating frequency, and power budget as core input conditions within the target process constraints, and then invoking a pre-defined timing power consumption prediction algorithm. This algorithm combines the circuit characteristics of different process nodes, such as transistor switching speed and leakage current, as well as timing requirements corresponding to the operating frequency and the structure of the register array, to quantify the critical path delay and dynamic / static power consumption of the register array, generating specific numerical results. This provides data for subsequent early risk assessment and intelligent optimization. Specifically, the critical path delay is the longest delay time for signal transmission between registers; dynamic power consumption is the power consumption caused by transistor switching during register operation; and static power consumption is the power consumption caused by leakage current when the register is in standby mode.

[0066] Among these factors, the target process node directly determines the basic performance of the circuit. For example, the transistor switching speed of the 14nm process node is faster and the leakage current is smaller than that of the 28nm process node, making it a core basic parameter for timing and power consumption estimation. The operating frequency defines the upper limit of the operating speed of the register array. For example, 1GHz requires the register array to complete 1 billion access operations per second, and timing estimation must ensure that the signal transmission delay does not exceed 1ns (1 / 1GHz). The power budget is the maximum allowable power consumption limit of the register array. For example, 100mW clearly indicates that the design must balance performance within this power consumption range.

[0067] Assuming a target process node of 14nm, an operating frequency of 1GHz, and a power budget of 100mW, with a register array containing 100 32-bit registers, the algorithm, considering the transistor characteristics of the 14nm process, calculates a critical path delay of 1.2ns, dynamic power consumption of 85mW, and static power consumption of 8mW, for a total power consumption of 93mW, which is within the 100mW budget. This provides clear timing and power consumption data for subsequent risk assessment. If the target process node is 28nm, the operating frequency is 500MHz, and the power budget is 150mW, the algorithm might estimate a critical path delay of 2.5ns, dynamic power consumption of 90mW, static power consumption of 15mW, and a total power consumption of 105mW, also within the budget.

[0068] Then, testability design checkpoints need to be inserted based on register access patterns and structures, a testability analysis module needs to be built, and testability analysis results need to be generated, which include at least test coverage.

[0069] Specifically, the process begins by analyzing the register access patterns, including the frequency of read and write operations on each register by the software. For example, some control registers are frequently read and written, while some status registers are only read periodically. The access order is also analyzed, such as configuring register A before accessing register B. Furthermore, considering the register's structural characteristics, such as bit width, connectivity, and module affiliation, testability design checkpoints are inserted into critical signal paths, including register input / output ports and important control signal nodes. Based on these checkpoints, a testability analysis module is built. This module simulates the production testing process, capturing the register's operating status and signal transmission through the checkpoints. It determines whether the test signals effectively cover all register functions, ultimately generating testability analysis results. The core metric is test coverage, which is the proportion of covered functions out of the total functions. It may also include the location and reasons for uncovered functions, providing direction for subsequent test optimization.

[0070] For example, the register with address 16'H0003, operation type RW, bit field [15:0], and local signal direction output has a software high-frequency read / write mode and is used for signal B of real-time control module D. Structurally, it is directly connected to the control port of external module D. The testability analysis module inserts checkpoints at the output of this register and on the read / write control signal path. During simulation testing, different values ​​are written to this register, and the checkpoints are used to capture whether the output signal is consistent with the written value. At the same time, it verifies whether the default value 16'ha4a4 is restored after reset. The final test coverage is 98%, indicating that most of the functions of this register have been tested and covered. The remaining 2% uncovered part is a specific abnormal write scenario, such as a write exceeding the bit field range, which requires additional test stimuli. For example, the register with address 16'H0004, bit field [20:13], operation type RW, and local signal direction output has a periodic read / write access mode. The control module D's signal F is used. The analysis module will insert checkpoints in its address decoding path and data output path. After simulation testing, a test coverage of 92% is generated. The uncovered part is a low-probability read / write conflict scenario, and the test plan needs to be optimized to supplement the coverage.

[0071] Finally, the functional model, timing power consumption prediction method, and testability analysis module are linked together to construct a unified and traceable digital twin of register design.

[0072] This involves deeply linking the high-level abstract functional model, timing and power consumption prediction algorithms, and the testability analysis module through data interfaces and linkage mechanisms, forming a unified and traceable digital twin of register design. Any logical change to the high-level abstract functional model (such as modifying register bit fields or operation types) will automatically trigger the timing and power consumption prediction algorithm to recalculate relevant metrics, while the testability analysis module will reassess test coverage. If the timing and power consumption prediction results show that the critical path latency exceeds the standard, it will be linked back to the corresponding register connection relationships in the functional model to help locate the problem. Uncovered functional points in the testability analysis results can also be linked to the specific logic and timing and power consumption data of the functional model, providing a comprehensive basis for optimization. The entire twin achieves unified management and traceability of functional, performance, and testability data, and the impact of each design decision can be reflected in the data across various dimensions.

[0073] For example, if the register bit field at address 16'H0001 in the high-level abstract functional model is changed from [31:1] to [20:1] due to functional requirements adjustments, the digital twin will automatically link the timing and power consumption prediction algorithm and recalculate the critical path delay. Due to the reduced bit width and shorter signal transmission path, the critical path delay may decrease from 1.2ns to 1.0ns, meeting the timing requirements of 1GHz, and the dynamic power consumption will also decrease from 85mW to 80mW. At the same time, the testability analysis module will re-examine the test coverage of this register. Due to the bit field adjustment, the original test stimulus needs to be adapted to the new bit field range, and the test coverage may temporarily decrease from 98% to 90%. The system will automatically mark the uncovered new bit field range to assist in the optimization of the test plan. For example, if the timing power consumption prediction algorithm finds that the static power consumption of a certain register is too high, the traceability function of the digital twin can be used to link the process parameter configuration of the register and the connection method in the functional model. It can be found that the reason is that the transistor type used does not match the process node. Then, the relevant parameters are adjusted to achieve power consumption optimization. The optimization effect will be synchronously fed back to the functional model and the testability analysis module to ensure the consistency of data in all dimensions.

[0074] In step S200 of this embodiment, an early risk assessment is performed on the structured definition information, and a risk report and optimization strategy are output, including:

[0075] Lightweight formal checks are performed on the high-level abstract functional model to verify that there are no address conflicts and that the reset behavior is correct.

[0076] The timing power prediction method is used to identify potential high fan-out signals and unbalanced paths, and to propose register grouping or buffer insertion suggestions.

[0077] Based on the testability analysis results from the testability analysis module, it is recommended to insert test observation points for production testing;

[0078] Based on the results of the lightweight formal inspection, timing and power consumption prediction, and testability analysis, an early risk report is generated, and structural adjustment strategies are proposed.

[0079] In this embodiment of the application, the purpose of step S200 is to identify hidden functional, timing, and testability risks in the structured definition information in the early stages of design, avoid rework during the later physical implementation through targeted optimization strategies, reduce development costs and cycles, and provide accurate risk guidance for subsequent formal verification and intelligent optimization.

[0080] Specifically, to achieve the above objectives, it is first necessary to run a lightweight formal check on the high-level abstract functional model to verify that there are no address conflicts and that the reset behavior is correct.

[0081] This approach leverages a high-level abstract functional model and deploys lightweight formal inspection tools to focus on the core, fundamental logic of registers—address allocation and reset behavior. It eliminates the need to traverse all complex scenarios, enabling efficient and rapid verification of critical logic. The lightweight formal inspection tool automatically extracts the address information of all registers in the model and performs uniqueness checks. Simultaneously, it simulates the system reset process to verify whether the reset value of each register matches the default value in the structured definition information. Any anomalies are immediately marked as risk points, and their specific locations and causes are recorded.

[0082] For example, a lightweight formal inspection tool traverses all register addresses in the high-level abstract functional model and finds that address 16'H0002 is assigned to both the status register (bit field [10:0]) and another newly added control register, indicating an address conflict risk. The conflicting address 16'H0002 and the information of the two involved registers are clearly recorded. During reset behavior verification, it is found that the default value of register 16'H0001 is defined as 31'h2222_3333, but the model returns 31'h1111_2222 after reset, which is inconsistent with the default value. This is identified as a reset behavior error risk, and the address of this register, its defined default value, and the actual reset value are recorded. This type of inspection does not require complex calculations and can quickly identify fundamental errors affecting the design, preventing read / write errors caused by address conflicts or abnormal initial states of the chip after power-on due to reset errors.

[0083] Next, the timing power estimation method needs to be used to identify potential high fan-out signals and unbalanced paths, and to propose register grouping or buffer insertion suggestions.

[0084] This involves invoking timing and power consumption prediction algorithms within the digital twin, combining target process constraints and the structural characteristics of the register array, to analyze the load and delay distribution of signal transmission paths. High fan-out signals refer to a single output signal simultaneously driving multiple input ports, which can easily lead to signal attenuation and increased delay; unbalanced paths refer to parallel transmission signal paths with excessively large delay differences, which can easily lead to data synchronization errors. The algorithm identifies these two types of potential performance risks by quantifying the number of drive loads and the delay time of each path. Then, combined with design constraints such as operating frequency and power budget, it provides optimization suggestions that balance performance and cost.

[0085] For example, with a target process node of 14nm and an operating frequency of 1GHz, algorithm analysis found that a certain control signal simultaneously drives the enable pins of 10 registers, driving a load far exceeding the reasonable threshold under the 14nm process. Typically, a single signal drives no more than 6 loads, and is therefore identified as a high fan-out signal. The path delay of this signal is estimated to be 1.5ns, exceeding the 1ns timing requirement corresponding to 1GHz. At the same time, two parallel data transmission paths were found, one with a delay of 1ns and the other with a delay of 2.8ns, with a delay difference of 1.8ns, which is identified as an unbalanced path, which is prone to data sampling errors.

[0086] For high fan-out signals, the timing and power consumption prediction algorithm proposes dividing the 10 driven registers into two groups of 5 registers each, based on their functional modules. A buffer is inserted between the original control signal and one of the register groups to distribute the drive load, which is expected to reduce the latency to 0.9ns. For unbalanced paths, the algorithm proposes adjusting the register layout along the path and optimizing the routing length to shorten the long path latency to 1.2ns, keeping the latency difference between the two paths within 0.2ns to meet timing synchronization requirements. If the target process node is 28nm and the operating frequency is 500MHz, and the algorithm identifies a signal driving 8 loads with a latency of 2.2ns, exceeding the 2ns timing requirement corresponding to 500MHz, it is recommended to insert a buffer or optimize the register grouping to control the latency within 1.8ns.

[0087] Then, based on the testability analysis results from the testability analysis module, test observation points are recommended for production testing.

[0088] This involves reading the test coverage and uncovered function point locations output by the testability analysis module, setting a preset test coverage threshold (e.g., 90%), and indicating that some function points cannot be verified in production testing if the actual coverage is lower than this threshold, posing a risk of hidden faults after delivery. For uncovered function points, the signal path characteristics are analyzed, and based on the testability analysis results output by the testability analysis module, test observation points are recommended to be inserted at key nodes. These observation points can capture signal states during testing, facilitating verification of whether the function point is working properly. Simultaneously, corresponding test cases are added to ensure that production testing fully covers core functions.

[0089] Finally, based on the results of the lightweight formal inspection, timing power consumption prediction, and testability analysis, an early risk report is generated, and structural adjustment strategies are proposed.

[0090] This involves integrating the results of the first three steps—lightweight formal checks, timing and power consumption predictions, and testability analysis—and categorizing them by risk type (functional risk, performance risk, testability risk), risk location (specific register address, signal path), and impact level (fatal risk, severe risk, general risk) to form a structured early risk report. Functional risks include address conflicts and incorrect reset behavior; performance risks include high fan-out signals and unbalanced paths; and testability risks include insufficient test coverage and specific uncovered functional points. Based on target process constraints, design requirements, and project cost budgets, targeted structural adjustment strategies are proposed for each risk point to ensure the strategies are implementable, effectively mitigate risks, and do not introduce new problems.

[0091] For example, the early risk reports summarized showed two functional risks, such as a conflict at address 16'H0002 and a reset error at address 16'H0001; three performance risks, such as two high fan-out signals and one unbalanced path; and four testability risks, such as test coverage of four registers being less than 90%. The corresponding structural adjustment strategies included:

[0092] Functional risk adjustment: One of the conflicting registers at address 16'H0002 is reassigned to address 16'H0005, and the address mapping table is updated; the reset logic at address 16'H0001 is corrected to ensure that the value after reset is consistent with the default value 31'h2222_3333.

[0093] Performance risk adjustment: Group the registers corresponding to the two high fan-out signals by module and insert buffers; adjust the register layout of unbalanced paths, optimize wiring length, and balance path delay.

[0094] Testability risk adjustment: Insert test observation points at key nodes of 4 low-coverage registers, and supplement corresponding abnormal scenarios and special timing test cases, with the goal of increasing the test coverage of all registers to over 95%.

[0095] The above strategy covers all risk points, and the adjustment method only involves basic structural optimizations such as register grouping, address allocation, and observation point insertion, without changing the core functional logic. It can be quickly implemented and effectively reduces the risk of later design.

[0096] In step S300 of this embodiment, based on the structured definition information and the hardware design logic of the digital twin derivation register, the formal assurance engine verifies the design logic to obtain the verification results, counterexample information, and a first confidence score.

[0097] Based on the structured definition information, the hardware design logic of the register to be implemented is derived.

[0098] The design logic, explicitly declared formal properties, and implicit properties automatically generated based on a general property rule base are jointly encoded into an assertion language that can be recognized by formal verification tools.

[0099] The formal assurance engine calls the formal verification tool to perform mathematical proof on the encoded set of assertions, verifying whether the design logic satisfies all properties;

[0100] Output the verification results, which include the proof status of each attribute; generate counterexample information containing specific violation scenarios for attributes whose proofs failed.

[0101] Based on the completeness of the attribute proof, the complexity of the counterexamples, and the consistency of the early risk assessment of the digital twin during the verification process, a first credibility score reflecting the credibility of this formal verification is calculated and output. The consistency of the early risk assessment of the digital twin and the first credibility score are directly proportional to the completeness of the attribute proof and inversely proportional to the complexity of the counterexamples.

[0102] In this embodiment of the application, the purpose of the above steps is to derive precise hardware design logic through digital twins and structured definition information, and then complete the mathematical logical correctness proof through formal verification. This not only outputs clear verification results and counterexamples, but also quantifies the credibility of the verification through the first credibility score, providing a rigorous logical basis for subsequent optimization and code generation, and fundamentally ensuring that the register array function is defect-free.

[0103] To achieve the above objectives, it is first necessary to derive the register hardware design logic to be implemented based on the structured definition information.

[0104] This involves using structured definition information as the basis for functionality, combined with high-level abstract functional models and timing and power consumption data from the digital twin, to transform abstract functions into concrete and implementable hardware logic. This includes register address decoding logic, read / write control logic, bit field operation logic, reset logic, and signal connection logic, ensuring that the logic matches both the functional definition and the process constraints.

[0105] For example, based on address 16'H0001, bit field [31:1], operation type RW, default value 31'h2222_3333, and local signal direction output, the address decoding logic is derived—the register is selected when the bus address is 16'H0001; the read / write control logic is derived—it supports writing data to the bus to update the [31:1] bit field, and outputs the current bit field value when reading; the reset logic is derived—the [31:1] bit field is set to 31'h2222_3333 when the system is reset; and the signal connection logic is derived—the bit field output is associated with the local signal output port. Combined with the timing data of the digital twin, the signal path is optimized in the logic to avoid exceeding delay limits.

[0106] Then, the design logic, explicitly declared formal properties, and implicit properties automatically generated based on a general property rule base are jointly encoded into an assertion language that can be recognized by the formal verification tool.

[0107] This involves collecting and encoding three types of core information: first, the derived register hardware design logic; second, the explicitly declared formal attributes from the attribute specification tab; and third, implicit attributes automatically generated by a general attribute rule base, such as read-write consistency and address uniqueness constraints. These three types of information are then transformed into assertion languages ​​supported by formal verification tools such as Cadence and JasperGold, such as SVA.

[0108] Next, the formal assurance engine calls the formal verification tool to perform mathematical proof on the encoded set of assertions, verifying whether the design logic satisfies all properties.

[0109] Once the formal assurance engine starts, it calls the preset formal verification tools, loads the encoded set of assertions and hardware design logic, and traverses all possible logical states through mathematical reasoning to verify whether the design logic satisfies the properties corresponding to each assertion. This ensures the completeness of the verification without relying on test case coverage.

[0110] For example, regarding the assertion that "the bit field of register 16'H0001[31:1] is 31'h2222_3333 after reset", the tool verifies through mathematical derivation whether the value of this bit field meets the requirements in all reset scenarios; regarding the assertion that "writing to read-only register 16'H0002 is invalid", it verifies whether the value of this register remains unchanged after all write operations are triggered, ensuring from a mathematical perspective that there are no exceptions in the logic.

[0111] The verification results are then output, including the proof status of each attribute; for attributes that fail to be proven, counterexample information containing specific violation scenarios is generated.

[0112] After verification, the tool outputs the proof status of each attribute, including three categories: proof passed, proof failed, and proof cannot be proven. For attributes that fail to prove, the tool generates specific violation scenarios, including triggering conditions, signal timing, state changes, and other counterexample information, to facilitate the identification of logical defects.

[0113] For example, if an assertion that "data is written to register 16'H0003[15:0] and then read immediately, and the value is consistent with the written value" fails, the counterexample information will show that the trigger condition is that data 16'ha5a5 is written to the bus, and the data is read immediately after the write clock edge. The read result is 16'h0000. At the same time, the text description corresponding to the signal timing diagram is given: when the write enable signal is valid, the data bus is 16'ha5a5, but the latching logic inside the register is delayed by 1 clock cycle, which causes the immediate read to not obtain the new value, thus clarifying the location of the logic defect.

[0114] Finally, based on the completeness of the attribute proof, the complexity of the counterexamples, and the consistency of the early risk assessment of the digital twin during the verification process, a first credibility score reflecting the credibility of this formal verification is calculated and output. The consistency of the early risk assessment of the digital twin and the first credibility score are directly proportional to the completeness of the attribute proof and inversely proportional to the complexity of the counterexamples.

[0115] The score is calculated based on three core indicators: the completeness of the attribute proof (the proportion of passed attributes to the total number of attributes); the complexity of the counterexamples (specifically, simple scenarios are considered low complexity, while complex temporal combinations are considered high complexity); and the consistency of the early risk assessment of the digital twin (the proportion of overlap between the risks discovered during verification and those assessed in the early risk assessment). Of these three indicators, consistency and completeness are directly proportional to the score, while the complexity of the counterexamples is inversely proportional to the score. The final score is calculated using a weighted formula, with a maximum score of 100 points.

[0116] For example, out of a total of 100 attributes, 95 were passed, resulting in a 95% completeness of the attribute proof; three risks were identified during verification, two of which were consistent with the early risk assessment of the digital twin, with a consistency rate of 66.7%; the counterexamples corresponding to the five attributes that failed to prove were all simple scenarios, i.e., single triggering conditions, indicating low complexity of the counterexamples.

[0117] Assuming the weighted formula is: First Credibility Score = Completeness × 0.6 + Consistency × 0.3 + (1 - Counterexample Complexity Coefficient) × 0.1, with the counterexample complexity coefficient set at a minimum of 0.2, the calculated score is 0.95. 0.6 + 0.667 0.3 + (1 - 0.2) 0.1 100 = (0.57 + 0.2001 + 0.08) 100 = 85.01 points, reflecting a high level of credibility in this formal verification. If the counterexample is a complex time series combination with a counterexample complexity coefficient of 0.8, then the first credibility score = 57 + 20.01 + 0.2 × 10 ≈ 79.01 points.

[0118] S400: Runs the intelligent optimization engine to perform multi-objective optimization based on risk reports, optimization strategies, historical access patterns and design constraints, and outputs optimization suggestions, second credibility scores and consistency indicators;

[0119] like Figure 2 As shown, in step S400 of this embodiment, running the intelligent optimization engine includes:

[0120] Historical register access logs are obtained and static correlation analysis is performed to extract access frequency, module correlation degree and signal dependency as static correlation features, i.e. the historical access pattern.

[0121] Load a pre-trained graph neural network optimization model, taking the static correlation features and user-defined physical time-series constraints as input;

[0122] The optimization model is run to generate optimization suggestions for register physical grouping, address space layout and interface configuration parameters. At the same time, the prediction confidence of the optimization model is generated and the access latency and power consumption gains are estimated.

[0123] The second confidence score is calculated based on the prediction confidence of the optimized model;

[0124] The optimization suggestions are compared with the design constraints to generate a consistency identifier that characterizes the degree of compliance.

[0125] In this embodiment of the application, the purpose of step S400 is to rely on the intelligent optimization engine to integrate multi-dimensional input data to achieve multi-objective optimization of register design. Under the premise of meeting design constraints, it optimizes physical grouping, address layout and interface configuration. At the same time, it quantifies the reliability of the optimization scheme through the second credibility score and uses consistency identifier to clarify the fit between the scheme and the constraints, providing a better and more reliable design basis for subsequent code generation, and balancing core requirements such as performance, power consumption and maintainability.

[0126] In this embodiment of the application, to achieve the above steps, firstly, it is necessary to obtain historical register access logs for static correlation analysis, and extract access frequency, module correlation degree and signal dependency relationship as static correlation features, namely the historical access pattern.

[0127] This involves collecting register access logs from similar chips or projects in the past, mining data patterns through static correlation analysis algorithms, and extracting three core static correlation features: access frequency, module correlation, and signal dependency, to form historical access patterns that reflect the actual usage characteristics of registers.

[0128] For example, regarding access frequency, log analysis revealed that the register at address 16'H0001 was accessed 500 times per second, while the register at address 16'H0002 was accessed 10 times per second, showing a significant difference in access frequency between the two.

[0129] Regarding module correlation, log analysis revealed that registers 16'H0001 and 16'H0003 are frequently accessed simultaneously by module A, with a correlation of 80%, while the correlation with 16'H0002 is only 10%.

[0130] Regarding signal dependencies, log analysis revealed that write operations to register 16'H0003 depend on the output signal of 16'H0001 being at a high level, indicating a clear signal dependency.

[0131] Next, a pre-trained graph neural network optimization model is loaded, taking the static correlation features and the user-defined physical time constraints as input.

[0132] The intelligent optimization engine incorporates a pre-trained graph neural network optimization model. This model, trained on a large amount of historical optimization data, accurately captures the mapping relationship between static correlation features and optimization objectives. Specifically, it constructs a training dataset by collecting a large amount of historical data related to register design, such as access logs, optimization schemes, constraints, and actual benefits. Based on the graph neural network architecture, the model abstracts registers, modules, and signals into nodes and edges, encoding features such as access frequency and correlation. The model is iteratively trained using the training dataset, and parameters are optimized to minimize prediction errors. After testing and verifying that the model's accuracy meets the standards, it is integrated into the intelligent optimization engine. Subsequent updates and optimizations will be made based on incremental data from new projects.

[0133] The extracted static correlation features and user-defined physical time-series constraints are used as inputs to provide a basis for generating optimization suggestions for the graph neural network optimization model.

[0134] For example, physical timing constraints include a maximum access latency of 1.2ns and a clock frequency of 1GHz; the static correlation features of the input graph neural network optimization model are an access frequency of 500 times / second to 10 times / second, a module correlation degree of 80% to 10%, and a signal dependency relationship of 16'H0003 depending on 16'H0001. The model combines these inputs with pre-training experience to generate targeted optimization schemes.

[0135] Then, the optimization model is run to generate optimization suggestions for register physical grouping, address space layout and interface configuration parameters, while generating the prediction confidence of the optimization model and estimating access latency and power consumption gains.

[0136] The optimization model generates optimization suggestions based on input data, focusing on three core dimensions: register physical grouping, address space layout, and interface configuration parameters. At the same time, it evaluates the reliability of the optimization scheme through internal algorithms, i.e. prediction confidence, and quantifies and estimates the benefits such as the reduction in access latency and the proportion of power saving after optimization.

[0137] For example, the physical grouping optimization suggestion in the optimization proposal could be: group 16'H0001 and 16'H0003, which have high access frequency and 80% module correlation, into the same physical group to reduce cross-group access latency;

[0138] The recommended optimization for address space layout is to allocate the frequently accessed 16'H0001 to the contiguous address region 16'H0001-16'H0002, and allocate the less frequently accessed 16'H0002 to the address 16'H0005, in order to improve address decoding efficiency.

[0139] The interface configuration parameter optimization suggestion is to adjust the interface data bit width from 32 bits to 64 bits to adapt to high-frequency access requirements;

[0140] The prediction confidence level can reach 92%, the estimated access latency is reduced from 1.5ns to 1.0ns, and the power consumption is reduced from 100mW to 85mW.

[0141] Then, a second confidence score is calculated based on the prediction confidence of the optimized model.

[0142] The second confidence score is directly derived from the prediction confidence of the optimization model. The prediction confidence reflects the optimization model's judgment on the effectiveness of the optimization suggestions. The higher the prediction confidence, the higher the second confidence score. The full score is 100 points, and the second confidence score is directly proportional to the prediction confidence.

[0143] For example, if the prediction confidence of an optimization scheme generated by the optimization model is 92%, then the second confidence score = 92% × 100 = 92 points; if the prediction confidence is 85%, then the second confidence score is 85 points, which intuitively reflects the reliability of the optimization scheme.

[0144] Finally, the optimization suggestions are compared with the design constraints to generate a consistency identifier that characterizes the degree of compliance.

[0145] The optimization suggestions to be generated are compared one by one with the design constraints set by the user, such as physical timing constraints and power budget, to evaluate whether the optimization suggestions meet all the constraints. The degree of compliance is represented by specific indicators, which can be divided into three categories: fully compliant, partially compliant, and non-compliant.

[0146] For example, the design constraints are a maximum access latency of 1.2ns and a power budget of 90mW. The optimization suggestion corresponds to an estimated access latency of 1.0ns and a power consumption of 85mW, both of which meet the constraints, and the consistency indicator is fully compliant. However, if the optimization suggestion estimates a power consumption of 88mW and an access latency of 1.3ns, which exceeds the latency constraints, the consistency indicator is partially compliant.

[0147] In step S500 of this application embodiment, based on the verification results and optimization suggestions, the final register hardware code, embedded assertions, and address mapping table are generated. An overall credibility score is then generated by combining the first credibility score, the second credibility score, and the consistency identifier, including:

[0148] Adjust the register address offset and grouping structure according to the proposed optimization scheme;

[0149] Generate core Verilog code containing register instantiation, read / write logic, and signal connections, which will serve as the final register hardware code.

[0150] Key formal properties are embedded in the core Verilog code as comments or synthesizable assertions;

[0151] Generate an address mapping table that reflects the final address layout, along with the corresponding C header file and software driver framework;

[0152] The overall credibility score is calculated by combining the first credibility score, the second credibility score, and the consistency identifier, and then embedded into the generated code comments or a separate credibility report.

[0153] In this embodiment, the purpose of step S500 is to translate the results of previous verification and optimization into register hardware code and supporting documents that can be directly used for chip design. Simultaneously, it generates an overall score by comprehensively considering multiple dimensions of reliability indicators, quantifying the reliability of the entire design process. This ensures that the hardware code meets verification requirements and optimization directions, while also perfecting the design deliverables through supporting documents such as embedded assertions and address mapping tables. Furthermore, the overall reliability score directly reflects the design quality, providing accurate and reliable design basis for subsequent chip tape-out and software adaptation.

[0154] To achieve the above objectives, it is first necessary to adjust the register address offset and grouping structure according to the optimization suggestions.

[0155] Based on the optimization suggestions output by the intelligent optimization engine, the physical grouping and address space layout of registers are adjusted. The core is to optimize the address offset (the relative position of different registers in the address space) and grouping, so as to ensure that the adjustment meets the optimization goals such as performance and power consumption.

[0156] For example, the optimization suggestion requires that the frequently accessed addresses 16'H0001 and 16'H0003 be assigned to the same physical group, with their addresses distributed consecutively. The original address 16'H0001 remains unchanged. The offset of the original address 16'H0003 is adjusted, and the new address is set to 16'H0002, forming a contiguous address segment with 16'H0001. Simultaneously, the offset of the infrequently accessed address 16'H0002 is adjusted to 16'H0005, and it is assigned to a low-priority physical group, thus completing the adjustment of the group structure and address offsets.

[0157] Next, the core Verilog code containing register instantiation, read / write logic, and signal connections needs to be generated as the final register hardware code.

[0158] Based on the adjusted address offset and grouping structure, combined with the core parameters in the structured definition information, such as address, bit field, and operation type, the core Verilog code containing register instantiation, read / write logic, and signal connections is automatically generated. The Verilog code must conform to the hardware design specifications and can be directly used for subsequent logic synthesis and physical implementation.

[0159] Then, the key formal properties need to be embedded in the core Verilog code as comments or synthesizable assertions.

[0160] This involves selecting key formal attributes, such as the correctness of reset behavior and read / write permission constraints, and converting them into a Verilog-compatible form. These attributes are then marked as comments next to the corresponding logic or written as synthesizable assertion statements such as SVA assertions and embedded in the code to facilitate verification of logical correctness during subsequent simulations or online testing.

[0161] Furthermore, it is necessary to generate an address mapping table that reflects the final address layout, as well as the corresponding C header file and software driver framework.

[0162] Based on the final adjusted register address layout, a structured address mapping table is generated, containing core information such as register addresses, bit fields, function descriptions, and operation types. At the same time, corresponding C header files for defining register address macros, bit field macros, and other information, as well as a software driver framework containing register read / write functions, initialization functions, and other content, are automatically generated to adapt to the software layer's access requirements for registers.

[0163] Finally, the overall credibility score is calculated by combining the first credibility score, the second credibility score, and the consistency identifier through a weighted average. The overall credibility score and the consistency identifier are then embedded into the generated code comments or a separate credibility report.

[0164] The overall credibility score (out of 100) is calculated by combining the first credibility score, the second credibility score, and the quantitative value corresponding to the consistency identifier using a weighted average formula. The consistency identifier needs to be quantified first: 100 points for complete compliance, 80 points for partial compliance, and 50 points for non-compliance. Then, the total score is calculated according to preset weights (e.g., the first credibility score accounts for 40%, the second credibility score accounts for 40%, and the quantitative value of the consistency identifier accounts for 20%). Finally, the score and consistency identifier are embedded in code comments or a separate credibility report.

[0165] For example, if the first confidence score is 85, the second confidence score is 92, and the consistency indicator is fully compliant (quantitative value 100), then the weighted formula is: Overall confidence score = 85 × 0.4 + 92 × 0.4 + 100 × 0.2 = 34 + 36.8 + 20 = 90.8. Ultimately, "Overall confidence score: 90.8, consistency indicator: fully compliant" will be embedded in the header comment of the Verilog code, or a separate confidence report will be generated, clearly indicating the score and its calculation basis. If the consistency indicator is partially compliant (quantitative value 80), then the overall score = 85 × 0.4 + 92 × 0.4 + 80 × 0.2 = 34 + 36.8 + 16 = 86.8.

[0166] In step S600 of this embodiment, the digital twin and the intelligent optimization engine are iteratively updated based on the verification data and performance data.

[0167] Collect formal verification counterexamples, simulation test results, and post-silicon performance data;

[0168] The timing power prediction algorithm parameters in the digital twin are calibrated using the collected real timing power consumption data;

[0169] The actual optimal address mapping scheme is used as a new sample to incrementally train the machine learning model in the intelligent optimization engine;

[0170] The newly discovered design error patterns are summarized as new implicit attributes, and the general attribute rule library and the optimization strategy library that is dynamically accumulated at runtime are updated.

[0171] When the overall credibility score is lower than a preset threshold, the enhanced training of the machine learning model in the digital twin and the intelligent optimization engine is triggered.

[0172] Adjust the weights of the optimization strategy based on the consistency identifier.

[0173] In this embodiment, the purpose of step S600 is to continuously iterate and optimize the performance of the digital twin and the intelligent optimization engine by collecting real data from the entire design process, making them more aligned with actual application scenarios. This not only improves the accuracy of timing and power consumption predictions and the rationality of optimization suggestions in subsequent designs, but also enriches the attribute rule library and optimization strategy library, enhances the completeness of formal verification, and strengthens training when the overall credibility is insufficient, ensuring that the tool continuously improves its reliability and adaptability during long-term use.

[0174] Specifically, to achieve the above objectives, it is first necessary to collect formal verification counterexample information, simulation test results, and post-silicon performance data.

[0175] This involves summarizing core verification and performance data from the entire design, testing, and mass production phases. It covers counterexamples from the formal verification phase, functional / timing test results from the simulation testing phase, and post-silicon performance data after chip tape-out. The post-silicon performance data after chip tape-out includes timing, power consumption, and yield data from actual operation, forming a complete dataset.

[0176] For example, the formal verification counterexamples collected showed that the value read immediately after writing to register 16'H0003 was inconsistent, triggered by the overlap of the write clock edge and the read clock edge; the simulation test results showed that the actual access latency of the register array was 1.1ns, which was 0.1ns higher than the estimated 1.0ns; the post-silicon performance data showed that the average dynamic power consumption of this register array in the mass-produced chip was 90mW, which was 5mW higher than the estimated 85mW, with a test coverage of 98%.

[0177] Then, the timing power prediction algorithm parameters in the digital twin need to be calibrated using the collected real timing power data.

[0178] The actual timing power consumption data to be collected, such as the actual access latency and dynamic / static power consumption after silicon, will be compared with the original estimated data of the digital twin to calculate the deviation value. Based on the deviation, the core parameters in the timing power consumption prediction method, such as the transistor delay coefficient and load power consumption coefficient corresponding to the process node, will be adjusted to improve the prediction accuracy.

[0179] Next, the actual optimal address mapping scheme needs to be used as a new sample to incrementally train the machine learning model in the intelligent optimization engine.

[0180] The optimal address mapping scheme that is about to be verified in chip mass production or testing, such as a layout that has been proven to have high access efficiency and low power consumption, can be used as a new sample to input into the machine learning model of the intelligent optimization engine. The model parameters are updated by incremental training, without the need to retrain the entire model, thereby improving the model's adaptability to real-world scenarios.

[0181] For example, in practical applications, it was found that when the frequently accessed registers 16'H0001 and 16'H0003 are grouped together with the associated registers of module A, and the address is allocated as a continuous segment from 16'H0001 to 16'H0004, the access latency is the lowest and the power consumption is optimal. This address mapping scheme is used as a new sample and input into the graph neural network optimization model in the intelligent optimization engine. The model updates its weights through incremental training, and when designing similar modules in the future, it can preferentially generate similar optimization schemes.

[0182] Secondly, the newly discovered design error patterns need to be summarized as new implicit attributes, and the general attribute rule library and the optimization strategy library dynamically accumulated at runtime need to be updated.

[0183] This involves analyzing collected counterexamples and test results, summarizing new design error patterns, such as read-write conflicts under specific timing combinations and address decoding logic vulnerabilities, and transforming them into new implicit attributes to supplement the general attribute rule base. At the same time, it involves updating the optimization strategy base with practically proven effective optimization methods (such as buffer insertion positions and grouping strategies in specific scenarios) to enrich the verification dimensions and optimization capabilities of the tool.

[0184] For example, the error pattern "address decoding race hazards are likely to occur when two register addresses are consecutive and accessed at high frequency at the same time" was discovered from counterexamples and transformed into the implicit attribute "decoding interlock logic needs to be added for high-frequency access to registers with consecutive addresses" and updated to the general attribute rule base; in practice, it was found that "for signals that drive more than 8 loads, inserting two-level buffers at intermediate nodes has a better optimization effect than single-level buffers" and this strategy was updated to the optimization strategy base.

[0185] Furthermore, when the overall credibility score falls below a preset threshold, it is necessary to trigger the enhanced training of the machine learning models in the digital twin and the intelligent optimization engine.

[0186] This means that a preset overall credibility score threshold, such as 85 points, is set. If the overall credibility score of a design project is lower than this threshold, it indicates that the accuracy of the digital twin's prediction or the reliability of the intelligent optimization engine's suggestions is insufficient. This triggers a reinforcement training process—using a larger scale of historical data and newly collected real data to intensively train the timing power consumption prediction method of the digital twin and the machine learning model of the intelligent optimization engine, thereby significantly improving the model performance.

[0187] For example, if the preset overall credibility score threshold is 85 points, and a project's final overall credibility score is 82 points, which is lower than the threshold, reinforcement training is triggered. By utilizing validation data from nearly 30 similar projects, post-silicon performance data, and counterexamples and test results from this project, the predicted algorithm parameters of the digital twin are comprehensively calibrated, and the machine learning model is fully updated. After training, the model's prediction error is reduced to 2%, and the prediction confidence of the optimization suggestions is increased to over 90%.

[0188] Finally, the weights of the optimization strategy need to be adjusted based on the consistency identifier.

[0189] Among them, the consistency identifier reflects the degree of fit between the optimization suggestion and the design constraints. For the optimization strategy corresponding to different consistency identifiers, its weight in the model is adjusted - the weight of the optimization strategy that fully meets the constraints is increased, the weight of the partially compliant strategy is maintained or slightly adjusted, and the weight of the non-compliant strategy is reduced, so as to ensure that the subsequent model prioritizes the generation of optimization suggestions that meet the constraints.

[0190] For example, the optimization strategy of "grouping registers physically according to module correlation" has been consistently identified as fully compliant in 90% of past applications, so its weight has been increased from 0.6 to 0.75; the strategy of "expanding interface bit width from 32 bits to 64 bits" has been partially compliant in 60% of cases, so its weight has been adjusted from 0.5 to 0.45; the strategy of "randomly allocating address space" has been non-compliant in 70% of cases, so its weight has been reduced from 0.3 to 0.1. When the model generates optimization suggestions in the future, the high-weight strategy will be given priority.

[0191] In step S600 of the embodiments of this application, the following is also included:

[0192] From the multiple optimization suggestions output by the intelligent optimization engine, the solution with an overall credibility score higher than the threshold is selected as the candidate solution;

[0193] Candidate solutions are visualized through a human-machine collaborative decision-making interface, with each solution associated with its address mapping, verification status, optimization benefits, overall credibility score, and consistency identifier.

[0194] After receiving the user's selection instruction, the solution package is output, which includes the final register hardware code, formal verification environment, digital twin model file and complete trust report.

[0195] In this embodiment of the application, the purpose of the above steps is to select highly reliable solutions from multiple optimization suggestions from the intelligent optimization engine, present key information in a visual manner to assist users in decision-making, and finally output a solution package containing a complete set of design deliverables. This ensures the reliability of the solution, improves the efficiency of user decision-making, and ensures that the deliverables are complete and can be directly used in the subsequent chip development process.

[0196] To achieve the above objectives, firstly, it is necessary to select the scheme with an overall credibility score higher than the threshold from the multiple optimization suggestions output by the intelligent optimization engine as the candidate scheme.

[0197] This involves setting a predefined overall credibility score threshold, selecting solutions with an overall credibility score higher than the threshold from multiple optimization suggestions output by the intelligent optimization engine, and eliminating solutions with insufficient credibility to ensure the basic reliability of candidate solutions.

[0198] For example, with a preset overall credibility score threshold of 85 points, the intelligent optimization engine outputs three optimization suggestions: Suggestion 1 has an overall credibility score of 90.8 points, Suggestion 2 has 88 points, and Suggestion 3 has 82 points. After filtering, Suggestion 1 and Suggestion 2 become candidate suggestions because their scores are higher than the threshold, while Suggestion 3 is eliminated.

[0199] Next, candidate solutions need to be visualized through a human-machine collaborative decision-making interface, with each solution associated with its address mapping, verification status, optimization benefits, overall credibility score, and consistency identifier.

[0200] This means that the core information of each candidate solution is presented in a unified format through a human-machine collaborative decision-making interface, including address mapping, verification status, optimization benefits, overall credibility score and consistency identifier, so that users can intuitively compare the advantages and disadvantages of each solution.

[0201] For example, the information displayed for Scheme 1 is as follows: the address mapping is 16'H0001-16'H0002 (high frequency group) and 16'H0005 (low frequency group); the verification status is that 98 out of 100 attributes passed the formal verification, with no fatal defects; the optimization benefits are an access latency of 1.0ns and a power consumption of 85mW; the overall credibility score is 90.8 points; and the consistency identifier is fully compliant.

[0202] The information displayed for Scheme 2 is as follows: the address mapping is 16'H0001-16'H0003 (high frequency group) and 16'H0006 (low frequency group); the verification status is that 96 out of 100 attributes passed the formal verification, with no fatal defects; the optimization benefits are an access latency of 1.1ns and a power consumption of 83mW; the overall credibility score is 88 points; and the consistency identifier is fully compliant.

[0203] Then, after receiving the user's selection instructions, the solution package needs to be output, which includes the final register hardware code, formal verification environment, digital twin model file, and complete trust report.

[0204] After the user selects the final solution through the human-machine collaborative decision-making interface, the system automatically integrates the complete set of deliverables corresponding to the solution, generates a solution package and outputs it. The deliverables cover hardware implementation, verification environment, model files and credibility assessment, meeting the needs of the entire subsequent development process.

[0205] For example, after the user selects Scheme 1, the output scheme package includes: the final register hardware code in Verilog format, containing embedded assertions; a formal verification environment, containing the encoded assertion set and verification script; a digital twin model file, containing a high-level abstract functional model and a calibrated timing and power consumption prediction algorithm; and a complete credibility report, including a first credibility score of 85 points, a second credibility score of 92 points, an overall credibility score of 90.8 points, a complete compliance with the consistency indicator, and the calculation basis, etc.

[0206] In step S600 of this application embodiment, it is also included that a scheme comparison function is provided in the human-machine collaborative decision-making interface, which supports users to perform multi-dimensional filtering and sorting based on multi-dimensional data, and automatically generates traceable decision records and compliance documents after determining the final scheme, wherein the decision records contain a detailed analysis of the overall credibility score and consistency identifier.

[0207] In this embodiment of the application, the purpose of the above steps is to facilitate users to compare candidate solutions and accurately select the optimal solution, while retaining traceable decision records and compliance documents to ensure that the decision-making process is transparent, compliant, and verifiable in the future.

[0208] The aforementioned solution comparison function supports users to perform multi-dimensional filtering and sorting based on multi-dimensional data. Specifically, it can be a solution comparison module built into the human-computer collaborative decision-making interface, which supports users to filter and sort by multiple dimensions such as access latency, power consumption, and overall credibility score, and intuitively present the differences between the solutions.

[0209] For example, users can filter solutions with an overall credibility score higher than 90 and a consistency indicator that is fully compliant, and then sort them by power consumption from low to high to quickly locate the optimal solution. For instance, solution 1 has a power consumption of 85mW and a score of 90.8, while solution 2 has a power consumption of 83mW and a score of 88. After filtering, only solution 1 will be displayed, and after sorting, solution 1 will be the first choice.

[0210] Specifically, after the final solution is determined, a traceable decision record and compliance document are automatically generated. After the user determines the final solution, the system automatically records key decision information and generates a decision record and compliance document. The decision record mainly includes a detailed analysis of the overall credibility score and consistency identifier.

[0211] For example, after a user selects Option 1, the decision record will state that the selection is based on an overall credibility score of 90.8, which is higher than the overall credibility score threshold of 85. The consistency indicator fully complies with all design constraints and there is no compliance risk. The compliance document will review the industry design specifications that the option complies with to ensure that it meets mass production requirements.

[0212] It should be noted that the descriptions of each embodiment in the above embodiments have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0213] Those skilled in the art will understand that embodiments of the present invention can provide methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0214] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0215] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0216] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0217] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Clearly, those skilled in the art can make various alterations and variations to the invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the invention and its equivalents, the invention is also intended to include these modifications and variations.

Claims

1. A method for automatically generating an implementation of a register array code, characterized by, The method includes: Read the structured definition information, attribute specifications, and target process constraints of the registers as register information; Based on the acquired register information, a digital twin of the register design is constructed, and an early risk assessment is performed on the structured definition information to output a risk report and optimization strategy. Based on the structured definition information and the hardware design logic of the digital twin derivation register, the formal assurance engine is run to verify the design logic and obtain the verification results, counterexample information and the first confidence score. Run the intelligent optimization engine to perform multi-objective optimization based on risk reports, optimization strategies, historical access patterns and design constraints, and output optimization suggestions, second credibility scores and consistency indicators; Based on the verification results and optimization suggestions, the final register hardware code, embedded assertions and address mapping table are generated, and the overall credibility score is generated by combining the first credibility score, the second credibility score and the consistency identifier. Based on the verification and performance data, the digital twin and intelligent optimization engine are iteratively updated.

2. The method for automatically generating register array code according to claim 1, characterized in that, Read the structured definition information, attribute specifications, and target process constraints of the registers as register information, including: Read the register address, bit fields, operation type, default value, local signal direction and comment information of the register to form structured definition information; Read the formal attribute specification tab attached to the register, which serves as the attribute specification and is used to define the constraints that the register group must satisfy in a declarative language. The target process node, operating frequency, and power consumption budget for reading registers are used as process constraints.

3. The method for automatically generating register array code according to claim 1, characterized in that, Based on the acquired register information, a register design digital twin is constructed, including: A high-level abstract functional model is generated based on the structured definition information, which is used for early algorithm verification and software-hardware co-simulation. Based on the target process constraints, a timing power consumption pre-estimation method is invoked to estimate the critical path delay and dynamic and static power consumption of the register array. Based on register access patterns and structure insertion testability design checkpoints, a testability analysis module is built and testability analysis results are generated, including at least test coverage. By associating the functional model, timing power consumption prediction method, and testability analysis module, a unified and traceable digital twin of register design is constructed.

4. The method for automatically generating register array code according to claim 3, characterized in that, Conduct early risk assessments on structured definition information, and output risk reports and optimization strategies, including: Lightweight formal checks are performed on the high-level abstract functional model to verify that there are no address conflicts and that the reset behavior is correct. The timing power prediction method is used to identify potential high fan-out signals and unbalanced paths, and to propose register grouping or buffer insertion suggestions. Based on the testability analysis results from the testability analysis module, it is recommended to insert test observation points for production testing; Based on the results of the lightweight formal inspection, timing and power consumption prediction, and testability analysis, an early risk report is generated, and structural adjustment strategies are proposed.

5. The method for automatically generating register array code according to claim 1, characterized in that, Based on the structured definition information and the hardware design logic of the digital twin derivation register, the formal assurance engine verifies the design logic, and obtains the verification results, counterexample information, and a first confidence score, including: Based on the structured definition information, the hardware design logic of the register to be implemented is derived. The design logic, explicitly declared formal properties, and implicit properties automatically generated based on a general property rule base are jointly encoded into an assertion language that can be recognized by formal verification tools. The formal assurance engine calls the formal verification tool to perform mathematical proof on the encoded set of assertions, verifying whether the design logic satisfies all properties; Output the verification results, which include the proof status of each attribute; generate counterexample information containing specific violation scenarios for attributes whose proofs failed. Based on the completeness of the attribute proof, the complexity of the counterexamples, and the consistency of the early risk assessment of the digital twin during the verification process, a first credibility score reflecting the credibility of this formal verification is calculated and output. The consistency of the early risk assessment of the digital twin and the first credibility score are directly proportional to the completeness of the attribute proof and inversely proportional to the complexity of the counterexamples.

6. The method for automatically generating register array code according to claim 1, characterized in that, Run the intelligent optimization engine, including: Historical register access logs are obtained and static correlation analysis is performed to extract access frequency, module correlation degree and signal dependency as static correlation features, i.e. the historical access pattern. Load a pre-trained graph neural network optimization model, taking the static correlation features and user-defined physical time-series constraints as input; The optimization model is run to generate optimization suggestions for register physical grouping, address space layout and interface configuration parameters. At the same time, the prediction confidence of the optimization model is generated and the access latency and power consumption gains are estimated. The second confidence score is calculated based on the prediction confidence of the optimized model; The optimization suggestions are compared with the design constraints to generate a consistency identifier that characterizes the degree of compliance.

7. The method for automatically generating register array code according to claim 1, characterized in that, Based on the verification results and optimization suggestions, the final register hardware code, embedded assertions, and address mapping table are generated. An overall credibility score is then generated by combining the first credibility score, the second credibility score, and the consistency flag, including: Adjust the register address offset and grouping structure according to the proposed optimization scheme; Generate core Verilog code containing register instantiation, read / write logic, and signal connections, which will serve as the final register hardware code. Key formal properties are embedded in the core Verilog code as comments or synthesizable assertions; Generate an address mapping table that reflects the final address layout, along with the corresponding C header file and software driver framework; The overall credibility score is calculated by combining the first credibility score, the second credibility score, and the consistency identifier, and then embedded into the generated code comments or a separate credibility report.

8. The method for automatically generating register array code according to claim 1, characterized in that, Based on the verification and performance data, iteratively update the digital twin and the intelligent optimization engine: Collect formal verification counterexamples, simulation test results, and post-silicon performance data; The timing power prediction algorithm parameters in the digital twin are calibrated using the collected real timing power consumption data; The actual optimal address mapping scheme is used as a new sample to incrementally train the machine learning model in the intelligent optimization engine; The newly discovered design error patterns are summarized as new implicit attributes, and the general attribute rule library and the optimization strategy library that is dynamically accumulated at runtime are updated. When the overall credibility score is lower than a preset threshold, the enhanced training of the machine learning model in the digital twin and the intelligent optimization engine is triggered. Adjust the weights of the optimization strategy based on the consistency identifier.

9. The method for automatically generating register array code according to claim 1, characterized in that, Also includes: From the multiple optimization suggestions output by the intelligent optimization engine, the solution with an overall credibility score higher than the threshold is selected as the candidate solution; Candidate solutions are visualized through a human-machine collaborative decision-making interface, with each solution associated with its address mapping, verification status, optimization benefits, overall credibility score, and consistency identifier. After receiving the user's selection instruction, the solution package is output, which includes the final register hardware code, formal verification environment, digital twin model file and complete trust report.

10. The method for automatically generating register array code according to claim 9, characterized in that, It also includes providing a solution comparison function in the human-machine collaborative decision-making interface, supporting users to perform multi-dimensional filtering and sorting based on multi-dimensional data, and automatically generating traceable decision records and compliance documents after determining the final solution. The decision records contain a detailed analysis of the overall credibility score and consistency identifier.

Images