Chip verification software and hardware interaction coverage rate determination method and device, equipment and medium

Abstract

The embodiment of the invention provides a chip verification software and hardware interaction coverage rate determination method and device, equipment and a medium, and relates to the field of software and hardware interaction testing. The method comprises the following steps: in the execution process of a scene case for chip software verification, extracting register operation sequences, identifying first register access sequences belonging to a register access sequence set from the register operation sequences, and storing each first register access sequence and an appearance sequence thereof into a database; comparing the access sequence with the access sequence of each register in the scene case and the appearance sequence of the access sequence, and determining an actual execution sequence of the scene case; and determining the coverage rate of the scene case based on the number of the actual execution sequences of the scene case and the total number of the register access sequences in the scene case. Through the mode, the coverage rate index can more clearly represent the quality of the interaction function of software and hardware, the defect of the evaluation index of the software coverage rate in the previous technical means is overcome, and the working efficiency between chip research and development teams is improved.

Description

Technical Field

[0001] The present application relates to the field of software-hardware interaction testing, and in particular to a method, device, equipment and medium for determining software-hardware interaction coverage of a chip verification. Background Art

[0002] In a chip R&D team, it is generally composed of multiple sub-teams such as the architecture design team, hardware verification team, software verification team, and testing team. Each team performs its duties and cooperates with each other to complete the task. Specifically, the R&D process of a certain chip product includes various sub-processes such as architecture design, software verification, testing, and delivery, and has a long life cycle. Among them, in the early stage of the chip R&D cycle, the architecture design team needs to give its definition of the chip architecture of the product and the register transfer level implementation of the chip architecture as deliverables. At the same time, in addition to deliverables such as architecture documents, design documents, and register transfer level code, the architecture design team also needs to give a definition of the interaction between software and hardware, and output it as one of the important outputs of this stage.

[0003] The software-hardware interaction definition specifically includes a chip hardware register interface list and register interface usage instructions, which are generally presented in the form of a text document.

[0004] In the middle and late stages of the chip development cycle, the definition of hardware-software interaction is an important input material and one of the conditions for the back-end teams such as the software verification team to carry out the development and debugging of software and verification functions.

[0005] Existing definitions of software-hardware interaction generally focus on listing and describing registers. When evaluating the coverage of software-hardware interaction codes in actual software verification work, it is found that even if the coverage of code, function or branch reaches a relatively high value, it cannot confirm whether the process and sequence of register operations are completely consistent with the definition of software-hardware interaction; code coverage also cannot indicate whether the scenario test covers all interface usage instructions defined in the software interaction definition.

[0006] Therefore, when evaluating the quality of chip verification software-hardware interaction code, a clearer and more accurate method for determining the software-hardware interaction coverage is urgently needed. Summary of the invention

[0007] Based on the above technical problems, the embodiments of the present application provide a method, device, equipment and medium for determining the software and hardware interaction coverage of chip verification, aiming to determine the software and hardware interaction coverage of chip verification more clearly and accurately.

[0008] A first aspect of an embodiment of the present application provides a method for determining chip verification software and hardware interaction coverage, the method comprising:

[0009] During the execution of the scenario use case of chip software verification, the register operation sequence is extracted. The register operation sequence is the operation on the register and its timing during the execution of the scenario use case.

[0010] From the register operation sequences, a first register access sequence belonging to a register access sequence set is identified, each register access sequence in the register access sequence set defining a register operation and a timing sequence of each sub-function in the software-hardware interaction design;

[0011] Compare each first register access sequence and its order of occurrence with each register access sequence and its order of occurrence in the scenario use case to determine the actual execution sequence of the scenario use case;

[0012] The scenario use case coverage is determined based on the number of actual execution sequences of the scenario use case and the total number of each register access sequence in the scenario use case.

[0013] Optionally, a first register access sequence belonging to a register access sequence set is identified from the register operation sequence, and the method further comprises:

[0014] For multiple scenario use cases, from the register operation sequence, identify and count the first register access sequence belonging to the register access sequence set;

[0015] De-duplication is performed on the identified first register access sequence to obtain a total number of non-repetitive first register access sequences;

[0016] A sequence coverage is determined based on the total number of non-repetitive first register access sequences and the total number of each register access sequence in the set of register access sequences.

[0017] Optionally, determining the scenario use case coverage based on the number of actual execution sequences of the scenario use case and the total number of register access sequences in the scenario use case further includes:

[0018] Determine the scenario use case coverage of each of the multiple scenario use cases;

[0019] The software and hardware interaction scenario coverage is determined based on the scenario use case coverage of each of the multiple scenario use cases and the total number of the multiple scenario use cases.

[0020] Optionally, the register access sequence set includes register access sequences of multiple sub-functions, and the register access sequence of each sub-function is defined by the following steps according to the architecture design and its hardware implementation. The method further includes:

[0021] Define a unique sequence identifier in the register access sequence set for each sub-function's register access sequence;

[0022] A register operation list is defined for a register access sequence of each sub-function, wherein the register operation list includes a plurality of register operations arranged in a sequential order, and the plurality of register operations include at least a read operation and / or a write operation;

[0023] In the case where a register operation is a read operation, the read address and the value expected to be read are defined;

[0024] In the case where a register operation is a write operation, the write address is defined.

