Method for verifying multi-mode high-speed asynchronous interface

Abstract

The invention discloses a method for verifying a multi-mode high-speed asynchronous interface. The method comprises the following steps of: 1, freely switching the interface and configuring an environment; 2, freely controlling and randomly controlling an interface time sequence and an interface access rate; step 3, based on the real scene error model, injecting various types of errors; 4, verifying an asynchronous path; and 5, performing automatic comparison for judging the correctness of the interface based on the correctness of the register data. By the adoption of the method, rapid RTL function verification can be conducted on the multi-mode asynchronous interface, time sequence verification can be conducted on the asynchronous path of the gate-level netlist corresponding to the multi-mode asynchronous interface, and by means of the parameterized controllable environment provided by the method, abnormity can be rapidly reproduced when simulation is abnormal.

Description

Technical Field

[0001] The invention relates to the field of digital electronic circuit front-end verification, and in particular to a method for verifying a multi-mode high-speed asynchronous interface. Background Art

[0002] The verification of asynchronous data parallel interfaces with more than 1,500 modes has the following difficulties: (1) There are many interface configurations, and verifying them one by one through targeted test stimuli will consume too many resources; (2) The interface timing needs to change in real time and the rate needs to be controllable to simulate the actual interface usage scenario; (3) Error injection should be as consistent as possible with the actual situation; (4) The timing of asynchronous interfaces is difficult to guarantee through static timing analysis and is usually guaranteed through manual calculation by back-end designers. Due to the complexity of the paths within the interface and the large number of asynchronous paths, manual calculations may result in omissions. (5) It is difficult to fully synchronize the behavior of the interface reference model with the interface behavior; The accuracy and stability of the asynchronous interface are related to whether the chip can be used normally. The above difficulties need to be solved systematically. Summary of the invention

[0003] Purpose of the invention: To provide a method for verifying a multi-mode high-speed asynchronous interface to solve the above-mentioned problems existing in the prior art.

[0004] Technical solution: A method for verifying a multi-mode high-speed asynchronous interface, comprising: Step 1: Freely switch interfaces and environment configurations; Step 2: freely control and randomly control the interface timing and interface access rate; Step 3: Based on the real-world error model, inject multiple types of errors; Step 4: Verify the asynchronous path; Step 5: Based on the correctness of the register data, an automatic comparison is performed to determine the correctness of the interface.

[0005] 1. The free configuration and switching of the verification environment and interface mode can quickly verify whether the interface is normal in different modes and implement random testing of different interface mode switching combinations; 2. The interface timing can be freely controlled, and any rate interface test can be performed; 3. Establish a set of error models based on real-world scenarios, which can be used to inject different types of errors to verify the stability of the interface; 4. Establish a set of methods to verify asynchronous paths, which can avoid the potential risk of functional errors in asynchronous interface circuits due to cross-clock domain problems at the simulation level; 5. Establish an automatic comparison environment to judge the correctness of the interface based on the correctness of the register data.

[0006] This method can be used to quickly verify the RTL function of a multi-mode asynchronous interface and the timing of the asynchronous path of its corresponding gate-level netlist. In addition, the parameterized and controllable environment provided by this method can quickly reproduce anomalies when they occur in simulation.

[0007] In a further embodiment, step 1 further comprises: Step 11: Generate all XML files containing interface configuration information and configuration verification information in advance; Step 12: Specify the desired interface configuration. Step 13: Select the corresponding XML file according to the desired configuration information, and load the configuration information into the interface to complete the configuration of the interface; Step 14: assign specified values ​​to static variables in the transaction-level file in the environment through the expected configuration information to complete the configuration of the verification environment; Step 15: Repeat steps 11-14 to implement other configuration switching.

