CN112580283B - Control method and device of cross-clock-domain model checker and electronic equipment - Google Patents

Abstract

The application provides a control method and a control device of a cross-clock-domain model checker, and electronic equipment, wherein the method comprises the following steps: analyzing the cross-clock-domain model through a waveform analysis tool to obtain model information of the cross-clock-domain model; analyzing the model information to obtain instantiation information of the cross-clock domain model; generating a control code for controlling a checker corresponding to the instantiation unit by traversing the instantiation information of the cross-clock domain model; and packaging the control code and the predefined user interface into a control module in a verification environment, adding a predefined control file to a specified position in the verification environment to obtain a target verification environment, and controlling the checker corresponding to the cross-clock-domain model through the target verification environment. The efficiency of functional verification in the cross-clock domain model can be improved.

Description

Control method, device and electronic device for cross-clock domain model checker

technical field

The present application relates to the field of computer technologies, and in particular, to a control method, apparatus, and electronic device for a cross-clock domain model checker.

Background technique

Chip design and verification generally need to be verified for a clock domain crossing (Clock Domain Crossing, hereinafter referred to as CDC) circuit.

Due to the diversity of chip design and simulation scenarios, the verification and inspection of cross-clock domain circuits needs to be adjusted and controlled in accordance with the actual cross-clock domain circuits and application conditions to determine the checker for detecting cross-clock domain circuits. The inspection rules are all reasonable. For example, general verifiers write code to do targeted fine-grained control to control when the checker needs to be turned on or off.

SUMMARY OF THE INVENTION

The purpose of the present application is to provide a control method, device and electronic device for a cross-clock domain model checker, which can solve the problem of functional verification in a cross-clock domain model.

In a first aspect, an embodiment of the present invention provides a method for controlling a cross-clock domain model checker, including:

The cross-clock domain model is analyzed by a waveform analysis tool to obtain model information of the cross-clock domain model, where the cross-clock domain model is a chip design model;

parsing the model information to obtain instantiation information of the cross-clock domain model, where the instantiation information is used to describe the instantiated unit;

By traversing the instantiation information of the cross-clock domain model, a control code for controlling the checker corresponding to the instantiated unit is generated;

Encapsulating the control code and the predefined user interface into a control module in the verification environment, and adding a predefined control file to a specified location in the verification environment to obtain a target verification environment;

The checker corresponding to the cross-clock domain model is controlled through the target verification environment.

In an optional implementation manner, generating the control code for controlling the checker corresponding to the instantiated unit by traversing the instantiation information of the cross-clock domain model, including:

According to a predefined control code generation script, the instantiation information of the cross-clock domain model is traversed, and a control code for controlling the checker corresponding to the instantiated unit is generated.

In the embodiment of the present application, the control code is directly generated by the control code generation script, which can reduce the operation of manually writing the code, so that it can be reused in the required environment, thereby improving the performance of each clock domain model for the cross-clock domain model. Verification efficiency of functions.

In an optional implementation manner, the script is generated according to the predefined control code, traverses the instantiation information of the cross-clock domain model, and generates control code for controlling the checker corresponding to the instantiation unit, including:

Generate a script according to a predefined control code, traverse the instantiation information of the cross-clock domain model to obtain target instantiation information, and generate a target instantiation unit corresponding to the target instantiation information for controlling the target instantiation information according to the target instantiation information The control code of the checker, the target instantiation information is any one of the instantiation information of the cross-clock domain model.

In the embodiment of the present application, based on different verification requirements, for example, when precise control is required, each instantiated information needs to correspond to a precise control code, and a corresponding control code can be generated for each instantiated information, thereby Achieve one-to-one precise control.

In an optional implementation manner, the script is generated according to the predefined control code, traverses the instantiation information of the cross-clock domain model, and generates control code for controlling the checker corresponding to the instantiation unit, including:

Generate a script according to a predefined control code, traverse the instantiation information of the cross-clock domain model to obtain the same type of instantiation information, and generate a script for controlling the checker corresponding to the instantiated unit under the same type of instantiation information The control code, the instantiation information of the cross-clock domain model includes one or more types of instantiation information.

In the embodiment of the present application, based on different verification requirements, for example, when a type of checker needs to be controlled at the same time, the same control logic can be used for multiple instantiation information, and a fuzzy matching method can be used to realize a type of instantiated information unified control, thereby improving the efficiency of control code generation.

In an optional implementation manner, the cross-clock domain model includes a plurality of modules, and the model information includes: a hierarchical structure path in the cross-clock domain model; the model information is parsed to obtain the instantiation information for the described cross-clock domain model, including:

Each module of the cross-clock domain model is parsed according to the hierarchical structure path and the pre-stored configuration file to obtain one or more instantiation information corresponding to each module.

