CN115563914A - Verification method and device, computing equipment and computer readable storage medium - Google Patents

Verification method and device, computing equipment and computer readable storage medium Download PDF

Info

Publication number
CN115563914A
CN115563914A CN202211200938.9A CN202211200938A CN115563914A CN 115563914 A CN115563914 A CN 115563914A CN 202211200938 A CN202211200938 A CN 202211200938A CN 115563914 A CN115563914 A CN 115563914A
Authority
CN
China
Prior art keywords
memory access
instruction
actual
expected
result
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211200938.9A
Other languages
Chinese (zh)
Inventor
袁媛
高军
刘晓燕
游柏青
赖彬
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Phytium Technology Co Ltd
Original Assignee
Phytium Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Phytium Technology Co Ltd filed Critical Phytium Technology Co Ltd
Priority to CN202211200938.9A priority Critical patent/CN115563914A/en
Publication of CN115563914A publication Critical patent/CN115563914A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00Computer-aided design [CAD]
    • G06F30/30Circuit design
    • G06F30/32Circuit design at the digital level
    • G06F30/33Design verification, e.g. functional simulation or model checking
    • G06F30/3308Design verification, e.g. functional simulation or model checking using simulation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2115/00Details relating to the type of the circuit
    • G06F2115/10Processors

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Provided are a verification method and device, a computing device and a computer readable storage medium, wherein the method comprises the following steps: the test case is utilized to drive the memory access component to execute the memory access instruction; responding to the execution of the access instruction, and acquiring an actual result of the access instruction; responding to the execution of the access instruction, and acquiring an expected result of the access instruction output by the reference model; and verifying the memory access component according to the actual result and the expected result of the memory access instruction. The verification method provided by the embodiment of the application can directly obtain the actual results of the memory access component after the storage instruction and the loading instruction are executed, the coupling relation between the storage instruction and the loading instruction verification is eliminated, and the verification efficiency of the memory access component is improved.

Description

