Verification file generation method and device, computer equipment, medium and product

Abstract

The embodiment of the invention discloses a verification file generation method and device, computer equipment, a medium and a product, and relates to the field of chip verification. The method comprises the steps that based on a keyword, a key signal is extracted from a state indication signal of a to-be-verified module, the to-be-verified module is a to-be-verified hardware module in a chip, the state indication signal is a signal used for representing the internal running state of the to-be-verified module, and the signal name of the key signal is related to the keyword; based on the key signal, a verification file of the to-be-verified module is generated, and the verification file is used for checking the signal state of the key signal generated by the to-be-verified module in the operation process. According to the verification file generation method provided by the invention, the chip verification efficiency is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of chip verification, and in particular to a method, apparatus, computer equipment, medium, and product for generating a verification file. Background Art

[0002] Chip verification is the process of ensuring that chip designs strictly comply with predetermined functional specifications. During chip verification, verifiers typically need to manually check whether the signal states of the status indicator signals in the signal list compiled by the designer meet the preset rules.

[0003] For example, there may be a large number of counters (cnt), first-in-first-out queues (FIFO) and other structures inside the hardware module of the chip. The status indication signal includes an idle signal (i.e., an idle signal, used to indicate whether the hardware module is in an idle state), a queue signal (such as an empty signal and a full signal, used to indicate whether the number of queue elements in the first-in-first-out queue is empty or full), and a counter signal (i.e., a counter signal, used to indicate the count of the counter). In the related art, the verification personnel need to manually check whether the signal status of each signal in the signal list (such as an idle signal, a full signal, an empty signal and a counter signal) meets the preset rules.

[0004] However, manually checking signal status using this method has many drawbacks. For example, the efficiency and quality of the check are low. Another example is that different verification personnel may use different manual inspection methods, making it impossible to establish a unified standard. Summary of the Invention

[0005] The present application provides a method, device, computer equipment, medium, and product for generating a verification file. The technical solution is as follows:

[0006] In one aspect, an embodiment of the present application provides a method for generating a verification file, the method comprising:

[0007] Extracting a key signal from a status indication signal of a module to be verified based on the keyword, wherein the module to be verified is a hardware module to be verified in a chip, the status indication signal is a signal used to represent an internal operating state of the module to be verified, and the signal name of the key signal is related to the keyword;

[0008] Based on the key signal, a verification file of the module to be verified is generated, and the verification file is used to check the signal status of the key signal generated by the module to be verified during operation.

[0009] On the other hand, an embodiment of the present application provides a device for generating a verification file, the device comprising:

[0010] an extraction module configured to extract a key signal from a status indication signal of a module to be verified based on a keyword, wherein the module to be verified is a hardware module to be verified in a chip, the status indication signal is a signal used to represent an internal operating state of the module to be verified, and a signal name of the key signal is related to the keyword;

[0011] A generating module is used to generate a verification file of the module to be verified based on the key signal, wherein the verification file is used to check the signal status of the key signal generated by the module to be verified during operation.

[0012] On the other hand, an embodiment of the present application provides a computer device, which includes a processor and a memory, wherein the memory stores at least one computer instruction, and the at least one computer instruction is loaded and executed by the processor to implement the method described in the above aspect.

[0013] On the other hand, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores at least one computer instruction, and the computer instruction is loaded and executed by a processor to implement the method described in the above aspects.

[0014] In another aspect, an embodiment of the present application provides a computer program product, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various optional implementations of the above aspects.

[0015] In an embodiment of the present application, based on keywords, key signals whose signal names are related to the keywords are extracted from the status indication signals of the module to be verified, which can realize automatic extraction of key signals, avoid manual sorting of signal lists by designers, and ensure the comprehensiveness and accuracy of key signal extraction; based on key signals, a verification file of the module to be verified is generated, and since the verification file is used to check the signal status of key signals generated by the module to be verified during operation, automatic verification of the module to be verified can be realized by generating the verification file; at the same time, since the verification file can be generated automatically, the tedious operation of manual verification by the verification personnel is avoided, and the verification efficiency of the module to be verified is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 is a flow chart of a method for generating a verification file provided by an exemplary embodiment of the present application;

[0018] Figure 2 is a schematic diagram of the script code of the first script provided by an exemplary embodiment of the present application;

[0019] Figure 3 This is a schematic diagram of obtaining all status indication signals in a module to be verified through the Verdi automatic debugging platform provided by an exemplary embodiment of the present application;

[0020] Figure 4 This is a flowchart of generating a verification file for a module to be verified based on a key signal provided by an exemplary embodiment of the present application;

[0021] Figure 5 This is a schematic diagram of the script code of the main function in the second script provided by an exemplary embodiment of the present application;

[0022] Figure 6 is a schematic diagram of the script code of the process_signal_sel function in the second script provided by an exemplary embodiment of the present application;

[0023] Figure 7 This is a schematic diagram of determining the signal type of a key signal corresponding to a key signal path in the script code of the process_csv function provided by an exemplary embodiment of the present application;

[0024] Figure 8 This is a schematic diagram of generating a first assertion check statement corresponding to a first signal type in the script code of the process_csv function provided by an exemplary embodiment of the present application;

[0025] Figure 9 This is a schematic diagram of generating a second assertion check statement corresponding to a second signal type and a third assertion check statement corresponding to a third signal type in the script code of the process_csv function provided by an exemplary embodiment of the present application;

[0026] Figure 10This is a schematic diagram of generating an assertion check statement corresponding to a critical signal when the signal type of the critical signal is the first signal type, the second signal type, or the third signal type, provided by an exemplary embodiment of the present application;

[0027] Figure 11 is a schematic diagram of generation and use of a verification file provided by an exemplary embodiment of the present application;

[0028] Figure 12 is a schematic diagram of a computer system provided by an exemplary embodiment of the present application;

[0029] Figure 13 This is a structural block diagram of a device for generating a verification file provided by an exemplary embodiment of the present application;

[0030] Figure 14 It is a structural diagram of a computer device provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0031] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0032] First, the nouns involved in the embodiments of this application are introduced.

[0033] Chip design: The starting point and core phase of chip creation. Chip design typically involves determining the chip's functional specifications based on application requirements, such as computing power and cache size. Next, logic design translates the functional requirements into specific logic circuits, implemented using hardware description languages ​​such as Verilog or System Verilog. This is followed by physical design, including layout and routing, which transforms the logic circuits into actual chip layouts.

[0034] Chip Verification: A step that ensures a chip design meets its intended functionality. Chip verification involves a variety of methods to check the design. For example, functional verification uses simulation tools to simulate the chip's operation under various input conditions to verify the correct output. Verification is an ongoing process throughout the chip design process, continuously identifying and correcting design errors to ensure reliable and stable chip operation after manufacturing.

[0035] Assertion checking: A technical method used in chip verification to verify design correctness. Assertion checking expresses conditions that a program or design should meet. For example, during program execution or design simulation, the expression in the assertion check is evaluated to verify that the actual behavior matches expectations. If it does not, an exception is thrown to help verifiers locate and debug the problem.

[0036] Counter (CNT): A digital circuit used to accumulate the number of input pulses is called a counter. Counters are widely used unit logic circuits in digital circuits and can be used for functions such as counting, frequency division, and timing. There are many types of counters. Based on the counting base system, they can be divided into binary, decimal, and N-ary counters; based on the increase or decrease of the value in the counter, they can be divided into adder counters, subtracter counters, and reversible counters; based on the different state transition times of each trigger in the counter, they can be divided into synchronous counters and asynchronous counters.

