Method, device, electronic device and storage medium for verifying instruction sequence

By verifying the instruction sequence of the DDR controller through DFI protocol signals independent of the physical layer and storage particles, the problems of long verification cycle and low efficiency in the existing technology are solved, and a fast and accurate verification effect is achieved. It is applicable to controllers of various DDR standards and manufacturers.

CN120407024BActive Publication Date: 2025-09-26MOORE THREADS TECH CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202510896766.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-06-30
Publication Date
2025-09-26
Estimated Expiration
2045-06-30

AI Technical Summary

Technical Problem

In the prior art, instruction sequence verification of a DDR controller relies on feedback from a complete execution link, resulting in a long verification cycle, low efficiency, and susceptibility to interference from physical layer delays or protocol conversion errors.

Method used

By generating command sequences and obtaining the actual response results of the DDR controller, we can directly compare the predicted results. This approach is independent of the physical layer and storage granular model, focusing only on the controller logic functions and using DFI protocol signals for verification.

Benefits of technology

It achieves fast and accurate instruction sequence verification, reduces the complexity of the verification environment, is applicable to controllers of multiple DDR standards and manufacturers, and improves verification efficiency and accuracy.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120407024B_ABST
    Figure CN120407024B_ABST
Patent Text Reader

Abstract

The present disclosure relates to the field of computer technology, and more particularly to a method, apparatus, electronic device, and storage medium for verifying an instruction sequence. The method comprises: generating an instruction sequence and inputting the instruction sequence into a device under test; obtaining an actual response outputted by a double data rate memory (DDR) controller of the device under test; and comparing the actual response with a predicted result to verify the correctness of the execution of the instruction sequence, wherein the predicted result is obtained based on the instruction sequence. According to an embodiment of the present disclosure, a verification platform can operate independently of the logic layer of the DDR controller, eliminating the need for coupling with a verification module, thereby reducing environmental complexity.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a method, device, electronic device, storage medium, and computer program product for verifying an instruction sequence. Background Art

[0002] In integrated circuit design, the Double Data Rate (DDR) memory controller is a key module connecting the processor and memory chips. Its performance and reliability directly impact the overall energy efficiency of the chip. As chip complexity increases, command sequence technology is widely adopted in DDR controllers. By pre-writing multiple instructions into hardware registers and automatically executing them, the hardware significantly reduces the frequency of interaction between software and hardware and improves task execution efficiency. However, verification methods for command sequences face significant challenges.

[0003] In related technologies, verification of instruction sequences often relies on feedback from the complete execution chain, i.e., obtaining the final execution result through the complete path from the DDR controller to the physical layer interface (PHY) and then to the storage device. For the entire execution sequence, verification of the instruction sequence focuses solely on whether the sequence has been completed. Verification of the results on the device side is performed through the Verification Intellectual Property (VIP) module, and relies on the read and write results of the storage device to determine whether the instruction sequence has been executed correctly. This results in long verification cycles and low efficiency. Furthermore, feedback from the device side may introduce interference due to physical layer delays or protocol conversion errors. Summary of the Invention

[0004] In view of this, the present disclosure proposes a technical solution for instruction sequence verification.

[0005] According to one aspect of the present disclosure, a method for verifying an instruction sequence is provided, comprising:

[0006] generating an instruction sequence, and inputting the instruction sequence into the device under test;

[0007] Obtaining an actual response result output by a double data rate memory (DDR) controller of the device under test;

[0008] The actual response result is compared with the predicted result to verify the correctness of the execution of the instruction sequence, wherein the predicted result is obtained by prediction based on the instruction sequence.

[0009] In a possible implementation, generating the instruction sequence includes:

[0010] Obtain an enumeration class, where the enumeration class is encapsulated by a predefined instruction type library, and each instruction type corresponds to an instruction in a scenario;

[0011] The enumeration class is dynamically randomized to generate an instruction sequence containing N instructions, where N≥1, and the type of each instruction is independently randomized.

[0012] In a possible implementation, obtaining an actual response result output by a double data rate memory (DDR) controller of the device under test includes:

[0013] Collecting a DFI protocol signal output by a memory front-end interface DFI of the DDR controller;

[0014] The DFI protocol signal is parsed into a DFI instruction format to obtain the actual response result.

[0015] In a possible implementation, after generating the instruction sequence, the method further includes:

[0016] For each instruction in the instruction sequence, a corresponding prediction instruction is generated based on the DFI protocol specification to obtain the prediction result.

[0017] In one possible implementation, comparing the actual response result with the predicted result to verify the correctness of the execution of the instruction sequence includes:

[0018] When the DDR controller completes executing an instruction in the instruction sequence, obtaining a predicted instruction from the prediction queue and comparing it with an actual response result;

[0019] After the comparison is completed, the prediction instructions that have been compared in the prediction queue are deleted;

[0020] After detecting that the DDR controller has completed executing the instruction sequence, detecting whether there are any remaining predicted instructions in the prediction queue;

[0021] In the absence of remaining predicted instructions, it is determined that the instruction sequence was successfully executed.

[0022] In a possible implementation, the method further includes:

[0023] Detecting the read and write operations of the verification module of the target language on the registers of the device under test, wherein the read and write operations include read and write operations on the register addresses and data executed by the trigger instruction sequence;

[0024] Dynamically updating the register model in the verification platform according to the content of the read and write operations so that the register model is consistent with the register state of the device under test;