[0025] Optionally, during the execution of the scenario use case of chip software verification, the following steps are also included:

[0026] Determine the expected number and order of occurrence of multiple register access sequences based on the use case scenarios and register access sequence sets of chip software verification;

[0027] Generate scenario use cases based on the expected number and order of occurrence of multiple register access sequences.

[0028] Optionally, according to the use case scenario of the chip software verification and the register access sequence set, the expected number of occurrences and the expected order of occurrence of multiple register access sequences are determined, including:

[0029] Based on the software and hardware interaction scenario, determine multiple sub-functions and the order of the multiple sub-functions, the multiple sub-functions including: a function of inputting parameters to hardware, a function of configuring status, and a function of interrupt processing;

[0030] determining a plurality of register access sequences from the set of register access sequences based on the plurality of sub-functions;

[0031] The sequence of the multiple sub-functions is determined as the expected occurrence order of the multiple register access sequences.

[0032] Optionally, during the execution of the scenario use case of chip software verification, extracting the register operation sequence also includes:

[0033] During the execution of the chip software verification scenario use case, the access timing and access operations to multiple registers are recorded;

[0034] Based on the register access sequence set, converting access timings and access operations to multiple registers into an execution list, a number of times, and an access timing of the register access sequence;

[0035] In the case where an access operation is a read operation, the read address and the read value are recorded;

[0036] In the case where an access operation is a write operation, the write address and the written value are recorded.

[0037] A second aspect of an embodiment of the present application provides a device for determining chip verification software and hardware interaction coverage, the device comprising:

[0038] An operation sequence extraction module is used to extract a register operation sequence during the execution of a scenario use case of chip software verification. The register operation sequence is the operation on the register and its timing during the execution of the scenario use case.

[0039] An access sequence identification module, used to identify a first register access sequence belonging to a register access sequence set from the register operation sequence, each register access sequence in the register access sequence set defining a register operation and a timing sequence of each sub-function in the software-hardware interaction design;

[0040] An execution sequence determination module, used to compare each first register access sequence and its occurrence order with each register access sequence and its occurrence order in the scenario use case, and determine the actual execution sequence of the scenario use case;

[0041] The scenario use case coverage determination module is used to determine the scenario use case coverage based on the number of actual execution sequences of the scenario use case and the total number of each register access sequence in the scenario use case.

[0042] Optionally, the access sequence identification module further includes:

[0043] A first access sequence identification submodule is used to identify and count the first register access sequence belonging to the register access sequence set from the register operation sequence for multiple scenario use cases;

[0044] a deduplication submodule, configured to dedupe the identified first register access sequence to obtain a total number of non-repetitive first register access sequences;

[0045] The sequence coverage determination submodule is used to determine the sequence coverage based on the total number of non-repetitive first register access sequences and the total number of each register access sequence in the register access sequence set.

[0046] Optionally, the scenario use case coverage determination module includes:

[0047] A scenario use case coverage submodule is used to determine the scenario use case coverage of each of multiple scenario use cases;

[0048] The software-hardware interaction scenario coverage submodule is used to determine the software-hardware interaction scenario coverage based on the scenario use case coverage of each of the multiple scenario use cases and the total number of the multiple scenario use cases.

[0049] Optionally, the access sequence identification module further includes:

[0050] A sequence identifier definition submodule, used to define a unique sequence identifier in the register access sequence set for each sub-function register access sequence;

[0051] A register operation list definition submodule, used to define a register operation list for a register access sequence of each subfunction, wherein the register operation list includes a plurality of register operations arranged in a sequential order, and the plurality of register operations include at least a read operation and / or a write operation;

[0052] A read operation definition submodule is used to define a read address and an expected read value when a register operation is a read operation;

[0053] The write operation definition submodule is used to define the write address when a register operation is a write operation.

[0054] Optionally, the operation sequence extraction module includes:

[0055] The access sequence expectation submodule is used to determine the expected number and order of occurrence of multiple register access sequences according to the use case scenario and register access sequence set of chip software verification;

[0056] The scenario use case generation submodule is used to generate scenario use cases according to the expected number of occurrences and the expected order of occurrences of multiple register access sequences.

[0057] Optionally, the execution sequence determination module further includes:

[0058] A sub-function determination sub-module, used to determine multiple sub-functions and the order of multiple sub-functions based on the software and hardware interaction scenario, wherein the multiple sub-functions include: a function of inputting parameters to the hardware, a function of configuring the status, and a function of interrupt processing;

[0059] a register access sequence determination submodule, configured to determine a plurality of register access sequences from the register access sequence set based on the plurality of sub-functions;

[0060] The expected order determination submodule is used to determine the sequence of the multiple sub-functions as the expected occurrence order of the multiple register access sequences.

[0061] Optionally, the operation sequence extraction module further includes:

[0062] The register access record submodule is used to record the access timing and access operations to multiple registers during the execution of the scenario use case of chip software verification;

[0063] An access sequence conversion submodule, for converting access timings and access operations to a plurality of registers into an execution list, a number of times and an access timing of a register access sequence based on the register access sequence set;

[0064] A read operation recording submodule, used for recording a read address and a read value when an access operation is a read operation;

[0065] The write operation recording submodule is used to record the write address and the written value when an access operation is a write operation.