[0037] First Input First Output (FIFO): A memory structure widely used in chip design. A FIFO consists of a queue or array of memory cells. The first data written to the queue is also the first data read from it. In chip design, FIFOs serve multiple purposes, including temporary storage, synchronization between different clock domains, and data bit width adjustment.

[0038] During chip verification, it is necessary to verify the signal states of various signals within the module to be verified, including the signal states of the signals during and after the module is running. For example, for a counter contained within the module to be verified, during the operation of the module to be verified, it is necessary to verify whether the counter count changes according to the preset rules (for example, when receiving both an increment instruction and a decrement instruction, the counter count should remain unchanged); after the module to be verified has completed operation, it is necessary to verify whether the counter count is the final expected count (for example, whether it is the default initial value of 0).

[0039] The current industry practice relies on designers' familiarity with the code to manually compile signal lists for verifiers, who then manually check the signal states of the signals in the signal lists and align the results with those of the designers. This approach has many drawbacks. For example, manually compiling signal lists by designers cannot ensure the comprehensiveness and completeness of the signals; the verification process is complex and inefficient; different verifiers may use different inspection methods, making it impossible to form a unified standard; and once new verification requirements are introduced in the module, realignment is required, which is time-consuming and labor-intensive.

[0040] Based on this, the present application proposes a method for generating a verification file, which extracts key signals that need to be verified through keywords and automatically generates a verification file based on the key signals. The verification file can realize automatic verification of the module to be verified and has high verification efficiency and accuracy.

[0041] See also Figure 1 , Figure 1 1 is a flowchart of a method for generating a verification file provided by an exemplary embodiment of the present application. In some embodiments, the method is executed by a computer device and includes the following steps.

[0042] Step 101: extract key signals from the status indication signal of the module to be verified based on the keyword. The module to be verified is a hardware module to be verified in the chip. The status indication signal is a signal used to characterize the internal operating status of the module to be verified. The signal name of the key signal is related to the keyword.

[0043] Optionally, the module to be verified may include hardware modules of various functions and types in the chip.

[0044] For example only, the module to be verified may be a processor core module (such as a central processing unit or a digital signal processor).

[0045] For example only, the module to be verified may be a storage module (such as a random access memory, a read-only memory, or a flash memory).

[0046] For example only, the module to be verified may also be a communication interface module (such as a serial peripheral interface, an integrated circuit bus), an analog module (such as an analog-to-digital converter, a digital-to-analog converter), or any other possible complex functional module (such as a video codec module), etc.

[0047] Optionally, the specific type of the module to be verified may be any other possible type, and the number of modules to be verified may be one, two or more. This application does not impose any restrictions on the specific type and number of modules to be verified.

[0048] In some embodiments, the module to be verified has a hierarchy. For example, in a hardware description language such as Verilog or System Verilog, the hierarchy of the module to be verified is used to reflect the hierarchical relationship between different submodules in the module to be verified. The hierarchy can be embodied by a tree structure.

[0049] The status indication signal is a signal used to indicate the internal operating status of the module to be verified.

[0050] For example only, in the case where the module to be verified includes a counter, the state indication signal is a counter signal, and the signal state of the counter signal is used to represent the counting of the counter.

[0051] For example only, if the module to be verified includes a first-in, first-out queue (FIFO), the status indication signal includes a full signal and an empty signal. When the full signal is 0 and the empty signal is 1, it indicates that the FIFO is empty and the number of queue elements in the FIFO is 0; when the full signal is 1 and the empty signal is 0, it indicates that the FIFO is full and the number of queue elements in the FIFO is the maximum number.

[0052] For example only, the status indication signal of the module to be verified also includes an idle signal (idle signal). When the idle signal is 1, it indicates that the module to be verified is in an idle state; when the idle signal is 0, it indicates that the module to be verified is in a busy state.

[0053] In some embodiments, the status indication signal may be a procedural signal generated during the operation of the module to be verified, or may be a final signal generated after the module to be verified completes its operation.

[0054] Optionally, the specific types of the above-mentioned status indication signals are only examples, and those skilled in the art may set the status indication signals of the verification module according to actual needs, without any limitation thereto.

[0055] In some embodiments, the status indication signal has a corresponding path in the hierarchy of the module to be verified. For example, the path of the status indication signal s1 in the hierarchy of the module to be verified is dut.abc, and the path of the status indication signal s2 in the hierarchy of the module to be verified is dut.out.

[0056] In some embodiments, the keyword is used to filter various status indication signals of the module to be verified to obtain a key signal, wherein the signal name of the key signal is related to the keyword.

[0057] In one possible scenario, the signal name of the critical signal includes the keyword.

[0058] In another possible scenario, the signal name of the key signal contains a word that has the same or similar meaning as the keyword (such as a synonym or a near synonym).

[0059] For example only, when there is a target word in the signal name of the key signal, the target word is completely consistent with the keyword, or the similarity between the target word and the keyword is greater than a similarity threshold, the computer device determines that the signal name of the key signal is related to the keyword.

[0060] In another possible scenario, the signal name of the key signal includes the abbreviation of the keyword (for example, the keyword is counter, and its abbreviation is cnt).

[0061] Optionally, the keyword may be a word pre-set by the computer device. For example, the verification personnel may set the keyword according to the verification requirements.

[0062] For example only, when the verification requirement includes verifying the working condition of a counter in the module to be verified, the keywords may include "counter" and "cnt" (abbreviation).

[0063] For example only, when the verification requirement includes verifying the working condition of the first-in-first-out queue in the verification module, the keyword may include "full" or "empty".

[0064] For example only, when the verification requirement includes verifying the idle or busy state of the module to be verified, the keyword may include "idle".

[0065] Regarding the specific method for extracting key signals from the status indication signals of the module to be verified based on keywords, in one possible implementation, the computer device may scan the signal names of the status indication signals of the module to be verified line by line according to a first script, thereby determining the status indication signals whose scanned signal names are associated with the keywords as key signals. For more information about the first script, please refer to the embodiments and related descriptions below and are not further elaborated here.

[0066] Regarding the specific method of extracting key signals from the status indication signals of the module to be verified based on keywords, in some embodiments, the computer device can also obtain the signal paths of each status indication signal, filter out the key signal paths therefrom, and determine the signal corresponding to the key signal path as the key signal.

[0067] In some embodiments, after extracting the key signal from the status indication signal of the module to be verified based on the keyword, the computer device may write the key signal path of the key signal into a signal path file and store it.

[0068] For example only, the signal path file may be a TXT file (Text File) or a CSV file (Comma-Separated Values), and the signal path file contains key signal paths corresponding to each key signal of the module to be verified.

[0069] Step 102 : generating a verification file of the module to be verified based on the key signal, wherein the verification file is used to check the signal status of the key signal generated by the module to be verified during operation.

[0070] Regarding the specific method for generating a verification file for a module to be verified based on key signals, in one possible implementation, a computer device may determine the signal type corresponding to the key signal of the module to be verified and, based on the signal type, generate a check statement corresponding to the key signal. The check statement is used to verify whether the key signal generated by the module to be verified during operation meets expectations. Different key signals of different signal types correspond to different check statements. The computer device generates the verification file based on the check statements corresponding to each key signal.

[0071] For example only, the key signal is the counter signal, and the signal type of the counter signal is the first signal type. The check statement corresponding to the first signal type can be used to check whether the final signal state of the counter signal generated by the module to be verified after the module to be verified is completed indicates that the final count of the counter is 0, or the check statement can be used to check whether the signal state of the counter signal indicates that the count of the counter changes according to a preset rule during the operation of the module to be verified (for example, when an increment instruction and a decrement instruction are received at the same time, the count should remain unchanged).