In the embodiment of the present application, by analyzing the basic information of the cross-clock-domain model, instantiation information adapted to the cross-clock-domain model is determined, so that the control for controlling the cross-clock-domain model can be generated more accurately code.

In an optional implementation manner, each module of the cross-clock domain model is parsed according to the hierarchical structure path and the pre-stored configuration file to obtain one or more instantiation information corresponding to each module, including :

Analyze each module according to the configuration file to obtain module information of each module, where the module information includes: module name, flag bit, and enable signal path;

According to the hierarchical structure path, flag bit and enable signal path of each module, multiple instantiation information corresponding to each module is determined.

In this embodiment of the present application, the instantiation information is determined according to the information in each module in the cross-clock domain model to meet the control requirements of different modules, so that the determined instantiated information can be more helpful for the cross-clock domain model in the Verification of individual functions across clock domains.

In an optional embodiment, the method further includes:

Store one or more instantiated information corresponding to each module according to the set data storage format.

In an optional implementation manner, the one or more instantiation information corresponding to each module is stored according to the set data storage format, including:

One or more instantiation information corresponding to each module is stored in the storage form of a hash array, and each hash array contains one instantiated information.

In the embodiment of the present application, by using a hash array for storage, the instantiated information can be traversed more conveniently, thereby providing convenience for generating control codes and improving the efficiency of generating control codes.

In a second aspect, an embodiment of the present invention provides a control device for a cross-clock domain model checker, including:

a model analysis module, configured to analyze the cross-clock domain model through a waveform analysis tool to obtain model information of the cross-clock domain model, where the cross-clock domain model is a chip design model;

an information parsing module, configured to parse the model information to obtain instantiation information of the cross-clock domain model;

a control code generation module, configured to generate a control code for controlling the checker corresponding to the instantiated unit by traversing the instantiation information of the cross-clock domain model;

A verification environment acquisition module, for encapsulating the control code and the predefined user interface into the control module in the verification environment, and adding the predefined control file to a specified position in the verification environment to obtain a target verification environment;

The checker control module is configured to control the checker corresponding to the cross-clock domain model through the target verification environment.

In a third aspect, an embodiment of the present invention provides an electronic device, including: a processor and a memory, where the memory stores machine-readable instructions executable by the processor, and when the electronic device runs, the machine-readable instructions The steps of the method as described in any of the preceding embodiments are performed when executed by the processor.

In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and when the computer program is run by a processor, the steps of the method described in any of the foregoing embodiments are executed. .

The beneficial effects of the embodiments of the present application are: by analyzing the cross-clock domain model, content such as instantiation information, control codes, etc. can be determined, thereby reducing the need to verify the cross-clock domain model in various writing verification environments every time. A new operation is required, so that the verification efficiency of each function of the cross-clock-domain model under the cross-clock domain can be improved.

Description of drawings

In order to illustrate the technical solutions of the embodiments of the present application more clearly, the following drawings will briefly introduce the drawings that need to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore do not It should be regarded as a limitation of the scope, and for those of ordinary skill in the art, other related drawings can also be obtained according to these drawings without any creative effort.

FIG. 1 is a schematic block diagram of an electronic device provided by an embodiment of the present application.

FIG. 2 is a flowchart of a control method of a cross-clock domain model checker provided by an embodiment of the present application.

FIG. 3 is a detailed flowchart of step 204 of the control method for a cross-clock domain model checker provided by an embodiment of the present application.

FIG. 4 is a schematic diagram of a target verification environment obtained by a control method of a cross-clock domain model checker provided by an embodiment of the present application.

FIG. 5 is a schematic diagram of multiplexing a verification environment of a control method for a cross-clock domain model checker provided by an embodiment of the present application.

FIG. 6 is a schematic diagram of functional modules of a control device of a cross-clock domain model checker provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application.

It should be noted that like numerals and letters refer to like items in the following figures, so once an item is defined in one figure, it does not require further definition and explanation in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", etc. are only used to distinguish the description, and cannot be understood as indicating or implying relative importance.

The chip design is generally divided into two processes: front-end design and back-end design. The front-end design represents the logic design, and the logic design refers to writing code through the functions required by the chip to construct a simulated chip model according to the code. Through the verification of the simulation model, it is determined whether the simulation chip model can realize the required functions, and whether it is accurate when realizing the required functions. The backend design represents the physical design. For example, physical design can include chip package and pin design, floorplan, power routing and power verification, prevention and correction of line-to-line interference, timing closure, etc.

In the design of a system-on-chip (SOC), there are more and more functions, more and more scale, and more and more clocks in the chip. Both chip design and verification need to ensure the correctness of a clock domain crossing (Clock Domain Crossing, CDC for short below) circuit. With the development of the verification of the CDC circuit, a general front-end model has been established for the CDC circuit, and a general checker has been added to the front-end model. In the functional simulation stage of the front-end design, the CDC circuit is found through the verification of the checker. possible problems.

