Universal verification system supporting multiple protocols and chip verification method

Abstract

The invention provides a universal verification system supporting multiple protocols and a chip verification method, and the system comprises a protocol configuration module which is used for receiving more than two kinds of protocol configuration information and converting the multiple kinds of protocol configuration information into a configuration file with a uniform format; the test management module is used for generating a test sequence according to the requirements of the configuration file and the test case; the protocol adaptable module is used for sending the test sequence to the to-be-tested device and receiving data returned by the to-be-tested device; the coverage rate collection module is used for counting coverage rate data of the to-be-tested device according to data returned by the to-be-tested device, and the parameter information in the configuration file comprises coverage points needing to be tested by the test case. The invention further provides a chip verification method implemented by applying the system. The universal verification system can be compatible with various communication protocols, and the test efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of chip testing, and in particular to a universal verification system supporting multiple protocols and a chip verification method implemented by applying the system. Background Art

[0002] During the chip design process, multiple chip verifications are often required to verify that the designed chip meets the specified requirements. Currently, the most commonly used chip verification method is the universal verification method based on UVM. During the chip testing process, a chip test system needs to be built. The chip test system sends test sequences to the chip under test and receives data returned by the chip under test. The verification system analyzes the chip based on the received data to determine whether the chip has passed verification.

[0003] However, existing chip verification systems are often only designed for a single communication protocol. For example, a chip verification system can only verify chips that use Ethernet or chips that use the PCIe protocol. Figure 1 The existing verification system is provided with a test top-level module 11, which transmits data with the device under test 10 through an interface 12. The test top-level module 11 is provided with a driver 15, a monitor 16 and a sequencer 17. After the sequencer 17 generates a test sequence, the test sequence is sent to the device under test 10 through the driver 15. After the device under test 10 executes the test sequence, the data returned is returned to the monitor 16 through the interface 12. The monitor 16 analyzes the returned data to determine whether the device under test has passed the verification.

[0004] Verification systems designed for a single communication protocol have limited scalability and are often incompatible with verification of chips using other communication protocols. This results in poor compatibility and makes it incompatible with verifying chips using multiple different communication protocols. Because the chips being tested may use different communication protocols, different verification systems are required for each chip, resulting in high verification costs and low verification efficiency.

[0005] Patent application CN115357441A discloses a UVM-based universal verification component that primarily performs verification for a variety of different bus protocols. However, this universal verification component does not provide a unified configuration file for different communication protocols and cannot meet the verification requirements for chips using multiple different communication protocols. Summary of the Invention

[0006] The first object of the present invention is to provide a general verification system supporting multiple protocols that can meet chip verification requirements of multiple communication protocols.

[0007] A second object of the present invention is to provide a chip verification method implemented by applying the above-mentioned universal verification system supporting multiple protocols.

[0008] To achieve the first purpose of the present invention, the general verification system supporting multiple protocols provided by the present invention includes a protocol configuration module for receiving two or more protocol configuration information, converting the multiple protocol configuration information into a configuration file with a unified format, wherein the configuration file includes parameter information of multiple protocols; a test management module for generating a test sequence according to the configuration file and the needs of the test case, and framing multiple test sequences to form a virtual sequence according to the test requirements of the test case; a protocol adaptable module for sending the test sequence to the device to be tested and receiving data returned by the device to be tested; a coverage collection module for counting the coverage data of the device to be tested based on the data returned by the device to be tested; wherein the parameter information in the configuration file includes the coverage points required to be tested by the test case.

[0009] It can be seen from the above scheme that the universal verification system that supports multiple protocols is equipped with a protocol configuration module, which can receive more than two types of protocol configuration information and can convert multiple protocol configuration information into a configuration file with a unified format. Since the configuration file includes parameter information of multiple protocols, these parameters are also the coverage points for subsequent tests. Therefore, when generating a test sequence, the required test sequence can be generated according to different protocols. After the device to be tested receives the test sequence, it can perform the corresponding operation. The universal verification system can analyze and count the coverage rate based on the received data.

[0010] It can be seen that the universal verification system provided by the present invention can verify chips of various different communication protocols, and can analyze the coverage of the devices to be tested under the current communication protocol, so that the universal verification system is compatible with various different communication protocols. The universal verification system has good compatibility and can reduce the verification cost of the chip.

[0011] A preferred solution is that the protocol adaptable module includes a sequencer, a driver and a monitor. The sequencer receives multiple test sequences in the virtual sequence, and the driver sends the test sequences to the device under test in a set order. The monitor is used to receive data returned by the device under test.

[0012] It can be seen that by setting up the sequence generator, driver and monitor, the universal verification system can output the test sequence in the set order, ensuring the smooth operation of the chip verification.

[0013] A further solution is that the universal verification system is further provided with a test top-level module for sending a stimulus signal to the device under test and sending data returned by the device under test to the monitor.

[0014] It can be seen that the universal verification system realizes signal input and output with the device under test by testing the top-level module, ensuring smooth communication between the universal verification system and the device under test.

[0015] In a preferred solution, the protocol configuration module is further configured to receive protocol configuration information of a newly added protocol, and add parameter information of the newly added protocol to the configuration file according to the protocol configuration information of the newly added protocol.

[0016] It can be seen from this that when a new communication protocol needs to be added, you only need to enter the protocol configuration information of the new protocol. The universal verification system can add the parameter information of the new protocol to the configuration file based on the protocol configuration information of the new protocol without adjusting other parts. Therefore, the operation of adding a new communication protocol is very convenient.

[0017] An optional solution is that the protocol configuration module is further configured to receive update information of the protocol configuration information of an existing protocol, and update the parameter information of the configuration file according to the update information of the protocol configuration information of the existing protocol.

[0018] It can be seen from this that when updating the protocol configuration information of an existing communication protocol, it is only necessary to send the updated information to the universal verification system, and there is no need to adjust other parts of the universal verification system.

[0019] A further solution is that the coverage collection module includes a functional coverage collection module for setting at least one functional coverage point according to the protocol type of the test case and the test requirements, and collecting functional coverage data of the device under test based on the data returned by the device under test.

[0020] It can be seen that the application function coverage collection module can set corresponding function coverage for different communication protocols, and can count one or more function coverages of the device to be tested to meet the chip verification requirements of different application communication protocols.

[0021] A further solution is that when the functional coverage collection module sets the functional coverage points, it obtains functional coverage points of two or more dimensions according to the protocol type of the test case to form a cross-dimensional functional coverage point group; the functional coverage collection module counts the coverage data of the cross-dimensional functional coverage point group based on the data returned by the device to be tested.

[0022] It can be seen that the use of cross-dimensional functional coverage point groups can count the functional coverage in multiple different dimensions, which is conducive to a comprehensive and intuitive analysis of the functional coverage of the chip under test from multiple different dimensions.

[0023] To achieve the second purpose mentioned above, the chip verification method provided by the present invention applies the above-mentioned universal verification system supporting multiple protocols to verify the chip. The method includes: receiving two or more protocol configuration information, and converting the multiple protocol configuration information into a configuration file with a unified format; generating a test sequence according to the configuration file and the needs of the test case, and framing multiple test sequences to form a virtual sequence according to the test requirements of the test case; sending the test sequence to the device to be tested, and receiving the data returned by the device to be tested, counting the coverage data of the device to be tested based on the data returned by the device to be tested, and completing the functional verification of the device to be tested in combination with the checker.

[0024] It can be seen from the above scheme that when performing chip verification, the universal verification system can obtain the protocol configuration information of multiple communication protocols and generate configuration files from it. During the chip verification process, for chips with different communication protocols, the universal verification system can set reasonable coverage points based on the actual communication protocol situation of the chip currently being tested and the situation of the test case, and thereby generate corresponding test sequences, thereby meeting the testing requirements of chips that use different communication protocols.

[0025] A further solution is to perform a hardware reset operation on the universal verification system before receiving two or more types of protocol configuration information; and to perform a reset operation after the main clock signal is stable.

[0026] It can be seen that by performing a hardware reset operation on the universal verification system, it is possible to ensure that the simulation environment is initialized to a certain state, avoid the impact of historical states on chip verification, and thus improve the accuracy of verification.

[0027] A further solution is that, if the current protocol is a protocol with physical layer link training, before triggering the power-on operation, a reset operation is performed on the links in the receiving direction and the sending direction respectively.

[0028] It can be seen that by performing the reset operation on the links in the receiving direction and the sending direction, it can ensure that normal communication between the universal verification system and the chip to be tested can be restored, avoiding the impact of communication abnormalities on verification.

[0029] A further solution is to generate a test case file after obtaining two or more protocol configuration information, classify the test cases, form a test case list, and perform statistics on the pass rate and coverage of each test case, and mark the test cases that need to be analyzed.

[0030] This shows that by categorizing multiple test cases, it is easier to find appropriate test cases from the corresponding categories based on different test environments and test requirements, thereby improving test efficiency. In addition, by marking the test cases that need to be analyzed, it is easier to analyze typical test cases later, thereby improving the test cases and enhancing the chip verification quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 This is a structural block diagram of an existing chip verification system.

[0032] Figure 2 It is a structural block diagram of an embodiment of a universal verification system supporting multiple protocols of the present invention.

[0033] Figure 3 This is a flow chart of constructing a universal verification system in an embodiment of the chip verification method of the present invention.

[0034] Figure 4 It is a flow chart of an embodiment of a chip verification method of the present invention.

[0035] The present invention will be further described below with reference to the accompanying drawings and embodiments. DETAILED DESCRIPTION

[0036] The present invention's universal verification system, which supports multiple protocols, is used for testing and verifying chips, particularly chips using different communication protocols. The present invention can verify chips using different communication protocols using only one universal verification system. The universal verification system has good compatibility with all communication protocols. When adding a new communication protocol or updating the parameters of an existing communication protocol, only the configuration file needs to be updated, eliminating the need for significant changes to the entire universal verification system. This reduces chip verification costs and improves verification efficiency.

[0037] An embodiment of a universal authentication system supporting multiple protocols: See also Figure 2 The universal verification system supporting multiple protocols in this embodiment comprises a protocol configuration module 21, a test management module 30, a protocol adaptable module 40, a test top-level module 50, and is provided with a test case 61 and a coverage collection module 62. The test top-level module 50 is connected to a device under test 51 and implements communication with the device under test 51. The device under test 51 can be a designed chip to be verified.

[0038] The protocol configuration module 21 is capable of receiving protocol configuration information for multiple protocols and converting this information into configuration files in a unified format. For example, the protocol configuration module 21 can identify configuration information for various communication protocols, such as Ethernet, PCIe, and USB. After the universal verification system receives the protocol configuration information, it can generate multiple configuration files using a pre-configured multi-protocol processing script 20. These configuration files have a unified format, making it easier for the test management module 30 to obtain the corresponding configuration files based on the functions to be tested, thereby generating different test sequences.

[0039] Furthermore, the configuration file includes parameter information of multiple protocols. For example, the configuration file includes parameter information such as the protocol type, version, number of channels, rate, bit width, etc. of the protocol to be tested. For example, the protocol types compatible with the general verification system include STAT, SA, PCIE, SERDES, USB3, MIPE, etc. The speeds supported by different communication protocols are also different. Therefore, when setting the configuration file, the communication speed supported by each communication protocol will be set. For example, the communication speeds supported by the communication protocol STAT include: 1.5G, 3G, 6G, 12G; the communication speeds supported by the communication protocol PCIE include: 2.5G, 5G, 8G, 16G, 32G, 64G; the communication speeds supported by the communication protocol SERDES include: 1.125G, 1.25G, 1.5G, 2.5G, 3.125G, 3.75G, 4G, 4.25G, 5G, 5.2083G, 6G, 6.25G, 7.5G, 10.3125G, 12.5G. Furthermore, different communication protocols support different bit widths. Therefore, the configuration file can also set the bit widths of various communication protocols. For example, the SATA communication protocol supports bit widths of BIT_40 and BIT_20, the PCIE communication protocol supports bit widths of BIT_40 and BIT_20, and the SERDES communication protocol supports bit widths of BIT_16 and BIT_20. Furthermore, different communication protocols also support different maximum numbers of channels (lanes). The maximum number of channels supported by each communication protocol can be set based on actual conditions.

[0040] In this embodiment, the universal verification platform is provided with a multi-protocol processing script 20. After the protocol configuration information of different communication protocols is input, the multi-protocol processing script 20 converts the protocol configuration information into a configuration file with a unified format. These configuration files include parameter information such as the protocol type, supported communication rate, bit width, number of channels, etc. of each communication protocol. Since the configuration files have a unified format, when the test management module 30 needs to call these configuration files, it can quickly obtain the required parameter information and can conveniently generate the required test sequence, thereby improving the test efficiency. Moreover, when generating the test sequence, the required parameter information is obtained based on the configuration file in a unified format. The format of the configuration file is independent of the communication protocol type, that is, a desensitization process is implemented between the test sequence generation and the communication protocol type, which can improve the efficiency of the test sequence generation.

[0041] In addition, since the present embodiment provides a protocol configuration module 21, when a new communication protocol needs to be added, it is only necessary to input the protocol type of the newly added communication protocol and the corresponding protocol configuration information, such as the supported communication rate, bit width, and other parameters, into the universal verification system, and the multi-protocol processing script 20 will automatically generate the corresponding configuration file. Specifically, the corresponding parameter information of the newly added communication protocol is added to the configuration file, such as the communication rate, bit width, and maximum number of supported channels supported by the newly added communication protocol. Furthermore, the universal verification system does not need to adjust the subsequent test management module 30, protocol adaptable module 40, test top-level module 50, etc. Therefore, the difficulty of operating the newly added communication protocol can be greatly reduced, and no adjustments need to be made to the framework of the universal verification system, so that the universal verification system can flexibly implement the addition of communication protocols.

[0042] If the protocol configuration information of an existing communication protocol needs to be modified, for example, if the supported bit width of an existing communication protocol needs to be changed, only the protocol configuration information of the existing communication protocol needs to be modified. The multi-protocol processing script 20 can automatically update the corresponding configuration file, for example, adding or modifying the corresponding bit width parameters in the existing communication protocol. Therefore, whether adding a new communication protocol or modifying the protocol configuration information of an existing communication protocol, there is no need to modify the environment interface and framework of the universal verification system, thereby saving time in debugging the test environment and improving test efficiency.

[0043] The test management module 30 can generate a test sequence based on the configuration file generated by the protocol configuration module 21 and the needs of the test case. Typically, the generated test sequences include multiple test sequences, such as test sequence 31...test sequence 38, and different test sequences are used to test different functions. The test management module 30 will also group multiple test sequences into virtual sequences based on the test requirements of the test case. Therefore, a virtual sequence is actually a sequence group containing multiple test sequences. Typically, a virtual sequence can achieve a certain test function, such as testing whether the communication rate of the device under test 51 reaches a preset communication rate. The virtual sequence will uniformly drive multiple test sequences, for example, sending multiple test sequences to the sequence generator 41 of the protocol adaptable module 40.

[0044] The universal verification platform can generate a corresponding protocol frame format based on the communication protocol type of the device under test 51 currently being tested, and send it as a stimulus signal to the device under test 51. For example, if the communication protocol currently used by the device under test 51 is Ethernet, the protocol frame format can be: |Preamble|SFD|Destination MAC Address|Source MAC Address|Type / Length|Data|FCS|, where SFD marks the start of a frame of data, and FCS is a CRC-32 checksum. For extended formats, such as VLAN tags, the protocol frame format can be: |Preamble|SFD|Destination MAC Address|Source MAC Address|Type / Length|VLAN Tag|Type / Length|Data|FCS|. If the communication protocol currently used by the device under test 51 is PCIe, the protocol frame format can be: |Header|Data|ECRC|, where the Header contains routing information (such as RequesterID, Tag) and transaction type (MemoryRead / Write), and the ECRC contains a CRC checksum.

[0045] In addition, the universal verification system will select an appropriate encoding method for the test sequence based on the type of communication protocol, such as NRZ or PAM4 encoding, and randomly select the values ​​of each field segment based on the range allowed by the communication protocol. For example, if a communication protocol can support communication rates including 2.5G, 5G, 8G, 16G, 32G, and 64G, then one of the supported communication rates can be randomly selected as the communication rate for testing, and a test sequence can be generated based on this. Since each type of communication protocol often has a corresponding encoding method, by selecting an appropriate encoding method, the generated test sequence can meet the encoding format requirements of the corresponding communication protocol, avoiding the problem of the DUT 51 being unable to correctly recognize the test sequence due to the mismatch between the encoding format of the test sequence and the communication protocol.

[0046] The protocol adaptable module 40 includes a sequencer 41, a driver 42, and a monitor 43. The sequencer 41 is used to receive the test sequences sent by the test management module 30, that is, to receive multiple test sequences in the virtual sequence, and to send the test sequences to the device under test 51 in a set order through the driver 42. Because different test cases have different test steps and test functions, it is necessary to call different test sequences based on the actual situation of the current test case and the currently used communication protocol, thereby forming a set of virtual sequences.

[0047] After receiving the test sequence, the device under test 51 makes a corresponding response according to the test sequence and returns response data to the protocol adaptable module 40 . At this time, the monitor 43 receives the data returned by the device under test 51 .

[0048] The test top-level module 50 is used to communicate with the device under test 51. Specifically, it sends the test sequence output by the driver 42 to the device under test 51 in the form of an excitation signal, and receives data returned by the device under test 51 and returns it to the monitor 43. Of course, the test top-level module 50 also needs to output a clock signal to the device under test 51 and generate an interface for data transmission with the device under test 51 based on the protocol configuration information.

[0049] The test case module 61 stores multiple test cases, which can be pre-set and stored in the test case module 61. When the device to be tested 51 needs to be tested, the existing test cases can be directly obtained from the test case module 61, which can avoid repeated development of test cases and improve testing efficiency.

[0050] The coverage collection module 62 collects and analyzes the coverage of the DUT 51 based on the data received from the monitor 43. For example, it analyzes the operation status of each coverage point, thereby forming the current coverage data of the DUT 51. Furthermore, the coverage collection module 62 can display the coverage data in a visual manner, so that the tester can intuitively understand the performance of the DUT 51.

[0051] Preferably, the coverage collection module 62 is provided with a functional coverage collection module and a code coverage collection module. The functional coverage collection module is used to collect and analyze the functional coverage data of the device to be tested 51. Specifically, it is necessary to define the functional coverage points that need to be tested, such as communication rate, bit width, power status, etc. When performing testing, it is necessary to generate a corresponding test sequence based on the functional coverage points that need to be tested.

[0052] For example, a functional coverage point is a rate level. The supported rate range set in the configuration file is [0:9], covering PCIe, Gen1 to Gen6, USB2, USB3, USB4, Ethernet, etc. If the communication protocol currently used by the device under test 51 is Gen4, the functional coverage point is set to bin = 4, thereby hitting the rate to be tested. For another example, a functional coverage point is a bit width. The supported bin values ​​for bit width in the configuration file include 16, 32, 64, and 128, which are applicable to communication protocols such as USB4 and PCIex16. During simulation testing, if the bit width to be configured is 64 bits, the corresponding bin is recorded as a hit. For another example, a functional coverage point is a power state. If the supported power states set in the configuration file include: L0 (active), L1 (power saving), L2 (off), etc., then each time the device under test 51 enters the corresponding power state, the corresponding functional coverage point bin is recorded as a hit.

[0053] In this way, by receiving the data returned by the device under test 51 , the functional coverage collection module can record and analyze the functional coverage data of the device under test 51 , and then determine whether the device under test 51 meets the preset functional requirements.

[0054] In addition, when setting the functional coverage points, the functional coverage collection module can also obtain functional coverage points of multiple dimensions according to the protocol type of the test case to form a cross-dimensional functional coverage point group (CrossCoverage), that is, to perform a cross-dimensional combination of functional coverage to form a complete coverage space, which is convenient for discovering test blind spots. For example, the three functional coverages of communication rate, bit width, and power state are combined into a cross-dimensional functional coverage point group to form a three-dimensional coverage matrix. Each group of cross-dimensional functional coverage point groups corresponds to a coverage bin, so that it is possible to detect whether all parameter combination scenarios are covered. For example, in a certain test scenario, the cross-dimensional functional coverage point group is set to: Gen4+64bit+L0, which means that it is necessary to test whether the device under test 51 can support the communication rate requirements of Gen4, and the bit width is 64 bits, and the power state can include the active state. If the bin is not hit, it means that this combination has not been verified.

[0055] If different coverage points are randomly combined, unreasonable cross-dimensional functional coverage point groups may appear, such as a combination with a rate less than Gen5 and a bit width greater than 64. Therefore, the functional coverage collection module needs to exclude these unreasonable combinations when setting the cross-dimensional functional coverage point group to avoid affecting the accuracy of the coverage statistics.

[0056] The code coverage collection module can support the interfaces of one or more chip design tools. When the device under test 51 is tested, it can collect the hit status of signal lines, conditions, branches, state machines, and assertions at all levels in the device under test 51, thereby automatically integrating multiple test cases or returned test results to generate an overall code coverage report, allowing testers to intuitively understand the code coverage status of the device under test 51.

[0057] As can be seen, when performing unified configuration of multiple communication protocols, protocol configuration information can be input externally through the $plusarg function. The universal verification system defines a configuration file with a unified format through the protocol configuration module 21. The configuration file includes parameters such as the protocol name, version, rate, maximum channel data volume, and bit width. In addition, the need to use functions such as EQ training and dynamic equalization adaptation is determined based on the actual test case. In the test case configuration, switches for turning on or off functions such as EQ training and dynamic equalization adaptation can be set, and these switches can be turned on or off according to actual test needs to enable or disable the corresponding functions.

[0058] The universal verification system can generate corresponding test sequences based on the function being tested and the communication protocol used in the test. Each test case can combine multiple test sequences into a virtual sequence according to the test needs. The virtual sequence drives each test sequence, and each test sequence is sent to the device under test 51 in a pre-set order. After receiving the test sequence, the device under test 51 performs the corresponding operations according to the test sequence and returns a response signal. After the monitor 43 obtains the returned data, the coverage collection module 62 analyzes the coverage of each coverage point of the device under test 51 to obtain functional coverage data and code coverage data.

[0059] The parameter information contained in the configuration file generated by the protocol configuration module 21 is actually the coverage point that can be set for the device to be tested. For example, the configuration file of the communication rate contains the communication rates supported by the communication protocol PCIE, including 2.5G, 5G, 8G, 16G, 32G, and 64G. Therefore, when the test case sets the coverage point of the device to be tested 51 under the communication protocol PCIE, it can select one of the multiple parameters of 2.5G, 5G, 8G, 16G, 32G, and 64G as the functional coverage point for testing. Therefore, when it is necessary to add a new communication protocol or update the protocol configuration information of an existing communication protocol, it is only necessary to update the configuration file without making changes to the test management module 30, the protocol adaptable module 40, the test top-level module 50, etc., which can improve the test efficiency while being compatible with multiple communication protocol tests.

[0060] Chip verification method embodiment: Before verifying the chip, you first need to build the general verification system mentioned above. Figure 3 When constructing the above-mentioned universal verification system, step S1 is first executed to generate a framework of a universal verification system that supports multiple protocols according to a pre-set template. Since the data in the framework has not been set, the generated framework does not have a configuration file, that is, the framework has not yet obtained the protocol configuration information.

[0061] Then, step S2 is executed to generate an interface file of the test top-level module to instantiate the device under test. The generated interface file of the test top-level module enables the test top-level module to perform data transmission with the device under test, thereby instantiating the device under test.

[0062] Next, step S3 is performed to connect the modules in the universal verification system, for example, the UVM component, the monitor and the checker. The checker of the universal verification system is used to receive data returned by the device under test and check the operating status of the device under test based on the received data to determine whether the device under test meets the desired design requirements.

[0063] Then, step S4 is executed, the universal verification system automatically generates a test case file, and the generated test case is stored in the test case module. In addition, parameters such as power supply and communication rate are modified and improved according to the configuration file.

[0064] Finally, step S5 is executed to classify the test cases and automatically generate a test case list (caselist) through the script. Preferably, the test cases are classified according to the functions tested, the corresponding communication protocols, etc. In addition, the pass rate and coverage of each test case are counted, and the test cases that need to be analyzed are marked. For example, failed test cases are marked. The marked test cases need to be analyzed later to analyze the reasons for their failure.

[0065] After the universal test system is built, the chip is verified by using the built universal verification system. In this embodiment, the chip to be verified is Figure 2 Before verifying the device under test, the chip needs to be connected to the test top-level module of the general verification system.

[0066] See also Figure 4 When verifying the chip, first execute step S11. After the universal verification system is started, first reset the universal verification system at the system level to ensure that the simulation environment is initialized to a certain state, avoiding the historical state from interfering with the current test, especially avoiding the previously executed test from interfering with the current test.

[0067] Specifically, a reset sequence is generated based on the DUT's interface and configuration information. For example, the generated reset sequence includes both a hardware reset sequence and a software reset sequence. These reset sequences are used to reset the universal verification system. Before each test, the universal verification system performs a reset operation to prevent the previous test from affecting the current test, thereby enabling more accurate verification and testing of the DUT.

[0068] Then, in step S12, the universal verification system obtains two or more types of protocol configuration information and applies a multi-protocol processing script to convert the multiple protocol configuration information into a configuration file with a unified format. As mentioned above, the generated configuration file includes various parameter information such as the protocol type, communication rate, bit width, power status, etc. of the multiple communication protocols.

[0069] Then, step S13 is executed to obtain rate configuration information of multiple protocols. Specifically, information is extracted from the protocol configuration information, and default rate parameters corresponding to the target protocol are extracted from the configuration database of the general verification system, or rate parameters specified by the tester are obtained.

[0070] Next, execute step S14, the universal verification system dynamically configures the parameters of the clock signal generator, and generates a matching master clock signal according to the rate of the current protocol. The frequency of the master clock signal can be 100MHz, 250MHz, 500MHz, etc. The master clock signal will subsequently be sent to the device under test to start the operation of the device under test to ensure that the universal verification platform is synchronized with the clock of the device under test, thereby ensuring that the device under test can correctly identify the data output by the universal verification platform.

[0071] Then, step S15 is executed. A reset operation is performed. Specifically, the universal verification system performs the reset operation only after the clock signal stabilizes, allowing the DUT and the verification environment to exit the reset state and enter normal operation. Next, the configuration file generated in steps S12 and S13 and the acquired rate configuration information are written to the memory of the universal verification system. Furthermore, for communication protocols with physical layer link training, such as PCIe and USB4, the links in both the receiving and transmitting directions are reset to ensure normal communication initialization.

[0072] Next, step S16 is executed. After completing the above basic configuration, the power-on operation is triggered to put the DUT into the power-on state and into the interactive working stage. At this time, the universal verification system can send data to the DUT, and the DUT can respond to the data sent by the universal verification system.

[0073] Then, step S17 is executed, and the universal verification system sends a data stream and a functional stimulus signal to the device under test. For example, the driver sends multiple test sequences to the device under test in a preset order. After receiving these test sequences, the device under test performs corresponding operations, and the universal verification system receives the data returned by the device under test through the monitor.

[0074] Finally, step S18 is executed. The coverage collection module collects coverage data for the current DUT based on the data returned by the DUT and, in conjunction with the checker, completes functional verification of the DUT. The checker can test various aspects of the DUT's performance, such as timing, protocol behavior, and data integrity, thereby completing functional-level verification of the DUT.

[0075] It can be seen that the universal verification system of the present invention is compatible with a variety of different communication protocols, and can convert a variety of protocol configuration information into a configuration file with a unified format during the configuration stage. When a new communication protocol needs to be added or the protocol configuration information of an existing communication protocol needs to be updated in the future, it is only necessary to modify or update the configuration file without modifying the framework of the universal verification system. This enables the universal verification system to be compatible with the testing requirements of a variety of different communication protocols, thereby improving testing efficiency.

[0076] Finally, it should be emphasized that the above are only preferred embodiments of the present invention and are not intended to limit the present invention. For those skilled in the art, the present invention may have various changes and modifications. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A universal authentication system that supports multiple protocols, characterized by: include: A protocol configuration module, configured to receive two or more types of protocol configuration information and convert the multiple types of protocol configuration information into a configuration file having a unified format, wherein the configuration file includes parameter information of the multiple protocols; A test management module, configured to generate a test sequence according to the configuration file and the test case requirements, and to group multiple test sequences into a virtual sequence according to the test requirements of the test case; A protocol adaptable module, configured to send the test sequence to the device under test and receive data returned by the device under test; A coverage collection module, configured to collect coverage data of the device under test based on data returned by the device under test; The parameter information in the configuration file includes the coverage points required to be tested by the test case.

2. The universal authentication system supporting multiple protocols according to claim 1, characterized in that: The protocol adaptable module includes a sequencer, a driver, and a monitor. The sequencer receives multiple test sequences in the virtual sequence, and the driver sends the test sequences to the device under test in a set order. The monitor is used to receive data returned by the device under test. The universal verification system is further provided with a test top-level module, which is used to send a stimulus signal to the device under test and send data returned by the device under test to the monitor.

3. The universal authentication system supporting multiple protocols according to claim 1 or 2, characterized in that: The protocol configuration module is further configured to receive protocol configuration information of a newly added protocol, and add parameter information of the newly added protocol to the configuration file according to the protocol configuration information of the newly added protocol.

4. The universal authentication system supporting multiple protocols according to claim 1 or 2, characterized in that: The protocol configuration module is further configured to receive update information of the protocol configuration information of an existing protocol, and update the parameter information of the configuration file according to the update information of the protocol configuration information of the existing protocol.

5. The universal authentication system supporting multiple protocols according to any one of claims 1 or 2, characterized in that: When the test management module generates the test sequence, it determines the encoding method of the test sequence according to the type of the communication protocol.

6. The universal authentication system supporting multiple protocols according to any one of claims 1 or 2, characterized in that: The coverage collection module includes a functional coverage collection module, which is used to set at least one functional coverage point according to the protocol type and test requirements of the test case, and to collect functional coverage data of the device under test based on the data returned by the device under test.

7. The universal authentication system supporting multiple protocols according to claim 6, characterized in that: When the function coverage collection module sets the function coverage points, it obtains function coverage points of two or more dimensions according to the protocol type of the test case to form a cross-dimensional function coverage point group; The functional coverage collection module collects coverage data of the cross-dimensional functional coverage point group according to the data returned by the device under test.

8. A chip verification method, comprising: applying the universal verification system supporting multiple protocols as claimed in any one of claims 1 to 7 to verify the chip, wherein: include: receiving two or more types of protocol configuration information, and converting the multiple types of protocol configuration information into a configuration file having a unified format; Generate a test sequence according to the configuration file and the needs of the test case, and group multiple test sequences into a virtual sequence according to the test requirements of the test case; The test sequence is sent to the device under test, and data returned by the device under test is received. Coverage data of the device under test is counted based on the data returned by the device under test, and functional verification of the device under test is completed in conjunction with a checker.

9. The chip verification method according to claim 8, wherein: Before receiving two or more protocol configuration information, perform a hardware reset operation on the universal verification system; After the main clock signal of the universal verification system is stable, the reset operation is performed.

10. The chip verification method according to claim 8 or 9, characterized in that: If the current protocol is a protocol with physical layer link training, before sending the test sequence to the device under test, a reset operation is performed on the links in the receiving direction and the transmitting direction respectively.

Images