Verification method and device, computing equipment and computer readable storage medium
Technical Field
The present application relates to the field of chips, and more particularly, to a verification method and apparatus, a computing device, and a computer-readable storage medium.
Background
Currently, the main stream processors in the industry are all processors of a load/store architecture, and the access of a processor core to a memory can be realized only through load and store instructions, so that the verification of a memory access component for executing the load and store instructions is very important. In the related art, after the storage instruction is executed, the data of the same address is loaded by using the loading instruction, so that the function of the memory access component is verified according to the loading result. In this verification method, the verification of the store-like instructions and the load-like instructions are coupled, i.e. the verification result of the store instructions depends on the verification result of the load instructions.
Disclosure of Invention
The application provides a verification method and device, computing equipment and a computer readable storage medium. Various aspects of embodiments of the present application are described below.
In a first aspect, a verification method is provided, the method comprising: the test case is utilized to drive the memory access component to execute the memory access instruction; responding to the execution of the access instruction, and acquiring an actual result of the access instruction; responding to the execution of the access instruction, and acquiring an expected result of the access instruction output by a reference model; and verifying the memory access component according to the actual result and the expected result of the memory access instruction.
As a possible implementation, the obtaining an actual result of the access instruction includes: monitoring a bus transaction packet generated after the memory access component executes the memory access instruction; and acquiring an actual result of the memory access instruction in response to monitoring the bus transaction packet.
As a possible implementation manner, if the memory access instruction is a load instruction, the bus transaction packet is a bus read transaction packet between the memory access component and one or more registers; and/or if the access instruction is a storage instruction, the bus transaction packet is a bus write transaction packet between the access component and the memory.
As a possible implementation manner, the memory access instruction includes a load instruction, the load instruction is used to store data in a memory format into one or more registers, and before the memory access component is verified according to an actual result and an expected result of the memory access instruction, the method further includes: storing an actual result and an expected result of the load instruction into a first merge queue, wherein the first merge queue is a queue with a register number as an index and is used for recording an actual value and an expected value corresponding to each of the one or more registers; the verifying the memory access component according to the actual result and the expected result of the memory access instruction comprises the following steps: comparing the actual value and the expected value corresponding to each of the one or more registers; if the actual value and the expected value corresponding to each of the one or more registers are consistent, determining that the execution of the load instruction is correct; and if the actual value and the expected value corresponding to each of the one or more registers are inconsistent, determining that the execution of the load instruction is wrong.
As a possible implementation manner, before the comparing the actual value and the expected value corresponding to each of the one or more registers, the method further includes: obtaining a loading operation corresponding to the loading instruction according to a mapping queue of the one or more registers, wherein the mapping queue is used for recording the mapping relation between the loading operation and the one or more registers; the comparing the actual result and the expected result corresponding to each of the one or more registers comprises: and if the loading operation is the oldest operation in the operations to be submitted, comparing the actual value and the expected value corresponding to the one or more registers respectively.
As a possible implementation, the method further includes: and releasing the one or more registers if the actual values and the expected values corresponding to the one or more registers respectively are consistent.
As a possible implementation manner, the memory access instruction includes a store instruction, the store instruction is used to store data in a register format into one or more addresses of a memory, and before the memory access component is verified according to an actual result and an expected result of the memory access instruction, the method further includes: storing data in the bus write transaction packet output by the memory access component into a second merge queue, and storing data in the bus write transaction packet output by the reference model into the second merge queue, wherein the second merge queue is a queue using a memory address as an index, and the second merge queue is used for recording actual data and expected data corresponding to the one or more addresses; the verifying the memory access component according to the actual result and the expected result of the memory access instruction comprises the following steps: comparing the actual data and the expected data corresponding to the one or more memory addresses respectively; if the actual data and the expected data corresponding to the one or more memory addresses are consistent, determining that the execution of the storage instruction is correct; and if the actual data and the expected data corresponding to the one or more memory addresses are inconsistent, determining that the execution of the storage instruction is wrong.
In a second aspect, there is provided an authentication apparatus, the apparatus comprising: the drive module is configured to drive the memory access component to execute the memory access instruction by utilizing the test case; a first obtaining module configured to obtain an actual result of the memory access instruction in response to execution of the memory access instruction; a second obtaining module configured to obtain an expected result of the memory access instruction output by a reference model in response to execution of the memory access instruction; and the verification module is configured to verify the memory access component according to the actual result and the expected result of the memory access instruction.
As a possible implementation manner, the first obtaining module is further configured to: monitoring a bus transaction packet generated after the memory access component executes the memory access instruction; and acquiring an actual result of the memory access instruction in response to monitoring the bus transaction packet.
As a possible implementation manner, if the memory access instruction is a load instruction, the bus transaction packet is a bus read transaction packet between the memory access component and one or more registers; and/or if the memory access instruction is a storage instruction, the bus transaction packet is a bus write transaction packet between the memory access component and the memory.
As a possible implementation manner, the memory access instruction includes a load instruction, and the load instruction is used to store data in a memory format into one or more registers, and the apparatus further includes: a first storage module, configured to store the actual result and the expected result of the load instruction into a first merge queue before the memory access component is verified according to the actual result and the expected result of the memory access instruction, where the first merge queue is a queue with a register number as an index, and the first merge queue is used to record the actual value and the expected value corresponding to each of the one or more registers; the authentication module includes: a comparison module configured to compare actual values and expected values corresponding to the one or more registers, respectively; a determination module configured to: if the actual value and the expected value corresponding to each of the one or more registers are consistent, determining that the execution of the load instruction is correct; and if the actual value and the expected value corresponding to each of the one or more registers are inconsistent, determining that the execution of the load instruction is wrong.
As a possible implementation manner, the apparatus further includes: the query module is configured to, before the comparison between the actual value and the expected value corresponding to each of the one or more registers, obtain a load operation corresponding to the load instruction according to a mapping queue of the one or more registers, where the mapping queue is used to record a mapping relationship between the load operation and the one or more registers; the comparison module is further configured to: and if the loading operation is the oldest operation in the operations to be submitted, comparing the actual value and the expected value corresponding to the one or more registers respectively.
As a possible implementation manner, the apparatus further includes: a releasing module configured to release the one or more registers if the actual values and the expected values corresponding to the one or more registers respectively are consistent.
As a possible implementation manner, the memory access instruction includes a store instruction, and the store instruction is used to store data in a register format to one or more addresses of a memory, and the apparatus further includes: a second storage module, configured to store, before the memory access component is verified according to the actual result and the expected result of the memory access instruction, data in a bus write transaction packet output by the memory access component into a second merge queue, and store data in a bus write transaction packet output by the reference model into the second merge queue, where the second merge queue is a queue using a memory address as an index, and the second merge queue is used to record actual data and expected data corresponding to each of the one or more addresses; the verification module is further configured to: comparing the actual data and the expected data corresponding to the one or more memory addresses respectively; if the actual data and the expected data corresponding to the one or more memory addresses are consistent, determining that the execution of the storage instruction is correct; and if the actual data and the expected data corresponding to the one or more memory addresses are inconsistent, determining that the execution of the storage instruction is wrong.
In a third aspect, a computing device is provided, comprising: a memory for storing code; a processor configured to execute the code stored in the memory to perform the method according to the first aspect or any one of the possible implementations of the first aspect.
In a fourth aspect, a computer-readable storage medium is provided, on which code for performing the method according to the first aspect or any one of its possible implementations is stored.
In a fifth aspect, a computer program code is provided, comprising instructions for performing the method according to the first aspect or any one of the possible implementations of the first aspect.
The verification method provided by the embodiment of the application can directly obtain the actual results of the memory access component after the storage instruction and the loading instruction are executed, the coupling relation between the storage instruction and the loading instruction is removed, and the verification efficiency of the memory access component is improved.
Drawings
Fig. 1 is a schematic structural diagram of a general verification platform.
Fig. 2 is a schematic flowchart of a verification method according to an embodiment of the present application.
FIG. 3 is a schematic diagram of a queue used by the load instruction validation process.
FIG. 4 is a schematic diagram of a queue used by the store instruction validation process.
FIG. 5 is a flow diagram illustrating a method for store instruction validation using the queue of FIG. 4.
Fig. 6 is a schematic structural diagram of an authentication apparatus according to an embodiment of the present application.
Fig. 7 is a schematic structural diagram of another verification apparatus provided in an embodiment of the present application.
Fig. 8 is a schematic structural diagram of a computing device according to another embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments.
With the continuous development of semiconductor processes and the continuous improvement of functional performance requirements of chips, the chip design process faces a series of problems and challenges, especially verification becomes a bottleneck in the design process.
The verification hierarchy for a chip may include a module level, a subsystem level, and a chip level. Generally, verification is performed from a module level to a subsystem level and then to a chip level, because the lower the level is, the easier it is to locate the design defect, and the shorter the iterative repair cycle of the design defect is, the effect of getting twice the result with half the effort can be achieved in the whole verification process.
Common verification methods include dynamic simulation and static simulation. The dynamic simulation method can perform simulation verification on the module to be tested based on the verification platform. Taking the verification of the microprocessor core as an example, the module to be tested in the verification platform may be a module, a subsystem or a chip of the microprocessor core.
Fig. 1 is a schematic structural diagram of a general authentication platform. The verification platform 100 may include a test case generator 110, a driver 120, a reference model (REF) 130, a module under verification (DUT) 140, a monitor 150, and a scoreboard 160.
The test case generator 110 is configured to generate one or more test cases required by the module to be verified, where the test cases may be data or instructions. For example, when verifying an adder, the test case generator 110 is used to generate an addend and an addend. As another example, when verifying an execution unit, the test case generator 110 is used to generate an instruction to be executed.
The driver 120 may be used to communicate test cases to the reference model 130 and to the module to be verified 140. As one implementation, driver 120 may drive test case information onto ports of reference model 130 and/or module to be verified 140 as specified by a bus protocol.
The reference model 130 is used for simulating the function of the model 140 to be verified, and provides a judgment basis for the verification result of the model 140 to be verified. The model to be verified 140 may execute the received test case and output an actual execution result. Generally speaking, the reference model 130 and the module to be verified 140 execute the same test case, and the execution result of the reference model 130 is taken as the expected result of the model to be verified 140 executing the same test case. The monitor 150 may collect the outputs of the reference model 130 and the model to be verified 140 and send the expected results and the actual results to the scoreboard 160. The score calculating board 160 may determine whether the function of the module to be verified 140 is normal according to the comparison result between the expected result and the actual result.
Currently, the main stream processors in the industry are processors of a load/store architecture, so that access to a memory by a processor core can only be realized through load and store instructions. The access component for executing the loading and storing instructions is used as an important component module of the microprocessor core and plays a role of a bridge for exchanging data with external storage in the processor core. If the memory access component has functional problems, the problem of crash or even crash of the whole processor system may occur, so that the functional correctness of the memory access component must be ensured, and the verification of the memory access component is very important.
In the existing design flow of the microprocessor core, the verification of the data loading and storing instructions executed by the memory access component is generally started at a module level or a subsystem level. Because the storage instruction is used for storing data in the microprocessor core into external storage such as a memory, a reference model in the verification platform cannot acquire an execution result of the storage instruction, so that the storage function of the access storage component cannot be verified.
Therefore, in the related art, the correctness of the execution result of the storage instruction can be generally verified by using the load instruction to load the data of the same address after the execution of the storage instruction, and verifying the storage function of the access storage component according to the load result. This means that if the execution result of the load instruction at the back of the program flow is correct and the address accessed by the load instruction is consistent with the access address of the store instruction at the front of the program flow, the execution result of the load instruction at the front of the program flow is considered correct. In this checking manner, the verification of the store-class instruction and the verification of the load-class instruction are coupled, that is, the correctness of the execution result of the store-class instruction needs to depend on the execution result of the subsequent load-class instruction with address correlation, and the verification is complex, low in accuracy and low in efficiency. The test cases may be hundreds of thousands of instructions, and if the first error site cannot be located in time, the time and difficulty for locating the design defects are undoubtedly greatly increased.
In addition, if no load instruction with the same address is executed after the program flow, it is not easy to determine whether the execution result of the front-end store instruction of the program flow is correct. Therefore, this method requires that the test case has a self-checking function, that is, the test case must include a load instruction with the same address as the store instruction.
In view of the foregoing problems, an embodiment of the present application provides a verification method. The following describes in detail the verification method provided in the embodiment of the present application with reference to fig. 2. The method can be used for the verification of the memory access component, namely, in a verification platform applied by the method, a module to be verified is the memory access component.
Referring to fig. 2, the method 200 includes steps S210 to S240.
In step S210, the test case is used to drive the memory access component to execute the memory access instruction.
The function of the memory access component comprises storing data into an external storage and loading the data in the external storage. Taking the memory access component of the microprocessor core as an example, the memory access component may store data in the microprocessor core into an external memory (such as a memory) of the microprocessor core, or may load data in the external memory into the microprocessor core. The data store and data load may be implemented by a data store instruction and a data load instruction, respectively.
Before verifying the memory access component, the test cases required by the memory access component can be acquired. The test cases can be generated through a test case generator, and the test case generator can be designed according to the requirements of the memory access component.
When the memory access component is verified, the test case can be driven to the memory access component. For example, the test case may be sent to the memory access component via the driver. And the test cases can be sent according to the bus protocol specification of the memory access component. In some embodiments, the memory access component may communicate with other components via bus transaction packets, and thus, information in the test case may also be sent to the memory access component in the form of transaction packets.
After the memory access component receives the test case, the instructions contained in the test case can be executed. The test case may include one instruction or a plurality of instructions. If the test case contains a plurality of instructions, the memory access component can cache the plurality of instructions in the test case and then execute the instructions according to a certain sequence. For example, the memory access component may execute instructions in the order in which they were received.
In step S220, in response to the execution of the access instruction, an actual result of the access instruction is obtained.
The actual result of the access instruction is the execution result of the instruction that can be directly obtained in response to the execution of the access instruction. For example, for a store instruction, the actual result is the result of the instruction execution that may be directly retrieved in response to execution of the instruction.
Whether a load instruction or a store instruction, it is a preset location to store data in the corresponding component. For example, a load instruction may be used to store memory formatted data into one or more registers, and a store instruction may be used to store register formatted data to one or more addresses of memory. Therefore, the actual result of the access instruction can be obtained from a preset position, and can also be obtained from information transmitted between the access component and a corresponding component (such as a register or a memory). If a load instruction is executed, the actual result of the instruction may be data in a register used to store the execution result of the load instruction. The actual result of the instruction can also be obtained through the communication information between the access unit and the register. If the storage instruction is executed, the actual result of the instruction can be obtained through the communication information between the access component and the memory.
As described above, a memory access component may communicate with other components via bus transaction packets, and thus, as one implementation, the actual result of a memory access instruction may be obtained from a bus transaction packet generated after execution of the memory access instruction. If the memory access instruction is a load instruction, the bus transaction packet may be a bus read transaction packet between the memory access component and one or more registers. And if the access instruction is a storage instruction, the bus transaction packet is a bus write transaction packet between the access component and the memory.
In order to obtain the bus transaction packet after the access instruction is executed, the bus transaction packet may be monitored at a corresponding position of the bus. Bus read transaction packets between the memory access component and one or more registers may be monitored at one end of the bus link register. For example, information in a bus read transaction packet may be written to a register via a register file interface, so that the bus read transaction packet may be monitored at the register file interface. For the bus write transaction packet between the access memory component and the memory, the transaction packet can be monitored on the bus between the access memory component and the memory.
In step S230, in response to the execution of the access instruction, an expected result of the access instruction output by the reference model is obtained.
The expected result corresponds to the memory access instruction in the test case. The output result of executing a load instruction or a store instruction by the reference model is the expected result corresponding to the instruction.
There are various ways to obtain the expected result of the memory access instruction output by the reference model. For example, the expected result may be obtained in a manner different from the actual result of the access instruction, or may be obtained in a manner similar to the actual result of the access instruction. If the expected result is obtained in the same manner as the actual result described above (i.e., obtaining the expected result via a bus transaction packet), the expected result of the load instruction may be obtained via a bus write transaction packet between the reference model and the memory, and the expected result of the read instruction may be obtained via a bus read transaction packet between the reference model and the one or more registers.
The instruction execution result (actual result) of the memory access component to be tested and the expected result output by the reference model can be monitored by the monitor described above. For example, a monitor may be employed to monitor bus read transaction packets and/or write transaction packets.
In step S240, the memory access component is verified according to the actual result and the expected result of the memory access instruction.
One possible verification method is that the actual result is compared with the expected result, if the actual result is consistent with the expected result, the verification result is that the memory access component has correct function; and if the actual result is inconsistent with the expected result, the verification result is that the function of the access storage component is wrong. The actual result and the expected result can be compared by using the scoring board, and the verification result of the memory access component is output.
The verification method provided by the embodiment of the application can directly obtain the actual result of the memory access component after the instruction is executed, the coupling relation between the storage instruction and the loading instruction verification is removed, and the verification efficiency of the memory access component is improved. In addition, the execution results of the loading instruction and the storage instruction are checked at the submission point of each instruction (a bus transaction packet generated after the access instruction is executed), so that a first error site can be timely positioned, the difficulty of positioning a design defect is reduced, and the time cost of positioning a design problem is reduced. Meanwhile, the method is used for module-level verification and has the characteristics of low verification level, fast defect positioning and short iteration period.
In order to improve the accuracy and comprehensiveness of the verification result, a certain number of test cases are usually used to verify the memory access component. As a result, a large number of execution results and expected results are generated during the verification process. To facilitate the implementation of the verification method, a queue may be used to store the actual result and the expected result of the memory access instruction.
Since the execution processes of the load instruction and the store instruction are different, the verification processes of the load instruction and the store instruction can be processed in different manners. The processing of the load instruction and the store instruction will be described in detail later.
As one implementation, the actual results and the expected results of the load instruction may be stored into a first merge queue, where each entry in the first merge queue may contain one actual result and one expected result. The index corresponding to each entry of the first merge queue may be a name of a load instruction, a name of an operand, a name of a corresponding test case, or a register number corresponding to the load instruction. Where the load instruction includes one or more operands, execution of the load instruction may include execution of one or more load operations.
If validation of multiple instructions is included in the validation process for a load instruction, the attributes of each of the multiple instructions may be the same or different. Since the time when the memory access unit executes the instructions with different attributes may be different, the order of the actual results output after the memory access unit executes the load instructions may be different from the order of the load instructions input to the memory access unit. As a result, the correspondence between the actual result of the execution of the load instruction and the instruction or the operand included in the instruction cannot be directly obtained. The load instruction may store the data in memory format into one or more registers, so the register number may be directly obtained according to the actual execution result of the load instruction. For example, since the read transaction packet includes the register number corresponding to the load instruction, if the actual execution result of the load instruction is obtained by grabbing the read transaction packet, the register number corresponding to the load instruction may be obtained at the same time. For the above reasons, the register number may be used as an index to a first merge queue, where the first merge queue may be used to record actual and expected values corresponding to one or more registers (i.e., a result register of a load instruction).
The result of the execution of the load instruction may be verified based on the results in the first merge queue. For example, the actual value and the expected value corresponding to each of one or more registers are compared: if the actual value and the expected value corresponding to each of the one or more registers are consistent, determining that the execution of the load instruction is correct; and if the actual value and the expected value corresponding to each of the one or more registers are inconsistent, determining that the execution of the load instruction is wrong.
The register verification result may be obtained by comparing the actual result and the expected result in the first merge queue. However, the mapping relationship between the verification result of the register and the load instruction or the load operation cannot be obtained based on the verification result. If the actual result in a register is inconsistent with the expected result, it is impossible to determine which load instruction executed the error, which is not favorable for error location and elimination. Thus, the mapping of a load operation to one or more registers may be recorded by the register map queue. After the register verification result is obtained, the loading operation corresponding to the register can be obtained by inquiring the register mapping queue, so that the verification result of the corresponding loading instruction is obtained.
It should be noted that, as described above, the actual results output by the memory access unit and the input load instructions may be in different orders, but the expected results output by the reference model and the input load instructions are in the same order. Thus, the mapping of the load operation to one or more registers may be obtained based on the order of the incoming load instructions and the mapping of the expected results of the output with reference to the model.
Before obtaining the mapping relationship between the load operation and one or more registers according to the order of the input load instructions of the reference model and the mapping relationship of the output expected result, the expected result of the reference model may be stored in a queue form by using an operand as an index, for example, may be stored in an expected result data queue. Meanwhile, the actual result of the access component may be stored in a queue, for example, a queue of actual result data indexed by an operand may be stored. Wherein the mapping of the actual result data and the operands may be obtained by referencing the expected result of the model.
As an implementation, when a plurality of registers in the first merge queue all contain actual results and expected results, that is, execution results of a plurality of instructions in the first merge queue are to be compared, an input order of the load instructions may be used as a comparison order of the execution results of the instructions. As described above, the order of the actual results output after the memory access component executes the load instruction may be different from the order of the load instruction input to the memory access component, so that the method can avoid that the verification is performed according to the order in which the memory access component outputs the actual results, which causes that the unverified instructions are flushed by the system, thereby losing the verification result. In practical applications, before comparing the expected result and the actual result in the first merge queue, it may be determined whether the corresponding load operation is the oldest operation in the operations to be submitted: and if the loading operation corresponding to the item in the first merging queue is the oldest operation to be submitted, comparing the actual value and the expected value in the register in the first merging queue.
Due to the limited number of system registers, when a large number of instructions are used for verification, the used registers need to be released in time for a new load operation. As one implementation, one or more registers are released if their respective actual and expected values are consistent.
The processing of load instructions is described in detail above, and the processing of store instructions is described below. It should be noted that some principles in the processing of the store instruction and the load instruction are the same, and will not be described in detail later.
As one implementation, the data in the bus write transaction packet output by the memory access component may be stored into the second merge queue, and the data in the bus write transaction packet output by the reference model may be stored into the second merge queue. The index corresponding to each entry of the second merge queue may be a name of a store instruction, a name of an operand, or a name of a corresponding test case. Since the store instruction is used to store the data in the register format to one or more addresses of the memory, the index corresponding to each entry of the second merge queue may also be the one or more addresses corresponding to the store instruction.
Similar to the execution process of the load instruction, the corresponding relationship between the actual result of the execution of the store instruction and the instruction or the operand included in the instruction cannot be directly obtained, but the memory address corresponding to the store instruction can be obtained according to the actual result of the store instruction. Therefore, the memory address may be used as an index of the second merge queue, and the second merge queue may record actual data and expected data corresponding to one or more addresses respectively.
The result of the execution of the store instruction may be verified based on the results in the second merge queue. For example, the actual data and the expected data corresponding to one or more memory addresses are compared: if the actual data and the expected data corresponding to one or more memory addresses are consistent, determining that the execution of the storage instruction is correct; and if the actual data and the expected data corresponding to the one or more memory addresses are inconsistent, determining that the execution of the storage instruction is wrong.
Similar to load instructions, the expected result of the reference model output is the same as the order in which store instructions were input. Thus, the mapping of a store operation to one or more memory addresses and the data to be stored to that address may be obtained from the mapping of the order of the input store instructions and the expected result of the output of the reference model. To facilitate the lookup, the addresses and data generated by the reference model may be stored in a queue indexed by the storage operands.
After the verification result is obtained according to the second merge queue, the storage operand corresponding to the verification result can be obtained by querying the queue using the storage operand as an index, and then the verification result corresponding to the storage instruction is obtained.
The storage instruction is to store the register format data in one or more registers into one or more addresses of the memory, and convert the register format data into storage format data. However, for checking the execution result of the memory access instruction, the register format data is easier to implement than the memory format data checking. Thus, memory formatted data in the write transaction packets of the actual and expected results may be converted to register formatted data prior to comparing the actual and expected results. As an implementation manner, a reference model write transaction packet processing function and a processing function of the memory access component write transaction packet may be constructed, and before the actual result and the expected result are stored in the second merge queue, the data in the memory format is converted into the data in the register format. The reference model write transaction packet processing function and the memory access component write transaction packet processing function can be the same or different.
As mentioned above, store instructions store data at one or more memory addresses, and thus, the size of the memory addresses contained within different store instructions may vary. That is, the data contained in the store instruction may take multiple bytes, and the data in the memory is stored in bytes, so the number of bytes required for writing the data in the store instruction to the memory is different. As one implementation, the data contained in the store instruction may be stored in bytes while the actual results and the expected results are stored in the second merge queue. That is, each entry of the second merge queue is an actual result and an expected result for one byte address. As an example, the write transaction packet processing function may also have a byte-splitting function of data, in other words, the write transaction packet processing function may also store the actual result and the expected result in bytes in the second merge queue.
Unlike load instructions, the order of comparison of the actual results and expected results of store instructions may be in the order of output of the write transaction packets of the memory access component. As one implementation mode, the write transaction packets of the memory access component can be stored into an address queue taking a natural number as an index according to the captured sequence, and each item of the queue can be used for recording the address and the byte size of the memory instruction access. In addition, the size of the address queue can be dynamically variable according to the frequency of accessing the memory by the program flow.
When the size of the address queue is not 0, that is, the memory access component executes one or more memory instructions and outputs a corresponding actual result, the addresses recorded in the address queue can be obtained in a first-in first-out manner, and the actual result and the expected result are compared by taking the addresses as indexes.
In some embodiments, a data comparison function indexed by address may be constructed, which is used to compare the actual result and the expected result of the store instruction to obtain the verification result.
In order to describe the verification method provided by the present application in more detail, the verification processes of the load instruction and the store instruction of the memory access component are fully described below with reference to fig. 3 to 5, respectively. It should be noted that the verification method described later may be applied to a verification platform, where the verification platform may further include a memory model in addition to the modules described above, so as to perform verification of the access instruction.
FIG. 3 is a schematic diagram of a queue used by the load instruction validation process. Referring to fig. 3, the process of validating a load instruction by a read transaction package includes steps 1 through 7.
In step 1, two register result queues indexed by an operation name are constructed in advance, such as act _ data _ q and exp _ data _ q shown in fig. 3, the size of the queues is dynamically variable, and the two queues are respectively used for storing an actual result of a memory access component to be tested and an expected result of a reference model.
In step 2, a merge queue indexed by register name, such as reglist _ q shown in fig. 3, is constructed, which has a size equal to the number of registers that can be used by the memory access component. For example, if the number of registers that the memory access component may use is 128, then the queue may include 128 entries, one for each register. Further, each entry in the merge queue contains the two register result queues in step 1, and each register number occupies one entry.
In step 3, a mapping queue indexed by register, such as tag _ map _ op _ q shown in fig. 3, is constructed, and the queue is used to store the operation name occupying the register number.
In step 4, the two result queues in the merge queue in step 2 are indexed according to the register number to obtain the states of the two result queues, and then the tag _ map _ op _ q queue is queried according to the register number to obtain the operation name number corresponding to the register number, which is used for judging whether the operation is the oldest operation to be submitted.
In step 5, if the two result queues are not empty and the corresponding operation name indicates that the current operation is the oldest operation to be submitted, the values stored in the two result queues are compared, if the two result queues are equal, the operation is correctly executed, otherwise, the operation is incorrectly executed.
In step 6, if the comparison result in step 5 is correct, the register number corresponding to the operation is released for being occupied by other operations, and the result comparison of the next operation is continued.
And 7, if the comparison in the step 5 is wrong, interrupting the verification, analyzing to locate the defect (problem), and verifying according to the steps again after the defect is repaired until all the test cases pass.
FIG. 4 is a schematic diagram of a queue used by the store instruction validation process. Referring to fig. 4, the process of validating a store instruction by a write transaction packet includes steps 1 through 13.
In step 1, an address queue (addr _ size _ q shown in fig. 4) indexed by a natural number is constructed in advance, and the address queue can be used for recording the addresses and byte sizes accessed by the memory component to be tested. The size of the queue can be dynamically variable according to the frequency of accessing the memory by the program flow.
In step 2, a merge queue (addrlist _ q shown in fig. 4) indexed by address is constructed, the merge queue includes two data storage queues indexed by address, the two data storage queues respectively store data to be loaded by an address of the memory component to be tested and an address corresponding to the reference model, and the data is stored in units of bytes.
In step 3, an address data queue (addr _ data _ q shown in fig. 4) indexed by the operation name (instr _ id) is constructed, and the address data queue can be used to store the address and data information of the access memory corresponding to the operation name.
In step 4, 1 function (dut _ proc _ func) for processing the write transaction packet of the access component is constructed, and the access component storing data in the merged queue stores the data queue in bytes.
At step 5, 1 function (ref _ proc _ func) is constructed that processes a reference pattern write transaction packet, saving data in bytes in the reference pattern store data queue in the merge queue.
In step 6, a data comparison function (com _ func) indexed by address is constructed, and the data of the memory component storage data queue and the reference model data queue in the merging queue are compared and compared in byte units.
In step 7, when the front end of the pipeline finds that a storage operation needs to be executed, a storage instruction sequence generated by the test case generator is sent to the memory access component and the reference model through a driver, and meanwhile, addresses and data generated by the reference model are stored in the queue (addr _ data _ q) constructed in step 3 according to the operation name (instr _ id).
And 8, processing the information saved in the step 7 by a function of the reference model write transaction packet, and saving the information in a reference model storage data queue in the merging queue.
And 9, monitoring the back end of the memory access component pipeline all the time, and collecting the transaction packet when monitoring the storage data write transaction packet of the memory access component.
In step 10, the memory access component storage data transaction packet collected in step 9 is processed by the function of the memory access component write transaction packet, stored in the memory access component storage data queue in the merge queue, and simultaneously the address in the transaction packet is recorded in the address queue constructed in step 1.
In step 11, if the size of the address queue constructed in step 1 is not 0, the addresses recorded in the address queue are obtained in a first-in first-out manner, and the comparison of the results is performed according to the stored data comparison function described in step 6: if the data in the two storage data queues in the merging queue are equal, the current operation is indicated to be correct, and otherwise, the current operation is indicated to be executed incorrectly.
In step 12, if the comparison result in step 11 is correct, the comparison continues with the next address in the address queue.
In step 13, if the comparison result in step 11 is incorrect, the operation is re-executed after the design defect is repaired until all the test cases pass.
A flow of a method for store instruction validation using the queue of FIG. 4 is described below in conjunction with FIG. 5.
Referring to fig. 5, a verification method 500 of a storage instruction includes steps S510 to S538.
In step S510, it is determined whether there is a store instruction to be issued. In the authentication platform described above, this step may be performed by the driver.
If the storage instruction needs to be transmitted, jumping to step S520 and step S530; if no store instruction needs to be issued, continue to step S510.
In step S520, the memory command to be transmitted is driven to the reference model (ref).
In step S521, the address and data generated by the reference model are saved in the addr _ data _ q queue shown in fig. 4 by the operation name.
In step S522, the address and data generated by the reference model are subjected to ref _ proc _ func function processing, and the write data is saved in bytes in exp _ mem _ data _ q in addrlist _ q shown in fig. 4.
In step S530, the store instruction to be issued is driven to the memory access component (dut) to be tested.
In step S531, it is determined whether the memory access component has a memory instruction submitted, and if so, the process jumps to step S532; if no store instruction commits, execution continues with step S531.
In step S532, the write transaction packet of the dut to the memory model update data is captured, and step S533 and step S534 are continuously executed.
In step S533, the write transaction packet captured in step S532 is processed by the dut _ proc _ func function, and is saved in bytes as act _ mem _ data _ q in the addrlist _ q.
In step S534, the address and byte size information in the write transaction packet captured in step S532 is saved in addr _ size _ q.
In step S535, it is determined whether addr _ size _ q is empty, and if addr _ size _ q is not empty, the process jumps to step S536; if addr _ size _ q is empty, execution continues with step S535.
In step S536, the address and the byte size are acquired from addr _ size _ q in a first-in-first-out manner, and the com _ func function is executed to process act _ mem _ data _ q and exp _ mem _ data _ q in addrlist _ q.
In step S537, it is determined whether the comparison result in step S536 is correct, and if the comparison result is correct, the process goes to step S538; and if the comparison result is wrong, restarting to execute the method after the problem of the access component is repaired.
In step S538, all the storage instructions of the test case are executed.
Method embodiments of the present application are described in detail above with reference to fig. 1 to 5, and apparatus embodiments of the present application are described in detail below with reference to fig. 6 to 8. It is to be understood that the description of the method embodiments corresponds to the description of the apparatus embodiments, and therefore reference may be made to the preceding method embodiments for parts not described in detail.
Fig. 6 is a schematic structural diagram of an authentication apparatus according to an embodiment of the present application. Referring to fig. 6, the verification apparatus 600 includes a driving module 610, a first obtaining module 620, a second obtaining module 630, and a verifying module 640.
And the driving module 610 is configured to drive the memory access component to execute the memory access instruction by using the test case.
A first obtaining module 620 configured to obtain an actual result of the memory access instruction in response to execution of the memory access instruction.
A second obtaining module 630, configured to obtain, in response to the execution of the memory access instruction, an expected result of the memory access instruction output by the reference model.
And the verification module 640 is configured to verify the memory access component according to the actual result and the expected result of the memory access instruction.
Optionally, the first obtaining module is further configured to: monitoring a bus transaction packet generated after the memory access component executes the memory access instruction; and acquiring an actual result of the memory access instruction in response to monitoring the bus transaction packet.
Optionally, if the memory access instruction is a load instruction, the bus transaction packet is a bus read transaction packet between the memory access component and one or more registers; and/or if the access instruction is a storage instruction, the bus transaction packet is a bus write transaction packet between the access component and the memory.
Optionally, the memory access instruction includes a load instruction, and the load instruction is configured to store the memory-formatted data into one or more registers, and the apparatus further includes: a first storage module, configured to store an actual result and an expected result of the load instruction into a first merge queue before the memory access component is verified according to the actual result and the expected result of the memory access instruction, where the first merge queue is a queue using a register number as an index, and the first merge queue is used to record an actual value and an expected value corresponding to each of the one or more registers; the authentication module includes: a comparison module configured to compare actual values and expected values corresponding to the one or more registers, respectively; a determination module configured to: if the actual value and the expected value corresponding to each of the one or more registers are consistent, determining that the execution of the load instruction is correct; and if the actual value and the expected value corresponding to each of the one or more registers are inconsistent, determining that the execution of the load instruction is wrong.
Optionally, the apparatus further comprises: the query module is configured to, before the comparing of the actual value and the expected value corresponding to each of the one or more registers, obtain a load operation corresponding to the load instruction according to a mapping queue of the one or more registers, where the mapping queue is used to record a mapping relationship between the load operation and the one or more registers; the comparison module is further configured to: and if the loading operation is the oldest operation in the operations to be submitted, comparing the actual value and the expected value corresponding to the one or more registers respectively.
Optionally, the apparatus further comprises: a releasing module configured to release the one or more registers if the actual values and the expected values corresponding to the one or more registers respectively are consistent.
Optionally, the memory access instruction includes a store instruction, where the store instruction is used to store data in a register format to one or more addresses of a memory, and the apparatus further includes: a second storage module, configured to store, before the memory access component is verified according to the actual result and the expected result of the memory access instruction, data in a bus write transaction packet output by the memory access component into a second merge queue, and store data in a bus write transaction packet output by the reference model into the second merge queue, where the second merge queue is a queue using a memory address as an index, and the second merge queue is used to record actual data and expected data corresponding to each of the one or more addresses; the verification module is further configured to: comparing the actual data and the expected data corresponding to the one or more memory addresses respectively; if the actual data and the expected data corresponding to the one or more memory addresses are consistent, determining that the execution of the storage instruction is correct; and if the actual data and the expected data corresponding to the one or more memory addresses are inconsistent, determining that the execution of the storage instruction is wrong.
Fig. 7 is a schematic structural diagram of another verification apparatus provided in an embodiment of the present application. Referring to fig. 7, the verification apparatus 700 includes a test case generator 710, a driver 720, a reference model 730, a memory access unit to be verified 740, a monitor 750, a score board 760, and a memory model 770.
The test case generator 710 may be configured to generate one or more test cases, which include load instructions and store instructions.
Driver 720 may be used to drive test cases generated by test case generator 710 to reference model 730 and/or to memory access component 740 to be verified.
The reference model 730 may be used to generate the expected results for each load instruction and store instruction.
The memory access unit 740 to be verified may be configured to execute the memory access instruction input by the driver 720 and output an actual result of the memory access instruction, which may be, for example, a bus transaction packet corresponding to the memory access instruction.
The monitor 750 may be used to snoop and collect expected and actual results for load instructions as well as store instructions. For example, monitor 750 may snoop and collect results bus read transaction packets after load instructions have completed execution and write transaction packets after store instructions have completed execution. Wherein, the monitor 750 may listen and collect bus read transaction packets at the to-be-verified access component 740 and the register file interface; the bus write transaction packet may be snooped and collected at the memory access component 740 to be verified and the bus of the memory.
The scoreboard 760 may include a load instruction comparator and a store instruction comparator. The load instruction comparator may be configured to compare expected results and actual results of the load instruction collected in the monitor, for example, by reading the transaction packet via the bus. The store instruction comparator may be used to compare expected results and actual results of store instructions collected in the monitor, such as may be compared by a write transaction packet. According to the comparison result, the verification result of the memory access component can be output.
The memory model 770 may be used to provide data stored at an instruction access address to a load instruction or to receive data carried by a store instruction and update to an access address.
Fig. 8 is a schematic structural diagram of a computing device according to yet another embodiment of the present application. The computing device 800 shown in fig. 8 may include a memory 810 and a processor 820. In some embodiments, the computing device 800 shown in fig. 8 may also include an input/output interface 830 and a transceiver 840. The memory 810, the processor 820, the input/output interface 830 and the transceiver 840 are connected by an internal connection, the memory 810 is used for storing instructions, and the processor 820 is used for executing the instructions stored in the memory 810 to execute the authentication method described in any of the previous embodiments.
It should be understood that, in the embodiment of the present application, the processor 820 may adopt a general-purpose Central Processing Unit (CPU), a microprocessor, an application specific integrated circuit A (ASIC), or one or more integrated circuits, which are used to execute related programs to implement the technical solutions provided in the embodiments of the present application.
It should also be understood that the transceiver 840, also referred to as a communication interface, enables communication between the computing device 800 and other devices or communication networks using transceiver means such as, but not limited to, transceivers.
The memory 810 may include both read-only memory and random access memory and provides instructions and data to the processor 820. A portion of processor 820 may also include non-volatile random access memory. For example, processor 820 may also store information of the device type.
In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 820. The verification method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software modules may be located in ram, flash, rom, prom, or eprom, registers, etc. as is well known in the art. The storage medium is located in the memory 810, and the processor 820 reads the information in the memory 810 and combines the hardware to complete the steps of the method. To avoid repetition, it is not described in detail here.
It should be understood that, in the embodiment of the present application, the processor may be a Central Processing Unit (CPU), and the processor may also be other general-purpose processors, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), field Programmable Gate Arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
It should be understood that in the embodiment of the present application, "B corresponding to a" means that B is associated with a, from which B can be determined. It should also be understood that determining B from a does not mean determining B from a alone, but may be determined from a and/or other information.
It should be understood that the term "and/or" herein is merely one type of association relationship that describes an associated object, meaning that three relationships may exist, e.g., a and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.
It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.
In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit.
In the above embodiments, all or part of the implementation may be realized by software, hardware, firmware, or any combination thereof. When implemented in software, it may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website, computer, server, or data center to another website, computer, server, or data center via wire (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be read by a computer or a data storage device including one or more available media integrated servers, data centers, and the like. The usable medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a Digital Versatile Disk (DVD)), or a semiconductor medium (e.g., a Solid State Disk (SSD)), among others.
The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (16)