[0025] The obtaining of an actual response result output by a double data rate memory (DDR) controller of the device under test includes:

[0026] An actual response result output by the DDR controller is obtained based on the register model.

[0027] In a possible implementation, the method further includes:

[0028] Acquire a target instruction sequence written by the verification module to the DDR controller according to the read and write operations;

[0029] Predicting the target instruction sequence to obtain a target prediction result;

[0030] Comparing the actual response result with the predicted result to verify the correctness of the execution of the instruction sequence includes:

[0031] The target prediction result is compared with the actual response result to verify the correctness of the execution of the target instruction sequence triggered by the verification module.

[0032] According to another aspect of the present disclosure, there is provided an apparatus for verifying an instruction sequence, comprising:

[0033] An instruction generation module, configured to generate an instruction sequence and input the instruction sequence into the device under test;

[0034] A result acquisition module is used to obtain an actual response result output by the double data rate memory DDR controller of the device under test;

[0035] A verification module is used to compare the actual response result with the prediction result to verify the correctness of the execution of the instruction sequence, wherein the prediction result is obtained by prediction based on the instruction sequence.

[0036] In a possible implementation, the instruction generation module is configured to:

[0037] Obtain an enumeration class, where the enumeration class is encapsulated by a predefined instruction type library, and each instruction type corresponds to an instruction in a scenario;

[0038] The enumeration class is dynamically randomized to generate an instruction sequence containing N instructions, where N≥1, and the type of each instruction is independently randomized.

[0039] In a possible implementation, the result acquisition module is configured to:

[0040] Collecting a DFI protocol signal output by a memory front-end interface DFI of the DDR controller;

[0041] The DFI protocol signal is parsed into a DFI instruction format to obtain the actual response result.

[0042] In a possible implementation, the apparatus further includes:

[0043] The prediction result acquisition module is used to generate a corresponding prediction instruction for each instruction in the instruction sequence based on the DFI protocol specification to obtain the prediction result.

[0044] In a possible implementation, the verification module is configured to:

[0045] When the DDR controller completes executing an instruction in the instruction sequence, obtaining a predicted instruction from the prediction queue and comparing it with an actual response result;

[0046] After the comparison is completed, the prediction instructions that have been compared in the prediction queue are deleted;

[0047] After detecting that the DDR controller has completed executing the instruction sequence, detecting whether there are any remaining predicted instructions in the prediction queue;

[0048] In the absence of remaining predicted instructions, it is determined that the instruction sequence was successfully executed.

[0049] In a possible implementation, the apparatus further includes:

[0050] A read and write operation detection module, used to detect the read and write operations of the verification module of the target language on the registers of the device under test, wherein the read and write operations include the read and write operations on the register addresses and data executed by the trigger instruction sequence;

[0051] A dynamic update module, configured to dynamically update a register model in the verification platform according to the content of the read and write operations, so that the register model is consistent with the register state of the device under test;

[0052] The result acquisition module is used to obtain the actual response result output by the DDR controller based on the register model.

[0053] In a possible implementation, the apparatus further includes:

[0054] A target instruction sequence acquisition module, configured to acquire a target instruction sequence written by the verification module to the DDR controller according to the read and write operations;

[0055] A prediction module, configured to predict the target instruction sequence to obtain a target prediction result;

[0056] The verification module is used to compare the target prediction result with the actual response result to verify the correctness of the execution of the target instruction sequence triggered by the verification module.

[0057] According to another aspect of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above method.

[0058] According to another aspect of the present disclosure, a non-volatile computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above method are implemented.

[0059] According to another aspect of the present disclosure, a computer program product is provided, including a computer program, or a non-volatile computer-readable storage medium carrying the computer program, wherein the computer program implements the steps of the above method when executed by a processor.

[0060] In the disclosed embodiments, verification focuses solely on the actual and predicted responses of the DDR controller. Because the verification process doesn't rely on the signal conversion capabilities of the PHY or feedback from the memory chip, the verification platform doesn't need to integrate PHY or chip models, focusing solely on the logical functionality of the controller itself. For example, in a simulation environment, the PHY and chips are implemented using complex physical models; however, this method, by separating these dependencies, only simulates the DFI interface signals, making the verification environment completely independent of the physical layer implementation. This allows the verification platform to operate independently of the DDR controller's logic layer, eliminating the need for coupled PHY or chip verification modules, reducing environmental complexity.

[0061] Furthermore, the DFI protocol is an industry-wide interface standard between DDR controllers and PHYs (as defined by JEDEC). Since verification is based on comparing DFI protocol instructions, and the DFI protocol is standardized, any DDR controller that complies with the DFI protocol can reuse the same verification process. For example, when a project upgrades from a DDR4 to a DDR5 controller, only the DFI protocol mapping rules (such as command encoding and timing parameters) need to be updated, without having to rebuild the entire verification platform. Therefore, the verification method provided by this disclosure can quickly adapt to different DDR standards (such as DDR4 / 5) or controller designs from different manufacturers, simply by adjusting the protocol prediction rules.

[0062] Furthermore, the overall process of this disclosure operates at the logic layer and does not involve physical implementation details. This decouples the verification process from the physical layer implementation (such as PHY circuit design and particle electrical characteristics), making it applicable to any controller scenario that complies with the DFI protocol. For example, the same verification platform can be used to verify the LPDDR5 controller in an automotive chip and the DDR5 controller in a server chip, requiring only adjustment of the DFI protocol parameters. Therefore, the verification method provided by this disclosure is not bound to a specific physical implementation and can be applied to DDR controller verification requirements in multiple scenarios and standards.