[0008] By designing the above scheme, in order to verify all modes of the interface more quickly, the present invention associates the configuration of the interface with the verification environment using XML to achieve the purpose of synchronous configuration, thereby realizing fast switching of modes and reducing the workload of writing test stimuli. The specific steps are as follows: The first step is to pre-generate 1500 XML files with interface configuration information and content verification information according to the interface configuration instructions; In the second step, by randomly specifying or directionally specifying the expected configuration of the interface, the corresponding XML file is automatically selected according to the specified configuration environment, and then the register configuration information contained in the XML is loaded into the relevant registers of the interface and the relevant static variables in the environment; In the third step, the environment initiates an interface reset to implement interface reconfiguration; In the fourth step, the environment performs the interface initialization process and the interface configuration switching is completed; In a further embodiment, step 2 further comprises: Step 21: define a high-precision dynamic random time variable in the transaction-level file, and define constraints on the random variable; Step 22: During simulation, the time variables in the transaction-level file are assigned or randomized and then passed to the interface driver task; Step 23: The interface driver task controls the timing of the interface according to the obtained time variable.

[0009] By designing the above scheme, in order to realize the controllable interface timing and real-time control of the interface rate, and better simulate the timing situation of the host when using the interface in actual use, the present invention parameterizes all the timings involved in the interface protocol, realizes that any timing in the protocol can be controlled, all timings can be random and meet the timing requirements, and the specific steps are as follows: The first step is to extract the timing requirements in the protocol and define them as random variables in the transaction-level file; The second step is to extract the correlation points between the time series and add appropriate constraints to the time series variables so that the time series variables can be completely random in the random process and meet the time series requirements in the protocol. The third step is to pass the specified or randomized timing variables to the interface driver through the sequence generator; The fourth step is to specify or randomly set the value of the random variable in the test stimulus to achieve precise parameterized control of the interface timing; This method can realize arbitrary regulation of the interface access rate. When an abnormality occurs in the random test interface, the timing parameters during simulation can be extracted, and the problem can be quickly reproduced.

[0010] In a further embodiment, the error model comprises: Configuration error: host and interface configurations do not match; Protocol error: the host uses an interface that does not meet the protocol requirements when the protocol requirements are not met. The protocol errors include timing errors, address errors, and protocol cycle errors. Various types of fault injection include: Step 31, according to steps 11-14, the interface and environment configuration do not match the error; Step 32, implementing the specified arbitrary timing error and the random arbitrary timing error according to steps 21-23; Step 33: assign or randomly set the address variable of any step in the asynchronous interface protocol in the transaction-level file to a value that does not conform to the interface protocol, thereby realizing an address error; Step 34: In the transaction-level file, any read / write cycle variable that contains any step in the asynchronous interface protocol is assigned or randomly set to a value that does not comply with the interface protocol, such as performing a write cycle operation in a read cycle, thereby causing a protocol cycle error.

[0011] The above scheme is designed mainly to test the stability of the interface and better simulate the error conditions that the interface may encounter in actual use. The present invention classifies the errors into four categories: configuration error, address error, cycle error and timing error, and defines four types of error behaviors. For address errors, the specific operation steps are as follows: The first step is to extract the address driven to the pin at each step in the interface protocol and define it as a random variable in the transaction-level file; The second step is to extract the variation range of the address variable and add appropriate constraints to the address variable so that the address variable can be random within a suitable range; The third step is to define an address error switch in the transaction-level file to control the generation of address errors.

[0012] If address error injection is required, turn on this switch and specify or randomly select the error address for each step; For periodic operation errors, the specific steps are as follows: The first step is to define the cycle error switch and cycle error phase in the transaction level file; The second step is to invert the read / write control signal in the driver according to the cycle error phase; The third step is to turn on the cycle error switch in the test stimulus and specify the cycle error stage; For timing errors, according to steps 21-23, the specific steps are as follows: The first step is to define the timing error switch in the transaction-level file to control the occurrence of timing errors; The second step is to define the timing constraints in the timing error mode; The third step is to turn on the timing error switch in the test stimulus to specify or randomly error the timing.

