Dynamic cdc verification method

Abstract

This invention discloses a method for dynamically verifying computer implementations of cross-clock domain (CDC) paths in register-transfer-level (RTL) designs. In addition to static analysis, formal analysis, and simulation steps, each CDC path is assigned a permanently unique identifier. This allows the use of this permanently unique identifier to update a centralized results database to tag associated CDC protocol assertions, functional coverage, and formal analysis and simulation results. Furthermore, prior to simulation analysis, CDC protocol assertions that have been verified during formal analysis are disabled, so that simulation runs are performed only for unverified CDC protocol assertions.

Description

Technical Field

[0001] This invention relates to a method for dynamic cross-clock domain (CDC) verification, and more particularly to a dynamic cross-clock domain verification method based on static cross-clock domain analysis and employing formal analysis and simulation. Background Technology

[0002] Digital circuit design typically employs hardware description languages ​​to create high-level representations of circuits. Synchronous digital circuits can use a design abstraction called Register Transfer Level (RTL) to model the flow of digital signals between hardware registers. Each hardware register is triggered by the edge of a clock signal, synchronizing the output of each register with its clock signal. A Clock Domain Crossing (CDC) path is a path in an RTL design between a source register and a destination register that enables CDC signal transmission, where the clocks of the source register and the destination register are asynchronous. When two clocks are asynchronous, there is no deterministic phase relationship between them. Due to this asynchrony, the source register may generate asynchronous signals that violate the set and hold requirements of the destination register, causing the destination register to enter a metastable state. Traditionally, this problem is addressed using synchronous logic structures (synchronizers), which are RTL structures added to the CDC path to prevent metastable events from propagating to downstream logic. While adding a synchronizer to the CDC path eliminates some metastability in the structure, it is insufficient on its own to ensure reliable transmission of CDC signals. Each synchronizer relies on a set of assumptions or protocols, and violating these assumptions or protocols can lead to data loss or corruption, or, in the worst case, allow metastable states to propagate to downstream logic—precisely what designers are trying to avoid. These events ultimately cause functional failures in RTL designs.

[0003] To avoid these problems, two processes are used: static CDC verification and dynamic CDC verification. As the names suggest, static CDC verification uses static structural analysis techniques to determine the correct synchronization structure of a digital circuit without requiring full-circuit simulation. On the other hand, dynamic CDC verification uses full-circuit simulation and / or formal simulation analysis of the full circuit to determine whether a protocol violation will occur when certain synchronizers are used. This is accomplished by generating an assertion against the synchronizer protocol and verifying that assertion in either a formal or simulation environment.

[0004] Figure 1 This illustrates data loss in a synchronizer employing two triggers (DFFs) due to a protocol violation. Figure 1The code illustrates the source register Tx, the destination register Rx, and the resulting synchronization signal Rxsync. The source clock Txclock provides the signal to the source register, while the destination clock Rxclock provides the signal to both the destination register and the synchronization signal. Initially, the source register Tx sends a single square wave at time t = t. Simultaneously, the destination register clock Rxclock sends a clock signal with a frequency of 0.5. The protocol used is NUM_CYCLES = 2, and as shown in the following code, this protocol is violated, resulting in the Tx signal transmitted to the destination register Rx at time t = t being corrupted, and no synchronization signal existing on Rxsync: `property data_stable_prop(data,clock,reset,arrest,NUM_CYCLES):`

[0005] @(posedge clock)disable iff(areset)

[0006] ##1! reset&&$changed(data)|=>$stable(data)[*(NUM_CYCLES-1)];

[0007] endproperty

[0008] Figure 2 A typical assertion-based verification method for verifying synchronizer protocols is illustrated. Static CDC analysis 2 is used to evaluate RTL design 1 to analyze the CDC paths and synchronizer structure used for signal transfer between registers, and CDC protocol assertions 3 are generated for each CDC path. In formal analysis environment 4, data from RTL design 1 is input along with CDC protocol assertions 3, and formal constraints 5 (such as clock, reset, and constant constraints) are added to run the analysis and display any violations of the protocol 6. In simulation environment 7, data from RTL design 1 and test bench data 8 are input along with CDC protocol assertions 3 to simulate the entire digital circuit to identify and display violations of the protocol 9.