[0066] A third aspect of an embodiment of the present application provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, the method for determining the chip verification software and hardware interaction coverage as in the first aspect of an embodiment of the present application is implemented.

[0067] A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the chip verification software and hardware interaction coverage determination method of the first aspect of the embodiment of the present application is implemented.

[0068] Through the chip verification hardware-software interaction coverage determination method of the embodiment of the present application, during the execution of the scenario use case of chip software verification, the register operation sequence is extracted, and the register access sequence belonging to the register access sequence set is identified from the register operation sequence, and the register access sequence and its occurrence order are compared with the various register access sequences and their occurrence order in the scenario use case to determine the actual execution sequence of the scenario use case. Finally, based on the number of actual execution sequences of the scenario use case and the total number of various register access sequences in the scenario use case, the scenario use case coverage is determined, and the identified register access sequences can also be deduplicated to obtain the non-repetitive total number of register access sequences to determine the sequence coverage. The hardware-software interaction scenario coverage can also be determined based on the scenario use case coverage of each of the multiple determined scenario use cases.

[0069] In this application, the existing chip verification hardware and software interaction coverage determination method is improved through three coverage indicators: scenario use case coverage, sequence coverage, and hardware and software interaction scenario coverage. It is more effective, objective, and transparent, and improves the problem of being unable to confirm whether the process and sequence of register operations are completely consistent with the definition of hardware and software interaction. It fundamentally clarifies the effectiveness of evaluating the use of hardware and software testing and verification, and can clearly evaluate the hardware and software interaction function quality of software function codes, avoiding the problem of high code coverage but the existence of omissions, multiple reads, illegal reads, illegal writes, read and write timing, etc., so that the coverage indicator can more clearly represent the quality of the hardware and software interaction function, making up for the shortcomings of the evaluation indicators of software coverage in previous technical means, realizing unambiguous communication between chip R&D teams, and improving the work efficiency between teams. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the description of the embodiments of the present application will be briefly introduced below. 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 paying any creative labor.

[0071] Figure 1 It is a flow chart of a chip verification software and hardware interaction coverage method proposed in one embodiment of the present application;

[0072] Figure 2 It is a block diagram of a method for verifying software and hardware interaction coverage of a chip proposed in an embodiment of the present application;

[0073] Figure 3 This is a diagram of an implementation process of chip verification software and hardware interaction coverage provided by an embodiment of the present application;

[0074] Figure 4 It is a schematic diagram of a sequence list of scenario use cases for chip verification of software and hardware interaction coverage provided by an embodiment of the present application;

[0075] Figure 5 It is a structural block diagram of a chip verification software and hardware interaction coverage device provided in an embodiment of the present application;

[0076] Figure 6 It is a schematic diagram of an electronic device shown in an embodiment of the present application. DETAILED DESCRIPTION

[0077] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0078] In the drawings, the size of the constituent elements, the thickness of the layer or the area may be exaggerated for the sake of clarity. Therefore, any implementation of the present application is not necessarily limited to the size shown in the drawings, and the shape and size of the components in the drawings do not reflect the true proportion. In addition, the drawings schematically show ideal examples, and any implementation of the present application is not limited to the shape or value shown in the drawings.

[0079] Please refer to Figure 1 , Figure 1 This is a flowchart of a method for determining the chip verification software and hardware interaction coverage in this application. Figure 1 As shown, the method may include steps S101 to S104:

[0080] Step S101: extracting a register operation sequence during the execution of a scenario use case of chip software verification, where the register operation sequence is the operation on the register and its timing during the execution of the scenario use case;

[0081] Step S102: identifying a first register access sequence belonging to a register access sequence set from the register operation sequence, each register access sequence in the register access sequence set defining a register operation and a timing sequence of each sub-function in the software-hardware interaction design;

[0082] Step S103: Compare each first register access sequence and its occurrence order with each register access sequence and its occurrence order in the scenario use case to determine the actual execution sequence of the scenario use case;

[0083] Step S104: Determine the scenario use case coverage based on the number of actual execution sequences of the scenario use case and the total number of register access sequences in the scenario use case.

[0084] In the prior art, in the process of verifying the software and hardware interaction coverage of a chip, the hardware team usually provides the software verification team with the software and hardware interaction definition as input material for the development and debugging of the software verification function. However, in general, the software and hardware interaction definition is generally provided through a simple table, which focuses on a simple listing and description of the registers used, and does not place too many requirements on the actual execution order of the registers. Therefore, in the actual process of software quality assessment, the code coverage of software execution is calculated, which usually only includes simple calculation contents such as code coverage, function coverage, and branch coverage. In fact, these coverage rates cannot fully prove the accuracy of the software and hardware interaction code, because the operation of the registers is time-sequential, and the corresponding operations need to be performed in a certain order to achieve the target function. However, the existing statistical methods only simply list the code that appears, and it is impossible to determine whether the target function can be achieved as expected, and whether the software and hardware interaction is completely covered.