[0072] For example only, the key signal is the empty signal, the signal type of the empty signal is the second signal type, and the check statement corresponding to the second signal type can be used to check whether the final signal state of the empty signal generated by the module to be verified after the module to be verified is completed indicates that the first-in-first-out queue is empty.

[0073] For example only, the key signal is the idle signal, the signal type of the idle signal is the third signal type, and the check statement corresponding to the third signal type can be used to check whether the final signal state of the idle signal generated by the module to be verified after the module to be verified has completed execution indicates that the module to be verified is in an idle state.

[0074] Regarding the specific method of generating a verification file for a model to be verified based on a key signal, in another possible implementation, the computer device can also generate a verification file based on the key signal using a large language model (LLM). For example, the signal name and prompt word of the key signal are input into the large language model to obtain a verification file generated by the large language model. The prompt word is used to prompt the large language model to generate a verification file for the module to be verified.

[0075] In some embodiments, the computer device may execute a second script, where the second script is used to generate a verification file of the module to be verified based on a key signal path of the key signal.

[0076] In addition, those skilled in the art may also adopt an automated generation method to generate verification files based on key signals according to actual needs, and there is no limitation to this.

[0077] Optionally, the verification file is a System Verilog file (SV file).

[0078] For example only, the verification file for checking the final signal state of the key signal generated after the verification module is completed is final_check.sv, and the verification file for checking the real-time signal state of the counter signal generated during the operation of the verification module is counter_check.sv.

[0079] In some embodiments, the generated verification file is used to automatically verify the module to be verified. For example, a computer device can mount the module to be verified into a verification environment via a macro file and execute assertion check statements to check the signal status of key signals generated during the operation of the module to be verified to obtain a verification result.

[0080] In some embodiments, if the verification result indicates a verification failure, the computer device may write verification failure information into a verification failure file for the designer to review and improve the design. The verification failure information may include information such as the key signal that failed verification and its key signal path.

[0081] To sum up, based on keywords, key signals whose signal names are related to the keywords are extracted from the status indication signals of the module to be verified, which can realize the automatic extraction of key signals, avoid the designer's manual sorting of signal lists, and ensure the comprehensiveness and accuracy of the key signal extraction; based on the key signals, a verification file of the module to be verified is generated. Since the verification file is used to check the signal status of the key signals generated by the module to be verified during operation, the generated verification file can realize automatic verification of the module to be verified; at the same time, since the verification file can be generated automatically, the tedious operation of manual verification by the verifier is avoided, and the verification efficiency of the module to be verified is improved.

[0082] Regarding the specific method in which a computer device extracts a key signal from a status indication signal of a module to be verified based on a keyword, in some embodiments, the computer device scans the signal name of the status indication signal of the module to be verified, and extracts the currently scanned status indication signal as the key signal when the signal name of the currently scanned status indication signal is related to the keyword.

[0083] In some embodiments, the steps of scanning the signal name of the status indication signal of the module to be verified, and extracting the currently scanned status indication signal as the key signal when the signal name of the currently scanned status indication signal is related to the keyword, are achieved by executing the first script.

[0084] In some embodiments, the computer device injects keywords into the first script.

[0085] The first script is used to filter the status indication signal of the module to be verified based on the keyword to obtain the key signal whose signal name is related to the keyword.

[0086] Optionally, the keyword can be a word pre-set by the computer device. For example, the verification personnel can set the keyword according to the verification requirements. For example only, when the verification requirements include verifying the working condition of the counter in the module to be verified, the keywords may include "counter" and "cnt" (abbreviation). For example only, when the verification requirements include verifying the working condition of the first-in-first-out queue in the module to be verified, the keywords may include "full" or "empty". For example only, when the verification requirements include verifying the idle and busy status of the module to be verified, the keywords may include "idle". In addition, the keyword can also be any other possible word set according to the verification requirements. The keyword may include one or more characters, without limitation.

[0087] See also Figure 2 , Figure 2 It is a schematic diagram of the script code of the first script provided by an exemplary embodiment of the present application.

[0088] Optionally, the first script is used to filter, based on keywords, the status indication signal of the module to be verified to obtain key signals whose signal names contain the keywords.

[0089] Since the first script is used to filter the status indication signals of the modules to be verified based on keywords to obtain key signals whose signal names contain the keywords, the first script may also be called file_filter.py.

[0090] Figure 2 The first script in is used to filter the key signals of the input file input_file based on keywords, filter out the key signals containing the keywords, and save the key signal paths of the key signals to the output file final_check_sglist.txt.

[0091] Figure 2Lines 1 to 5 of the script code of the first script import the sys file that stores the input file parameters and use len(sys.argv)!=2 to determine whether the number of input file parameters in the passed-in sys file is not 2. This is used to require that an input file parameter must be passed in when running the first script. If no input file parameter is passed in, the execution of the first script will be terminated.

[0092] Figure 2 Line 7 of the script code of the first script specifies that the second parameter (index 1) of the sys file is assigned to the input file input_file, and line 8 specifies that output_file = "final check sqlist.txt" is used as the file name of the output file.

[0093] Regarding the method of obtaining the input file input_file, in some embodiments, the computer device may obtain all status indication signals of the module to be verified, and use all status indication signals of the module to be verified as the input file input_file.

[0094] In a possible implementation, the computer device may obtain all status indication signals in the module to be verified through a signal search app built into the Verdi automatic debugging platform.

[0095] In some embodiments, the computer device can determine the status indication signals of each level in the hierarchy of the module to be verified based on the hierarchy of the module to be verified; and execute the first script to scan the signal names of the status indication signals of each level of the module to be verified line by line.

[0096] See also Figure 3 , Figure 3 This is a schematic diagram of obtaining all status indication signals in a module to be verified through the Verdi automatic debugging platform, provided by an exemplary embodiment of the present application.

[0097] like Figure 3As shown, a computer device triggers a built-in app control in the Verdi automatic debugging platform through an automated tool, calling a signal search program 321 (signal search app) in the built-in app page 320. The Verdi automatic debugging platform displays a signal search page 330. In the signal search page 330, the automated tool can set search parameters, such as search rules, search scopes, and output directories (output.log). The search scope is the hierarchy of the module to be verified, such as tb_top.dut_top.m_mcu. The search scope instructs the signal search program 321 to search for status indication signals at each level in the module to be verified.

[0098] After the signal search program 321 finds all the status indication signals in the module to be verified, the computer device uses all the status indication signals of the module to be verified as the input file input_file in the first script, and scans the signal names of the status indication signals at each level of the module to be verified line by line by executing the first script.

[0099] Figure 2 Line 9 of the script code of the first script is used to inject keywords into the first script. For example, the keywords in the keyword list keywords in line 9 include "idle", "full", "cnt", "count", and "empty".

[0100] Figure 2 Lines 11 to 21 of the script code of the first script obtain key signals through the try-except block.

[0101] In the try block, open the input file input_file in read-only mode and the output file output_file in write mode, then traverse each line of the input file and use rstrip() to remove the specified characters at the end of the line. If the current scan line contains the string 'tb_top.dut.top.m_cu.mt_cu' (representing that the signal is the status indication signal of any level in the module to be verified), and the current scan line contains any keyword in the keyword list, the current scan line is processed, the status indication signal after 'Signal:' is extracted as the key signal, and the key signal path of the key signal is written to the output file.

[0102] In one possible scenario, since the hierarchical structure of the module to be verified may contain multiple levels, when the verification requirement is to verify only the level to be verified in the module to be verified, the computer device can determine the level to be verified from the hierarchical structure of the module to be verified, and scan the signal name of the status indication signal of the level to be verified of the module to be verified.

[0103] The to-be-verified level refers to all or part of the levels in the hierarchy of the to-be-verified module.

[0104] For example, the computer device can modify the tb_top.dut.top.m_cu.mt_cu (i.e., the hierarchical structure of the module to be verified) in the statement if'tb_top.dut.top.m_cu.mt_cu'in stripped_line in line 15 of the script code of the first script to the path corresponding to the level (partial level) to be verified in the module to be verified, thereby realizing line-by-line scanning of the signal name of the status indication signal of the level to be verified of the module to be verified.

[0105] In the except block, if a FileNotFoundError exception occurs, an error message is displayed.

[0106] In some embodiments, the computer device can also convert the output file final_check_sqlist.txt into files of other formats. For example, after the computer device confirms the completeness and correctness of the key signal paths of the key signals in the output file final_check_sqlist.txt, it converts the final_check_sqlist.txt file into a signal path file final_check_sqlist.csv, which is used to record the key signal paths of each key signal in the module to be verified.

[0107] In this embodiment, by executing the first script and scanning the signal name of the status indication signal of the module to be verified, key signals whose signal names are related to the keywords can be filtered from the status indication signal of the module to be verified based on keywords, which can be used for subsequent generation of verification files, thereby realizing automatic filtering of key signals and achieving high efficiency and accuracy in extracting key signals.

[0108] After extracting the key signal, the computer device generates a verification file for the module to be verified based on the key signal.

[0109] See also Figure 4 , Figure 4 This is a flowchart of generating a verification file of a module to be verified based on a key signal provided by an exemplary embodiment of the present application. The flow includes the following steps.

[0110] Step 410 : Write the key signal path of the key signal into a signal path file. The key signal path is the path of the key signal in the hierarchical structure of the module to be verified.

[0111] Exemplarily, the computer device writes the signal path of the key signal of the module to be verified obtained by filtering the first script into the output file final_check_sqlist.txt, and generates a signal path file (csv file) based on the output file, and records the key signal path of each key signal in the module to be verified through the csv file.

[0112] The key signal path is the path of the key signal in the hierarchical structure of the module to be verified. For example, the path of the key signal s3 in the hierarchical structure of the module to be verified is dut.abcd.

[0113] In some embodiments, the computer device executes the second script, reads the signal path file, and generates a verification file of the module to be verified based on the signal path file.

[0114] The second script is used to generate a verification file of the module to be verified based on the signal path file.

[0115] Step 420 : Determine the signal type of the key signal corresponding to the key signal path according to the key signal path in the read signal path file.

[0116] In some embodiments, the steps of reading the signal path file and generating a verification file of the module to be verified based on the signal path file are implemented by executing a second script.

[0117] Regarding the specific method in which a computer device determines the signal type of a key signal corresponding to a key signal path based on the key signal path in the signal path file, in one possible implementation method, the computer device determines the inclusion of a to-be-verified word in the key signal path based on the key signal path in the signal path file, where the to-be-verified word is a word associated with the item to be verified.

[0118] The word to be verified can also be called a "string", which is a word associated with the item to be verified.

[0119] For example only, when the item to be verified of the module to be verified is a counter, the word string1 to be verified is "counter"; when the item to be verified of the module to be verified is a first-in-first-out queue, the word string2 to be verified is "FIFO"; when the item to be verified of the module to be verified is the idle or busy state of the module to be verified, the word string3 to be verified is "IDLE".

[0120] Regarding the specific form of the second script, in some embodiments, the second script includes a main function, a process_signal_sel function, and a process_csv function that are nested in sequence.

[0121] Among them, the main function is used to specify the module name, hierarchical structure and words to be verified of the module to be verified.

[0122] See also Figure 5 , Figure 5 This is a schematic diagram of the script code of the main function in the second script provided by an exemplary embodiment of the present application.

[0123] like Figure 5 As shown, the first line of the script code of the main function specifies the name of the main function; the second line specifies the module name of the module to be verified as "i_cu"; the third line specifies the hierarchical structure of the module to be verified as "tb_top.dut_top.m_cu.mt_cu"; the fourth to sixth lines specify three words to be verified, string1 = "counter", string2 = "FIFO", and string3 = "IDLE", respectively; the seventh line calls the process_signal_sel function, and takes the module name, hierarchical structure, and three specified words to be verified of the module to be verified as inputs of the process_signal_sel function.

[0124] See also Figure 6 , Figure 6 This is a schematic diagram of the script code of the process_signal_sel function in the second script provided by an exemplary embodiment of the present application.

[0125] The process_signal_sel function in the second script is used to automatically process the CSV file based on the module name, hierarchical structure and verification word of the module to be verified, and finally generate the verification file of the module to be verified.

[0126] like Figure 6 Lines 1 to 2 of the script code of the process_signal_sel function define that the input of the process_signal_sel function includes the module name, hierarchical structure and the word to be verified (srting1, srting2, srting3) of the module to be verified.

[0127] Figure 6 Lines 3 to 6 use os.getenv to get the environment variable PRJDIR. If the environment variable is not set, the program will report an error and terminate.

[0128] Figure 6Lines 8 to 11 use os.path.join to concatenate the path signal_sel_dir (the full path is PRJDIR / bin / signal_sel). If it is an invalid directory, an error will be reported. The full path signal_sel_dir is the default path for storing CSV files.

[0129] Figure 6 Line 13 prints the full path.

[0130] Figure 6 Lines 15 and 16 open the final_check.sv and counter_check.sv files, which are then used to output the processing results of the CSV files.

[0131] Figure 6 Lines 15 to 20 use os.walk to traverse all files under the full path, filter out files ending with .csv, and concatenate the full path of the file (root is the path of the CSV file, file is the file name of the CSV file).

[0132] Figure 6 Line 21 prints the path to the CSV file.

[0133] Figure 6 Lines 22 to 32: Call the process_csv function, pass in the path of the CSV file, the module name of the module to be verified, the hierarchical structure, and three words to be verified, and generate verification files (including final_check_file and counter_file) by calling the process_csv function.

[0134] See also Figure 7 , Figure 7 It is a schematic diagram of determining the signal type of a key signal corresponding to a key signal path in the script code of the process_csv function provided by an exemplary embodiment of the present application.

[0135] like Figure 7 As shown, lines 1 to 2 of the script code of the process_csv function define the input of the process_csv function, including the path of the CSV file, the module name of the module to be verified, the hierarchical structure, three words to be verified (string1 to string3), the separator, and define the output files as final_check_file and counter_file.

[0136] Lines 5 to 10 of the script code of the process_csv function use csv.reader to read the key signal paths of the key signals contained in the CSV file line by line.

[0137] In some embodiments, the computer executes a second script to determine, based on the key signal path in the signal path file, whether the key signal path includes the target word to be verified. If the key signal path includes the target word to be verified, the target signal type corresponding to the target word to be verified is determined as the signal type of the key signal corresponding to the key signal path.

[0138] Lines 11 to 17 of the script code of the process_csv function define that when the read key signal path contains the first to-be-verified word sting1 = "counter", the signal type of the key signal corresponding to the key signal path is determined to be the first signal type (i.e., mode = 1); when the read key signal path contains the second to-be-verified word sting2 = "FIFO", the signal type of the key signal corresponding to the key signal path is determined to be the second signal type (i.e., mode = 2); when the read key signal path contains the third to-be-verified word sting3 = "IDLE", the signal type of the key signal corresponding to the key signal path is determined to be the third signal type (i.e., mode = 3).

[0139] Step 430 , based on the signal type of the critical signal, generates an assertion check statement corresponding to the critical signal, the assertion check statement is used to check the signal status of the critical signal generated by the module to be verified during operation, wherein different assertion check statements correspond to critical signals of different signal types.

[0140] See also Figure 8 , Figure 8 It is a schematic diagram of generating a first assertion check statement corresponding to a first signal type in the script code of the process_csv function provided by an exemplary embodiment of the present application.

[0141] like Figure 8 As shown, when the signal type of the key signal is the first signal type (i.e., mode == 1), the computer device generates a first assertion check statement final_cnt_check by executing the script code of the process_csv function. At the same time, by executing the script code of the process_csv function, a first assertion check statement cnt incdec check is also generated.

[0142] See also Figure 9 , Figure 9 It is a schematic diagram of generating a second assertion check statement corresponding to a second signal type and a third assertion check statement corresponding to a third signal type in the script code of the process_csv function provided by an exemplary embodiment of the present application.

[0143] like Figure 9 As shown, when the signal type of the critical signal is the second signal type (ie, mode == 2), the computer device generates a second assertion check statement final_empty_check by executing the script code of the process_csv function.

[0144] like Figure 9 As shown, when the signal type of the critical signal is the third signal type (ie, mode == 3), the computer device generates a third assertion check statement final idlecheck by executing the script code of the process_csv function.

[0145] For the specific contents of the first assertion check statement, the second assertion check statement, and the third assertion check statement, please refer to the embodiments and related descriptions below, which will not be repeated here.

[0146] Step 440: Generate a verification file for the module to be verified based on the assertion check statements corresponding to each key signal.

[0147] In a possible implementation, the computer device may combine the assertion check statements corresponding to the key signals in the module to be verified into a verification file of the module to be verified.

[0148] In another possible implementation, the computer device may further combine assertion check statements for verifying the signal states of key signals generated during the operation of the module to be verified into a procedural verification file (e.g., counter_check.sv), and combine assertion check statements for verifying the final signal states of key signals generated after the module to be verified completes its operation into a final verification file (e.g., final_check.sv).

[0149] In this embodiment, by executing the second script, the signal type of the key signal corresponding to the key signal path in the signal path file is determined, and based on the signal type of the key signal, the assertion check statement corresponding to the key signal is generated. This allows the assertion check statement in the verification file to be used to check the signal status of the key signal generated in the verification module process, thereby realizing the automatic generation of the verification file and improving the verification efficiency and verification quality of the verification module.

[0150] See also Figure 10 , Figure 10 It is a schematic diagram of generating an assertion check statement corresponding to a critical signal when the signal type of the critical signal is the first signal type, the second signal type, or the third signal type, provided by an exemplary embodiment of the present application.

[0151] like Figure 10As shown, the computer device reads the signal path file (CSV file) by executing the second script, and traverses the key signal path in the signal path file line by line to determine the signal type of the key signal corresponding to the key signal path.

[0152] In some embodiments, when the critical signal path includes the target word to be verified, the computer device determines the target signal type corresponding to the target word to be verified as the signal type of the critical signal corresponding to the critical signal path.

[0153] Optionally, when the critical signal path includes a first word to be verified (string 1), it is determined that the signal type of the critical signal corresponding to the critical signal path is the first signal type (mode=1), and the first word to be verified is a word associated with the counter.

[0154] For example only, the first word to be verified (string 1) is "counter".

[0155] Optionally, when the critical signal path includes a second word to be verified (string 2), the signal type of the critical signal corresponding to the critical signal path is determined to be the second signal type (mode=2), and the second word to be verified is a word associated with the queue.

[0156] For example only, the second word to be verified (string 2) is "FIFO".

[0157] Optionally, when the critical signal path includes a third word to be verified (string 3), the signal type of the critical signal corresponding to the critical signal path is determined to be a third signal type (mode=3), and the third word to be verified is a word associated with the idle or busy state of the module to be verified.

[0158] For example only, the third word to be verified (string 3) is "IDLE".

[0159] The following describes specific contents of generating assertion check statements corresponding to critical signals when the signal type of the critical signal is the first signal type, the second signal type, or the third signal type.

[0160] (1) First signal type (mode=1).

[0161] In some embodiments, the key signal includes a counter signal, and a signal state of the counter signal represents a count of the counter.

[0162] Merely by way of example, a signal state of 5 of the counter signal characterizes a count of 5 in the counter.

[0163] In some embodiments, the computer device generates a first assertion checking statement corresponding to the counter signal based on a first signal type of the counter signal.

[0164] The first assertion check statement is used to check whether the signal state of the counter signal generated by the module to be verified indicates that the count of the counter is the expected count, and / or to check whether the signal state of the counter signal indicates that the count of the counter changes according to a preset rule.

[0165] In a possible scenario, the first assertion check statement is used to check whether the final signal state of the counter signal generated by the module to be verified after completion of execution represents that the final count of the counter is the final expected count.

[0166] Optionally, the final expected count is a value preset by the computer device, such as 0.

[0167] For example, when the module to be verified is completed, if the final signal state of the counter signal represents that the final count is the final expected count of 0, then it is determined that the verification of the counter in the module to be verified is successful; otherwise (for example, if the final signal state of the counter signal represents that the final count is not the final expected count), the verification fails.

[0168] In some embodiments, when the first assertion check statement is used to check the final signal state of the counter signal generated by the module to be verified after completion of execution, and whether it represents that the final count of the counter is the final expected count, the first assertion check statement may also be called final_cnt_check.

[0169] In another possible scenario, the first assertion check statement may also be used to check whether the signal state of the counter signal represents that the count of the counter changes according to a preset rule.

[0170] For example only, the preset rules for the count change of the counter include at least one of the following: when an increment instruction is received, the count of the counter is incremented; when a decrement instruction is received, the count of the counter is decremented; when an increment instruction and a decrement instruction are received at the same time, the count of the counter remains unchanged.

[0171] In some embodiments, when the first assertion check statement is used to check whether the signal state of the counter signal represents that the count of the counter changes according to a preset rule, the first assertion check statement may also be called cnt_inc_dec_check.

[0172] (2) Second signal type (mode=2).

[0173] In some embodiments, the critical signal includes a queue signal, and the signal state of the queue signal represents the number of queue elements.

[0174] For example only, the queue signal is a first-in-first-out queue signal, including at least one of an empty signal and a full signal. When the empty signal is 1 and the full signal is 0, it indicates that the number of queue elements is 0 and the first-in-first-out queue is empty. When the empty signal is 0 and the full signal is 1, it indicates that the number of queue elements is the maximum number and the first-in-first-out queue is full.

[0175] In some embodiments, the computer device generates a second assertion checking statement corresponding to the queue signal based on the second signal type of the queue signal.

[0176] The second assertion check statement is used to check whether the signal state of the queue signal generated by the module to be verified indicates that the number of queue elements is the expected number.

[0177] In a possible scenario, the second assertion check statement is used to check whether the final signal state of the queue signal generated by the module to be verified after completion of execution indicates that the number of queue elements is the final expected number.

[0178] Optionally, the final expected number is a number preset by the computer device, such as 0.

[0179] For example only, when the module to be verified is completed, if the final signal state of the generated empty signal is 1, indicating that the number of queue elements is the final expected number 0, then the verification of the first-in-first-out queue in the module to be verified is successful; otherwise (for example, the final signal state of the empty signal is 0), the verification fails.