[0013] In a further embodiment, the verification asynchronous path comprises: Step 41: There is a single-bit variable in the test stimulus whose flip cycle is the same as the internal clock cycle; Step 42: Using a single-bit variable, based on steps 21-23, the phase difference between the external clock and the internal clock is precisely controlled to complete a comprehensive test of the asynchronous path.

[0014] By designing the above scheme, in order to prevent the timing problem of the read / write data latch register across the clock domain inside the asynchronous interface from the verification level, and provide a guarantee for the correct design judgment of the gate-level netlist, based on the timing control method provided in steps 21-23, the present invention provides a method that can traverse and verify all asynchronous paths in an acceptable time, and the specific steps are as follows: The first step is to define a single-bit variable with the same change period as the internal clock in the test stimulus, and use this variable as a reference to specify the phase difference with its external clock; In the second step, the value of the corresponding timing control parameter is automatically calculated according to the function based on this phase difference; The third step is to reverse the read / write data bit from 0 to 1 and from 1 to 0 in the same phase difference. In the fourth step, the phase difference is increased with the minimum simulation accuracy until it reaches the clock period value of the internal clock; In a further embodiment, step 5 comprises: Step 51: Establish a register reference model for simulating the interface register, monitor the access operation of the interface, and update the expected value of the register; Step 52, access the register through the interface to obtain a return value; Step 53: Create a scoreboard and pass the predicted value and the return value into the scoreboard for comparison.

[0015] By designing the above scheme, in order to monitor the correctness of the interface, the present invention provides an automatic comparison system based on whether the register read and write data is correct, such as Figure 6 As shown, the specific steps are as follows: The first step is to establish a register model to store the expected value of the register and obtain the actual value of the register; the second step is to establish a reference model to parse the expected operation of the register in the transaction and the expected value of some functional registers.

[0016] For writing, the write address and write data are provided to the register model, and the register model updates the expected value of the corresponding register; For reading, the read address and the corresponding register expected value are provided to the register model, and the register model updates the expected value to the model of the corresponding register.

[0017] For special interface access, for example, when registers are accessed in a manner inconsistent with the bus width, the expected value is updated according to the number of bits accessed. For accesses to the internal status registers of the design under test, the reference model predicts the accesses accordingly and then updates the expected value of the register model. The whole process does not consume simulation time. The third step is to establish a scoreboard, obtain events from the reference model, parse the map and domain of the corresponding register and send it to the register model. The register model returns the actual value and expected value of the corresponding register, and the reference model compares the corresponding bits of the data according to the access rules.

[0018] Beneficial effects: The present invention discloses a method for verifying a multi-mode high-speed asynchronous interface, which has the following advantages compared with the prior art: 1. The free configuration and switching of the verification environment and interface mode can quickly verify whether the interface is normal in different modes and implement random testing of different interface mode switching combinations; 2. The interface timing can be freely controlled, and any rate interface test can be performed; 3. Establish a set of error models based on real-world scenarios, which can be used to inject different types of errors to verify the stability of the interface; 4. Establish a set of methods to verify asynchronous paths, which can avoid the potential risk of functional errors in asynchronous interface circuits due to cross-clock domain problems at the simulation level; 5. Establish an automatic comparison environment to judge the correctness of the interface based on the correctness of the register data.

[0019] This method can be used to quickly verify the function of the multi-mode asynchronous interface and the timing of the asynchronous path of the corresponding gate-level netlist. In addition, relying on the parameterized and controllable environment provided by this method, anomalies can be quickly reproduced when they occur in the simulation. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a schematic diagram of the configuration switching process of the present invention.

[0021] Figure 2 It is a schematic diagram of the timing test flow of the present invention.

[0022] Figure 3 It is a schematic diagram of the error injection process of the present invention.

[0023] Figure 4 It is a schematic diagram of the asynchronous path timing verification process of the present invention.

[0024] Figure 5 It is a schematic diagram of the automatic determination process of the correctness of the interface of the present invention.

[0025] Figure 6 It is a schematic diagram of the automatic comparison environment architecture of the present invention. DETAILED DESCRIPTION