[0009] However, using these three systems is complex and time-consuming because CDC constraints and instructions need to be translated to each environment, requiring significant time and effort to set up the RTL design for both formal and simulation runs. Debugging the results from both environments is also cumbersome, as results must be reviewed in three environments (since formal and simulation environments differ from static CDC analysis), and any debugging work needs to be done in each. Using inaccurate constraints can lead to numerous false firings (where protocol assertions are incorrectly violated); for example, an error in specifying the clock frequency can cause incorrect design behavior. Correlating formal and simulation results back to the static CDC analysis is tricky because there is no correlation between the results in each environment. Manual correlation is time-consuming due to the complexity of the various synchronizers involved, such as FIFO (First-In-First-Out) and handshake, where each synchronizer has multiple assertions that are treated as separate entities in the formal and simulation environments but correlated back to a single CDC path. While it may seem that using both formal and simulation environments together would be beneficial for users, a certain amount of redundancy and routine workload can result when assertions proven in formal analysis are unnecessarily re-verified in simulation.

[0010] Formal analysis itself requires specialized techniques. Formal simulation checks of assertion protocols will produce three types of results:

[0011] Confirmation: All events confirm the assertion—proving using an exhaustive algorithm that the assertion cannot be violated;

[0012] Violation: The assertion is violated - show a formal counterexample of the set of stimuli that violated the assertion, illustrated by generating a waveform showing the stimuli in question;

[0013] Undetermined: Formal analysis cannot generate proofs or detect violations—for example, the design may be too large, the assertions too difficult to solve, there may be a lack of computing resources, or there may be deficiencies in the formal algorithm.

[0014] A formal environment also requires designers to specify formal setting constraints, including design configuration information, clock information, and input port information. This information includes constants specifying the configuration of ports and registers, clock constraints and frequencies, and constraints on the main input ports and their associated clock frequencies. Without such a formal environment, any formal model checking operates unconstrained, without any constraints describing the legal and illegal stimuli of the design. This leads to false assertion violations based on illegal stimuli and inconclusive results. The lack of any assertion constraints describing legal and illegal stimuli increases the logic state space of the formal simulation checking analysis. With a large state space, formal analysis comparisons become difficult to focus on generating confirmatory or counterexamples. Overcoming these difficulties requires time and the use of advanced formal analysis techniques, both of which may be unavailable to designers. Summary of the Invention

[0015] The present invention aims to address these problems by providing, in a first aspect, a method for dynamically verifying a computer implementation of a cross-clock domain (CDC) path in a register-transfer-level (RTL) design, the method comprising:

[0016] Extract information about the presence of structures in the CDC path and any associated CDC protocol assertions and functional coverage from the CDC static analysis database;

[0017] Bundle CDC protocol assertions and functional coverage into the RTL design in the bundled file;

[0018] Generate formal analysis files and simulation setup files from RTL design, generate setup and constraint data for CDC paths extracted from a static CDC analysis database, and use the generated formal analysis and simulation setup files to compile bundled files;

[0019] Perform formal analysis of the RTL design to determine proven and unproven CDC protocol assertions;

[0020] Update the simulation settings file to disable proven CDC protocol assertions;

[0021] Use unproven protocol assertions and functional coverage to run simulations of RTL designs;

[0022] The centralized results database is updated using formal analysis and simulation results from RTL design; and

[0023] Generate visualizations of formal analysis results and simulation results for review and debugging purposes;

[0024] Each CDC path is assigned a permanent unique identifier, which is then used to update the centralized results database to tag associated CDC protocol assertions, functional coverage, and formal analysis and simulation results.

[0025] Unlike existing systems, embodiments of this invention provide designers with the ability to simultaneously visualize results from all three analysis environments, and to modify the RTL code without affecting the consistency of this visualization. By disabling verified CDC protocol assertions in the simulation setup file after formal analysis, a significant reduction in simulation time is achieved compared to existing CDC protocol assertion verification methods. Furthermore, when using embodiments of this invention, the coverage of CDC protocol assertion verification is higher than that of existing methods.

[0026] Preferably, the CDC path information includes at least one text string, wherein the permanently unique identifier is a numeric string generated from the text string. Preferably, the numeric string is generated by reducing the number of characters in the text string using mathematical operations. More preferably, the permanently unique identifier is added to the assertions and instance names of the functional coverage of the CDC path. Furthermore, preferably, the permanently unique identifier is added to the CDC protocol assertions associated with the structures in the CDC path.

[0027] Preferably, the structure in the CDC path is a CDC synchronizer, and the associated CDC protocol assertion is generated based on the type of CDC synchronizer.

[0028] Preferably, when a structure does not exist in the CDC path, the associated CDC protocol assertion is generated based on the non-existent structure.

[0029] Preferably, unproven CDC protocol assertions are either violated or inconclusive.

[0030] Preferably, during formal analysis, counterexamples indicating incentives that violate CDC protocol assertions are generated.

[0031] Preferably, during formal analysis, a sound waveform is generated for the verified CDC protocol assertion, indicating stimuli that do not violate the CDC protocol assertion. Preferably, visualization of the formal analysis results includes displaying this sound waveform. Preferably, visualization of both the formal analysis results and simulation results includes displaying waveforms that show stimuli that violate the CDC protocol assertion.

[0032] Preferably, the simulation parameter file and the form file include callback functions to enable updates to the centralized results database. Preferably, the simulation parameter file uses PLI (programming language interface) callback functions to capture assertion information, which includes data indicating whether the stimulus violates a CDC protocol assertion.

[0033] Preferably, the method further includes the step of updating the static CDC analysis database with the results of CDC protocol assertions and functional coverage.

[0034] Preferably, the CDC protocol assertion is a SystemVerilog assertion (SVA). Furthermore, preferably, the CDC protocol functional coverage consists of SystemVerilog coverage points and coverage groups.

[0035] Preferably, the configuration files include: simulation compilation and simulation parameter files, formal analysis compilation and execution scripts, and formal analysis constraint files.

[0036] In a second aspect, the present invention also provides a data processing system comprising a processor adapted to perform the steps of the method.

[0037] In a third aspect, the present invention also provides a computer program comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 18. Attached Figure Description

[0038] The invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0039] Figure 1 This illustrates data loss in a synchronizer employing two triggers (DFFs) due to a protocol violation;

[0040] Figure 2 A typical assertion-based verification method for verifying synchronizer protocols is shown.

[0041] Figure 3 This is a flowchart illustrating a method overview according to an embodiment of the present invention;

[0042] Figure 4 This is a schematic diagram illustrating the steps for binding CDC protocol assertions performed by embodiments of the present invention; and

[0043] Figure 5 This is a schematic diagram illustrating the steps performed by an embodiment of the present invention to generate a settings file. Detailed Implementation

[0044] Compared to existing methods in the prior art, this invention uses an identification system that traces CDC dynamic analysis, including formal model checking and simulation, through CDC static analysis and enables visualization of the results. The method of this invention dynamically verifies CDC paths in an RTL design. This requires several steps. First, information about the presence of structures in the CDC path and any associated CDC protocol assertions and functional coverage is extracted from the CDC static analysis database. Second, the CDC protocol assertions and functional coverage are bundled into the RTL design in a bundle file. This allows the generation of setup files for formal analysis and simulation from the RTL design, where the setup and constraint data for the CDC path are extracted from the static CDC analysis database. The bundle file is then compiled using the generated setup files for formal analysis and simulation. Formal analysis of the RTL design is run to identify verified and unverified CDC protocol assertions. This allows the simulation setup file to be updated to disable verified CDC protocol assertions. Simulation of the RTL design is then run using the unverified CDC protocol assertions and functional coverage. Once this occurs, the centralized results database is updated with the formal analysis and simulation results of the RTL design, and the formal analysis and simulation results are visualized for at least one of the following: review and debugging. A permanently unique identifier is assigned to each CDC path, and this permanently unique identifier is used to update the centralized results database to identify the associated CDC protocol assertions, functional coverage, and formal analysis and simulation results.

[0045] Figure 3 A top-level view of a method according to an embodiment of the present invention is shown. Figure 3This is a flowchart illustrating a method overview according to an embodiment of the present invention. As a starting point, method 100 requires that a static CDC analysis 110 has been performed at some point, or that the processing device performing method 100 has access to a static CDC analysis database 112 containing details of the CDC path, including the presence of structures such as CDC synchronizers in the CDC path, and any associated CDC protocol assertions and functional coverage. The functional coverage defines the area for simulating CDC protocol assertions, for example, the range of x regarding whether a statement about x has been made. At step 120, information regarding the presence of structures in the CDC path, any associated CDC protocol assertions, and functional coverage is extracted from the static CDC analysis database 112. At this point, at step 130, setup files for formal analysis 131 and simulation 132 are generated from the RTL design, and setup and constraint data for the RTL design are extracted from the static CDC analysis database 112. These generated formal analysis and simulation setup files are then used to compile the bundle file. Step 140 is to run a formal analysis of the RTL design to determine which protocol assertions are verified and which are not. At step 150, the simulation setup file is updated to disable verified CDC protocol assertions, leaving unverified protocol assertions to be used during the simulation phase. At step 160, the RTL simulation is run using the unverified assertions and functional coverage. At this point, at step 170, the centralized results database 171 is updated with the formal analysis results and simulation results of the RTL design. Finally, at step 180, the formal analysis results and simulation results are visualized for at least one of review and debugging. A permanently unique identifier is assigned to each CDC path, enabling the centralized results database 171 to be updated using this permanently unique identifier to tag associated CDC protocol assertions, functional coverage, and formal analysis and simulation results.

[0046] The above steps will be described in more detail below.

[0047] Assertions based on the CDC agreement

[0048] Figure 4 This is a schematic diagram illustrating the steps for binding CDC protocol assertions performed by an embodiment of the present invention. As described above, at step 120, information regarding the existence of structures in the CDC path, any associated CDC protocol assertions, and functional coverage is extracted from the static CDC analysis database 112. During this step, several actions occur, starting from the extraction of information regarding the existence of structures in the CDC path at step 121. This CDC path has been assigned a permanently unique identifier, the assignment process of which will be discussed below. Preferably, this structure is a CDC structure or scheme as shown in Table 1 below:

[0049] Table 1: Examples of CDC Structures and Schemes

[0050]

[0051] Here, "Check" indicates the module name of the CDC assertion module associated with the CDC structure, "SVA Check" indicates the CDC protocol assertion included in the CDC assertion module, and "CDC Scheme" indicates the type of scheme or structure detected on the CDC path. It's also possible that no CDC synchronizer is detected on the CDC path. In this case, a CDC protocol assertion will still be generated, but it will be a pessimistic CDC protocol assertion, indicating the absence of a CDC synchronizer on the CDC path. If the CDC structure is a CDC synchronizer, only one or zero CDC synchronizers will be detected on the CDC path.

[0052] To generate CDC protocol assertions, at step 123, the CDC structures are iterated over the entire CDC static analysis database 112. During this process, the logic of each CDC structure, in other words, all connections of the CDC protocol assertions for that CDC structure, are inferred and generated. In the case where the CDC structure is a CDC synchronizer, this process results in the complete identification of individual (or zero) CDC synchronizers and their associated CDC protocol assertions and functional coverage at step 124. At step 125, the CDC protocol assertions and their functional coverage, along with tcl callback functions, are bundled into the RTL design in the design file, allowing the formal analysis database to be updated once the run is complete.

[0053] Generate configuration file

[0054] Figure 5This is a schematic diagram of the steps performed by an embodiment of the present invention to generate a setup file. Step 130 includes generating a setup file for formal analysis and simulation. At step 131, RTL design, setup, and constraint data are extracted from the CDC static analysis database 112 to generate the setup file for formal analysis and simulation. For formal analysis, constraints are automatically generated. The CDC protocol generation utility converts CDC information for constant, stable, Grey-code signals into formal constraints and assumptions for formal verification. Additionally, input and output port clock domain information is also converted into formal constraints to improve the accuracy of formal counterexamples. Additional constraint data for formal analysis can be specified by the designer and includes information on legal (permitted) and illegal (disallowed) stimuli in the RTL design. These constraints define the legal state space of the design for proving or violating CDC assertion protocols in the legal state space; these constraints are also specified by the designer. At step 132, the information obtained from the CDC static analysis database 112 is converted into the correct format for formal analysis and simulation tools and added to the settings of the respective tools. At step 133, a setup file for formal analysis and simulation is generated based on information extracted from the CDC static analysis database 112. The setup file for formal analysis includes compilation and run scripts for performing formal analysis on the CDC protocol assertions generated in step 122, as well as a formal analysis constraint file. Furthermore, the setup file includes callback functions, preferably tcl callback functions, to allow updating the centralized results database 171 with the results of the formal analysis. The simulation setup file is a simulation compilation and simulation parameter file generated for compilation, fabrication, and simulation. Designers can use the simulation parameter file to easily include CDC protocol assertions and associated bundles into the simulation without modifying the original RTL design. At step 134, the generated setup file is used to compile the bundle files, preparing for formal analysis and simulation execution.

[0055] Excluding proven assertions

[0056] A key advantage of embodiments of the present invention over the prior art is the ability to update the simulation setup file by removing (or disabling) CDC protocol assertions that have been verified in the formal analysis. To achieve this, a formal analysis is first run at step 140, which produces multiple verified CDC protocol assertions and multiple unverified assertions. The formal analysis results are iterated to identify the verified assertions. The formal proof is exhaustive, and it is determined that the CDC protocol assertions will not be violated. Sound waveforms can be generated for the verified CDC protocol assertions to indicate stimuli that do not violate the CDC protocol assertions. However, if a violation occurs, counterexamples indicating the stimuli that caused the violation are generated. Waveforms indicating stimuli that violate the CDC protocol assertions can also be generated. At the end of the formal analysis run, a tcl callback function generates a CDC protocol assertion exclusion file. Once the verified assertions are identified, the simulation setup file is updated at step 150 to disable the verified assertions, as they will not be violated in the simulation. For CDC protocol assertions that use SystemVerilog (SV) as the programming language, use the `$assertoff` command to disable verified CDC protocol assertions. Removing verified CDC protocol assertions will reduce simulation runtime in the next step of the method. An example of disabling four CDC protocol assertions is shown:

[0057] $assertoff(0,cdc_protocol.fifo_2332.cdc_fifo_wr_ptr_hamming_check.assert_hamming);

[0058] $assertoff(0,cdc_protocol.fifo_2332.cdc_fifo_rd_ptr_hamming_check.assert_hamming);

[0059] $assertoff(0,cdc_protocol.bus_two_diff_4271.cdc_hamming_check.assert_hamming);

[0060] $assertoff(0,cdc_protocol.two_diff_68078.cdc_sync_stable_check.assert_stable);

[0061] Capture Results

[0062] The results of the formal analysis run are captured in the database at the end of the run, ensuring that CDC protocol assertions and functional coverage results are logged. A PLI callback routine is included in the simulation setup file, and at step 161, CDC protocol assertions and functional coverage results are captured from the simulation run by appending data to the existing CDC static analysis database 112 during the simulation run.

[0063] Update results

[0064] The results update step occurs at the end of the formal analysis and simulation run using information provided in the setup file. Based on either a TCL callback step or a PLI callback step, the formal analysis results or simulation results are parsed to update the centralized results database 171 with relevant information using a permanently unique identifier assigned to the CDC path in the CDC static analysis database. An example of this correlation is shown in Table 2 below:

[0065] Table 2: CDC Protocol Assertion Results After Formal Analysis and Simulation Examples

[0066]

[0067] The CDC ID is the name of the CDC structure, in this case, the CDC synchronizer type plus a permanently unique identifier. The protocol ID indicates the CDC protocol assertion, plus a permanently unique identifier. The formal result is the result of the formal analysis of the CDC protocol assertion and is either proven or unproven. The two unproven states are "excited," where the CDC protocol assertion has been violated, and "inconclusive," where it is impossible to provide proof in the design state space for a particular constraint. Simulation results produce four distinct outcomes: the CDC protocol assertion is excited (violated), covered (the simulation has shown that the CDC protocol assertion remains true and is fully run by the same stimulus), evaluated (the simulation has shown that the CDC protocol assertion remains true and is partially run by the same stimulus), and not evaluated (the simulation has shown that the CDC protocol assertion remains true and is not run by the same stimulus).