[0063] Further features and aspects of the present disclosure will become apparent from the following detailed description of exemplary embodiments with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate exemplary embodiments, features, and aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0065] Figure 1 A flowchart of a method for verifying an instruction sequence according to an embodiment of the present disclosure is shown.

[0066] Figure 2 A block diagram illustrating an apparatus for verifying an instruction sequence according to an embodiment of the present disclosure is shown.

[0067] Figure 3 A block diagram illustrating an apparatus for verifying an instruction sequence according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0068] Various exemplary embodiments, features, and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0069] As used herein, the terms "comprises," "comprising," "having," or variations thereof are open ended and include one or more stated features, integers, elements, steps, parts, or functions, but do not preclude the presence or addition of one or more other features, integers, elements, steps, parts, functions, or groups thereof.

[0070] When an element is referred to as being "connected," "coupled," "responsive" or variations thereof to another element, it can be directly connected, coupled or responsive to the other element or intervening elements may be present.

[0071] Although the terms first, second, third, etc. may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another element / operation. Therefore, without departing from the teachings of the present invention, the first element / operation in some embodiments may be referred to as the second element / operation in other embodiments.

[0072] The word “exemplary” is used exclusively herein to mean “serving as an example, example, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0073] In addition, numerous specific details are provided in the following detailed description to better illustrate the present disclosure. Those skilled in the art will appreciate that the present disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art are not described in detail in order to highlight the main points of the present disclosure.

[0074] As integrated circuits (ICs) continue to grow in complexity, efficient and accurate verification of their instruction sequences has become crucial. To address this, the present disclosure provides an instruction sequence verification method, which can be implemented on a verification platform. This method is primarily applicable to the field of integrated circuit design, particularly during the development and verification of dynamic random access memory (DRAM) systems. This method is suitable for various scenarios requiring instruction sequence verification, such as the design and testing phases of microprocessors, memory controllers, and embedded systems.

[0075] A verification platform is a simulation environment built on a hardware description language (such as System Verilog) for functional verification of a device under test (DUT). It generates various stimulus signals and test cases to simulate the DUT's behavior in a real-world environment, thereby verifying that the DUT's functionality meets design requirements.

[0076] The DUT can be written in the Verilog hardware description language. Verilog is a widely used hardware description language for designing and verifying digital circuits. A DUT written in Verilog accurately describes its functionality and behavior, facilitating simulation and testing in a verification platform. The verification platform interacts with the DUT's interfaces, applying stimuli and acquiring responses, thereby fully verifying the DUT.

[0077] After the Register-Transfer Level (RTL) code (written in Verilog) of the DDR controller is developed, the verification method provided in this disclosure is used to verify whether its instruction sequence execution function meets the design specifications.

[0078] Figure 1 FIG. 1 is a flow chart showing a method for verifying an instruction sequence according to an embodiment of the present disclosure. Figure 1 As shown, the method includes:

[0079] In step S11 , an instruction sequence is generated and input into the device under test.

[0080] A command sequence is a set of predefined instructions arranged in a specific order that instructs the DDR controller to perform a specific task. In other words, a command sequence is a set of commands input to a hardware module, such as a DDR controller. In one example, the command sequence might define parameters such as the memory access operation type (e.g., read or write), address, and data. In another example, the command sequence might also include instructions for switching to a low-power mode.

[0081] The device under test is an integrated circuit module or system whose functions are to be verified, specifically a DDR controller or a chip module containing a DDR controller, for example, a memory controller in a system on chip (SoC).

[0082] When generating an instruction sequence, the instruction sequence (such as a read-write combination) can be generated by randomization or preset rules. For details, please refer to the possible implementation methods provided in the present disclosure, which will not be described here.

[0083] After the instruction sequence is generated, it can be written into the instruction register of the DDR controller, which then triggers the DDR controller to execute the instruction sequence.

[0084] In step S12, an actual response result output by the double data rate memory DDR controller of the device under test is obtained.

[0085] When a command sequence is input into the device under test, it performs the corresponding operations based on these commands. Specifically, the command sequence is first sent to the DDR controller, which converts the commands into DFI protocol commands. These commands are then sent to the PHY layer via the DRAM Front Interface (DFI). The PHY layer receives the DFI commands from the DDR controller and converts them into signals suitable for transmission on the physical medium. The converted signals are then transmitted to the memory chips via a physical connection (such as the memory bus). After receiving these signals, the memory chips perform the corresponding operations.

[0086] The DDR controller is a hardware module used to manage DDR memory access. It communicates with the physical layer interface (PHY) using the DFI protocol and outputs command signals that comply with the protocol specifications. When verifying the successful execution of a command sequence, you can independently verify that the DDR controller correctly converts the command sequence into the signals defined by the DFI protocol.

[0087] The actual response output by the DDR controller can then be obtained and verified for correctness. This actual response is the result of the DUT's DDR controller executing the instruction sequence. Specifically, the DFI protocol output signals of the DDR controller (such as timing waveforms, data content, and protocol status) can be captured and decoded into readable DFI protocol instructions.

[0088] In step S13, the actual response result is compared with the predicted result to verify the correctness of the execution of the instruction sequence, wherein the predicted result is obtained by prediction based on the instruction sequence.