1. A method of authentication, comprising:
the test case is utilized to drive the memory access component to execute the memory access instruction;
responding to the execution of the access instruction, and acquiring an actual result of the access instruction;
responding to the execution of the memory access instruction, and acquiring an expected result of the memory access instruction output by a reference model;
and verifying the memory access component according to the actual result and the expected result of the memory access instruction.
2. The verification method of claim 1, wherein the obtaining the actual result of the memory access instruction comprises:
monitoring a bus transaction packet generated after the memory access component executes the memory access instruction;
and responding to the monitored bus transaction packet, and acquiring an actual result of the memory access instruction.
3. The authentication method according to claim 2, wherein:
if the memory access instruction is a loading instruction, the bus transaction packet is a bus read transaction packet between the memory access component and one or more registers; and/or
And if the memory access instruction is a storage instruction, the bus transaction packet is a bus write transaction packet between the memory access component and the memory.
4. The validation method of claim 1, wherein the memory access instruction comprises a load instruction to store memory formatted data into one or more registers,
before the verifying the memory access component according to the actual result and the expected result of the memory access instruction, the method further comprises the following steps:
storing an actual result and an expected result of the load instruction into a first merge queue, wherein the first merge queue is a queue using a register number as an index and is used for recording an actual value and an expected value corresponding to each of the one or more registers;
the verifying the memory access component according to the actual result and the expected result of the memory access instruction comprises the following steps:
comparing the actual value and the expected value corresponding to the one or more registers respectively;
if the actual value and the expected value corresponding to each of the one or more registers are consistent, determining that the execution of the load instruction is correct;
and if the actual value and the expected value corresponding to each of the one or more registers are inconsistent, determining that the execution of the load instruction is wrong.
5. The verification method of claim 4, wherein prior to said comparing the actual value and the expected value for each of the one or more registers, the method further comprises:
obtaining a loading operation corresponding to the loading instruction according to a mapping queue of the one or more registers, wherein the mapping queue is used for recording the mapping relation between the loading operation and the one or more registers;
the comparing the actual result and the expected result corresponding to each of the one or more registers comprises:
and if the loading operation is the oldest operation in the operations to be submitted, comparing the actual value and the expected value corresponding to the one or more registers respectively.
6. The method of validating as defined in claim 4, further comprising:
and releasing the one or more registers if the actual values and the expected values corresponding to the one or more registers respectively are consistent.
7. The verification method of claim 1, wherein the memory access instruction comprises a store instruction to store data in a register format to one or more addresses of a memory,
before the verifying the memory access component according to the actual result and the expected result of the memory access instruction, the method further comprises the following steps:
storing data in the bus write transaction packet output by the memory access component into a second merge queue, and storing data in the bus write transaction packet output by the reference model into the second merge queue, wherein the second merge queue is a queue using a memory address as an index, and the second merge queue is used for recording actual data and expected data corresponding to the one or more addresses;
the verifying the memory access component according to the actual result and the expected result of the memory access instruction comprises the following steps:
comparing actual data and expected data corresponding to the one or more memory addresses respectively;
if the actual data and the expected data corresponding to the one or more memory addresses are consistent, determining that the execution of the storage instruction is correct;
and if the actual data and the expected data corresponding to the one or more memory addresses are inconsistent, determining that the execution of the storage instruction is wrong.
8. An authentication apparatus, comprising:
the drive module is configured to drive the memory access component to execute the memory access instruction by utilizing the test case;
a first obtaining module configured to obtain an actual result of the memory access instruction in response to execution of the memory access instruction;
a second obtaining module configured to obtain an expected result of the memory access instruction output by a reference model in response to execution of the memory access instruction;
and the verification module is configured to verify the memory access component according to the actual result and the expected result of the memory access instruction.
9. The authentication apparatus of claim 8, wherein the first obtaining module is further configured to:
monitoring a bus transaction packet generated after the memory access component executes the memory access instruction;
and acquiring an actual result of the memory access instruction in response to monitoring the bus transaction packet.
10. The authentication device of claim 9, wherein:
if the memory access instruction is a loading instruction, the bus transaction packet is a bus read transaction packet between the memory access component and one or more registers; and/or
And if the memory access instruction is a storage instruction, the bus transaction packet is a bus write transaction packet between the memory access component and the memory.
11. The apparatus as claimed in claim 8, wherein the memory access instruction comprises a load instruction, the load instruction to store data in memory format into one or more registers, the apparatus further comprising:
a first storage module, configured to store an actual result and an expected result of the load instruction into a first merge queue before the memory access component is verified according to the actual result and the expected result of the memory access instruction, where the first merge queue is a queue using a register number as an index, and the first merge queue is used to record an actual value and an expected value corresponding to each of the one or more registers;
the authentication module includes:
a comparison module configured to compare actual values and expected values corresponding to the one or more registers, respectively;
a determination module configured to:
if the actual value and the expected value corresponding to each of the one or more registers are consistent, determining that the execution of the load instruction is correct;
and if the actual value and the expected value corresponding to each of the one or more registers are inconsistent, determining that the execution of the load instruction is wrong.
12. The authentication apparatus of claim 11, wherein the apparatus further comprises:
the query module is configured to, before the comparing of the actual value and the expected value corresponding to each of the one or more registers, obtain a load operation corresponding to the load instruction according to a mapping queue of the one or more registers, where the mapping queue is used to record a mapping relationship between the load operation and the one or more registers;
the comparison module is further configured to:
and if the loading operation is the oldest operation in the operations to be submitted, comparing the actual value and the expected value corresponding to the one or more registers respectively.
13. The authentication apparatus of claim 11, wherein the apparatus further comprises:
a releasing module configured to release the one or more registers if the actual values and the expected values corresponding to the one or more registers respectively are consistent.
14. The apparatus of claim 8, wherein the memory access instruction comprises a store instruction to store data in a register format to one or more addresses of a memory,
the device further comprises:
a second storage module, configured to store, before the memory access component is verified according to the actual result and the expected result of the memory access instruction, data in a bus write transaction packet output by the memory access component into a second merge queue, and store data in the bus write transaction packet output by the reference model into the second merge queue, where the second merge queue is a queue using a memory address as an index, and the second merge queue is used to record actual data and expected data corresponding to the one or more addresses;
the verification module is further configured to:
comparing actual data and expected data corresponding to the one or more memory addresses respectively;
if the actual data and the expected data corresponding to the one or more memory addresses are consistent, determining that the execution of the storage instruction is correct;
and if the actual data and the expected data corresponding to the one or more memory addresses are inconsistent, determining that the execution of the storage instruction is wrong.
15. A computing device, comprising:
a memory for storing code;
a processor for executing code stored in the memory to perform the method of any of claims 1-7.
16. A computer-readable storage medium having stored thereon code for performing the method of any one of claims 1-7.
CN202211200938.9A 2022-09-29 2022-09-29 Verification method and device, computing equipment and computer readable storage medium Pending CN115563914A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211200938.9A CN115563914A (en) 2022-09-29 2022-09-29 Verification method and device, computing equipment and computer readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211200938.9A CN115563914A (en) 2022-09-29 2022-09-29 Verification method and device, computing equipment and computer readable storage medium