[0068] Permanent unique identifier

[0069] A key aspect of this invention is the use of permanently unique identifiers. Typically, CDC path information includes at least one text string, such as a handshake. Preferably, the permanently unique identifier is a numeric string generated from the text string. This numeric string is typically generated by reducing the number of characters in the text string using mathematical operations. For example, a hash of the characters in the text string can be created, as this reduces the number of characters in the text string and provides a unique identifier. The permanently unique identifier is added to the assertion and functional coverage instance names of the CDC path, and preferably to the CDC protocol assertions associated with the structures in the CDC path. By ensuring that everything is tagged with permanently unique identifiers, it becomes possible to update and correlate results across all three environments (CDC static analysis, formal analysis, and simulation).

[0070] Unique identifiers need to be permanent to ensure accuracy and traceability during analysis. An initial unique identifier is assigned to the CDC path. If the supporting RTL design code changes at some point during the design phase, this change will not affect the unique identifier as long as the structure of the CDC path remains unchanged. For example, if it is decided to modify the structure of the CDC path, the unique identifier is no longer permanent because it will change due to the changes within the CDC path. Therefore, changes to the code, or changes around but not affecting the CDC path, will not affect the unique identifier, thus making the unique identifier permanent.

[0071] Results visualization

[0072] exist Figure 3 At the end of the process outlined above, visualizations of the formal analysis and simulation results are generated. This allows designers to review the results or debug the code used in the process. One way to do this is to generate text files, displays, or documents similar to those in Table 2 above, enabling designers to review the results. Alternatively, healthy waveforms generated during formal analysis to indicate stimuli that do not violate the CDC protocol and are therefore confirmed can be displayed as part of the visualization. Furthermore, waveforms can be generated as counterexamples showing stimuli that do indeed violate the CDC protocol assertions.

[0073] To illustrate the embodiments of the invention described above, the verification method was tested on a practical design and compared with the same tests performed using existing formal analysis and simulation techniques. Three RTL designs were tested: Design A, Design B, and Design C, each with 10 million to 30 million gates.

[0074] Tables 3a and 3b show comparative examples. Formal analysis and simulation verification of a given number of CDC protocol assertions were performed using traditional CDC protocol assertion verification methods, employing QuestaCDC, Questa PropCheck, and Questa Simulation respectively.

[0075] Table 3a

[0076]

[0077] Table 3b

[0078]

[0079]

[0080] Tables 4a and 4b show examples of using the methods according to embodiments of the present invention:

[0081] Table 4a

[0082]

[0083] Table 4b

[0084]

[0085] In the comparative examples and embodiments using the invention, the form coverage is given by the following formula:

[0086] ((failure assertions + overriding assertions) / total assertions) * 100

[0087] For the comparison example, the simulation coverage is given by the following formula:

[0088] ((failure assertions + overriding assertions) / total assertions) * 100

[0089] For examples using embodiments of the present invention, the simulation coverage is given by the following formula:

[0090] ((Failure assertions + Overriding assertions + Confirmation assertions) / Total assertions)) * 100

[0091] Compared to conventional verification methods, embodiments of the present invention offer numerous improvements. A significant reduction in formal analysis setup time was observed due to automation of setup generation and a reduction in incremental debugging iterations for incomplete and incorrect setups. Furthermore, setup time for simulation was also reduced. This is again due to automation of setup generation and a reduction in incremental debugging iterations for incomplete and incorrect setups. Automated setup generation and the introduction of CDC design constraints into formal analysis reduce formal setup errors and consequently reduce error triggering (i.e., erroneous violations of CDC protocol assertions). Improved formal setup and constraints also result in fewer indeterminate CDC protocol assertions and more confirmed and violated assertions. Removing confirmed CDC protocol assertions from simulation results in a higher percentage of triggered and covered simulation CDC protocol assertions. Since confirmed CDC protocol assertions are not simulated in the examples employing embodiments of the present invention, they are considered covered to maintain consistency in simulation coverage between conventional and inventive methods. The reduced number of CDC protocol assertions passed to simulation due to the exclusion of formally confirmed CDC protocol assertions reduces the verification effort required to review confirmed CDC protocol assertions in simulation. The correlation between structural CDC analysis, formal verification, and simulation results improves debugging productivity and makes it easier to correlate protocol errors with their associated CDC paths, especially through the use of permanently unique identifiers in embodiments of the present invention. Therefore, when comparing practical designs, using embodiments of the present invention offers significant advantages over conventional methods.