[0089] The prediction result is based on the theoretical expected output of the instruction sequence, which can be the expected DFI protocol instruction generated for each instruction in the instruction sequence according to the DFI protocol specification. It can be implemented by calling a pre-written function. For details, please refer to the possible implementation methods provided in this disclosure, which will not be elaborated here.

[0090] Since the instruction sequence contains multiple instructions, the corresponding actual response result will also correspond to multiple DFI instructions, and the prediction result may also contain multiple DFI instructions. The DFI instructions will include command type, address mapping and timing requirements.

[0091] When comparing the actual response result with the expected result, the command type, address, and timing of the actual DFI protocol instruction and the predicted instruction can be compared one by one. If there is any inconsistency, the instruction sequence is marked as defective; if there is consistency, it indicates that the verification of the instruction sequence has passed.

[0092] In the disclosed embodiments, verification focuses solely on the actual and predicted responses of the DDR controller. Because the verification process doesn't rely on the signal conversion capabilities of the PHY or feedback from the memory chip, the verification platform doesn't need to integrate PHY or chip models, focusing solely on the logical functionality of the controller itself. For example, in a simulation environment, the PHY and chips are implemented using complex physical models; however, this method, by separating these dependencies, only simulates the DFI interface signals, making the verification environment completely independent of the physical layer implementation. This allows the verification platform to operate independently of the DDR controller's logic layer, eliminating the need for coupled PHY or chip verification modules, reducing environmental complexity.

[0093] Furthermore, the DFI protocol is an industry-wide interface standard between DDR controllers and PHYs (as defined by JEDEC). Since verification is based on comparing DFI protocol instructions, and the DFI protocol is standardized, any DDR controller that complies with the DFI protocol can reuse the same verification process. For example, when a project upgrades from a DDR4 to a DDR5 controller, only the DFI protocol mapping rules (such as command encoding and timing parameters) need to be updated, without having to rebuild the entire verification platform. Therefore, the verification method provided by this disclosure can quickly adapt to different DDR standards (such as DDR4 / 5) or controller designs from different manufacturers, simply by adjusting the protocol prediction rules.

[0094] Furthermore, the overall process of this disclosure operates at the logic layer and does not involve physical implementation details. This decouples the verification process from the physical layer implementation (such as PHY circuit design and particle electrical characteristics), making it applicable to any controller scenario that complies with the DFI protocol. For example, the same verification platform can be used to verify the LPDDR5 controller in an automotive chip and the DDR5 controller in a server chip, requiring only adjustment of the DFI protocol parameters. Therefore, the verification method provided by this disclosure is not bound to a specific physical implementation and can be applied to DDR controller verification requirements in multiple scenarios and standards.

[0095] In one possible implementation, generating an instruction sequence includes: obtaining an enumeration class, where the enumeration class is encapsulated by a predefined instruction type library, and each instruction type corresponds to an instruction in a scenario; and dynamically randomizing the enumeration class to generate an instruction sequence containing N instructions (N≥1, where N is a positive integer), wherein the type of each instruction is independently randomized.

[0096] An enumeration class is a special class type used to enumerate a fixed set of constant values. An enumeration class explicitly defines a set of related constants, each representing a specific state or value. Enumeration classes are often encapsulated from a predefined library of instruction types. To do this, you first define an enumeration class that contains various instruction types, with each enumeration constant corresponding to a specific instruction type. By encapsulating these enumeration constants in a class, you can easily manage and use these instruction types.

[0097] Each instruction type corresponds to an instruction in a specific scenario. Examples of these scenarios include data write / read instructions, and instructions for entering / exiting low-power mode. Different application scenarios correspond to different types of instructions. By using enumeration classes, these instruction types can be clearly defined and distinguished.

[0098] Dynamic randomization of enumeration classes allows for the generation of diverse instruction sequences to cover a wider range of test scenarios and situations. Specifically, a random number generator can be used to randomly select constants from the enumeration class, generating random instruction types. Furthermore, constraints and weighting can be combined to tailor the randomization process to specific needs and scenarios. For example, in certain test scenarios, certain instruction types may need to appear more frequently. In this case, biased randomization can be achieved by assigning weights to these enumeration constants.

[0099] During randomization, the length N of the instruction sequence can be randomized, generating an instruction sequence consisting of N instructions, where N can be any integer greater than or equal to 1. By setting different N values, instruction sequences of varying lengths can be generated to meet the instruction sequence length requirements of different test scenarios. Longer instruction sequences can be used to test the long-term stability and complex logic processing capabilities of the system, while shorter instruction sequences are suitable for rapid functional verification and unit testing.

[0100] Furthermore, each instruction type can be independently randomized. That is, when generating an instruction sequence, the instruction at each position is randomly selected independently, unaffected by other instructions. This independent randomization ensures the diversity and unpredictability of instruction sequences, allowing the generated instruction sequences to cover a wider range of test scenarios.

[0101] In the disclosed embodiments, dynamic randomization is used to generate sequences containing multiple instruction types, enabling coverage of a wider range of test scenarios and situations. Because each instruction type is independently randomized, a variety of different instruction combinations and sequences can be generated, significantly increasing the diversity of test stimuli. This comprehensive coverage approach helps uncover potential defects hidden in a variety of complex scenarios, reducing the likelihood of missing issues and thus improving the comprehensiveness and quality of verification.

[0102] The independent randomization of each instruction ensures unpredictable testing, making the verification process more realistic and reliable. Because test cases are randomly generated, developers and testers cannot predict the specific test content and sequence in advance, thus avoiding subjective bias and the need for targeted test case design. This objective testing approach helps identify edge cases and anomalies that are easily overlooked in conventional testing, thereby improving the credibility and reliability of verification results.

[0103] In one possible implementation, obtaining the actual response result output by the double data rate memory DDR controller of the device under test includes: collecting a DFI protocol signal output by a memory front-end interface DFI of the DDR controller; and parsing the DFI protocol signal into a DFI instruction format to obtain the actual response result.

[0104] DFI is a standardized interface protocol between the DDR controller and the physical layer (PHY), primarily used to transmit information such as commands, addresses, and data. By acquiring signals at the DFI interface, we can obtain the raw protocol signals output by the DDR controller when executing a command sequence. These signals, in the form of electrical signals, contain the DDR controller's direct response to the command sequence, reflecting the controller's operation and state changes at each moment.

[0105] The collected DFI protocol signals need to be parsed and converted into DFI commands with clear semantics and format. Parsing converts the raw signals into easy-to-understand and process command sets, such as read, write, and refresh commands. These parsed DFI commands constitute the actual response results, which can intuitively demonstrate the specific behavior and operation sequence of the DDR controller during command execution.

[0106] In the disclosed embodiments, by directly collecting and parsing DFI protocol signals, the most original and authentic response information of the DDR controller can be obtained, avoiding interference or errors that may be introduced by relying on PHY or storage particles, thereby more accurately verifying the execution effect of the instruction sequence. Because the verification process focuses only on the signals and instructions at the DFI interface level and is unrelated to the specific implementation details of the PHY and storage particles, it can be verified independently of these hardware components. This independence enables the verification platform to effectively test and verify the instruction sequence of the DDR controller without relying on a complete hardware link. As a standardized interface protocol, DFI is widely used in various DDR storage systems. Therefore, the verification method based on the DFI interface can be easily ported to different hardware platforms and design environments, and is applicable to various types of DDR controller verification projects, greatly improving the versatility and flexibility of the verification environment.

[0107] In a possible implementation, after generating the instruction sequence, the method further includes: for each instruction in the instruction sequence, generating a corresponding prediction instruction based on a DFI protocol specification to obtain the prediction result.

[0108] The DFI protocol is a standardized interface that defines the communication method between the DDR controller and the physical layer (PHY). It specifies the transmission format and timing requirements for information such as commands, addresses, and data. Familiarity with the DFI protocol specification is essential for generating accurate command predictions.

[0109] When generating predicted instructions, the instruction sequence can be analyzed in detail to determine the type, parameters, and execution order of each instruction. For example, the instruction sequence may include different types of instructions, such as read instructions, write instructions, and refresh instructions. Then, according to the DFI protocol specification, a corresponding predicted instruction is generated for each instruction. A predicted instruction describes the DFI protocol signal that the device under test (DUT) is expected to output when executing the corresponding instruction. For example, for a read instruction, the predicted instruction should comply with the DFI protocol specification and include information such as the read command, target address, and the expected data format.

[0110] The generated predicted instructions are then organized according to the execution order of the instruction sequence to form a complete prediction result set. For example, the predicted instructions can be placed in a queue to form a prediction queue. Each predicted instruction corresponds to a specific instruction in the original instruction sequence, and the order of the predicted instructions in the prediction result set is consistent with the order of the instructions in the original instruction sequence.

[0111] In the disclosed embodiments, the predicted instructions generated based on the DFI protocol specification accurately describe the expected behavior of the DUT when executing each instruction. By comparing these predicted instructions with the actual response results, any deviations or errors in the DUT can be accurately detected, thereby improving verification accuracy.

[0112] In one possible implementation, comparing the actual response result with the predicted result to verify the correctness of the execution of the instruction sequence includes: when the DDR controller completes executing an instruction in the instruction sequence, obtaining the predicted instruction from the prediction queue and comparing it with the actual response result; after the comparison is completed, deleting the predicted instruction in the prediction queue that has been compared; after detecting that the DDR controller has completed executing the instruction sequence, detecting whether there are any remaining predicted instructions in the prediction queue; and if there are no remaining predicted instructions, determining that the instruction sequence is successfully executed.

[0113] As previously mentioned, before verification begins, a prediction queue is created based on the generated instruction sequence and the DFI protocol specification. This queue contains prediction instructions corresponding to each instruction in the instruction sequence, and the order of the prediction instructions in the queue exactly matches the execution order of the instructions in the instruction sequence. The prediction instructions describe in detail the format, content, and timing of the DFI protocol signals that the DDR controller expects to output when executing the corresponding instruction.

[0114] As the DDR controller executes a command sequence, it collects DFI protocol signals output by the DFI interface and parses them into DFI command format to obtain the actual response result. Each time the DDR controller executes an instruction in the command sequence, it retrieves the corresponding predicted instruction from the prediction queue and compares the predicted instruction with the actual response result. For example, if a read instruction is executed, the memory address read, the data value read, and the timing of the read operation are compared to ensure consistency with the predicted instruction.

[0115] To maintain the accuracy and timeliness of the prediction queue, after each comparison is completed, the predicted instructions that have been compared can be immediately deleted from the queue. This can avoid confusion or mismatches during subsequent comparisons and ensure that the queue only contains predicted instructions that have not yet been compared.

[0116] The prediction queue is managed using a first-in, first-out (FIFO) principle. Whenever a predicted instruction is removed for comparison and then deleted, the next predicted instruction in the queue automatically moves forward to fill the gap. This ensures that the order of predicted instructions always matches the execution order of the instruction sequence, ensuring accurate comparison.

[0117] After detecting that the DDR controller has completed executing the instruction sequence, it is detected whether there are any remaining predicted instructions in the prediction queue. If there are any remaining predicted instructions, it means that during the execution of the instruction sequence, some predicted instructions did not obtain corresponding actual response results, and there may be problems such as instructions not being executed or the execution order being wrong.

[0118] When it is detected that the DDR controller has completed executing the instruction sequence and there are no remaining predicted instructions in the prediction queue, it can be determined that each instruction in the instruction sequence has been correctly executed, indicating that the actual response result is completely consistent with the predicted result, and the verification is passed.

[0119] After confirming that the instruction sequence has been successfully executed, the verification platform can generate a corresponding verification report. The report records the verification status and may include additional information such as verification time and resource consumption to facilitate subsequent analysis and evaluation.

[0120] In the embodiment of the present disclosure, by performing a comparison immediately after each instruction is executed, errors in the execution process can be discovered in a timely manner, avoiding difficulties in locating problems caused by the accumulation of errors. At the same time, the method of comparing one instruction at a time ensures accurate inspection of the execution of each instruction, thereby improving the accuracy of verification. After the execution of the instruction sequence is completed, the remaining instructions in the prediction queue are checked to ensure that all predicted instructions are compared with the actual response results, avoiding the omission of verification of any instructions and ensuring the integrity of the verification. If there are remaining predicted instructions, it indicates that there are problems such as instructions not being executed or the execution order being wrong, thereby improving the efficiency of the verification work.

[0121] In one possible implementation, the method further includes: detecting read and write operations performed by a verification module in a target language on registers of a device under test, the read and write operations including read and write operations on register addresses and data executed by a trigger instruction sequence; dynamically updating a register model in a verification platform based on the content of the read and write operations to ensure that the register model is consistent with the register state of the device under test; and obtaining an actual response result output by a double data rate memory (DDR) controller of the device under test includes: obtaining the actual response result output by the DDR controller based on the register model.

[0122] Integrated circuit verification typically utilizes a variety of programming languages ​​and verification tools, such as System Verilog and C. Target language verification modules are modules written in a specific language and used to verify the functionality of the device under test (DUT). These modules can include functions such as test case generation, stimulus signal transmission, and response result collection. The target language is a language different from the language used to execute the method. In one example, when the method is executed by a module written in System Verilog, the target language is C; when the method is executed by a module written in C, the target language is System Verilog.

[0123] In order to verify the test of the DUT by the verification module of the target language, the read and write operations of the target language verification module on the DUT registers can be monitored, for example, the read and write operations on the register addresses and data used to trigger the execution of the instruction sequence, because these operations directly affect the behavior of the DUT and the execution flow of the instruction sequence.

[0124] Registers within the DUT are used to control and configure its various functions. Reading and writing register addresses can change the DUT's operating mode, trigger specific actions, or retrieve current status information. For example, writing to a register address can initiate the execution of an instruction sequence, while reading the same address can return the execution status of the instruction sequence.

[0125] When reading and writing registers, data transmission is crucial. The written data determines the specific behavioral parameters of the DUT, such as memory address and operation type. The read data reflects the current state of the DUT or the result of the operation, which is crucial for verifying the correctness of the instruction sequence.

[0126] In the verification platform, a register model corresponding to the internal register structure of the DUT is constructed. This model contains information such as the address, bit width, initial value, and access rights of all registers, and is used to simulate the behavior and status of the DUT registers.

[0127] Whenever the target language verification module detects a read or write operation on a DUT register, it can promptly update the corresponding register status in the register model based on the operation content (such as register address, read or write type, data value, etc.). For example, if a write operation is detected, the written data is updated to the corresponding address in the register model; if a read operation is detected, the data at the corresponding address is retrieved from the register model.

[0128] Because the register model is consistent with the DUT's register states, the actual response output from the DDR controller can be obtained by querying the register model. For example, the values ​​of certain registers in the model directly reflect the DDR controller's output states, such as commands, addresses, and data. Based on the data in the register model, the actual response can be parsed according to the DFI protocol specification or other relevant standards.

[0129] The actual response obtained based on the register model is then compared with the predicted response to verify the correct execution of the instruction sequence. If the two are consistent, the DUT's behavior meets expectations; otherwise, further analysis is required to determine the cause of the discrepancy.

[0130] In the embodiments of the present disclosure, in a multi-language verification environment, through a unified register model, verification modules written in different languages ​​can work together better, which helps to integrate various verification resources, verify the results of the verification process triggered by verification modules written in different languages, form a more complete and powerful verification system, and improve the overall quality and efficiency of verification.

[0131] In one possible implementation, the method further includes: obtaining a target instruction sequence written by the verification module to the DDR controller based on the read and write operations; predicting the target instruction sequence to obtain a target prediction result; and comparing the actual response result with the prediction result to verify the correctness of the execution of the instruction sequence, including: comparing the target prediction result with the actual response result to verify the correctness of the execution of the target instruction sequence triggered by the verification module.

[0132] As mentioned above, the communication between the verification module in the target language and the DDR controller can be monitored. By analyzing the read and write operations of the verification module, the instruction sequence written to the DDR controller by the verification module can be extracted. For ease of description, this instruction sequence is referred to as the target instruction sequence. Specifically, the extracted instructions can be arranged in the execution order to construct the complete target instruction sequence.

[0133] Then, based on the DFI protocol specification, the DDR controller predicts the response it should generate when executing the target instruction sequence. This prediction result is referred to as the target prediction result for ease of description. For details, see the implementation method for generating prediction instructions provided in this disclosure, which will not be detailed here.

[0134] The target prediction result is then compared with the actual response result to verify the correctness of the instruction sequence executed by the verification module of the target language. The specific verification process can be found in the implementation method of comparing the actual response result with the prediction result provided in this disclosure, and will not be repeated here.

[0135] In the disclosed embodiment, by monitoring the read and write operations of the verification module of the target language on the registers of the device under test, the target instruction sequence written by the verification module to the DDR controller is directly obtained, thereby ensuring the accuracy and authenticity of the obtained instruction sequence. Then, based on this target instruction sequence, a prediction is made to obtain a target prediction result, and the result is compared with the actual response result, so that the correctness of the execution of the instruction sequence triggered by the verification module of the target language can be accurately verified. Direct verification of the instruction sequence triggered by the verification module of the target language is achieved, avoiding the errors and uncertainties that may be caused by indirect verification, improving the accuracy and reliability of verification, and also helping to timely discover and locate problems in the verification process, thereby improving the efficiency and quality of the entire verification process.

[0136] According to another aspect of the present disclosure, there is provided a device for verifying an instruction sequence. Figure 2 A block diagram of an instruction sequence verification device according to an embodiment of the present disclosure is shown. The instruction sequence verification device 20 includes:

[0137] An instruction generation module 21 is used to generate an instruction sequence and input the instruction sequence into the device under test;

[0138] A result acquisition module 22 is used to obtain an actual response result output by the double data rate memory DDR controller of the device under test;

[0139] The verification module 23 is used to compare the actual response result with the prediction result to verify the correctness of the execution of the instruction sequence, wherein the prediction result is obtained by prediction based on the instruction sequence.

[0140] In a possible implementation, the instruction generation module is configured to:

[0141] Obtain an enumeration class, where the enumeration class is encapsulated by a predefined instruction type library, and each instruction type corresponds to an instruction in a scenario;

[0142] The enumeration class is dynamically randomized to generate an instruction sequence containing N instructions, where N≥1, and the type of each instruction is independently randomized.

[0143] In a possible implementation, the result acquisition module is configured to:

[0144] Collecting a DFI protocol signal output by a memory front-end interface DFI of the DDR controller;

[0145] The DFI protocol signal is parsed into a DFI instruction format to obtain the actual response result.

[0146] In a possible implementation, the apparatus further includes:

[0147] The prediction result acquisition module is used to generate a corresponding prediction instruction for each instruction in the instruction sequence based on the DFI protocol specification to obtain the prediction result.

[0148] In a possible implementation, the verification module is configured to:

[0149] When the DDR controller completes executing an instruction in the instruction sequence, obtaining a predicted instruction from the prediction queue and comparing it with an actual response result;

[0150] After the comparison is completed, the prediction instructions that have been compared in the prediction queue are deleted;

[0151] After detecting that the DDR controller has completed executing the instruction sequence, detecting whether there are any remaining predicted instructions in the prediction queue;

[0152] In the absence of remaining predicted instructions, it is determined that the instruction sequence was successfully executed.

[0153] In a possible implementation, the apparatus further includes:

[0154] A read and write operation detection module, used to detect the read and write operations of the verification module of the target language on the registers of the device under test, wherein the read and write operations include the read and write operations on the register addresses and data executed by the trigger instruction sequence;

[0155] A dynamic update module, configured to dynamically update a register model in the verification platform according to the content of the read and write operations, so that the register model is consistent with the register state of the device under test;

[0156] The result acquisition module is used to obtain the actual response result output by the DDR controller based on the register model.

[0157] In a possible implementation, the apparatus further includes:

[0158] A target instruction sequence acquisition module, configured to acquire a target instruction sequence written by the verification module to the DDR controller according to the read and write operations;

[0159] A prediction module, configured to predict the target instruction sequence to obtain a target prediction result;

[0160] The verification module is used to compare the target prediction result with the actual response result to verify the correctness of the execution of the target instruction sequence triggered by the verification module.

[0161] In some embodiments, the functions or modules included in the device provided by the embodiments of the present disclosure can be used to execute the method described in the above method embodiments. The specific implementation can refer to the description of the above method embodiments. For the sake of brevity, it will not be repeated here.

[0162] An embodiment of the present disclosure further provides an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above method.

[0163] An embodiment of the present disclosure further provides a non-volatile computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the steps of the above method when executed by a processor.

[0164] An embodiment of the present disclosure further provides a computer program product, including a computer program, or a non-volatile computer-readable storage medium carrying the computer program, wherein the computer program implements the steps of the above method when executed by a processor.

[0165] Figure 3 A block diagram of an apparatus for verifying an instruction sequence according to an embodiment of the present disclosure is shown. For example, apparatus 1900 may be provided as a server or terminal device. Figure 3The apparatus 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932 for storing instructions, such as an application, that can be executed by the processing component 1922. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute the instructions to perform the above-described method.