Publications (1)

Publication Number Publication Date
CN115563914A true CN115563914A (en) 2023-01-03

Family

ID=84743399

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211200938.9A Pending CN115563914A (en) 2022-09-29 2022-09-29 Verification method and device, computing equipment and computer readable storage medium

Country Status (1)

Country Link
CN (1) CN115563914A (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115840593A (en) * 2023-02-13 2023-03-24 飞腾信息技术有限公司 Method and device for verifying execution component in processor, equipment and storage medium
CN116108782A (en) * 2023-04-14 2023-05-12 此芯科技(上海)有限公司 MCU peripheral control register behavior simulation method and related device
CN116166595A (en) * 2023-04-26 2023-05-26 上海励驰半导体有限公司 Data transmission system, method and chip for SOC bus
CN117076330A (en) * 2023-10-12 2023-11-17 北京开源芯片研究院 Access verification method, system, electronic equipment and readable storage medium
CN117075969A (en) * 2023-08-28 2023-11-17 中国科学院软件研究所 Form verification method and device for RISC-V processor privilege instruction set consistency

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115840593A (en) * 2023-02-13 2023-03-24 飞腾信息技术有限公司 Method and device for verifying execution component in processor, equipment and storage medium
CN116108782A (en) * 2023-04-14 2023-05-12 此芯科技(上海)有限公司 MCU peripheral control register behavior simulation method and related device
CN116108782B (en) * 2023-04-14 2023-07-25 此芯科技(上海)有限公司 MCU peripheral control register behavior simulation method and related device
CN116166595A (en) * 2023-04-26 2023-05-26 上海励驰半导体有限公司 Data transmission system, method and chip for SOC bus
CN117075969A (en) * 2023-08-28 2023-11-17 中国科学院软件研究所 Form verification method and device for RISC-V processor privilege instruction set consistency
CN117076330A (en) * 2023-10-12 2023-11-17 北京开源芯片研究院 Access verification method, system, electronic equipment and readable storage medium
CN117076330B (en) * 2023-10-12 2024-02-02 北京开源芯片研究院 Access verification method, system, electronic equipment and readable storage medium

Similar Documents

Publication Publication Date Title
CN115563914A (en) Verification method and device, computing equipment and computer readable storage medium
US8386851B2 (en) Functional coverage using combinatorial test design
US5996034A (en) Bus bridge verification system including device independent bus monitors
US7293204B2 (en) Computer peripheral connecting interface system configuration debugging method and system
US20070234310A1 (en) Checking for memory access collisions in a multi-processor architecture
CN108351907B (en) Method and circuit for debugging a circuit design
US9286180B1 (en) Final result checking for system with pre-verified cores
US8122293B2 (en) Method for automatically simulating manual testing of a computer, and testing system for performing the method
CN112925524A (en) Method and device for detecting unsafe direct memory access in driver
US8739012B2 (en) Co-hosted cyclical redundancy check calculation
CN114168200B (en) System and method for verifying memory access consistency of multi-core processor
CN112286750A (en) GPIO (general purpose input/output) verification method and device, electronic equipment and medium
US7502966B2 (en) Testcase generation via a pool of parameter files
CN111352997A (en) Test environment verification method and system
CN111338864A (en) Memory problem detection method and device, computer equipment and storage medium
CN115827636A (en) Method for storing and reading simulation data of logic system design from waveform database
CN115269199A (en) Data processing method and device, electronic equipment and computer readable storage medium
US20030177428A1 (en) Simulation method and apparatus for verifying logic circuit including processor
CN106339270B (en) Data verification method and device
US5941971A (en) Bus bridge transaction checker for correct resolution of combined data cycles
CN113760696A (en) Program problem positioning method and device, electronic equipment and storage medium
CN116643945B (en) Data detection method and system for secondary cache and computer equipment
CN114267402B (en) Bad storage unit testing method, device, equipment and storage medium of flash memory
CN112416687B (en) Method and system for verifying access operation, verification device and storage medium
JP6052847B2 (en) Transaction processing apparatus and illegal transaction detection method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination