Code verification method and device, electronic equipment, storage medium and program product

Abstract

The present disclosure provides a code verification method and device, electronic equipment, storage medium and program product, applied to the technical field of computer, the method comprises the steps of: generating a first CDC constraint file based on a general design constraint file and a cross clock domain verification (CDC) constraint condition; generating a first DC constraint file based on the general design constraint file and a design compiler (DC) constraint condition; determining a second DC constraint file based on the first CDC constraint file and a conversion table, and determining a target DC constraint file based on the first DC constraint file and the second DC constraint file; determining a second CDC constraint file based on the first DC constraint file and the conversion table, and determining a target CDC constraint file based on the first CDC constraint file and the second CDC constraint file; and verifying the target code based on the target DC constraint file and the target CDC constraint file respectively to obtain the verification result of the target code. In this way, the automatic completion of the mutual mapping of the two types of constraints can be realized, and the consistency of the constraints can be effectively ensured.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to a code verification method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] As the complexity of integrated circuit chip design increases, register transfer level (RTL) static verification and logic synthesis have become critical steps in chip development. SpyGlass is a mainstream static verification tool for clock domain crossing (CDC), primarily used for CDC checks. It can identify asynchronous clock domain signals and verify synchronization mechanisms to avoid metastability risks. It requires configuration with Synopsys Design Constraints (SDC) to complete the verification. The Design Compiler (DC), Synopsys' core logic synthesis tool, is responsible for converting RTL code into gate-level netlists and optimizing timing, area, and power consumption. It also relies on SDC configuration.

[0003] In practical engineering, SpyGlass's CDC verification and DC logic synthesis have similar constraint syntax but different application scenarios and constraint rules, requiring the manual writing and maintenance of two independent SDC files. Manual writing is not only time-consuming, labor-intensive, and inefficient, but also makes it difficult to ensure consistency between the two sets of constraints, easily leading to discrepancies between code inspection results and synthesis results, and causing potential chip design problems. Furthermore, when the design code is iterated and modified, both sets of constraints need to be manually updated simultaneously, which is prone to omissions and errors, seriously affecting the reliability and development efficiency of the chip design process. Summary of the Invention

[0004] This disclosure provides a code verification method, apparatus, electronic device, storage medium, and program product to at least solve the above-mentioned technical problems existing in the prior art.

[0005] According to a first aspect of this disclosure, a code verification method is provided, comprising: Generate a general design constraint file based on basic design information; Based on the general design constraint file and cross-clock domain verification of CDC constraints, the first CDC constraint file is generated. Based on the general design constraint file and the DC constraint conditions of the design compiler, the first DC constraint file is generated; Based on the first CDC constraint file and the transformation table, a second DC constraint file is determined, and based on the first DC constraint file and the second DC constraint file, a target DC constraint file is determined. Based on the first DC constraint file and the transformation table, a second CDC constraint file is determined, and based on the first CDC constraint file and the second CDC constraint file, a target CDC constraint file is determined. The target code is verified based on the target DC constraint file and the target CDC constraint file respectively, and the verification result of the target code is obtained.

[0006] The method in the above scheme further includes: If the verification result includes violation information, then the constraint file corresponding to the violation information is determined; If the constraint file corresponding to the violation information is a general design constraint file, then the basic design information is updated, and the updated design constraint file is determined based on the updated basic design information; based on the CDC constraint file, DC constraint file, and updated design constraint file, the updated CDC constraint file and updated DC constraint file are determined, and the target code is verified again based on the updated CDC constraint file and updated DC constraint file. If the constraint file corresponding to the violation information is the target CDC constraint file, then the CDC constraint condition is updated. Based on the general design constraint file, the updated CDC constraint condition, and the DC constraint file, the updated CDC constraint file and the updated DC constraint file are determined. Based on the updated CDC constraint file and the updated DC constraint file, the target code is verified again. If the constraint file corresponding to the violation information is the target DC constraint file, then the DC constraint condition is updated. Based on the general design constraint file, the updated DC constraint condition, and the CDC constraint file, the updated CDC constraint file and the updated DC constraint file are determined. Based on the updated CDC constraint file and the updated DC constraint file, the target code is verified again.

[0007] In the above scheme, the generation of a general design constraint file based on basic design information includes: Based on at least one of the clock information, clock grouping information, reset information, and input / output information included in the basic design information, a general design constraint file is determined; The general design constraint file includes at least one of clock constraint code, clock grouping constraint code, and input / output constraint code.

[0008] In the above scheme, the step of generating the first CDC constraint file based on the general design constraint file and cross-clock domain verification CDC constraints includes: Determine the reset constraint code and static signal constraint code based on the CDC constraint conditions; The first CDC constraint file is generated based on the general design constraint file, reset constraint code, and static signal constraint code.

[0009] In the above scheme, generating the first DC constraint file based on the general design constraint file and the DC constraint conditions of the design compiler includes: Determine at least one of the following based on DC constraints: pseudo-path constraint code, clock exception constraint code, static signal constraint code, and multi-cycle path constraint code; The first DC constraint file is generated based on the general design constraint file and at least one of the pseudo path constraint code, clock exception constraint code, static signal constraint code, and multi-cycle path constraint code.

[0010] In the above scheme, the conversion table includes the correspondence between CDC constraint file syntax and DC constraint file syntax. The step of determining the second DC constraint file based on the first CDC constraint file and the conversion table includes: Obtain at least one target CDC constraint code from the first CDC constraint file; Based on the transformation table, the at least one target CDC constraint code is converted into at least one DC constraint code; Determine that the at least one DC constraint code constitutes the second DC constraint file; The target CDC constraint code includes constraint codes contained in the CDC constraint file but not in the DC constraint file.

[0011] In the above scheme, the at least one target CDC constraint code includes a CDC-specific constraint code and a synchronizer constraint code; the conversion of the at least one target CDC constraint code into at least one DC constraint code based on the conversion table includes at least one of the following: Convert the CDC-specific constraint code into a DC-specific constraint code based on the transformation table; The synchronizer constraint code is converted into a retiming-prohibited constraint code based on the transformation table.

[0012] In the above scheme, determining the target DC constraint file based on the first DC constraint file and the second DC constraint file includes: The first DC constraint file and the second DC constraint file are determined to constitute the target DC constraint file.

[0013] In the above scheme, the conversion table includes the correspondence between CDC constraint file syntax and DC constraint file syntax. The step of determining the second CDC constraint file based on the first DC constraint file and the conversion table includes: Obtain at least one target DC constraint code from the first DC constraint file; Based on the transformation table, the at least one target DC constraint code is converted into at least one CDC constraint code; The at least one CDC constraint code is determined to constitute the second CDC constraint file; The target DC constraint code includes constraint codes that are included in the DC constraint file but not in the CDC constraint file.

[0014] In the above scheme, the at least one target DC constraint code includes a pseudo-path constraint code, and the conversion of the at least one target DC constraint code into at least one CDC constraint code based on the transformation table includes: The pseudo-path constraint code of the DC constraint file syntax is converted into the pseudo-path constraint code corresponding to the CDC constraint file syntax based on the transformation table. The abstract port constraint code corresponding to the CDC constraint file syntax is determined based on the black-box port clock domain and the aforementioned conversion table. The second CDC constraint file is determined based on the pseudo-path constraint code corresponding to the CDC constraint file syntax and the abstract port constraint code corresponding to the CDC constraint file syntax.

[0015] In the above scheme, determining the target CDC constraint file based on the first CDC constraint file and the second CDC constraint file includes: The first CDC constraint file and the second CDC constraint file are determined to constitute the target CDC constraint file.

[0016] According to a second aspect of this disclosure, a code verification apparatus is provided, comprising: A general document generation unit is used to generate general design constraint documents based on basic design information. The CDC constraint file generation unit is used to generate the first CDC constraint file based on the general design constraint file and the cross-clock domain verified CDC constraint conditions. The DC constraint file generation unit is used to generate the first DC constraint file based on the general design constraint file and the DC constraint conditions of the design compiler. The DC constraint file generation unit is further configured to determine a second DC constraint file based on the first CDC constraint file and the transformation table, and to determine a target DC constraint file based on the first DC constraint file and the second DC constraint file. The CDC constraint file generation unit is further configured to determine a second CDC constraint file based on the first CDC constraint file and the transformation table, and to determine a target CDC constraint file based on the first CDC constraint file and the second CDC constraint file; The verification unit is used to verify the target code based on the target DC constraint file and the target CDC constraint file respectively, and obtain the verification result of the target code.

[0017] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the methods of this disclosure.

[0018] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing the computer to perform the methods described in this disclosure.

[0019] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, describes the methods of this disclosure.

[0020] This disclosed code verification method enables automatic consistency conversion between SpyGlass's CDC and DC logic synthesis's SDC. It eliminates the need for manual writing and maintenance of two separate constraint files, significantly reducing workload and improving design efficiency. It allows for automatic mapping and completion of the two types of constraints, effectively ensuring constraint consistency and avoiding deviations in checking and synthesis results caused by inconsistencies. Constraints are updated bidirectionally with a single modification, eliminating omissions and errors from manual maintenance and improving the stability and reliability of the chip design process.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0022] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which: In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

[0023] Figure 1 This illustration shows an optional flowchart of the code verification method provided in an embodiment of the present disclosure; Figure 2 A schematic diagram of another optional process for the code verification method provided in this disclosure embodiment is shown; Figure 3 A schematic diagram of the consistency conversion verification process provided in the embodiments of this disclosure is shown; Figure 4 A schematic diagram of an optional structure of the code verification apparatus provided in an embodiment of this disclosure is shown; Figure 5 A schematic diagram of the composition structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0024] To make the objectives, features, and advantages of this disclosure more apparent and understandable, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0025] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0026] In the following description, the terms "first" and "second" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first" and "second" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this disclosure described herein can be implemented in an order other than that illustrated or described herein.

[0027] Unless otherwise defined, all technical and scientific terms used in this disclosure have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. The terminology used in this disclosure is for the purpose of describing embodiments of this disclosure only and is not intended to be limiting of this disclosure.

[0028] It should be understood that in the various embodiments of this disclosure, the sequence number of each implementation process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure.

[0029] SpyGlass, developed by Synopsys, is an RTL static verification tool focused on identifying potential problems early in chip design, shortening design cycles, and reducing costs. A crucial aspect of SpyGlass code inspection is CDC (Cross-Clock Domain) checking. This automatically identifies asynchronous clock domain signals (such as First-Input First-Out (FIFO) memory and handshake protocols) and verifies the correctness of synchronization mechanisms (such as dual-flip-flop synchronization), avoiding metastability risks. During CDC checking, constraints need to be imposed on the design code; SpyGlass then performs cross-clock domain checks based on these constraints.

[0030] DC synthesis is Synopsys' core logic synthesis tool, responsible for converting RTL code into netlists corresponding to the technology library, and optimizing timing, area, and power consumption. DC synthesis also requires us to impose constraints on the design code.

[0031] Although both SpyGlass code inspection and DC logic synthesis require imposing constraints on the design, the constraints are not entirely the same. Therefore, two different sets of constraints need to be written for target code verification and logic synthesis.

[0032] Constraints for SpyGlass code verification include clock constraints, reset constraints, I / O constraints, static signal constraints, and black-box constraints. Constraints for DC logic synthesis include clock constraints, I / O constraints, and pseudo-path constraints.

[0033] While both sets of constraints share some commonalities, they also have specific requirements for each tool. Designers often write two sets of constraints to meet different needs, one for code inspection and the other for logic synthesis. Furthermore, if code modifications are made, both sets of constraints need to be maintained simultaneously.

[0034] In the existing EDA workflow, manually writing and maintaining two sets of SDC constraint files—one for SpyGlass CDC verification and the other for DC logic synthesis—wasted a significant amount of time and reduced efficiency. Furthermore, manually writing and maintaining two sets of SDC constraint files could not guarantee consistency between them, leading to discrepancies between code inspection results and synthesis results.

[0035] Specifically, SpyGlass's SDC file requires defining CDC constraints (such as cdc_false_path, quasi_static), while DC's SDC file focuses on timing path optimization. Although their syntax is similar, their goals differ. For example, regarding the code "false_path," a CDC constraint indicates ignoring CDC checks, while a DC constraint indicates ignoring timing analysis. If this statement from a DC constraint is directly reused in a CDC constraint, it will mask CDC vulnerabilities. SpyGlass requires explicitly specifying the black-box port clock domain (abstract_port), while DC does not require this constraint. Furthermore, the conversion between CDC and DC constraint files relies on manual constraint conversion, which is prone to errors. For example, quasi-static signals need to be marked in CDC to avoid false alarms, but there is no equivalent constraint in DC. The clock path of the multiplexer (MUX) needs to be constrained by set_case_analysis; failure to define it in SpyGlass will result in a CDC violation.

[0036] Furthermore, both the CDC constraint file and the DC constraint file include clock constraints, clock group constraints, and confirm clock synchronization / asynchronous relationships, as well as IO constraints. Among them, the CDC constraints require IO constraints to specify the clock domain for the port, while the DC constraints require IO constraints for timing optimization.

[0037] To address the shortcomings in related technologies, this disclosure provides a code verification method applied to RTL code verification. This method can convert CDC constraint files and DC constraint files, ensuring the consistency of the two sets of constraint files. The conversion is performed automatically, reducing manual intervention and improving work efficiency.

[0038] Figure 1 A schematic diagram of an optional flowchart of the code verification method provided in this disclosure is shown, and the steps will be described accordingly.

[0039] Step S101: Generate a general design constraint file based on the basic design information.

[0040] In some embodiments, the basic design information of the RTL code may include at least one of clock information, clock grouping information, reset information, input / output (I / O) information, static signals, and timing exception information.

[0041] The basic design information includes information contained in both the DC constraint file and the CDC constraint file.

[0042] In some embodiments, the general design constraint file includes at least one of clock constraint code, clock grouping constraint code, and input / output constraint code.

[0043] The carrier can be computer programs, electronic circuits, databases, mobile applications, electronic devices, cloud computing platforms, distributed systems, artificial intelligence frameworks, mathematical models, automation tools, and microcontrollers, etc., which are software or hardware capable of implementing algorithms and methods.

[0044] Step S102: Generate the first CDC constraint file based on the general design constraint file and CDC constraint conditions.

[0045] In some embodiments, the carrier implementing the code verification method (hereinafter referred to as the carrier) determines reset constraint code and static signal constraint code based on the CDC constraint conditions. Further, the reset constraint code and static signal constraint code are added to the general design constraint file to obtain a first CDC constraint file.

[0046] Step S103: Generate the first DC constraint file based on the general design constraint file and DC constraint conditions.

[0047] In some embodiments, the carrier determines at least one of pseudo-path constraint code, clock exception constraint code, static signal constraint code, and multi-cycle path constraint code based on DC constraint conditions; and adds at least one of the pseudo-path constraint code, clock exception constraint code, static signal constraint code, and multi-cycle path constraint code to the general design constraint file to obtain a first DC constraint file.

[0048] Step S104: Based on the first CDC constraint file and the transformation table, determine the second DC constraint file, and based on the first DC constraint file and the second DC constraint file, determine the target DC constraint file.

[0049] In some embodiments, the carrier identifies at least one target CDC constraint code included in the CDC constraint file but not included in the DC constraint file; the at least one target CDC constraint code is converted into a DC constraint code based on a transformation table to obtain a second DC constraint code. The DC constraint code includes constraint codes that the DC constraint file can understand.

[0050] In specific implementation, the carrier can convert the CDC-specific constraint code into DC-specific constraint code based on the transformation table; for example, marking the quasi_static code as the dont_touch attribute in SDC to avoid synthesis optimization from destroying the quasi-static characteristics; and / or, converting the synchronizer constraint code into a retime-prohibited constraint code based on the transformation table, for example, converting the synchronizer constraint code sync_cell into the dont_retime constraint code in DC.

[0051] In some embodiments, the target DC constraint file includes a general design constraint file, a constraint file corresponding to the DC constraint conditions, and a second DC constraint file converted from the CDC constraint file.

[0052] Step S105: Based on the first DC constraint file and the transformation table, determine the second CDC constraint file, and based on the first CDC constraint file and the second CDC constraint file, determine the target CDC constraint file.

[0053] In some embodiments, the carrier determines the target DC constraint code that is included in the DC constraint file but not in the CDC constraint file.

[0054] In some embodiments, the carrier converts the at least one target DC constraint code into at least one CDC constraint code based on the conversion table; and determines that the at least one CDC constraint code constitutes the second CDC constraint file.

[0055] In specific implementation, the carrier will infer the clock domain for the black-box output port by using the set_false_path code in the DC constraint file, the cdc_false_path code, and / or the clock domain for the black-box output port, and generate abstract_port.

[0056] In some embodiments, the target CDC constraint file includes a general design constraint file, a constraint file corresponding to the CDC constraint conditions, and a second CDC constraint file obtained by converting the DC constraint file.

[0057] Step S106: Verify the target code based on the target DC constraint file and the target CDC constraint file respectively, and obtain the verification result of the target code.

[0058] In some embodiments, the carrier performs DC logic synthesis verification on the target code based on the target DC constraint file to obtain a first verification result; and performs SpyGlass code inspection verification on the target code based on the target CDC constraint file to obtain a second verification result.

[0059] If no violation information is found in either the first verification result or the second verification result, the target code is determined to have passed verification. Alternatively, if at least one violation information is found in either the first verification result or the second verification result, the constraint file corresponding to the violation information is determined, and the constraint file is updated. The specific steps for updating the constraint file will be described later.

[0060] This enables automatic consistency conversion between SpyGlass's CDC and DC logic synthesis's SDC. It eliminates the need for manual writing and maintenance of two separate constraint files, significantly reducing workload and improving design efficiency. Automatic mapping and completion between the two types of constraints effectively ensures constraint consistency and avoids deviations in checking and synthesis results caused by inconsistencies. Constraints are updated bidirectionally and synchronously with a single modification, eliminating omissions and errors from manual maintenance and improving the stability and reliability of the chip design process.

[0061] Figure 2 This illustration shows another optional flowchart of the code verification method provided in this disclosure, which will be described step by step.

[0062] Step S201: Determine the constraint file corresponding to the violation information.

[0063] In some embodiments, in response to the inclusion of at least one violation information in the first verification result and / or the second verification result, the constraint file that caused the at least one violation information is determined. Specifically, if the first verification result includes violation information, the constraint file corresponding to the violation information is determined to be the target DC constraint file; if the second verification result includes violation information, the constraint file corresponding to the violation information is determined to be the target CDC constraint file.

[0064] In specific implementation, if the second verification result includes aggregation conflict (AC_conv01 / 02 / 03) or glitch risk (AC_glitch03), then the constraint file corresponding to the violation information is determined to be the target CDC constraint file.

[0065] Alternatively, in specific implementation, if the first verification result includes an overlap between the timing violation path and the CDC marker path, then the constraint file corresponding to the violation information is determined to be the target CDC constraint file; when updating the target CDC constraint file subsequently, the cdc_filter_coherency code in the target CDC constraint file can be updated.

[0066] Step S202: Optimize the constraint file corresponding to the violation information, regenerate the target CDC constraint file and the target DC constraint file, and verify the target code again.

[0067] In some embodiments, in response to the constraint file corresponding to the violation information being a general design constraint file, the basic design information is updated, and steps S101 to S106 are repeated to generate an updated design constraint file based on the updated basic design information; the first CDC constraint file is updated based on the updated design constraint file and CDC constraint conditions; and the first DC constraint file is updated based on the updated design constraint file and DC constraint conditions.

[0068] Based on the updated first CDC constraint file and the transformation table, an updated second DC constraint file is determined; based on the updated first DC constraint file and the updated second DC constraint file, an updated target DC constraint file is determined. Based on the updated first DC constraint file and the transformation table, an updated second CDC constraint file is determined; based on the updated first CDC constraint file and the updated second CDC constraint file, an updated target CDC constraint file is determined. The target code is then verified based on both the updated target DC constraint file and the updated target CDC constraint file to obtain the verification results of the target code.

[0069] If the verification result of the target code includes violation information, then steps S201 to S202 are repeated; if the verification result of the target code does not include violation information, then the target code is determined to have passed verification.

[0070] In other embodiments, in response to the constraint file corresponding to the violation information being a target CDC constraint file, the general design constraint file and the first DC constraint file remain unchanged. The CDC constraints are updated, and the updated first CDC constraint file is determined based on the CDC constraints and the general design constraint file. The updated second DC constraint file is determined based on the updated first CDC constraint file and the transformation table. The updated target CDC constraint file is determined based on the updated first CDC constraint file and the second CDC constraint file. The updated target DC constraint file is determined based on the first DC constraint file and the updated second DC constraint file. The target code is then verified based on both the updated target DC constraint file and the updated target CDC constraint file to obtain the verification result of the target code.

[0071] In some embodiments, in response to the constraint file corresponding to the violation information being a target DC constraint file, the general design constraint file and the first CDC constraint file remain unchanged. The CDC constraint conditions are updated, and the updated first DC constraint file is determined based on the DC constraint conditions and the general design constraint file. The updated second CDC constraint file is determined based on the updated first DC constraint file and the transformation table. The updated target DC constraint file is determined based on the updated first DC constraint file and the second DC constraint file. The updated target CDC constraint file is determined based on the first CDC constraint file and the updated second CDC constraint file. The target code is then verified based on both the updated target DC constraint file and the updated target CDC constraint file to obtain the verification result of the target code.

[0072] In the above scheme, if the verification result of the target code includes violation information, then steps S201 to S202 are repeated; if the verification result of the target code does not include violation information, then the target code is determined to have passed the verification.

[0073] In some embodiments, if the constraint file corresponding to the violation information is a target CDC constraint file or a target DC constraint file, then after updating the CDC constraint conditions or DC constraint conditions and generating the corresponding constraint file, a consistency conversion verification will be performed and mapped to the corresponding constraint file.

[0074] Figure 3 A schematic diagram of the consistency conversion verification process provided in an embodiment of this disclosure is shown.

[0075] Taking the constraint file corresponding to the violation information as the target CDC constraint file, and taking the need to update the CDC constraints as an example, combined with... Figure 3 Please provide an explanation.

[0076] After updating the CDC constraints, the updated first CDC constraint file is obtained. This file, along with the first DC constraint file, undergoes semantic parsing and transformation according to a transformation table, yielding the updated second DC constraint file and the second CDC constraint file, respectively. Combining the updated first and second CDC constraint files, the updated target CDC constraint file is obtained. Finally, combining the first and updated second DC constraint files, the updated DC constraint file is obtained.

[0077] The conversion table may include a DC constraint code to CDC constraint code conversion table, used to convert DC constraint codes into corresponding CDC constraint codes; it may also include a CDC constraint code to DC constraint code conversion table, used to convert CDC constraint codes into corresponding DC constraint codes.

[0078] In practice, the consistency conversion verification performs semantic parsing on the input constraint files (at least one of CDC constraint files and DC constraint files) to distinguish between the two types. Based on the constraint type, it matches a preset conversion table to complete the lookup conversion of constraint syntax and semantics, generating new constraint code. At the same time, it retains the original information in the original constraint file, such as the module hierarchy, port mapping, and timing associations, and reconstructs and writes new constraints according to the corresponding tool syntax rules and completes the output.

[0079] For example, the quasi-static signal constraint quasi_static in the CDC constraint file can be mapped to the corresponding prohibition of optimization constraint dont_touch in the DC constraint file through a transformation table. All quasi_static constraint statements in the CDC constraint file are extracted by traversing and extracting them. The equivalent code dont_touch in the DC constraint file is obtained by searching the transformation table. Then, the design hierarchy structure and target information corresponding to the original constraint are inherited. Finally, a transformed DC constraint file that is syntactically compliant, hierarchically matched, and semantically consistent is generated.

[0080] This enables automatic consistency conversion between SpyGlass's CDC and DC logic synthesis's SDC. It eliminates the need for manual writing and maintenance of two separate constraint files, significantly reducing workload and improving design efficiency. Automatic mapping and completion between the two types of constraints effectively ensures constraint consistency and avoids deviations in checking and synthesis results caused by inconsistencies. Constraints are updated bidirectionally and synchronously with a single modification, eliminating omissions and errors from manual maintenance and improving the stability and reliability of the chip design process.

[0081] Figure 4 A schematic diagram of an optional structure of the code verification apparatus provided in an embodiment of this disclosure is shown, and the steps will be described accordingly.

[0082] In some embodiments, the code verification device includes a general file generation unit, a CDC constraint file generation unit, a DC constraint file generation unit, and a verification unit.

[0083] The general file generation unit is used to generate a general design constraint file based on basic design information; The CDC constraint file generation unit is used to generate a first CDC constraint file based on a general design constraint file and cross-clock domain verification CDC constraints. The DC constraint file generation unit is used to generate a first DC constraint file based on the general design constraint file and the DC constraint conditions of the design compiler. The DC constraint file generation unit is further configured to determine a second DC constraint file based on the first CDC constraint file and the transformation table, and to determine a target DC constraint file based on the first DC constraint file and the second DC constraint file. The CDC constraint file generation unit is further configured to determine a second CDC constraint file based on the first CDC constraint file and the transformation table, and to determine a target CDC constraint file based on the first CDC constraint file and the second CDC constraint file; The verification unit is used to verify the target code based on the target DC constraint file and the target CDC constraint file respectively, and obtain the verification result of the target code.

[0084] The verification unit is further configured to, in response to the verification result including violation information, determine the constraint file corresponding to the violation information; If the constraint file corresponding to the violation information is the target CDC constraint file, then the CDC constraint condition is updated. Based on the general design constraint file, the updated CDC constraint condition, and the DC constraint file, the updated CDC constraint file and the updated DC constraint file are determined. Based on the updated CDC constraint file and the updated DC constraint file, the target code is verified again. If the constraint file corresponding to the violation information is the target DC constraint file, then the DC constraint condition is updated. Based on the general design constraint file, the updated DC constraint condition, and the CDC constraint file, the updated CDC constraint file and the updated DC constraint file are determined. Based on the updated CDC constraint file and the updated DC constraint file, the target code is verified again.

[0085] The general file generation unit is also used to determine a general design constraint file based on at least one of the clock information, clock grouping information, reset information and input / output information included in the basic design information; The general design constraint file includes at least one of clock constraint code, clock grouping constraint code, and input / output constraint code.

[0086] The CDC constraint file generation unit is specifically used to determine the reset constraint code and the static signal constraint code based on the CDC constraint conditions. The first CDC constraint file is generated based on the general design constraint file, reset constraint code, and static signal constraint code.

[0087] The DC constraint file generation unit is specifically used to determine at least one of the pseudo-path constraint code, clock exception constraint code, static signal constraint code, and multi-cycle path constraint code based on the DC constraint conditions. The first DC constraint file is generated based on the general design constraint file and at least one of the pseudo path constraint code, clock exception constraint code, static signal constraint code, and multi-cycle path constraint code.

[0088] In some embodiments, the conversion table includes a correspondence between CDC constraint file syntax and DC constraint file syntax, and the DC constraint file generation unit is specifically used for... Obtain at least one target CDC constraint code from the first CDC constraint file; Based on the transformation table, the at least one target CDC constraint code is converted into at least one DC constraint code; Determine that the at least one DC constraint code constitutes the second DC constraint file; The target CDC constraint code includes constraint codes contained in the CDC constraint file but not in the DC constraint file.

[0089] In some embodiments, the at least one target CDC constraint code includes CDC-specific constraint code and synchronizer constraint code; the DC constraint file generation unit is specifically used for at least one of the following: Convert the CDC-specific constraint code into a DC-specific constraint code based on the transformation table; The synchronizer constraint code is converted into a retiming-prohibited constraint code based on the transformation table.

[0090] The DC constraint file generation unit is specifically used to determine that the first DC constraint file and the second DC constraint file constitute the target DC constraint file.

[0091] In some embodiments, the conversion table includes a correspondence between CDC constraint file syntax and DC constraint file syntax, and the CDC constraint file generation unit is specifically used to obtain at least one target DC constraint code in the first DC constraint file; Based on the transformation table, the at least one target DC constraint code is converted into at least one CDC constraint code; The at least one CDC constraint code is determined to constitute the second CDC constraint file; The target DC constraint code includes constraint codes that are included in the DC constraint file but not in the CDC constraint file.

[0092] In some embodiments, the at least one target DC constraint code includes pseudo-path constraint code, and the CDC constraint file generation unit is specifically used to convert the pseudo-path constraint code of the DC constraint file syntax into the pseudo-path constraint code corresponding to the CDC constraint file syntax based on the transformation table. The abstract port constraint code corresponding to the CDC constraint file syntax is determined based on the black-box port clock domain and the aforementioned conversion table. The second CDC constraint file is determined based on the pseudo-path constraint code corresponding to the CDC constraint file syntax and the abstract port constraint code corresponding to the CDC constraint file syntax.

[0093] The CDC constraint file generation unit is specifically used to determine that the first CDC constraint file and the second CDC constraint file constitute the target CDC constraint file.

[0094] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0095] Figure 5 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0096] like Figure 5 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0097] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0098] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as code verification methods. For example, in some embodiments, the code verification method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the code verification method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform code verification methods by any other suitable means (e.g., by means of firmware).

[0099] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0100] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0101] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0102] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0103] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0104] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0105] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0106] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A code verification method characterized by, The method includes: Generate a general design constraint file based on basic design information; Based on the general design constraint file and cross-clock domain verification of CDC constraints, the first CDC constraint file is generated. Based on the general design constraint file and the DC constraint conditions of the design compiler, the first DC constraint file is generated; Based on the first CDC constraint file and the transformation table, a second DC constraint file is determined, and based on the first DC constraint file and the second DC constraint file, a target DC constraint file is determined. Based on the first DC constraint file and the transformation table, a second CDC constraint file is determined, and based on the first CDC constraint file and the second CDC constraint file, a target CDC constraint file is determined. The target code is verified based on the target DC constraint file and the target CDC constraint file respectively, and the verification result of the target code is obtained.

2. The method of claim 1, wherein, The method further includes: If the verification result includes violation information, then the constraint file corresponding to the violation information is determined; If the constraint file corresponding to the violation information is the target CDC constraint file, then the CDC constraint condition is updated. Based on the general design constraint file, the updated CDC constraint condition, and the DC constraint file, the updated CDC constraint file and the updated DC constraint file are determined. Based on the updated CDC constraint file and the updated DC constraint file, the target code is verified again. If the constraint file corresponding to the violation information is the target DC constraint file, then the DC constraint condition is updated. Based on the general design constraint file, the updated DC constraint condition, and the CDC constraint file, the updated CDC constraint file and the updated DC constraint file are determined. Based on the updated CDC constraint file and the updated DC constraint file, the target code is verified again.

3. The method of claim 1, wherein, The generation of a general design constraint file based on basic design information includes: Based on at least one of the clock information, clock grouping information, reset information, and input / output information included in the basic design information, a general design constraint file is determined; The general design constraint file includes at least one of clock constraint code, clock grouping constraint code, and input / output constraint code.

4. The method of claim 1, wherein, The process of generating a first CDC constraint file based on a general design constraint file and cross-clock domain verification of CDC constraints includes: Determine the reset constraint code and static signal constraint code based on the CDC constraint conditions; The first CDC constraint file is generated based on the general design constraint file, reset constraint code, and static signal constraint code.

5. The method according to claim 1, characterized in that, The generation of the first DC constraint file based on the general design constraint file and the DC constraint conditions of the design compiler includes: Determine at least one of the following based on DC constraints: pseudo-path constraint code, clock exception constraint code, static signal constraint code, and multi-cycle path constraint code; The first DC constraint file is generated based on the general design constraint file and at least one of the pseudo path constraint code, clock exception constraint code, static signal constraint code, and multi-cycle path constraint code.

6. The method according to claim 1, characterized in that, The transformation table includes the correspondence between CDC constraint file syntax and DC constraint file syntax. The step of determining the second DC constraint file based on the first CDC constraint file and the transformation table includes: Obtain at least one target CDC constraint code from the first CDC constraint file; Based on the transformation table, the at least one target CDC constraint code is converted into at least one DC constraint code; Determine that the at least one DC constraint code constitutes the second DC constraint file; The target CDC constraint code includes constraint codes contained in the CDC constraint file but not in the DC constraint file.

7. The method according to claim 6, characterized in that, The at least one target CDC constraint code includes a CDC-specific constraint code and a synchronizer constraint code; the conversion of the at least one target CDC constraint code to at least one DC constraint code based on the conversion table includes at least one of the following: Convert the CDC-specific constraint code into a DC-specific constraint code based on the transformation table; The synchronizer constraint code is converted into a retiming-prohibited constraint code based on the transformation table.

8. The method according to claim 6, characterized in that, The step of determining the target DC constraint file based on the first DC constraint file and the second DC constraint file includes: The first DC constraint file and the second DC constraint file are determined to constitute the target DC constraint file.

9. The method according to claim 1, characterized in that, The transformation table includes the correspondence between CDC constraint file syntax and DC constraint file syntax. The step of determining the second CDC constraint file based on the first DC constraint file and the transformation table includes: Obtain at least one target DC constraint code from the first DC constraint file; Based on the transformation table, the at least one target DC constraint code is converted into at least one CDC constraint code; The at least one CDC constraint code is determined to constitute the second CDC constraint file; The target DC constraint code includes constraint codes that are included in the DC constraint file but not in the CDC constraint file.

10. The method according to claim 9, characterized in that, The at least one target DC constraint code includes a pseudo-path constraint code, and the conversion of the at least one target DC constraint code into at least one CDC constraint code based on the transformation table includes: The pseudo-path constraint code of the DC constraint file syntax is converted into the pseudo-path constraint code corresponding to the CDC constraint file syntax based on the transformation table. The abstract port constraint code corresponding to the CDC constraint file syntax is determined based on the black-box port clock domain and the aforementioned conversion table. The second CDC constraint file is determined based on the pseudo-path constraint code corresponding to the CDC constraint file syntax and the abstract port constraint code corresponding to the CDC constraint file syntax.

11. The method according to claim 9, characterized in that, The step of determining the target CDC constraint file based on the first CDC constraint file and the second CDC constraint file includes: The first CDC constraint file and the second CDC constraint file are determined to constitute the target CDC constraint file.

12. A code verification device, characterized in that, The device includes: A general document generation unit is used to generate general design constraint documents based on basic design information. The CDC constraint file generation unit is used to generate the first CDC constraint file based on the general design constraint file and the cross-clock domain verified CDC constraint conditions. The DC constraint file generation unit is used to generate the first DC constraint file based on the general design constraint file and the DC constraint conditions of the design compiler. The DC constraint file generation unit is further configured to determine a second DC constraint file based on the first CDC constraint file and the transformation table, and to determine a target DC constraint file based on the first DC constraint file and the second DC constraint file. The CDC constraint file generation unit is further configured to determine a second CDC constraint file based on the first CDC constraint file and the transformation table, and to determine a target CDC constraint file based on the first CDC constraint file and the second CDC constraint file; The verification unit is used to verify the target code based on the target DC constraint file and the target CDC constraint file respectively, and obtain the verification result of the target code.

13. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-11.

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

15. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-11.

Images