[0026] The present application relates to a method for verifying a multi-mode high-speed asynchronous interface, which is explained in detail below through a specific implementation method.

[0027] A method for verifying a multi-mode high-speed asynchronous interface, comprising: Step 1: Freely switch interfaces and environment configurations; Step 2: freely control and randomly control the interface timing and interface access rate; Step 3: Based on the real-world error model, inject multiple types of errors; Step 4: Verify the asynchronous path; Step 5: Based on the correctness of the register data, an automatic comparison is performed to determine the correctness of the interface.

[0028] Step 1: Freely switch interfaces and environment configurations; Step 2: freely control and randomly control the interface timing and interface access rate; Step 3: Based on the real-world error model, inject multiple types of errors; Step 4: Verify the asynchronous path; Step 5: Based on the correctness of the register data, an automatic comparison is performed to determine the correctness of the interface.

[0029] 1. The free configuration and switching of the verification environment and interface mode can quickly verify whether the interface is normal in different modes and implement random testing of different interface mode switching combinations; 2. The interface timing can be freely controlled, and any rate interface test can be performed; 3. Establish a set of error models based on real-world scenarios, which can be used to inject different types of errors to verify the stability of the interface; 4. Establish a set of methods to verify asynchronous paths, which can avoid the potential risk of functional errors in asynchronous interface circuits due to cross-clock domain problems at the simulation level; 5. Establish an automatic comparison environment to judge the correctness of the interface based on the correctness of the register data.

[0030] This method can be used to quickly verify the RTL function of a multi-mode asynchronous interface and the timing of the asynchronous path of its corresponding gate-level netlist. In addition, the parameterized and controllable environment provided by this method can quickly reproduce anomalies when they occur in simulation.

[0031] The step 1 also includes: Step 11: Generate all XML files containing interface configuration information and configuration verification information in advance; Step 12: Specify the desired interface configuration. Step 13: Select the corresponding XML file according to the desired configuration information, and load the configuration information into the interface to complete the configuration of the interface; Step 14: assign specified values ​​to static variables in the transaction-level file in the environment through the expected configuration information to complete the configuration of the verification environment; Step 15: Repeat steps 11-14 to implement other configuration switching.

[0032] By designing the above scheme, in order to verify all modes of the interface more quickly, the present invention associates the configuration of the interface with the verification environment using XML to achieve the purpose of synchronous configuration, thereby realizing fast switching of modes and reducing the workload of writing test stimuli. The specific steps are as follows: The first step is to pre-generate 1500 XML files with interface configuration information and content verification information according to the interface configuration instructions; In the second step, by randomly specifying or directionally specifying the expected configuration of the interface, the corresponding XML file is automatically selected according to the specified configuration environment, and then the register configuration information contained in the XML is loaded into the relevant registers of the interface and the relevant static variables in the environment; In the third step, the environment initiates an interface reset to implement interface reconfiguration; In the fourth step, the environment performs the interface initialization process and the interface configuration switching is completed; The step 2 also includes: Step 21: define a high-precision dynamic random time variable in the transaction-level file, and define constraints on the random variable; Step 22: During simulation, the time variables in the transaction-level file are assigned or randomized and then passed to the interface driver task; Step 23: The interface driver task controls the timing of the interface according to the obtained time variable.

[0033] By designing the above scheme, in order to realize the controllable interface timing and real-time control of the interface rate, and better simulate the timing situation of the host when using the interface in actual use, the present invention parameterizes all the timings involved in the interface protocol, realizes that any timing in the protocol can be controlled, all timings can be random and meet the timing requirements, and the specific steps are as follows: The first step is to extract the timing requirements in the protocol and define them as random variables in the transaction-level file; The second step is to extract the correlation points between the time series and add appropriate constraints to the time series variables so that the time series variables can be completely random in the random process and meet the time series requirements in the protocol. The third step is to pass the specified or randomized timing variables to the interface driver through the sequence generator; The fourth step is to specify or randomly set the value of the random variable in the test stimulus to achieve precise parameterized control of the interface timing; This method can realize arbitrary regulation of the interface access rate. When an abnormality occurs in the random test interface, the timing parameters during simulation can be extracted, and the problem can be quickly reproduced.