Claims

1. A method for dynamically verifying a computer implementation of a cross-clock domain (CDC) path in a register-transfer-level (RTL) design, the method comprising: Extract information about the presence of structures in the CDC path and any associated CDC protocol assertions and functional coverage from the CDC static analysis database; Bundle the CDC protocol assertions and the functional coverage into the RTL design in the bundled file; The formal analysis file and simulation setup file are generated from the RTL design, setting and constraint data for the CDC path are extracted from the CDC static analysis database, and the generated formal analysis and simulation setup files are used to compile the bundled file; Perform a formal analysis of the RTL design to determine the proven and unproven CDC protocol assertions; Update the simulation settings file to disable the proven CDC protocol assertion; Use the unverified protocol assertions and functional coverage to run a simulation of the RTL design; The centralized results database is updated using the formal analysis and simulation results of the RTL design. as well as Generate visualizations of the formal analysis and simulation results for use in at least one of the review and debugging processes; Each CDC path is assigned a permanent unique identifier, and the centralized results database is updated using the permanent unique identifier to tag associated CDC protocol assertions, functional coverage, and formal analysis and simulation results.

2. The method according to claim 1, wherein, Information extracted from the CDC static analysis database regarding the existence of structures in the CDC path and any associated CDC protocol assertions and functional coverage includes at least one text string, wherein the permanently unique identifier is a numeric string generated from the text string.

3. The method according to claim 2, wherein, The number string is generated by reducing the number of characters in the text string using mathematical operations.

4. The method according to claim 3, wherein, The permanent unique identifier is added to the assertion and the instance name of the functional coverage of the CDC path.

5. The method according to claim 3, wherein, The permanent unique identifier is added to the CDC protocol assertion associated with the structure in the CDC path.

6. The method according to claim 1, wherein, The structure in the CDC path is a CDC synchronizer, and the associated CDC protocol assertion is generated based on the type of the CDC synchronizer.

7. The method according to claim 1, wherein, There is no structure in the CDC path, and the associated CDC protocol assertion is generated based on the absence of the structure.

8. The method according to claim 1, wherein, The unproven claims about the CDC protocols are either violated or inconclusive.

9. The method according to claim 8, wherein, During formal analysis, counterexamples are generated that indicate incentives that violate CDC protocol assertions.

10. The method according to claim 9, wherein, During formal analysis, a sound waveform is generated for the verified CDC protocol assertion, which indicates that the stimuli of the CDC protocol assertion are not violated.

11. The method according to claim 10, wherein, The visualization of the formal analysis results includes displaying the healthy waveform.

12. The method according to claim 9, wherein, The visualization of the formal analysis and simulation results includes displaying waveforms representing stimuli that violate the CDC protocol assertion.

13. The method according to claim 8, wherein, The simulation setup file and formal analysis file include callback functions that allow updating the centralized results database.

14. The method according to claim 12, wherein, The simulation setup file uses a PLI callback function to capture assertion information, which includes data indicating whether the stimulus violates the CDC protocol assertion.

15. The method according to claim 13, wherein, The method further includes the following steps: The CDC static analysis database is updated using the results of the CDC protocol assertions and functional coverage.

16. The method according to claim 1, wherein, The CDC protocol assertion is a SystemVerilog assertion (SVAs).

17. The method according to claim 1, wherein, The functional coverage of the CDC protocol consists of SystemVerilog coverage points and coverage groups.

18. The method according to any one of the preceding claims, wherein, The simulation setup files include: simulation compilation and simulation parameter files, formal analysis compilation and execution scripts, and formal analysis constraint files.

19. A data processing system, wherein, The data processing system includes a processor adapted to perform the steps of the method according to any one of claims 1 to 18.

20. A computer program product comprising instructions, wherein, When the computer program is executed by a computer, the instructions cause the computer to perform the steps of the method according to any one of claims 1 to 18.

Images