[0085] Therefore, this application proposes a method for determining the coverage of chip verification software and hardware interaction. During the execution of the scenario use case of chip software verification, the register operation sequence in the actual operation process is extracted, and the corresponding register operation that meets the sub-function in the software and hardware interaction design is identified. According to the identified register access sequence and the order before and after its execution, the register sequence that is actually correctly executed during the scenario use case test can be determined and determined as the actual execution sequence. According to the actual execution sequence and the total number of register access sequences in the scenario use case, the coverage of the scenario use case can be determined. Compared with the simple listing of the executed register code in the prior art, this application proposes a coverage determination index based on the register access sequence, so that only the register operations executed in the expected order can be identified as valid register access sequences, and the register access sequences executed in the expected order can be identified as scenario use cases. In this way, the statistical chip verification software and hardware interaction coverage has a specific meaning, and can more accurately display the evaluation results in terms of software and hardware interaction.

[0086] Step S101: during the execution of the scenario use case of the chip software verification, a register operation sequence is extracted. The register operation sequence is the operation on the register and its timing during the execution of the scenario use case.

[0087] Table 1 Register operation sequence

[0088]

[0089] In the embodiment of the present application, as shown in Table 1, Table 1 is a schematic diagram of the register operation sequence, wherein the table content includes: execution number, from 1 to n; register address, replaced by A1; execution operation, R represents read operation (READ), W represents write operation (WRITE); VAL represents the specific value that needs to be operated. During the execution of the scenario use case of chip software verification, all register operations performed within the time period are extracted from the register operation list according to the start time and end time of the executed scenario use case. These register operations are all actions of software and hardware interaction in the execution of the scenario use case. These register operations are executed in a certain order, so it is necessary not only to record the specific operations on the registers, but also to record the timing of the operations in order to fully reflect the execution process of implementing the scenario use case.

[0090] Step S102: identifying a first register access sequence belonging to a register access sequence set from the register operation sequence, each register access sequence in the register access sequence set defines a register operation and a timing sequence of each sub-function in the software-hardware interaction design.

[0091] In the embodiment of the present application, the register access sequence is defined in the design stage, and each register access sequence represents the register operation required for the register set to execute a minimum unit of sub-function, including specific parameters of the register operation and the timing of multiple register operation executions. In the actual test process, after extracting the register actual operation sequence in the above steps, it is necessary to identify and extract the first register access sequence from the register actual operation sequence according to the pre-set register access sequence, which represents that the sub-function represented by the first register access sequence was executed at this timing position during this test.

[0092] For example, the specific implementation process is as follows Figure 2 As shown, Figure 2 This is a block diagram of a method for verifying the software-hardware interaction coverage of a chip proposed in an embodiment of the present application. In the design phase, the expected register access sequence is defined according to the software-hardware interaction definition, and the possible scenario use cases and the register access sequences contained therein are anticipated according to the design of the verification software use case. In the test phase, the various register access sequences that meet the expectations are identified according to the actual register operations.

[0093] Step S103: Compare each first register access sequence and its occurrence order with each register access sequence and its occurrence order in the scenario use case to determine the actual execution sequence of the scenario use case.

[0094] In an embodiment of the present application, the scenario use case is expected to include multiple register access sequences, and these register access sequences are arranged in a fixed timing sequence, that is, the sub-functions are executed in sequence according to this order, so that the functions expected to be achieved by the scenario use case can be achieved.

[0095] Therefore, in a test, after completing the identification and extraction of the actual operation sequences of all registers, multiple register access sequences can be obtained, and the multiple register access sequences are arranged in a certain time sequence. The actual register access sequences arranged in time sequence are compared with the register access sequences expected in the scenario use case of this test, so that the differences and similarities between the actual test results and the expected results can be obtained.

[0096] During the chip verification of the hardware-software interaction code, the expected register access sequence should be able to implement the corresponding function of the scenario use case. However, due to various problems that may exist in the actual design process, there may be differences between the actual register access sequence and the expected register access sequence. Therefore, starting from the first executed register operation, the sequence that is completely consistent with the two is determined as the actual execution sequence of the scenario use case. It should be noted that once a register operation that does not meet expectations occurs during this process, even if the subsequent actual register access sequence is the same as the expected register access sequence, it will not be used as the actual execution sequence in this scenario use case.

[0097] Step S104: Determine the scenario use case coverage based on the number of actual execution sequences of the scenario use case and the total number of register access sequences in the scenario use case.

[0098] In an embodiment of the present application, based on the actual execution sequence of the scenario use case obtained in the above steps and the expected register access sequence, the ratio of the number of register access sequences contained therein is used as the scenario use case coverage in the scenario use case test, which is used to characterize the test results of the scenario use case test and fundamentally clarify the effectiveness of the software verification use case.

[0099] For example, the specific implementation process is as follows Figure 3 As shown, Figure 3 This is an implementation process diagram of a chip verification software and hardware interaction coverage proposed in an embodiment of the present application. First, in the design stage, a register access sequence set is defined, which includes multiple register access sequences. Then, according to different scenario use cases, the expected register access sequences are defined. Then, in the test stage, according to the register operation sequence extracted from the actual operating environment, the expected register access sequence is analyzed, and based on the analysis results, the software and hardware interaction coverage is calculated.

[0100] In combination with the above embodiments, in one implementation, the present application further provides a chip verification software and hardware interaction coverage determination method, which identifies a first register access sequence belonging to a register access sequence set from a register operation sequence, specifically including the following contents:

[0101] First, for multiple scenario use cases, a first register access sequence belonging to a register access sequence set is identified from register operation sequences and counted.

[0102] In an embodiment of the present application, during the process of software and hardware interaction testing, multiple scenario use cases are usually included, and different scenario use cases correspond to tests of different functions. However, in the expectations of different scenario use cases, they are all implemented through sub-functions represented by preset register access sequences. Therefore, it is necessary to identify the register access sequences for multiple scenario use cases.

[0103] Then, the identified first register access sequence is deduplicated to obtain the total number of non-repetitive first register access sequences.

[0104] Since different sub-functions may be used to implement different functions, multiple identical register access sequences may be included in different scenario use cases. Therefore, it is necessary to deduplicate the reused register access sequences and count the number of non-repeated register access sequences during the actual test process.

[0105] Finally, the sequence coverage is determined based on the total number of non-repetitive first register access sequences and the total number of each register access sequence in the register access sequence set.

[0106] According to the register access sequences extracted from the actual operation process in the above steps, after deduplication, the number of register access sequences actually used is obtained, and then compared with the total number of preset register access sequences to obtain the sequence coverage.

[0107] In the embodiment of the present application, the sequence coverage represents the difference between the actual register access sequence and the expected one during the software-hardware interaction test. The expected value is 100%, that is, the different sub-functions required to implement various scenario use cases and the register access sequences required to implement these sub-functions are taken into consideration during the design process. Since there may be various situations such as missing steps or code errors during the actual execution process, the final sequence coverage is not 100%. The method proposed in the present application also makes it easier to locate the cause of the problem and prescribe the right medicine.

[0108] In combination with the above embodiments, in one implementation, the present application further provides a method for determining chip verification software and hardware interaction coverage, in which the scenario use case coverage is determined based on the number of actual execution sequences of the scenario use case and the total number of register access sequences in the scenario use case, and specifically includes the following contents:

[0109] First, determine the scenario use case coverage of each of the multiple scenario use cases.

[0110] In an embodiment of the present application, according to the process of steps S101 to S104, the coverage rate of a scenario use case in a scenario use case can be determined. As mentioned above, since a software and hardware interaction test usually includes multiple scenario use cases, it is necessary to determine the scenario use case coverage rate of each scenario use case in order to understand the overall situation and determine the result of this software and hardware interaction test.

[0111] Then, based on the scenario use case coverage of each of the multiple scenario use cases and the total number of the multiple scenario use cases, the software and hardware interaction scenario coverage is determined.

[0112] In the embodiment of the present application, the scenario use case coverage of each scenario use case is averaged, so that the overall code coverage of the software and hardware interaction test can be obtained at a macro level, that is, the sum of the scenario coverage rates is compared with the total number of scenario use cases to obtain the software and hardware interaction scenario coverage rate.

[0113] In summary, the present application proposes three coverage indicators, namely, scenario use case coverage, sequence coverage and software-hardware interaction scenario coverage. Compared with the coverage calculation methods of the prior art for code level, function level, etc., the chip verification software-hardware interaction coverage determination method proposed in the present application is more effective, objective and transparent. It raises the consideration of coverage from the level of simple code or register operation to the register access sequence representing a sub-function, introduces the timing factor, improves the problem of being unable to confirm whether the process and sequence of register operations are completely consistent with the software-hardware interaction definition, and avoids the problem of high code coverage but the existence of omissions, multiple reads, illegal reads, illegal writes, read-write timing, etc., so that the coverage indicator can more clearly represent the quality of the software-hardware interaction function, realize unambiguous communication between chip R&D teams, and improve work efficiency between teams.

[0114] In combination with the above embodiments, in one implementation, the present application further provides a method for determining chip verification software and hardware interaction coverage, in which the register access sequence set includes register access sequences of multiple sub-functions, and the register access sequence of each sub-function is defined according to the architecture design and its hardware implementation, specifically by the following steps:

[0115] First, a unique sequence identifier in the register access sequence set is defined for each sub-function's register access sequence.

[0116] In the embodiment of the present application, as described above, each register access sequence represents the specific register operation timing and actual operation value for implementing a sub-function. Therefore, before performing software-hardware interaction testing, it is necessary to define the register access sequence for the expected sub-function according to its architectural design and hardware implementation, and in this software-hardware interaction test, a unique sequence identifier is set for the register access sequence to distinguish it from the register access sequences in the sequence set.

[0117] That is to say, in a software-hardware interaction test, the expected sub-functions and register access sequences are one-to-one corresponding to each other, which is a minimum operation unit. In addition, in the process of defining the register access sequence, its atomicity should be ensured, that is, a certain function should not be implemented through one register access sequence and another register access sequence.

[0118] Then, a register operation list is defined for the register access sequence of each sub-function, wherein the register operation list includes a plurality of register operations arranged in a sequential order, and the plurality of register operations include at least a read operation and / or a write operation.

[0119] For each register access sequence, it should include actual operations on more than one register. This operation is a fixed operation in this access sequence and has timing, that is, each register operation in the register access sequence must be executed in sequence to achieve the sub-function represented by the register access sequence. Usually, these operations include at least read and write operations on registers, where:

[0120] In the case where a register operation is a read operation, the read address and the value expected to be read are defined;

[0121] In the case where a register operation is a write operation, the write address is defined.

[0122] Table 2 Register access sequence

[0123]