Due to the diversity of chip design, the front-end simulation scenarios in chip design are also diverse. The general front-end model and checker need to be adjusted and controlled adaptively with the actual simulation scenario, so that the checker's checking rules are all reasonable. For example, in some specific cases, some general-purpose checkers are not applicable, and the relevant verifiers need to write codes for specific and precise control, for example, to turn on or off certain checkers at specific times.

The inventors of the present application have conducted research on the prior art and found that the existing technical solutions generally control these checkers one by one through handwritten codes by verifiers. Different simulation environments require similar checker control for the same circuit. , the workload is huge, which reduces the verification efficiency of the chip.

Among them, the checker used to verify the CDC circuit is controlled one by one through the code written by the verifier, which may have the following defects:

There may be error-prone situations due to the large amount of code written. Especially when the circuit is complex and more control codes are required, it is easy to make mistakes due to the huge amount of code. If there is an error in the code used to detect the CDC circuit, the inspection for the CDC circuit may also miss the defect.

The same CDC circuit may have many fine controls that are the same in different levels of simulation environments. Different simulation environments need to build the fine control separately, and some repetitive work may be done, resulting in lower verification efficiency of the CDC circuit.

In view of the above research, the inventors of the present application have studied the CDC circuit and learned that the above deficiencies can be compensated by using a common underlying control module and user interface. Exemplarily, the general control module can be instantiated through a specific simulation CDC model verification environment, and the general interface can define a unified control method. Based on this, embodiments of the present application provide a control method, apparatus, and electronic device for a cross-clock domain model checker. The solutions provided by the embodiments of the present application are described below through several embodiments.

Example 1

In order to facilitate understanding of this embodiment, an electronic device that executes the control method of the cross-clock domain model checker disclosed in the embodiment of this application is first introduced in detail.

As shown in FIG. 1, it is a block diagram of an electronic device. The electronic device 100 may include a memory 111 , a memory controller 112 , a processor 113 , a peripheral interface 114 , an input and output unit 115 , and a display unit 116 . Those of ordinary skill in the art can understand that the structure shown in FIG. 1 is only for illustration, and does not limit the structure of the electronic device 100 . For example, the electronic device 100 may also include more or fewer components than shown in FIG. 1 , or have a different configuration than that shown in FIG. 1 .

The above-mentioned elements of the memory 111 , the storage controller 112 , the processor 113 , the peripheral interface 114 , the input/output unit 115 and the display unit 116 are directly or indirectly electrically connected to each other to realize data transmission or interaction. For example, these elements may be electrically connected to each other through one or more communication buses or signal lines. The above-mentioned processor 113 is used to execute executable modules stored in the memory.

Wherein, the memory 111 may be, but not limited to, a random access memory (Random Access Memory, referred to as RAM), a read only memory (Read Only Memory, referred to as ROM), a programmable read only memory (Programmable Read-Only Memory, referred to as PROM) , Erasable Programmable Read-Only Memory (Erasable Programmable Read-Only Memory, referred to as EPROM), Electrically Erasable Read-Only Memory (Electric Erasable Programmable Read-Only Memory, referred to as EEPROM) and so on. The memory 111 is used to store a program, and the processor 113 executes the program after receiving the execution instruction, and the method executed by the electronic device 100 defined by the process disclosed in any of the embodiments of this application may be applied in the processor 113 or implemented by the processor 113 .

The above-mentioned processor 113 may be an integrated circuit chip with signal processing capability. The above-mentioned processor 113 may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU for short), a network processor (Network Processor, NP for short), etc.; it may also be a digital signal processor (Digital signal processor, DSP for short) , Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, and discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of this application can be implemented or executed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The aforementioned peripheral interface 114 couples various input/output devices to the processor 113 and the memory 111 . In some embodiments, peripheral interface 114, processor 113, and memory controller 112 may be implemented in a single chip. In other instances, they may be implemented by separate chips.

The above-mentioned input and output unit 115 is used to provide input data to the user. The input and output unit 115 may be, but not limited to, a mouse, a keyboard, and the like.

The above-mentioned display unit 116 provides an interactive interface (eg, a user operation interface) between the electronic device 100 and the user or is used to display image data for the user's reference. In this embodiment, the display unit may be a liquid crystal display or a touch display. In the case of a touch display, it can be a capacitive touch screen or a resistive touch screen that supports single-point and multi-touch operations. Supporting single-point and multi-touch operation means that the touch display can sense the touch operation from one or more positions on the touch display at the same time, and hand over the sensed touch operation to the processor. calculation and processing.

Exemplarily, the above-mentioned display unit 116 may be used to display a schematic diagram generated in the process of controlling the checker of the cross-clock domain model.