[0166] The device 1900 may also include a power supply component 1926 configured to perform power management of the device 1900, a wired or wireless network interface 1950 configured to connect the device 1900 to a network, and an input / output interface 1958 (I / O interface). The device 1900 may operate based on an operating system stored in the memory 1932, such as Windows Server 2003. TM , MacOS X TM , Unix TM , Linux TM , FreeBSD TM or similar.

[0167] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions that can be executed by the processing component 1922 of the apparatus 1900 to perform the above-described method.

[0168] A computer-readable storage medium can be a tangible device that can hold and store programs / instructions used by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device, such as a punch card or raised structure within a groove on which instructions are stored, and any suitable combination thereof. As used herein, a computer-readable storage medium is not to be construed as a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted via wires.

[0169] The computer programs (or computer-readable program instructions) described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage medium in the respective computing / processing device for storage.

[0170] The computer program (or computer program instructions) used to perform the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, the state information of the computer-readable program instructions is used to personalize an electronic circuit, such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), so that the electronic circuit can execute the computer-readable program instructions, thereby implementing various aspects of the present disclosure.

[0171] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0172] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device is generated that implements the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, where these instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0173] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

[0174] The flow charts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems, methods and computer program products according to multiple embodiments of the present disclosure. In this regard, each box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and the part of the module, program segment or instruction contains one or more executable instructions for realizing the prescribed logical function. In some alternative implementations, the functions marked in the box can also occur in a sequence different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented by a dedicated hardware-based system that performs the prescribed function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0175] While various embodiments of the present disclosure have been described above, the foregoing description is intended to be illustrative, non-exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, their practical applications, or technological improvements in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for verifying an instruction sequence, characterized in that: include: generating an instruction sequence, and inputting the instruction sequence into the device under test; Obtaining an actual response result output by a double data rate memory (DDR) controller of the device under test; Comparing the actual response result with the predicted result to verify the correctness of the execution of the instruction sequence, wherein the predicted result is obtained by prediction based on the instruction sequence; The obtaining of an actual response result output by a double data rate memory (DDR) controller of the device under test includes: Collecting a DFI protocol signal output by a memory front-end interface DFI of the DDR controller; Parsing the DFI protocol signal into a DFI instruction format to obtain the actual response result; The generating instruction sequence comprises: Obtain an enumeration class, where the enumeration class is encapsulated by a predefined instruction type library, and each instruction type corresponds to an instruction in a scenario; The enumeration class is dynamically randomized to generate an instruction sequence containing N instructions, where N≥1, and the type of each instruction is independently randomized.

2. The method according to claim 1, characterized in that After generating the instruction sequence, the method further includes: For each instruction in the instruction sequence, a corresponding prediction instruction is generated based on the DFI protocol specification to obtain the prediction result.

3. The method according to claim 1, characterized in that Comparing the actual response result with the predicted result to verify the correctness of the execution of the instruction sequence includes: When the DDR controller completes executing an instruction in the instruction sequence, obtaining a predicted instruction from the prediction queue and comparing it with an actual response result; After the comparison is completed, the prediction instructions that have been compared in the prediction queue are deleted; After detecting that the DDR controller has completed executing the instruction sequence, detecting whether there are any remaining predicted instructions in the prediction queue; In the absence of remaining predicted instructions, it is determined that the instruction sequence was successfully executed.

4. The method according to claim 1, wherein The method further comprises: Detecting the read and write operations of the verification module of the target language on the registers of the device under test, wherein the read and write operations include read and write operations on the register addresses and data executed by the trigger instruction sequence; Dynamically updating the register model in the verification platform according to the content of the read and write operations so that the register model is consistent with the register state of the device under test; The obtaining of an actual response result output by a double data rate memory (DDR) controller of the device under test includes: An actual response result output by the DDR controller is obtained based on the register model.

5. The method according to claim 4, characterized in that The method further comprises: Acquire a target instruction sequence written by the verification module to the DDR controller according to the read and write operations; Predicting the target instruction sequence to obtain a target prediction result; Comparing the actual response result with the predicted result to verify the correctness of the execution of the instruction sequence includes: The target prediction result is compared with the actual response result to verify the correctness of the execution of the target instruction sequence triggered by the verification module.

6. A device for verifying an instruction sequence, characterized in that: include: An instruction generation module, configured to generate an instruction sequence and input the instruction sequence into the device under test; A result acquisition module is used to obtain an actual response result output by the double data rate memory DDR controller of the device under test; a verification module, configured to compare the actual response result with a predicted result to verify the correctness of the execution of the instruction sequence, wherein the predicted result is obtained by prediction based on the instruction sequence; The result acquisition module is used to: Collecting a DFI protocol signal output by a memory front-end interface DFI of the DDR controller; Parsing the DFI protocol signal into a DFI instruction format to obtain the actual response result; The instruction generation module is used to: Obtain an enumeration class, where the enumeration class is encapsulated by a predefined instruction type library, and each instruction type corresponds to an instruction in a scenario; The enumeration class is dynamically randomized to generate an instruction sequence containing N instructions, where N≥1, and the type of each instruction is independently randomized.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 5.

8. A non-volatile computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Citation Information

Patent Citations

  • Prototype verification method and device of DDR4 controller, equipment, medium and product

    CN120087291A