[0124] As shown in Table 2, Table 2 is a schematic diagram of a register access sequence, where the table content includes: execution sequence number, from 1 to n; register address, replaced by A1; execution operation, R represents read operation (READ), W represents write operation (WRITE), OP is the operation code; VAL represents the specific value to be operated. When a register needs to be read, the expected read address and the expected read value need to be given; when a register needs to be written, the expected write address needs to be given. All corresponding operations in the register access sequence are completed according to the expected value, which can be regarded as completing the expected sub-function.

[0125] In combination with the above embodiments, in one implementation, the present application further provides a method for determining chip verification hardware and software interaction coverage. In the method, during the execution of the scenario use case of chip software verification, the following contents are specifically included:

[0126] First, based on the use case scenarios and register access sequence sets of chip software verification, the expected number and order of occurrence of multiple register access sequences are determined.

[0127] Table 3 Scenario use cases

[0128] Sequence ID1 Sequence ID3 Sequence ID5 ...

[0129] In an embodiment of the present application, as shown in Table 3, Table 3 is a schematic diagram of a scenario use case. After a register access sequence set including multiple register access sequences is defined as expected in the above steps, it is also necessary to define the scenario use case in the software and hardware interaction test. The scenario use case is used to describe the specific implementation steps for realizing a certain function. In order to realize the function, multiple sub-functions need to be executed in sequence. Therefore, when anticipating the scenario use case, it should include multiple register access sequences, and these register access sequences should be arranged in a certain order.

[0130] Then, scenario use cases are generated according to the expected number of occurrences and the expected order of occurrences of multiple register access sequences.

[0131] After obtaining the expected number and order of multiple register access sequences, the scenario use cases required for this hardware and software interaction test are generated. It should be noted that the register access sequences contained in the scenario use cases may be repeated, because the register access sequence represents the implementation of a very small sub-function, which may be needed in implementing different functions of different scenario use cases.

[0132] For example, Figure 4 As shown, Figure 4This is a sequence list diagram of a scenario use case for chip verification of software and hardware interaction coverage proposed in an embodiment of the present application, wherein, after the expected test starts, each register access sequence is executed in sequence in the direction indicated by the arrows in the figure, wherein the register access sequences with sequence IDs 1, 3, and 5 constitute scenario use case 1, and the register access sequences with sequence IDs 1, 9, and 6 constitute scenario use case 2, which will not be elaborated later.

[0133] In combination with the above embodiments, in one implementation, the present application further provides a method for determining chip verification software and hardware interaction coverage, in which the expected number of occurrences and the expected order of occurrence of multiple register access sequences are determined according to the use case scenario and register access sequence set of chip software verification, and specifically includes the following contents:

[0134] First, based on the software-hardware interaction scenario, multiple sub-functions and the order of the multiple sub-functions are determined, wherein the multiple sub-functions include: a function of inputting parameters to the hardware, a function of configuring the status, and a function of interrupt processing.

[0135] In the embodiments of the present application, as described above, different functions need to be implemented based on different scenarios of software and hardware interaction, and these functions are implemented by executing multiple sub-functions in a certain order, and these sub-functions include the function of inputting parameters to the hardware, the function of configuring the status, the function of interrupt processing, etc. Different sub-functions also correspond to different register operation sequences, that is, the registers need to be operated to specific values ​​according to a fixed operation sequence in order to implement these sub-functions.

[0136] Then, based on the multiple sub-functions, a plurality of register access sequences are determined from the register access sequence set.

[0137] According to the multiple sub-functions expected to be implemented, multiple register access sequences are determined to correspond to each other, and the expected sub-functions are implemented according to the actual operations performed on the registers according to the register access sequences.

[0138] Finally, the sequence of the multiple sub-functions is determined as the expected occurrence order of the multiple register access sequences.

[0139] In the embodiment of the present application, as mentioned above, the sub-function, as the smallest unit for realizing a certain function in the software-hardware interaction test, needs to be arranged and acted in sequence according to a certain timing to realize the expected function. Therefore, after determining the mutual correspondence between multiple sub-functions and register access sequences, it is also necessary to determine their expected order of appearance in order to realize specific functions.

[0140] In combination with the above embodiments, in one implementation, the present application further provides a method for determining chip verification software and hardware interaction coverage. In the method, during the execution of a scenario use case of chip software verification, a register operation sequence is extracted, which specifically includes the following contents:

[0141] First, during the execution of the scenario use case for chip software verification, the access timing and access operations to multiple registers are recorded.

[0142] In an embodiment of the present application, during the actual testing process, the register operations actually performed will be recorded. After the test process of a scenario use case is completed, the steps of the actual software and hardware interaction under the scenario use case are determined based on the recorded register operations. The record of the register operation includes time, so it is possible to distinguish the time periods between different scenario test cases, as well as the sequence of the actual register operations.

[0143] Then, based on the register access sequence set, the access timing and access operations to the plurality of registers are converted into an execution list, a number of times and an access timing of the register access sequence.

[0144] As described in step S102, after obtaining the actual operation record of the register, it is necessary to extract the register access sequence according to the expectations of the register operation, that is, which operations consistent with the expectations are included in the actual operation of the register. It is necessary to compare not only the numerical values ​​of the operations, but also the timing of the operations.

[0145] The consistency between the two can be used to determine whether the test meets expectations. The actual operation steps for the registers include at least:

[0146] In the case where an access operation is a read operation, the read address and the read value are recorded;

[0147] In the case where an access operation is a write operation, the write address and the written value are recorded.

[0148] In the read and write access operations, it is necessary to record not only the read and write addresses but also the read and write values, and compare them completely to determine that the test results meet expectations.

[0149] In summary, this application improves the previous method of determining the software and hardware interaction coverage of chip verification by calculating the three aspects of scenario use case coverage, sequence coverage, and software and hardware interaction scenario coverage, and gives more consideration to the problems that may be encountered in the actual production process, and makes corresponding improvements. It should be noted that the three coverage indicators proposed in this application should not be used as a limitation of this application. According to the inventive ideas of this application, more other coverage indicators can also be derived according to the needs of the user, such as the error rate of the register access sequence, etc. For general technicians in this field, according to the ideas of this application, there may be changes in the specific implementation method and scope of application.

[0150] Based on the same design concept, an embodiment of the present application provides a chip verification hardware and software interaction coverage determination device. Figure 5 , Figure 5 1 is a block diagram of a chip verification hardware and software interaction coverage determination device provided in an embodiment of the present application. Figure 5 As shown, the device comprises:

[0151] An operation sequence extraction module is used to extract a register operation sequence during the execution of a scenario use case of chip software verification. The register operation sequence is the operation on the register and its timing during the execution of the scenario use case.

[0152] An access sequence identification module, used to identify a first register access sequence belonging to a register access sequence set from the register operation sequence, each register access sequence in the register access sequence set defining a register operation and a timing sequence of each sub-function in the software-hardware interaction design;

[0153] An execution sequence determination module, used to compare each first register access sequence and its occurrence order with each register access sequence and its occurrence order in the scenario use case, and determine the actual execution sequence of the scenario use case;

[0154] The scenario use case coverage determination module is used to determine the scenario use case coverage based on the number of actual execution sequences of the scenario use case and the total number of each register access sequence in the scenario use case.

[0155] Optionally, the access sequence identification module further includes:

[0156] A first access sequence identification submodule is used to identify and count the first register access sequence belonging to the register access sequence set from the register operation sequence for multiple scenario use cases;

[0157] a deduplication submodule, configured to dedupe the identified first register access sequence to obtain a total number of non-repetitive first register access sequences;

[0158] The sequence coverage determination submodule is used to determine the sequence coverage based on the total number of non-repetitive first register access sequences and the total number of each register access sequence in the register access sequence set.

[0159] Optionally, the scenario use case coverage determination module includes:

[0160] A scenario use case coverage submodule is used to determine the scenario use case coverage of each of multiple scenario use cases;

[0161] The software-hardware interaction scenario coverage submodule is used to determine the software-hardware interaction scenario coverage based on the scenario use case coverage of each of the multiple scenario use cases and the total number of the multiple scenario use cases.

[0162] Optionally, the access sequence identification module further includes:

[0163] A sequence identifier definition submodule, used to define a unique sequence identifier in the register access sequence set for each sub-function register access sequence;

[0164] A register operation list definition submodule, used to define a register operation list for a register access sequence of each subfunction, wherein the register operation list includes a plurality of register operations arranged in a sequential order, and the plurality of register operations include at least a read operation and / or a write operation;

[0165] A read operation definition submodule is used to define a read address and an expected read value when a register operation is a read operation;

[0166] The write operation definition submodule is used to define the write address when a register operation is a write operation.

[0167] Optionally, the operation sequence extraction module includes:

[0168] The access sequence expectation submodule is used to determine the expected number and order of occurrence of multiple register access sequences according to the use case scenario and register access sequence set of chip software verification;

[0169] The scenario use case generation submodule is used to generate scenario use cases according to the expected number of occurrences and the expected order of occurrences of multiple register access sequences.

[0170] Optionally, the execution sequence determination module further includes:

[0171] A sub-function determination sub-module, used to determine multiple sub-functions and the order of multiple sub-functions based on the software and hardware interaction scenario, wherein the multiple sub-functions include: a function of inputting parameters to the hardware, a function of configuring the status, and a function of interrupt processing;

[0172] a register access sequence determination submodule, configured to determine a plurality of register access sequences from the register access sequence set based on the plurality of sub-functions;

[0173] The expected order determination submodule is used to determine the sequence of the multiple sub-functions as the expected occurrence order of the multiple register access sequences.

[0174] Optionally, the operation sequence extraction module further includes:

[0175] The register access record submodule is used to record the access timing and access operations to multiple registers during the execution of the scenario use case of chip software verification;

[0176] An access sequence conversion submodule, for converting access timings and access operations to a plurality of registers into an execution list, a number of times and an access timing of a register access sequence based on the register access sequence set;

[0177] A read operation recording submodule, used for recording a read address and a read value when an access operation is a read operation;

[0178] The write operation recording submodule is used to record the write address and the written value when an access operation is a write operation.

[0179] Based on the same design concept, another embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps in the chip verification software and hardware interaction coverage determination method as described in any of the above embodiments of the present application are implemented.

[0180] Based on the same design concept, another embodiment of the present application provides an electronic device, such as Figure 6 shown. Figure 6 This is a schematic diagram of an electronic device shown in an embodiment of the present application. The electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes, the steps in the chip verification software and hardware interaction coverage determination method described in any of the above embodiments of the present application are implemented.

[0181] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0182] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0183] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, devices, or computer program products. Therefore, the embodiments of the present application may adopt the form of complete hardware embodiments, complete software embodiments, or embodiments in combination with software and hardware. Moreover, the embodiments of the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0184] The embodiments of the present application are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0185] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0186] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable terminal device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0187] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present application.

[0188] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0189] The above is a detailed introduction to the chip verification software and hardware interaction coverage determination method, device, equipment and medium provided by the present application. This article uses specific examples to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A method for determining chip verification software and hardware interaction coverage, characterized in that: include: During the execution of the scenario use case of chip software verification, the register operation sequence is extracted. The register operation sequence is the operation on the register and its timing during the execution of the scenario use case. From the register operation sequences, a first register access sequence belonging to a register access sequence set is identified, each register access sequence in the register access sequence set defining a register operation and a timing sequence of each sub-function in the software-hardware interaction design; Compare each first register access sequence and its order of occurrence with each register access sequence and its order of occurrence in the scenario use case to determine the actual execution sequence of the scenario use case; The scenario use case coverage is determined based on the number of actual execution sequences of the scenario use case and the total number of each register access sequence in the scenario use case.

2. A chip verification software and hardware interaction coverage determination method according to claim 1, characterized in that: From the register operation sequences, a first register access sequence belonging to the register access sequence set is identified, further comprising: For multiple scenario use cases, from the register operation sequence, identify and count the first register access sequence belonging to the register access sequence set; De-duplication is performed on the identified first register access sequence to obtain a total number of non-repetitive first register access sequences; A sequence coverage is determined based on the total number of non-repetitive first register access sequences and the total number of each register access sequence in the set of register access sequences.

3. A chip verification software and hardware interaction coverage determination method according to claim 1, characterized in that: Determine the scenario use case coverage based on the number of actual execution sequences of the scenario use case and the total number of register access sequences in the scenario use case, and also include: Determine the scenario use case coverage of each of the multiple scenario use cases; The software and hardware interaction scenario coverage is determined based on the scenario use case coverage of each of the multiple scenario use cases and the total number of the multiple scenario use cases.

4. A chip verification software and hardware interaction coverage determination method according to claim 1, characterized in that: The register access sequence set includes register access sequences of multiple sub-functions, and the register access sequence of each sub-function is defined according to the architecture design and its hardware implementation through the following steps: Define a unique sequence identifier in the register access sequence set for each sub-function's register access sequence; A register operation list is defined for a register access sequence of each sub-function, wherein the register operation list includes a plurality of register operations arranged in a sequential order, and the plurality of register operations include at least a read operation and / or a write operation; In the case where a register operation is a read operation, the read address and the value expected to be read are defined; In the case where a register operation is a write operation, the write address is defined.

5. A chip verification software and hardware interaction coverage determination method according to claim 1, characterized in that: The execution process of the chip software verification scenario use case also includes: Determine the expected number and order of occurrence of multiple register access sequences based on the use case scenarios and register access sequence sets of chip software verification; Generate scenario use cases based on the expected number and order of occurrence of multiple register access sequences.

6. A chip verification software and hardware interaction coverage determination method according to claim 1, characterized in that: According to the use case scenarios and register access sequence sets of chip software verification, determine the expected number and order of occurrence of multiple register access sequences, including: Based on the software and hardware interaction scenario, determine multiple sub-functions and the order of the multiple sub-functions, the multiple sub-functions including: a function of inputting parameters to hardware, a function of configuring status, and a function of interrupt processing; determining a plurality of register access sequences from the set of register access sequences based on the plurality of sub-functions; The sequence of the multiple sub-functions is determined as the expected occurrence order of the multiple register access sequences.

7. A chip verification software and hardware interaction coverage determination method according to claim 1, characterized in that: During the execution of the chip software verification scenario, the register operation sequence is extracted, including: During the execution of the chip software verification scenario use case, the access timing and access operations to multiple registers are recorded; Based on the register access sequence set, converting access timings and access operations to multiple registers into an execution list, a number of times, and an access timing of the register access sequence; In the case where an access operation is a read operation, the read address and the read value are recorded; In the case where an access operation is a write operation, the write address and the written value are recorded.

8. A chip verification hardware and software interaction coverage determination device, characterized in that: The device comprises: An operation sequence extraction module is used to extract a register operation sequence during the execution of a scenario use case of chip software verification. The register operation sequence is the operation on the register and its timing during the execution of the scenario use case. An access sequence identification module, used to identify a first register access sequence belonging to a register access sequence set from the register operation sequence, each register access sequence in the register access sequence set defining a register operation and a timing sequence of each sub-function in the software-hardware interaction design; An execution sequence determination module, used to compare each first register access sequence and its occurrence order with each register access sequence and its occurrence order in the scenario use case, and determine the actual execution sequence of the scenario use case; The scenario use case coverage determination module is used to determine the scenario use case coverage based on the number of actual execution sequences of the scenario use case and the total number of each register access sequence in the scenario use case.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the computer program is executed by the processor, the method for determining the chip verification software and hardware interaction coverage as described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for determining the chip verification software and hardware interaction coverage as described in any one of claims 1 to 7 is implemented.

Images