The electronic device 100 in this embodiment may be used to execute each step in each method provided in this embodiment of the present application. The implementation process of the control method of the cross-clock domain model checker is described in detail below through several embodiments.

Embodiment 2

Please refer to FIG. 2 , which is a flowchart of a control method of a cross-clock domain model checker provided by an embodiment of the present application. The specific flow shown in FIG. 2 will be described in detail below.

Step 202 , analyze the cross-clock domain model by using a waveform analysis tool to obtain model information of the cross-clock domain model.

In this embodiment, the cross-clock domain model is a chip design model, and the cross-clock domain model includes a plurality of modules. The chip design model may be data obtained after compiling model codes, and the model codes are codes written based on the functions of the chip to be implemented.

Exemplarily, the above model code can be submitted to a simulation tool for compilation.

Illustratively, the simulation tool may be vcs. The vcs is a tool for simulation developed by synopsys.

Exemplarily, the simulation tool may also be a simulation tool such as Mentor's ModelSim, Cadence's Verilog-XL, and Cadence's NC-Verilog.

Optionally, the above-mentioned waveform analysis tool may be Verdi. Among them, the Verdi is a tool developed by synopsys for analyzing simulation waveforms.

Exemplarily, the model information of the chip design corresponding to the compiled model code can be extracted through the NPI (Native Programming Interface, native programming interface) of Verdi.

Exemplarily, the model information extracted by the NPI of verdi may be specified information extracted from the model code compiled by vcs.

Illustratively, the model information may include: hierarchy, module name, and file path. The cross-clock domain model in this embodiment may include multiple modules. The module may refer to the CDC module.

Exemplarily, the model information can be represented as the content shown in Table 1 below:

Table 1

Hierarchy Path Module Name File Path Hierarchy_Path_1 CDC_Wrapper_Name_1 File_Path_1 … … … Hierarchy_Path_n CDC_Wrapper_Name_N File_Path_n

Among them, Hierarchy Path represents the hierarchical structure path of each module of the cross-clock domain model; ModuleName represents the name of the CDC module of the cross-clock domain model; File Path represents the storage location of the file corresponding to the corresponding CDC module.

Step 204: Parse the model information to obtain instantiation information of the cross-clock domain model.

In this embodiment, each CDC module may include one or more pieces of instantiated information, and by analyzing the above-mentioned model information, the location of each instantiated information can be determined.

Exemplarily, the model information includes: a hierarchical structure path in the cross-clock domain model.

Optionally, the model information may further include: each module file path.

In one embodiment, step 204 may include: parsing each module of the cross-clock domain model according to the hierarchical structure path and the pre-stored configuration file to obtain one or more instantiation information corresponding to each module .

Exemplarily, the pre-stored configuration file is a file pre-edited by the user. The pre-stored configuration file includes relevant information of each CDC module.

Optionally, as shown in FIG. 3 , step 204 may include the following steps.

Step 2041, parse each module according to the configuration file to obtain module information of each module.

Exemplarily, the module information includes: a module name, a flag bit (Process Flag), and an enable signal path (Control Signal Path).

Exemplarily, by parsing the configuration file, the instantiation information of each module can be obtained.

Exemplarily, in one instance, the module information of each CDC module of the cross-clock domain model in the configuration file may be represented as the content shown in Table 2 below:

Table 2

Module Name Process Flag Control Signal Path CDC_Wrapper_Name_1 0/1 Control_Signal_Path_1 … … … CDC_Wrapper_Name_N 0/1 Control_Signal_Path_N

Among them, Module Name represents the module name of the corresponding CDC; Process Flag represents the flag bit; ControlSignal Path represents the enable signal path of the control checker. Among them, Process Flag indicates whether post-processing of the hierarchical structure of the CDC module is required. Exemplarily, there may be differences in the hierarchical structure of the same CDC module under different instantiation parameters.

Step 2042: Determine a plurality of instantiation information corresponding to each module according to the hierarchical structure path, flag bit and enable signal path of each module.

In this embodiment, different hierarchical structures of the cross-clock domain model can be obtained by using different instantiation parameters.

Optionally, the instantiation information of each module in the cross-clock domain model can be parsed through a predefined script.

In this embodiment, the paths in the instantiation information of each module corresponding to different Process Flag flags may be different.

Exemplarily, when the Process Flag flag is 1, the instantiation information of each module is the first path; when the Process Flag flag is 2, the instantiation information of each module is the second path, wherein the first path is the same as the one. The second path is different.

Exemplarily, when the Process Flag bit is a different value, the path in the instantiation information can be obtained by analyzing the original file in the file path File Path.

Optionally, the storage of each instantiated information may also be stored according to a predefined storage rule.

Optionally, the method in this embodiment may further include step 205, storing one or more instantiation information corresponding to each module according to a set data storage format.

In an implementation manner, one or more instantiation information corresponding to each module is respectively stored in the storage form of a hash array, and each hash array contains one piece of instantiated information.

Exemplarily, an instantiated information of a CDC module can be represented as the content shown in Table 3 below:

table 3

Key Value Dis Control Signal Path Hier Hierarchy Path

Among them, the key Key represents a keyword corresponding to the instantiated information, and the value Value represents the corresponding path information.

In this embodiment, a hierarchical structure path corresponding to an instantiated unit can be determined by the value of the key Hier Hierarchy Path, and an enable signal path of the corresponding instantiated unit can be determined by the value of the key Dis Control Signal Path. Therefore, the path of an instantiated unit checker control signal can be uniquely determined by the values corresponding to the key Dis and the key Hier.

In this embodiment, the model information of the cross-clock domain model is traversed, and a hash array of the CDC modules as shown in Table 3 can be generated for the instantiation information of all CDC modules.

Exemplarily, the instantiation information of all CDC modules is aggregated and stored in a new hash array, referred to as CDC instance hash for short, which can be expressed as the content shown in Table 4:

Table 4

In the example shown in Table 4, the CDC module _{CDC_Wrapper_Name_1} includes N1 instantiated units. The instantiation information of each instantiated unit can be represented as Sub_Hash_11, . . . , Sub_Hash_N ₁ , respectively.

Exemplarily, the instance information corresponding to each instance unit may be path information of the instance unit.

In this embodiment, through steps 202 to 204, the location of the instantiation information of each module in a cross-clock domain model can be determined. By the location of the instantiated information, the control code of the checker that controls the instantiated information can be constructed.

Step 206 , by traversing the instantiation information of the cross-clock domain model, a control code for controlling the checker corresponding to the instantiated unit is generated.

Optionally, by traversing all the instantiation information of the cross-clock domain model, a corresponding control code is generated for the checker corresponding to the instantiated unit of all the instantiated information of the cross-clock domain model, based on the control code. Implements control of the inspector for each instantiated unit.

Optionally, the actions of step 206 may be performed by predefined steps. Exemplarily, step 206 may include: generating a script according to a predefined control code, traversing the instantiation information of the cross-clock domain model, and generating a control code for controlling the checker corresponding to the instantiated unit.

Exemplarily, the control code generation script may perform an action of traversing the instantiation information of the cross-clock domain model, and may also perform an action of generating a control code for controlling the checker corresponding to the instantiated unit according to the instantiated information obtained by the traversal.

Exemplarily, the control code generation script may include a control code template, where the content that needs to be personalized is reserved in the control code template.

For example, the control code template may reserve a location where the path information of the instantiated unit needs to be filled. When a control code template is filled with path information of an instantiated unit, the control code of the checker corresponding to the instantiated unit can be formed.

In one instance, the hash array for one of the CDC modules can be:

my%HASH = ();

$HASH{'cdc_model'}{0}{dis}='sync_r.InputChkDis';

$HASH{'cdc_model'}{0}{hier}='tb.pcie.upcs.txClk_Ack_sync_0';

$HASH{'cdc_model'}{1}{dis}='sync_r.InputChkDis';

$HASH{'cdc_model'}{1}{hier}='tb.pcie.upcs.txClk_Ack_sync_1';

$HASH{'cdc_model'}{2}{dis}='sync_r.InputChkDis';

$HASH{'cdc_model'}{2}{hier}='tb.pcie.upcs.txClk_Ack_sync_2';

$HASH{'cdc_model'}{3}{dis}='sync_r.InputChkDis';

$HASH{'cdc_model'}{3}{hier}='tb.pcie.upcs.txClk_Ack_sync_3';

The above CDC module cdc_model corresponds to four instantiation units. Exemplarily, {0}{dis}='sync_r.InputChkDis' and {0}{hier}='tb.pcie.upcs.txClk_Ack_sync_0' represent the instantiation information of the first instantiation unit of the CDC module cdc_model.

The control code generated for the first instantiated unit can be expressed as:

Taking the above example as an example, the control code template can be expressed as:

Wherein, "XXX" in the control code template is used to fill in the path information of the instantiated unit that needs to be controlled, and "YYY" is used to fill the path information of the enable signal of the instantiated unit that needs to be controlled.

In this embodiment, required control codes can be generated based on different control requirements.

In one embodiment, the control code may include a precise control code for, when an instantiated unit that completely matches the provided path is found, the checker corresponding to the instantiated unit may be turned on or off.

Exemplarily, for instantiated units that require precise control, each instantiated unit may correspond to a set of control codes.

Exemplarily, step 206 may include: generating a script according to a predefined control code, traversing the instantiation information of the cross-clock domain model to obtain target instantiation information, and generating a script for controlling the target according to the target instantiation information. The control code of the checker corresponding to the target instantiation unit of the instantiation information, where the target instantiation information is any one of the instantiation information of the cross-clock domain model.

Exemplarily, the control code may include a fuzzy control code, and when an instantiated unit partially matching the provided path is found, the checker corresponding to the instantiated unit whose partial path is successfully matched may be turned on or off.

In one embodiment, step 206 may include: generating a script according to a predefined control code, traversing the instantiation information of the same type obtained by traversing the instantiation information of the cross-clock domain model, and generating an instance for controlling the same type The control code of the checker corresponding to the instantiation unit under the instantiation information, where the instantiation information of the cross-clock domain model includes one or more types of instantiation information.

Exemplarily, the above instantiation information of the same type may refer to the fact that the path information of the instantiation units corresponding to each instantiation information in the instantiation information of the same type is different, and the instantiation information corresponding to the instantiation information of the same type corresponds to The controlled logic of the instantiated unit is the same. For example, under the same conditions, the checkers corresponding to some instantiated units need to be closed at the same time, then the partial instantiation units can be the same type of instantiation units, and the instantiation information corresponding to the partial instantiation units is the same Class instantiation information.

In this embodiment, the control codes corresponding to each instantiated unit may form a low-level control module.

Exemplarily, through steps 202 to 208, the underlying control modules for controlling each checker can be generated.

Step 208: Encapsulate the control code and the predefined user interface into a control module in a verification environment, and add a predefined control file to a specified location in the verification environment to obtain a target verification environment.

Exemplarily, the control of the checker of the control unit corresponding to each instantiated unit can be implemented based on the above-mentioned underlying control module.

Optionally, a general interface can also be constructed for the above-mentioned underlying control module.

Through the above general interface, as long as you provide the status of the checker to be controlled (whether input_chk_en is TURN_ON or TURN_OFF), the path information of the instantiated unit corresponding to the checker, and the fuzzy matching mode control switch (use_regex) and other information, the instantiation can be realized. Control of the unit's inspector.

In this embodiment, the above-mentioned predefined control file may be a control file defined according to the actual function of the cross-clock domain model and scenario requirements.

Illustratively, the control file includes logic for controlling switches of the checker of the CDC module.

Optionally, the control files corresponding to each cross-clock domain model are packaged into independent control files. When the function of the corresponding cross-clock-domain model in the cross-clock-domain state needs to be checked, the relevant checker can be controlled according to the corresponding control file.

In this embodiment, the underlying control module formed by the control code constructed in the above step 206 and the general interface corresponding to the underlying control module are encapsulated into a control module, thereby realizing the instantiation of the control module in a verification environment.

Exemplarily, as shown in FIG. 4 , FIG. 4 shows a schematic diagram of a target verification environment constructed by a bottom layer control module, a general interface and a control file.

Step 210: Control the checker corresponding to the cross-clock domain model through the target verification environment.

In this embodiment, by controlling the checker corresponding to the cross-clock domain model, it is to realize the verification of the CDC module, and the checker can be conveniently turned off when there is no need to check, thereby improving the verification efficiency.

In this embodiment, through steps 202 to 208, a verification environment for verifying the cross-clock domain model can be implemented.

The underlying control modules implemented in steps 202 to 206 may be automatically generated based on the cross-clock domain model that needs to be verified.

In this embodiment, the predefined control file can be converged, and can be reused in any verification environment including the same circuit module, so as to control the checkers of all CDC modules, thereby improving the verification efficiency.

In this embodiment, when constructing the target verification environment, the entire method can be added to any verification environment with only a few changes.

Illustratively, as shown in Figure 5, Design A is part of Design B. Verification environment A is used to verify design A, and verification environment B is used to verify design B. If the verification environment A has completed the development of the control module and the control file, it is only necessary to automatically generate the underlying code corresponding to the design B and slightly change the design path of the control file, and then the entire CDC control module can be changed from the verification environment. A is multiplexed to the verification environment B.

The control of the existing common CDC module checker requires the verifier to manually write the control code one by one, and directly use the force/release combination to operate the CDC module checker, and the control code may also be scattered in the CDC module. Verify every corner of the environment. The volume is large, there is no unified organization, and it is prone to errors and omissions. Compared with the prior art, in this embodiment, by mounting a dedicated bottom control module and a unified general interface, the control of the checker of the CDC module can be reused between different verification environments, reducing the number of different verification environments. The repeated construction of some of the same information in the verification environment, as well as the errors caused by the lack of timely synchronization between the verification environments and the time for processing errors, improve verification efficiency and reduce maintenance costs.

In the method in this embodiment, the checker control files of the CDC module for the same circuit can be directly reused between different verification environments, and the verifier only needs to continuously maintain one set of control files, thereby improving the efficiency of the CDC module verification. .

Embodiment 3

Based on the same application concept, the embodiment of the present application also provides a control device for the cross-clock domain model checker corresponding to the control method for the cross-clock domain model checker. Embodiments of the control method of the cross-clock domain model checker are similar, so for the implementation of the apparatus in this embodiment, reference may be made to the descriptions in the foregoing method embodiments, and repeated descriptions will not be repeated.

Please refer to FIG. 6 , which is a schematic diagram of functional modules of a control device of a cross-clock domain model checker provided by an embodiment of the present application. Each module in the control device of the cross-clock domain model checker in this embodiment is configured to execute each step in the foregoing method embodiment. The control device of the cross-clock domain model checker includes: a model analysis module 301, an information analysis module 302, a control code generation module 303, a verification environment acquisition module 304, and a checker control module 305; wherein,

A model analysis module 301, configured to analyze a cross-clock domain model through a waveform analysis tool to obtain model information of the cross-clock domain model, where the cross-clock domain model is a chip design model;

an information parsing module 302, configured to parse the model information to obtain instantiation information of the cross-clock domain model;

a control code generation module 303, configured to generate a control code for controlling the checker corresponding to the instantiated unit by traversing the instantiation information of the cross-clock domain model;

The verification environment acquisition module 304 is used to encapsulate the control code and the predefined user interface into the control module in the verification environment, and add the predefined control file to a specified location in the verification environment to obtain the target verification environment ;

The checker control module 305 is configured to control the checker corresponding to the cross-clock domain model through the target verification environment.

In a possible implementation manner, the control code generation module 303 is used for:

According to a predefined control code generation script, the instantiation information of the cross-clock domain model is traversed, and a control code for controlling the checker corresponding to the instantiated unit is generated.

In a possible implementation manner, the control code generation module 303 is used for:

Generate a script according to a predefined control code, traverse the instantiation information of the cross-clock domain model to obtain target instantiation information, and generate a target instantiation unit corresponding to the target instantiation information for controlling the target instantiation information according to the target instantiation information The control code of the checker, the target instantiation information is any one of the instantiation information of the cross-clock domain model.

In a possible implementation manner, the control code generation module 303 is used for:

Generate a script according to a predefined control code, traverse the instantiation information of the cross-clock domain model to obtain the same type of instantiation information, and generate a script for controlling the checker corresponding to the instantiated unit under the same type of instantiation information The control code, the instantiation information of the cross-clock domain model includes one or more types of instantiation information.

In a possible implementation manner, the cross-clock domain model includes a plurality of modules, and the model information includes: a hierarchical structure path and each module file path in the cross-clock domain model; an information parsing module 302, configured to:

Each module of the cross-clock domain model is parsed according to the hierarchical structure path and the pre-stored configuration file to obtain one or more instantiation information corresponding to each module.

In a possible implementation manner, the information parsing module 302 is used for:

Analyze each module according to the configuration file to obtain module information of each module, where the module information includes: module name, flag bit, and enable signal path;

According to the hierarchical structure path, flag bit and enable signal path of each module, multiple instantiation information corresponding to each module is determined.

In a possible implementation manner, the control device of the cross-clock domain model checker in this embodiment further includes:

The storage module is used for storing one or more instantiated information corresponding to each module according to the set data storage format.

In a possible implementation, the storage module is used for:

One or more instantiation information corresponding to each module is stored in the storage form of a hash array, and each hash array contains one instantiated information.

In addition, an embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and the computer program is executed by a processor to perform the cross-clock domain model check described in the foregoing method embodiments. The steps of the control method of the device.

The computer program product of the control method for the cross-clock domain model checker provided by the embodiments of the present application includes a computer-readable storage medium storing program codes, and the instructions included in the program codes can be used to execute the methods described in the foregoing method embodiments. For the steps of the control method of the cross-clock domain model checker, reference may be made to the foregoing method embodiments, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may also be implemented in other manners. The apparatus embodiments described above are merely illustrative, for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architectures, functions and possible implementations of apparatuses, methods and computer program products according to various embodiments of the present application. operate. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code that contains one or more functions for implementing the specified logical function(s) executable instructions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It is also noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented in dedicated hardware-based systems that perform the specified functions or actions , or can be implemented in a combination of dedicated hardware and computer instructions.

In addition, each functional module in each embodiment of the present application may be integrated together to form an independent part, or each module may exist independently, or two or more modules may be integrated to form an independent part.

If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be embodied in the form of a software product in essence, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, Read-Only Memory (ROM, Read-Only Memory), Random Access Memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program codes . It should be noted that, in this document, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any relationship between these entities or operations. any such actual relationship or sequence exists. Moreover, the terms "comprising", "comprising" or any other variation thereof are intended to encompass a non-exclusive inclusion such that a process, method, article or device that includes a list of elements includes not only those elements, but also includes not explicitly listed or other elements inherent to such a process, method, article or apparatus. Without further limitation, an element defined by the phrase "comprises" does not preclude the presence of additional identical elements in a process, method, article, or device that includes the element.

The above descriptions are only preferred embodiments of the present application, and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and changes. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included within the protection scope of this application. It should be noted that like numerals and letters refer to like items in the following figures, so once an item is defined in one figure, it does not require further definition and explanation in subsequent figures.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited to this. should be covered within the scope of protection of this application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (11)

1. A control method for a cross-clock domain model checker, comprising: The cross-clock domain model is analyzed by a waveform analysis tool to obtain model information of the cross-clock domain model, where the cross-clock domain model is a chip design model; parsing the model information to obtain instantiation information of the cross-clock domain model, where the instantiation information is used to describe the instantiated unit; By traversing the instantiation information of the cross-clock domain model, a control code for controlling the checker corresponding to the instantiated unit is generated; Encapsulating the control code and the predefined user interface into a control module in the verification environment, and adding a predefined control file to a specified location in the verification environment to obtain a target verification environment; The checker corresponding to the cross-clock domain model is controlled through the target verification environment. 2 . The method according to claim 1 , wherein generating the control code for controlling the checker corresponding to the instantiated unit by traversing the instantiation information of the cross-clock domain model, comprising: 2 . According to a predefined control code generation script, the instantiation information of the cross-clock domain model is traversed, and a control code for controlling the checker corresponding to the instantiated unit is generated. 3. The method according to claim 2, wherein the script is generated according to a predefined control code, the instantiation information of the cross-clock domain model is traversed, and the checker corresponding to the instantiation unit is generated for controlling control code, including: Generate a script according to a predefined control code, traverse the instantiation information of the cross-clock domain model to obtain target instantiation information, and generate a target instantiation unit corresponding to the target instantiation information for controlling the target instantiation information according to the target instantiation information The control code of the checker, the target instantiation information is any one of the instantiation information of the cross-clock domain model. 4. The method according to claim 2, wherein the script is generated according to a predefined control code, the instantiation information of the cross-clock domain model is traversed, and the checker corresponding to the instantiation unit is generated for controlling control code, including: Generate a script according to a predefined control code, traverse the instantiation information of the cross-clock domain model to obtain the same type of instantiation information, and generate a script for controlling the checker corresponding to the instantiated unit under the same type of instantiation information The control code, the instantiation information of the cross-clock domain model includes one or more types of instantiation information. 5. The method according to claim 1, wherein the cross-clock domain model comprises a plurality of modules, and the model information comprises: a hierarchical structure path in the cross-clock domain model; The information is parsed to obtain the instantiation information of the cross-clock domain model, including: Each module of the cross-clock domain model is parsed according to the hierarchical structure path and the pre-stored configuration file to obtain one or more instantiation information corresponding to each module. 6 . The method according to claim 5 , wherein the analysis is performed on each module of the cross-clock domain model according to the hierarchical structure path and a pre-stored configuration file to obtain one or more corresponding modules of each module. 7 . Multiple instantiation information, including: Analyze each module according to the configuration file to obtain module information of each module, where the module information includes: module name, flag bit, and enable signal path; According to the hierarchical structure path, flag bit and enable signal path of each module, multiple instantiation information corresponding to each module is determined. 7. The method according to claim 5, wherein the method further comprises: Store one or more instantiated information corresponding to each module according to the set data storage format. 8. The method according to claim 7, wherein the storing one or more instantiated information corresponding to each module according to a set data storage format, comprising: One or more instantiation information corresponding to each module is stored in the storage form of a hash array, and each hash array contains one instantiated information. 9. A control device for a cross-clock domain model checker, comprising: a model analysis module, configured to analyze the cross-clock domain model through a waveform analysis tool to obtain model information of the cross-clock domain model, where the cross-clock domain model is a chip design model; an information parsing module, configured to parse the model information to obtain instantiation information of the cross-clock domain model; a control code generation module, configured to generate a control code for controlling the checker corresponding to the instantiated unit by traversing the instantiation information of the cross-clock domain model; A verification environment acquisition module, for encapsulating the control code and the predefined user interface into the control module in the verification environment, and adding the predefined control file to a specified position in the verification environment to obtain a target verification environment; The checker control module is configured to control the checker corresponding to the cross-clock domain model through the target verification environment. 10. An electronic device, comprising: a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device runs, the machine-readable instructions are executed by the The processor executes the steps of the method according to any one of claims 1 to 8 when executed. 11. A computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is run by a processor, the steps of the method according to any one of claims 1 to 8 are executed.

Images