[0034] The error model includes: Configuration error: host and interface configurations do not match; Protocol error: the host uses an interface that does not meet the protocol requirements when the protocol requirements are not met. The protocol errors include timing errors, address errors, and protocol cycle errors. Various types of fault injection include: Step 31, according to steps 11-14, the interface and environment configuration do not match the error; Step 32, implementing the specified arbitrary timing error and the random arbitrary timing error according to steps 21-23; Step 33: assign or randomly set the address variable of any step in the asynchronous interface protocol in the transaction-level file to a value that does not conform to the interface protocol, thereby realizing an address error; Step 34: In the transaction-level file, any read / write cycle variable that contains any step in the asynchronous interface protocol is assigned or randomly set to a value that does not comply with the interface protocol, such as performing a write cycle operation in a read cycle, thereby causing a protocol cycle error.

[0035] The above scheme is designed mainly to test the stability of the interface and better simulate the error conditions that the interface may encounter in actual use. The present invention classifies the errors into four categories: configuration error, address error, cycle error and timing error, and defines four types of error behaviors. For address errors, the specific operation steps are as follows: The first step is to extract the address driven to the pin at each step in the interface protocol and define it as a random variable in the transaction-level file; The second step is to extract the variation range of the address variable and add appropriate constraints to the address variable so that the address variable can be random within a suitable range; The third step is to define an address error switch in the transaction-level file to control the generation of address errors.

[0036] If address error injection is required, turn on this switch and specify or randomly select the error address for each step; For periodic operation errors, the specific steps are as follows: The first step is to define the cycle error switch and cycle error phase in the transaction level file; The second step is to invert the read / write control signal in the driver according to the cycle error phase; The third step is to turn on the cycle error switch in the test stimulus and specify the cycle error stage; For timing errors, according to steps 21-23, the specific steps are as follows: The first step is to define the timing error switch in the transaction-level file to control the occurrence of timing errors; The second step is to define the timing constraints in the timing error mode; The third step is to turn on the timing error switch in the test stimulus to specify or randomly error the timing.

[0037] The verification asynchronous path includes: Step 41: There is a single-bit variable in the test stimulus whose flip cycle is the same as the internal clock cycle; Step 42: Using a single-bit variable, based on steps 21-23, the phase difference between the external clock and the internal clock is precisely controlled to complete a comprehensive test of the asynchronous path.

[0038] By designing the above scheme, in order to prevent the timing problem of the read / write data latch register across the clock domain inside the asynchronous interface from the verification level, and provide a guarantee for the correct design judgment of the gate-level netlist, based on the timing control method provided in steps 21-23, the present invention provides a method that can traverse and verify all asynchronous paths in an acceptable time, and the specific steps are as follows: The first step is to define a single-bit variable with the same change period as the internal clock in the test stimulus, and use this variable as a reference to specify the phase difference with its external clock; In the second step, the value of the corresponding timing control parameter is automatically calculated according to the function based on this phase difference; The third step is to reverse the read / write data bit from 0 to 1 and from 1 to 0 in the same phase difference. In the fourth step, the phase difference is increased with the minimum simulation accuracy until it reaches the clock period value of the internal clock; The step 5 comprises: Step 51: Establish a register reference model for simulating the interface register, monitor the access operation of the interface, and update the expected value of the register; Step 52, access the register through the interface to obtain a return value; Step 53: Create a scoreboard and pass the predicted value and the return value into the scoreboard for comparison.

[0039] By designing the above scheme, in order to monitor the correctness of the interface, the present invention provides an automatic comparison system based on whether the register read and write data is correct, such as Figure 6 As shown, the specific steps are as follows: The first step is to establish a register model to store the expected value of the register and obtain the actual value of the register; the second step is to establish a reference model to parse the expected operation of the register in the transaction and the expected value of some functional registers.

[0040] For writing, the write address and write data are provided to the register model, and the register model updates the expected value of the corresponding register; For reading, the read address and the corresponding register expected value are provided to the register model, and the register model updates the expected value to the model of the corresponding register.

[0041] For special interface access, for example, when registers are accessed in a manner inconsistent with the bus width, the expected value is updated according to the number of bits accessed. For accesses to the internal status registers of the design under test, the reference model predicts the accesses accordingly and then updates the expected value of the register model. The whole process does not consume simulation time. The third step is to establish a scoreboard, obtain events from the reference model, parse the map and domain of the corresponding register and send it to the register model. The register model returns the expected value and actual value of the corresponding register, and the reference model compares the corresponding bits of the data according to the access rules. Example

[0042] Example 1 describes the process of synchronizing and switching configuration between the interface and the environment: like Figure 1As shown in the figure, this process can not only realize the fast test of all interface modes with the least amount of code, but also test the random switching of interface configuration. First, list all configuration options according to the configuration information, such as interface width (8bit, 16bit), interface signal enable polarity (low enable, high enable), interface phase (single phase, double phase), etc., and then use the automated script to traverse and generate all xml configuration files containing configuration and verification information for the environment to use; The configuration information is specified in the stimulus. On the one hand, the corresponding XML file is loaded into the configuration memory of the interface and the interface is waiting for power-on reset. On the other hand, the corresponding XML file is read, the detailed configuration information is parsed, and the static configuration variables of the transaction-level file are passed. These static configuration variables are consistent in all instances of the transaction class unless reconfigured. The instance of the transaction class containing the configuration information is passed to the driver through the sequencer, and the driver can perform configuration matching operations with the interface. The environment performs initialization polling on the interface until the interface reset is complete. After that, the stimulus can perform the required test operations on the interface; If the configuration needs to be changed, the configuration information is re-specified, the XML is loaded into the interface configuration register, and the parsed detailed configuration information is passed to the static configuration variables of the transaction-level file. Then, the interface is reset and initialization polling is performed until the interface reset is completed; Example

[0043] Example 2 describes the interface timing test process. Figure 2 shown.

[0044] The timing involved in the interface protocol has been parameterized in the environment, and can be directed and randomized. Under this premise, the test process can be carried out. First, the interface is tested under the extreme timing specified by the protocol. If an error occurs, the environment will give the timing value at this time for debugging. If it is normal, the interface rate is controlled by controlling the interface timing, and the interface rate test is carried out. If it is normal, a random test of the measured port rate is carried out. Example

[0045] Example 3 describes the test process of random error injection of the interface. Figure 3 shown.

[0046] The interface error switch, error type, and driver behavior under different error types have been defined in the environment, and the test process can be carried out under this premise. First, a normal access test that meets the interface protocol is performed. If the result is normal, a specified or random error injection is performed. After the error injection, a normal access test is performed again to determine whether the interface is affected by the error injection. If the interface is abnormal, the error source is located and repaired according to the error information provided by the environment. Example

[0047] Embodiment 4 describes a test flow for timing verification of asynchronous paths during gate simulation. Figure 4 shown.

[0048] The timing involved in the interface protocol has been parameterized in the environment and can be specified in a directional manner. Under this premise, the test process can be carried out. First, the clock period of the internal clock in the asynchronous path is obtained, and then a single-bit variable with the same inversion period is defined in the stimulus. In the stimulus, this variable is used as a reference to control the phase difference between the external clock and the internal clock through the timing variable, and the phase difference is traversed to the size of the clock period. Example

[0049] Example 5 describes the process of automatically judging the correctness of an interface when performing a read / write operation on the interface. Figure 5 shown.

[0050] Automatic comparison environment architecture Figure 6 shown.

[0051] For automatic comparison of the read operation process, the interface returns the read data, and the scoreboard compares the expected value from the register model with the read data. If they are the same, the process ends normally. If they are not the same, relevant information for error location is printed. For automatic comparison of the read operation process, the reference model updates the expected value of the relevant register to the register model. The scoreboard compares the expected value from the register model with the actual value. If they are the same, the process ends normally. If they are not the same, relevant information for error location is printed.

[0052] Working principle description: Step 1: Freely switch interfaces and environment configurations; Step 2: freely control and randomly control the interface timing and interface access rate; Step 3: Based on the real-world error model, inject multiple types of errors; Step 4: Verify the asynchronous path; Step 5: Based on the correctness of the register data, an automatic comparison is performed to determine the correctness of the interface.

[0053] The preferred specific embodiments of the present invention are described in detail above in conjunction with the accompanying drawings. However, the present invention is not limited to the specific details in the above specific embodiments. Within the technical concept of the present invention, various equivalent transformations can be made to the technical scheme of the present invention, and these equivalent transformations all belong to the protection scope of the present invention.

Claims

1. A method for verifying a multi-mode high-speed asynchronous interface, characterized in that: include: Step 1: Switch interface and environment configuration; Step 2: Control interface timing and interface access rate; Step 3: Based on the real-world error model, inject multiple types of errors; Step 4: Verify the asynchronous path; Step 5: Based on the correctness of the register data, an automatic comparison is performed to determine the correctness of the interface.

2. A method for verifying a multi-mode high-speed asynchronous interface according to claim 1, characterized in that: The step 1 also includes: Step 11: Generate all XML files containing interface configuration information and configuration verification information in advance; Step 12: Specify the desired interface configuration. Step 13: Select the corresponding XML file according to the desired configuration information, and load the configuration information into the interface to complete the configuration of the interface; Step 14: assign specified values ​​to static variables in the transaction-level file in the environment through the expected configuration information to complete the configuration of the verification environment; Step 15: Repeat steps 11-14 to implement other configuration switching.

3. A method for verifying a multi-mode high-speed asynchronous interface according to claim 1, characterized in that: The step 2 also includes: Step 21: define a high-precision dynamic random time variable in the transaction-level file, and define constraints on the random variable; Step 22: During simulation, the time variables in the transaction-level file are assigned or randomized and then passed to the interface driver task; Step 23: The interface driver task controls the timing of the interface according to the obtained time variable.

4. A method for verifying a multi-mode high-speed asynchronous interface according to claim 1, characterized in that: The error model includes: Configuration error: host and interface configurations do not match; Protocol error: the host uses an interface that does not meet the protocol requirements when the protocol requirements are not met. The protocol errors include timing errors, address errors, and protocol cycle errors. Various types of fault injection include: Step 31, according to steps 11-14, the interface and environment configuration do not match the error; Step 32, implementing the specified arbitrary timing error and the random arbitrary timing error according to steps 21-23; Step 33: assign or randomly set the address variable of any step in the asynchronous interface protocol in the transaction-level file to a value that does not conform to the interface protocol, thereby realizing an address error; Step 34: In the transaction-level file, any read / write cycle variable in any step of the asynchronous interface protocol is assigned or randomly set to a value that does not conform to the interface protocol, thereby achieving a protocol cycle error.

5. The method for verifying a multi-mode high-speed asynchronous interface according to claim 1, wherein: The verification asynchronous path includes: Step 41: There is a single-bit variable in the test stimulus whose flip cycle is the same as the internal clock cycle; Step 42: Using a single-bit variable, based on steps 21-23, the phase difference between the external clock and the internal clock is precisely controlled to complete a comprehensive test of the asynchronous path.

6. A method for verifying a multi-mode high-speed asynchronous interface according to claim 1, characterized in that: The step 5 comprises: Step 51: Establish a register reference model for simulating the interface register, monitor the access operation of the interface, and update the expected value of the register; Step 52, access the register backdoor through the register model to obtain a return value; Step 53: Create a scoreboard and pass the predicted value and the return value into the scoreboard for comparison.

Images