[0180] In some embodiments, when the second assertion check statement is used to check the final signal state of the queue signal generated by the module to be verified after completion of execution, and whether it indicates that the number of queue elements is the final expected number, the second assertion check statement can also be called final_empty_check.

[0181] (3) The third signal type (mode=3).

[0182] In some embodiments, the critical signal includes an idle signal, and the signal state of the idle signal represents the idle or busy state of the module to be verified.

[0183] For example only, the idle signal is an idle signal. When the signal state of the idle signal is 1, it indicates that the module to be verified is in an idle state; when the signal state of the idle signal is 0, it indicates that the module to be verified is in a busy state.

[0184] In some embodiments, the computer device generates a third assertion check statement corresponding to the idle signal based on the third signal type of the idle signal.

[0185] The third assertion check statement is used to check whether the signal state of the idle signal generated by the module to be verified indicates that the module to be verified is in an expected idle or busy state.

[0186] In a possible scenario, the third assertion check statement is used to check whether the final signal state of the idle signal generated after the module to be verified is completed represents that the module to be verified is in the final expected idle or busy state.

[0187] Optionally, the final expected busy / idle state is a signal state preset by the computer device, such as an idle state (represented by an idle signal being 1).

[0188] For example only, when the module to be verified is completed, if the final signal state of the idle signal generated is 1, indicating that the module to be verified is in an idle state after completion of the operation, then the idle and busy state verification of the module to be verified is successful; otherwise (for example, the final signal state of the idle signal is 0), the verification fails.

[0189] In some embodiments, when the third assertion check statement is used to check the final signal state of the idle signal generated after the module to be verified is completed, whether it indicates that the module to be verified is in the final expected idle state, the third assertion check statement can also be called final_idle_check.

[0190] In some embodiments, the computer device generates a verification file for the module to be verified based on the assertion check statements corresponding to each key signal.

[0191] For example only, the computer device determines the first assertion check statement cnt_inc_dec_check corresponding to the counter signal (counter signal) as the first verification file counter_check.sv of the module to be verified.

[0192] For example only, the computer device determines the first assertion check statement final_cnt_check corresponding to the counter signal (counter signal), the second assertion check statement final_empty_check corresponding to the queue signal (empty signal), and the third assertion check statement final_idle_check corresponding to the idle signal (idle signal) as the second verification file final_check.sv of the module to be verified.

[0193] In this embodiment, based on the signal type of the key signal, an assertion check statement corresponding to the key signal is generated, so that the verification file containing the assertion check statement can be used to check the signal status of the key signal generated during the operation of the verification module to obtain accurate verification results.

[0194] See also Figure 11 , Figure 11 It is a schematic diagram of the generation and use of a verification file provided by an exemplary embodiment of the present application.

[0195] like Figure 11 As shown, when the design of the module to be verified is completed in the chip design phase, the computer device extracts the key signal containing the keyword from the status indication signal of the module to be verified by executing the first script, and writes the key signal path of the key signal into the signal path file (CSV file).

[0196] Next, the computer device reads the key signal path of each key signal in the signal path file by executing the second script, and generates a verification file (SV file) of the module to be verified according to the key signal path.

[0197] After obtaining the verification file, the computer device may mount the verification file to the verification environment.

[0198] The verification environment is used to simulate the execution environment of the verification use case.

[0199] For example only, the verification environment may be a VCS (Verilog Compiled Simulator) environment, wherein VCS is a high-performance Verilog simulator; in addition, those skilled in the art may also select any other possible verification environment, without limitation.

[0200] Optionally, the computer device may mount the verification file to the verification environment in the form of a macro file.

[0201] In some embodiments, during the process of executing verification use cases in the verification environment, the computer device obtains key signals generated by the module to be verified during operation, and executes assertion check statements in the verification file to check the signal status of the key signals to obtain verification results.

[0202] In some embodiments, the verification case includes instructions input into the module to be verified. By way of example only, the verification case includes increment instructions and decrement instructions input into a counter in the module to be verified. By way of example only, the verification case includes instructions input into a first-in-first-out queue to add queue elements, delete queue elements, or modify queue elements. By way of example only, the verification case includes instructions input into the module to be verified to change the idle or busy status of the module to be verified. In addition, those skilled in the art may further set the specific content of the verification case based on actual verification requirements, without limitation thereto.

[0203] For example only, during the execution of a verification use case in a verification environment, the computer device obtains a counter signal generated by the module to be verified during operation, and checks whether the count indicated by the signal state of the counter signal changes according to a preset rule to obtain a verification result.

[0204] For example only, when the verification environment completes the verification use case, the computer device obtains the counter signal generated by the module to be verified after the operation is completed, and checks whether the count indicated by the final signal state of the counter signal is the final expected count to obtain the verification result.

[0205] For example only, when the verification environment completes the execution of the verification use case, the computer device obtains the empty signal generated by the module to be verified after the operation is completed, and obtains the verification result based on whether the number of queue elements indicated by the final signal state of the empty signal is the final expected number.

[0206] For example only, when the verification environment completes the execution of the verification use case, the computer device obtains the idle signal generated by the module to be verified after the operation is completed, and obtains the verification result based on whether the x idle-busy state indicated by the final signal state of the idel signal is the final expected idle-busy state.

[0207] In some embodiments, after mounting the verification file to the verification environment and obtaining the verification results, the computer device can feed back the verification results to the designer for result alignment, so that the designer can re-debug and re-design the module to be verified if the verification fails.

[0208] See also Figure 12 , Figure 12 FIG1 is a schematic diagram of a computer system provided by an exemplary embodiment of the present application, wherein the computer system includes a computer device 1210 and a verification environment 1220 .

[0209] Computer device 1210 is a device used to execute the verification file generation method provided herein. In some embodiments, computer device 1210 extracts key signals from the status indication signal of module to be verified 1201 based on keywords and generates verification file 1202 corresponding to module to be verified 1201 based on the key signals. The assertion check statements contained in verification file 1202 are used to check the signal status of key signals generated by module to be verified 1201 during operation.

[0210] Verification environment 1220 is used to simulate the execution environment of verification cases 1203. Optionally, verification environment 1220 can comprehensively test various modules 1201 to be verified (such as modules with various functions and types in chip design). Optionally, verification environment 1220 includes a series of pre-defined verification cases 1203. Verification cases 1203 cover different input conditions, edge cases, and abnormal scenarios.

[0211] In some embodiments, the computer device 1210 and the verification environment 1220 are connected to each other via a wired or wireless network. In some embodiments, the computer device 1210 is used to mount the verification file 1202 to the verification environment 1220. In addition, the computer device 1210 can also transmit the data and configuration parameters required for verification to the verification environment 1220 to ensure that the verification environment can start and run normally. During the execution of the verification case 1203, the verification environment 1220 will feedback the key signals generated by the module to be verified 1201 to the computer device 1210. In some embodiments, during the execution of the verification case 1203 in the verification environment 1220, the computer device 1210 obtains the key signals generated by the module to be verified 1201 during operation, executes the assertion check statements in the verification file 1202, checks the signal status of the key signals, and obtains the verification result 1204. In some embodiments, the computer device 1210 is also used to analyze and process the verification result 1204. Once an error or abnormality is found during the verification process, an alarm will be issued in a timely manner, and a detailed verification report will be generated to provide a basis for subsequent problem investigation and optimization.

[0212] It should be noted that the above embodiment only describes the general architecture of the computer system. The system may also include more or fewer components, or combine certain components, and this embodiment does not limit this.

[0213] See also Figure 13 , Figure 13 This is a block diagram of a device for generating a verification document provided by an exemplary embodiment of the present application. The device includes:

[0214] An extraction module 1301 is configured to extract a key signal from a status indication signal of a module to be verified based on a keyword, wherein the module to be verified is a hardware module to be verified in a chip, the status indication signal is a signal representing an internal operating state of the module to be verified, and the signal name of the key signal is related to the keyword;

[0215] The generating module 1302 is configured to generate a verification file of the module to be verified based on the key signal, wherein the verification file is used to check the signal status of the key signal generated by the module to be verified during operation.

[0216] Optionally, the extraction module 1301 is configured to:

[0217] Scan the signal name of the status indication signal of the module to be verified;

[0218] In a case where the signal name of the currently scanned state indication signal is related to the keyword, the currently scanned state indication signal is extracted as the key signal.

[0219] Optionally, the extraction module 1301 is configured to:

[0220] Determine a level to be verified from each level of the hierarchical structure of the module to be verified, wherein the level to be verified is all or part of the levels in the hierarchical structure;

[0221] Scan the signal name of the status indication signal of the to-be-verified layer of the to-be-verified module.

[0222] Optionally, the step of scanning the signal name of the status indication signal of the module to be verified, and extracting the currently scanned status indication signal as the key signal when the signal name of the currently scanned status indication signal is related to the keyword, is implemented by executing a first script; the extraction module 1301 is further used to:

[0223] The keyword is injected into the first script.

[0224] Optionally, the generating module 1302 is configured to:

[0225] Writing a key signal path of the key signal into a signal path file, wherein the key signal path is a path of the key signal in the hierarchical structure of the module to be verified;

[0226] The signal path file is read, and the verification file of the module to be verified is generated based on the signal path file.

[0227] Optionally, the generating module 1302 is configured to:

[0228] Determining, according to the key signal path in the signal path file, a signal type of the key signal corresponding to the key signal path;

[0229] Based on the signal type of the key signal, generating the assertion check statement corresponding to the key signal, the assertion check statement being used to check the signal state of the key signal generated during the operation of the module to be verified, wherein different assertion check statements correspond to key signals of different signal types;

[0230] Based on the assertion check statements corresponding to the key signals, the verification file of the module to be verified is generated.

[0231] Optionally, the generating module 1302 is configured to:

[0232] determining, according to the key signal path in the signal path file, whether the key signal path includes a word to be verified, where the word to be verified is a word associated with an item to be verified;

[0233] In a case where the critical signal path includes a target word to be verified, the target signal type corresponding to the target word to be verified is determined as the signal type of the critical signal corresponding to the critical signal path.

[0234] Optionally, the generating module 1302 is configured to:

[0235] In a case where the critical signal path includes a first word to be verified, determining that the signal type of the critical signal corresponding to the critical signal path is a first signal type, and the first word to be verified is a word associated with a counter;

[0236] In a case where the critical signal path includes a second word to be verified, determining that the signal type of the critical signal corresponding to the critical signal path is a second signal type, and the second word to be verified is a word associated with a queue;

[0237] In the case that the critical signal path includes a third word to be verified, the signal type of the critical signal corresponding to the critical signal path is determined to be a third signal type, and the third word to be verified is a word associated with the idle or busy state of the module to be verified.

[0238] Optionally, the key signal includes a counter signal, and the signal state of the counter signal represents the count of the counter; the generating module 1302 is configured to:

[0239] Based on the first signal type of the counter signal, a first assertion check statement corresponding to the counter signal is generated, wherein the first assertion check statement is used to check whether the signal state of the counter signal generated by the module to be verified represents that the count of the counter is the expected count, and / or to check whether the signal state of the counter signal represents that the count of the counter changes according to a preset rule.

[0240] Optionally, the first assertion check statement is used to check whether the final signal state of the counter signal generated after the module to be verified is completed represents that the final count of the counter is the final expected count.

[0241] Optionally, the key signal includes a queue signal, and the signal state of the queue signal represents the number of queue elements; the generating module 1302 is configured to:

[0242] Based on the second signal type of the queue signal, a second assertion check statement corresponding to the queue signal is generated, and the second assertion check statement is used to check whether the signal state of the queue signal generated by the module to be verified indicates that the number of queue elements is the expected number.

[0243] Optionally, the second assertion check statement is used to check whether the final signal state of the queue signal generated after the module to be verified is completed indicates that the number of queue elements is the final expected number.

[0244] Optionally, the key signal includes an idle signal, and the signal state of the idle signal represents the idle or busy state of the module to be verified; the generating module 1302 is configured to:

[0245] Based on the third signal type of the idle signal, a third assertion check statement corresponding to the idle signal is generated, and the third assertion check statement is used to check whether the signal state of the idle signal generated by the module to be verified indicates that the module to be verified is in an expected idle or busy state.

[0246] Optionally, the third assertion check statement is used to check whether the final signal state of the idle signal generated after the module to be verified is completed represents that the module to be verified is in a final expected idle or busy state.

[0247] Optionally, the step of reading the signal path file and generating the verification file of the module to be verified based on the signal path file is achieved by executing a second script.

[0248] Optionally, the device further includes a verification module, the verification module being configured to:

[0249] Mounting the verification file to a verification environment, wherein the verification environment is used to simulate an execution environment of a verification use case;

[0250] During the process of executing the verification use case in the verification environment, obtaining the key signal generated during the operation of the module to be verified;

[0251] The assertion check statement in the verification file is executed to check the signal status of the key signal to obtain a verification result.

[0252] See also Figure 14 , Figure 14 14 is a schematic diagram of the structure of a computer device provided by an exemplary embodiment of the present application. Specifically, the computer device 1400 includes a central processing unit (CPU) 1401, a system memory 1404 including a random access memory 1402 and a read-only memory 1403, and a system bus 1405 connecting the system memory 1404 and the CPU 1401. The computer device 1400 also includes a basic input / output system (I / O system) 1406 that facilitates information transmission between various components within the computer, and a mass storage device 1407 for storing an operating system 1413, application programs 1414, and other program modules 1415.

[0253] The basic input / output system 1406 includes a display 1408 for displaying information and an input device 1409, such as a mouse or keyboard, for user input. Both the display 1408 and the input device 1409 are connected to the central processing unit 1401 via an input / output controller 1410 connected to the system bus 1405. The basic input / output system 1406 may also include an input / output controller 1410 for receiving and processing input from a variety of other devices, such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 1410 also provides output to a display screen, printer, or other types of output devices.

[0254] The mass storage device 1407 is connected to the central processing unit 1401 via a mass storage controller (not shown) connected to the system bus 1405. The mass storage device 1407 and its associated computer-readable media provide non-volatile storage for the computer device 1400. In other words, the mass storage device 1407 may include a computer-readable medium (not shown) such as a hard disk or drive.

[0255] Without loss of generality, the computer-readable medium may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer storage media include random access memory (RAM), read-only memory (ROM), flash memory or other solid-state storage technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, tape cassettes, magnetic tapes, disk storage or other magnetic storage devices. Of course, those skilled in the art will appreciate that the computer storage media are not limited to the above-mentioned ones. The above-mentioned system memory 1404 and mass storage device 1407 can be collectively referred to as memory.

[0256] The memory stores one or more programs, and the one or more programs are configured to be executed by one or more central processing units 1401. The one or more programs contain computer instructions for implementing the above-mentioned methods. The central processing unit 1401 executes the one or more programs to implement the methods provided by the above-mentioned various method embodiments.

[0257] According to various embodiments of the present application, the computer device 1400 may also be connected to a remote computer on a network such as the Internet for operation. That is, the computer device 1400 may be connected to a network 1412 via a network interface unit 1411 connected to the system bus 1405, or the network interface unit 1411 may be used to connect to other types of networks or remote computer systems (not shown).

[0258] The memory also includes one or more programs, which are stored in the memory and include steps executed by a computer device in the method provided in the embodiment of the present application.

[0259] The present application also provides a computer-readable storage medium having at least one computer instruction stored therein, which is loaded and executed by a processor to implement the method described in the above embodiment. Optionally, the computer-readable storage medium may include: ROM, RAM, solid-state drives (SSDs), or optical disks. Among them, RAM may include resistance random access memory (ReRAM) and dynamic random access memory (DRAM).

[0260] The present application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in various optional implementations of the above aspects.

[0261] The above description is merely an optional embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A method for generating a verification file, characterized in that: The method comprises: Extracting a key signal from a status indication signal of a module to be verified based on the keyword, wherein the module to be verified is a hardware module to be verified in a chip, the status indication signal is a signal used to represent an internal operating state of the module to be verified, and the signal name of the key signal is related to the keyword; Based on the key signal, a verification file of the module to be verified is generated, and the verification file is used to check the signal status of the key signal generated by the module to be verified during operation.

2. The method according to claim 1, characterized in that The step of extracting a key signal from a status indication signal of a module to be verified based on a keyword includes: Scan the signal name of the status indication signal of the module to be verified; In a case where the signal name of the currently scanned state indication signal is related to the keyword, the currently scanned state indication signal is extracted as the key signal.

3. The method according to claim 2, characterized in that The signal name of the status indication signal of the module to be verified during scanning includes: Determining a level to be verified from the hierarchical structure of the module to be verified, wherein the level to be verified is all or part of the levels in the hierarchical structure; Scan the signal name of the status indication signal of the to-be-verified layer of the to-be-verified module.

4. The method according to claim 2, characterized in that The steps of scanning the signal name of the status indication signal of the module to be verified, and extracting the status indication signal currently being scanned as the key signal when the signal name of the status indication signal currently being scanned is related to the keyword, are achieved by executing a first script; The method further comprises: The keyword is injected into the first script.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: Writing a key signal path of the key signal into a signal path file, wherein the key signal path is a path of the key signal in the hierarchical structure of the module to be verified; Generating a verification file of the module to be verified based on the key signal includes: The signal path file is read, and the verification file of the module to be verified is generated based on the signal path file.

6. The method according to claim 5, characterized in that The reading of the signal path file and generating the verification file of the module to be verified based on the signal path file includes: Determining, according to the key signal path in the signal path file, a signal type of the key signal corresponding to the key signal path; Based on the signal type of the key signal, generating an assertion check statement corresponding to the key signal, the assertion check statement being used to check the signal state of the key signal generated during the operation of the module to be verified, wherein different assertion check statements correspond to key signals of different signal types; Based on the assertion check statements corresponding to the key signals, the verification file of the module to be verified is generated.

7. The method according to claim 6, characterized in that The determining, according to the key signal path in the signal path file, the signal type of the key signal corresponding to the key signal path includes: determining, according to the key signal path in the signal path file, whether the key signal path includes a word to be verified, where the word to be verified is a word associated with an item to be verified; In a case where the critical signal path includes a target word to be verified, the target signal type corresponding to the target word to be verified is determined as the signal type of the critical signal corresponding to the critical signal path.

8. The method according to claim 7, characterized in that When the key signal path includes a target word to be verified, determining the target signal type corresponding to the target word to be verified as the signal type of the key signal corresponding to the key signal path includes at least one of the following: In a case where the critical signal path includes a first word to be verified, determining that the signal type of the critical signal corresponding to the critical signal path is a first signal type, and the first word to be verified is a word associated with a counter; In a case where the critical signal path includes a second word to be verified, determining that the signal type of the critical signal corresponding to the critical signal path is a second signal type, and the second word to be verified is a word associated with a queue; In the case that the critical signal path includes a third word to be verified, the signal type of the critical signal corresponding to the critical signal path is determined to be a third signal type, and the third word to be verified is a word associated with the idle or busy state of the module to be verified.

9. The method according to claim 6, characterized in that The key signal includes a counter signal, and the signal state of the counter signal represents the count of the counter; and generating an assertion check statement corresponding to the key signal based on the signal type of the key signal includes: Based on the first signal type of the counter signal, a first assertion check statement corresponding to the counter signal is generated, wherein the first assertion check statement is used to check whether the signal state of the counter signal generated by the module to be verified represents that the count of the counter is the expected count, and / or to check whether the signal state of the counter signal represents that the count of the counter changes according to a preset rule.

10. The method according to claim 9, characterized in that The first assertion check statement is used to check whether the final signal state of the counter signal generated by the module to be verified after completion of operation represents that the final count of the counter is the final expected count.

11. The method according to claim 6, characterized in that The key signal includes a queue signal, and the signal state of the queue signal represents the number of queue elements; generating an assertion check statement corresponding to the key signal based on the signal type of the key signal includes: Based on the second signal type of the queue signal, a second assertion check statement corresponding to the queue signal is generated, and the second assertion check statement is used to check whether the signal state of the queue signal generated by the module to be verified indicates that the number of queue elements is the expected number.

12. The method according to claim 11, characterized in that The second assertion check statement is used to check whether the final signal state of the queue signal generated by the module to be verified after completion of execution indicates that the number of queue elements is the final expected number.

13. The method according to claim 6, characterized in that The key signal includes an idle signal, and the signal state of the idle signal represents the idle or busy state of the module to be verified; and generating an assertion check statement corresponding to the key signal based on the signal type of the key signal includes: Based on the third signal type of the idle signal, a third assertion check statement corresponding to the idle signal is generated, and the third assertion check statement is used to check whether the signal state of the idle signal generated by the module to be verified indicates that the module to be verified is in an expected idle or busy state.

14. The method according to claim 13, characterized in that The third assertion check statement is used to check whether the final signal state of the idle signal generated after the module to be verified is completed indicates that the module to be verified is in the final expected idle or busy state.

15. The method according to claim 5, characterized in that The step of reading the signal path file and generating the verification file of the module to be verified based on the signal path file is achieved by executing a second script.

16. The method according to any one of claims 1 to 15, characterized in that The method further comprises: Mounting the verification file to a verification environment, wherein the verification environment is used to simulate an execution environment of a verification use case; During the process of executing the verification use case in the verification environment, obtaining the key signal generated during the operation of the module to be verified; The assertion check statement in the verification file is executed to check the signal status of the key signal to obtain a verification result.

17. A device for generating a verification file, characterized in that: The device comprises: an extraction module configured to extract a key signal from a status indication signal of a module to be verified based on a keyword, wherein the module to be verified is a hardware module to be verified in a chip, the status indication signal is a signal used to represent an internal operating state of the module to be verified, and a signal name of the key signal is related to the keyword; A generating module is used to generate a verification file of the module to be verified based on the key signal, wherein the verification file is used to check the signal status of the key signal generated by the module to be verified during operation.

18. A computer device, characterized in that: The computer device includes a processor and a memory; the memory stores at least one computer instruction, and the at least one computer instruction is used to be executed by the processor to implement the method for generating a verification document according to any one of claims 1 to 16.

19. A computer-readable storage medium, characterized in that The computer-readable storage medium stores at least one computer instruction, and the computer instruction is loaded and executed by a processor to implement the method for generating a verification file according to any one of claims 1 to 16.

20. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the method for generating a verification file as described in any one of claims 1 to 16.

Images