A universal verification system and chip verification method supporting multiple protocols

Abstract

This invention provides a universal verification system and chip verification method supporting multiple protocols. The system includes a protocol configuration module for receiving configuration information for two or more protocols and converting this information into a configuration file with a unified format; a test management module for generating test sequences based on the configuration file and test case requirements; a protocol adaptability module for sending the test sequences to the device under test (DUT) and receiving data returned by the DUT; and a coverage collection module for statistically analyzing the coverage data of the DUT based on the data returned by the DUT. The parameter information in the configuration file includes the coverage points required by the test cases. This invention also provides a chip verification method implemented using the above system. The universal verification system of this invention is compatible with multiple communication protocols, improving testing efficiency.

Description

Technical Field

[0001] This invention relates to the technical field of chip testing, specifically to a universal verification system supporting multiple protocols and a chip verification method implemented using this system. Background Technology

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

[0003] However, existing chip verification systems are often designed for only a single communication protocol. For example, a chip verification system can only verify chips that use Ethernet, or only chips that use the PCIe protocol. See also Figure 1 The existing verification system is equipped with a test top-level module 11. The test top-level module 11 transmits data with the device under test 10 through interface 12. The test top-level module 11 is equipped with a driver 15, a monitor 16 and a sequence generator 17. After the sequence generator 17 generates a test sequence, it sends the test sequence 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 interface 12. The monitor 16 analyzes the returned data to determine whether the device under test has passed the verification.

[0004] Because verification systems for a single communication protocol have low scalability, they are typically incompatible with chip verification for other communication protocols. This results in poor compatibility of chip verification systems, making it impossible to verify chips using multiple different communication protocols. Since the chips under test may use different communication protocols, different verification systems are required to verify chips using different communication protocols, leading to high verification costs and low verification efficiency.

[0005] Patent application CN115357441A discloses a universal verification component based on UVM, mainly for verifying various bus protocols. However, this universal verification component does not have a unified configuration file for different communication protocols, and therefore cannot meet the verification needs of chips with multiple different communication protocols. Summary of the Invention

[0006] The primary objective of this invention is to provide a universal verification system that supports multiple protocols and can meet the chip verification requirements of various communication protocols.

[0007] A second objective of this invention is to provide a chip verification method implemented using the aforementioned universal verification system that supports multiple protocols.

[0008] To achieve the first objective of this invention, the universal verification system supporting multiple protocols provided by this invention includes a protocol configuration module for receiving configuration information for two or more protocols and converting the multiple protocol configuration information into a configuration file with a unified format, the configuration file including parameter information for multiple protocols; a test management module for generating test sequences according to the configuration file and the needs of test cases, and framing multiple test sequences into virtual sequences according to the test requirements of the test cases; a protocol adaptability module for sending the test sequences to the device under test and receiving data returned by the device under test; and a coverage collection module for statistically analyzing the coverage data of the device under test based on the data returned by the device under test; wherein, the parameter information in the configuration file contains the coverage points that the test cases need to test.

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

[0010] As can be seen, the universal verification system provided by this invention can verify chips with various communication protocols and analyze the coverage of the device under test under the current communication protocol. This makes the universal verification system compatible with various communication protocols, and its good compatibility can reduce the verification cost of chips.

[0011] In a preferred embodiment, the protocol adaptable module includes a sequence generator, a driver, and a monitor. The sequence generator receives multiple test sequences from a 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] Therefore, by setting up a sequence generator, driver, and monitor, the general verification system can output test sequences in a set order, ensuring the smooth operation of chip verification.

[0013] A further approach is to include a top-level test module in the general verification system, which sends excitation signals to the device under test and transmits the data returned by the device under test to the monitor.

[0014] As can be seen, the general verification system achieves signal input and output with the device under test through the top-level module, ensuring smooth communication between the general verification system and the device under test.

[0015] A preferred embodiment is that the protocol configuration module is also used to receive the protocol configuration information of the new protocol, and add the parameter information of the new protocol to the configuration file according to the protocol configuration information of the new protocol.

[0016] Therefore, when a new communication protocol needs to be added, only the protocol configuration information of the new protocol needs to be entered. The general verification system can add the parameter information of the new protocol to the configuration file according to the protocol configuration information of the new protocol, without the need to adjust other parts. Therefore, the operation of adding a new communication protocol is very convenient.

[0017] Alternatively, the protocol configuration module can also receive update information of the protocol configuration information of existing protocols, and update the parameter information of the configuration file according to the update information of the protocol configuration information of existing protocols.

[0018] Therefore, when updating the protocol configuration information of an existing communication protocol, it is only necessary to send the updated information to the general verification system, without needing to adjust other parts of the general verification system.

[0019] A further approach is to include a coverage collection module that includes a functional coverage collection module, which is used to set at least one functional coverage point based on the protocol type of the test case and the test requirements, and to collect functional coverage data of the device under test based on the data returned by the device under test.

[0020] Therefore, the application function coverage collection module can set corresponding function coverage for different communication protocols and can statistically analyze the function coverage of one or more devices under test, thus meeting the chip verification requirements of different application communication protocols.

[0021] A further approach is that when setting functional coverage points, the functional coverage collection module obtains functional coverage points from two or more dimensions based on the protocol type of the test cases to form a cross-dimensional functional coverage point group; the functional coverage collection module then calculates the coverage data of the cross-dimensional functional coverage point group based on the data returned by the device under test.

[0022] Therefore, it can be seen that using cross-dimensional functional coverage point groups can statistically analyze the functional coverage under multiple different dimensions, which is beneficial for a comprehensive and intuitive analysis of the functional coverage of the chip under test from multiple different dimensions.

[0023] To achieve the second objective mentioned above, the chip verification method provided by this invention applies the aforementioned universal verification system supporting multiple protocols to verify the chip. The method includes: receiving configuration information for two or more protocols; converting the configuration information into a configuration file with a unified format; generating test sequences according to the configuration file and the needs of the test cases; framing multiple test sequences into a virtual sequence according to the test requirements of the test cases; sending the test sequences to the device under test (DUT); receiving data returned by the DUT; calculating the coverage data of the DUT based on the data returned by the DUT; and completing the functional verification of the DUT in conjunction with an inspector.

[0024] As can be seen from the above scheme, when performing chip verification, the general verification system can obtain the protocol configuration information of multiple communication protocols and generate configuration files accordingly. During the chip verification process, for chips with different communication protocols, the general verification system can set reasonable coverage points according to the actual communication protocol and test cases of the chip being tested, and generate corresponding test sequences, thereby meeting the testing requirements of chips using different communication protocols.

[0025] A further approach is to perform a hardware reset on the general verification system before receiving configuration information from two or more protocols; and to perform a de-reset operation after the master clock signal has stabilized.

[0026] Therefore, by performing a hardware reset on the general verification system, the simulation environment can be initialized to a deterministic state, avoiding the impact of historical states on chip verification and thus improving the accuracy of verification.

[0027] A further approach is to perform a de-reset operation on the receiving and transmitting links respectively before triggering the power-on operation, if the current protocol is a protocol with physical layer link training.

[0028] Therefore, by performing a reset operation on the links in the receiving and transmitting directions, it can be ensured that normal communication can be restored between the general verification system and the chip under test, thus avoiding the impact of communication abnormalities on verification.

[0029] A further approach involves obtaining configuration information for two or more protocols, generating test case files, categorizing the test cases to form a test case list, and statistically analyzing the pass rate and coverage of each test case, while also marking the test cases that need to be analyzed.

[0030] Therefore, classifying multiple test cases facilitates the subsequent retrieval of suitable test cases from the corresponding categories based on different testing environments and requirements, thereby improving testing efficiency. Furthermore, marking test cases requiring analysis allows for the analysis of typical test cases, leading to improvements in test cases and enhancing the verification quality of the chip. Attached Figure Description

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

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

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

[0034] Figure 4 This is a flowchart of an embodiment of the 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 Implementation

[0036] This invention provides a universal verification system supporting multiple protocols for chip testing and verification, particularly for chips using different communication protocols. This invention enables the verification of chips employing different communication protocols using only one universal verification system. The universal verification system exhibits good compatibility with communication protocols; when a new communication protocol needs to be added or the parameters of an existing protocol need to be updated, only the configuration file needs to be updated, without requiring significant modifications to the entire universal verification system. This reduces chip verification costs and improves verification efficiency.

[0037] Implementation examples of a general verification system supporting multiple protocols:

[0038] See Figure 2 The multi-protocol universal verification system of this embodiment includes a protocol configuration module 21, a test management module 30, a protocol adaptability module 40, and a test top-level module 50. It also includes test cases 61 and a coverage collection module 62. The test top-level module 50 is connected to the device under test (DUT) 51 and enables communication with it. The DUT 51 can be a pre-designed chip to be verified.

[0039] The protocol configuration module 21 can receive protocol configuration information for multiple protocols and convert this information into configuration files with a unified format. For example, the protocol configuration module 21 can recognize configuration information for various communication protocols such as Ethnet, PCIe, and USB. After the general verification system receives the protocol configuration information, it can generate multiple configuration files using a pre-set multi-protocol processing script 20. These configuration files have a unified format, allowing the test management module 30 to obtain the corresponding configuration files based on the functions to be tested, thereby generating different test sequences.

[0040] Furthermore, the configuration file includes parameter information for various protocols, such as the protocol type, version, number of channels, rate, and bit width of the protocol under test. For example, the universal verification system is compatible with protocols such as STAT, SA, PCIE, SERDES, USB3, and MIPE. Different communication protocols support different speeds. 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 STAT communication protocol are set to 1.5G, 3G, 6G, and 12G; the communication speeds supported by the PCIE communication protocol are set to 2.5G, 5G, 8G, 16G, 32G, and 64G; and the communication speeds supported by the SERDES communication protocol are set to 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, and 12.5G. Furthermore, different communication protocols support different bit widths. Therefore, the configuration file can also set the bit width for various communication protocols. For example, the configuration file can specify the bit width supported by the SATA communication protocol (BIT_40, BIT_20), the PCIe communication protocol (BIT_40, BIT_20), and the SERDES communication protocol (BIT_16, BIT_20). In addition, the maximum number of lanes supported by different communication protocols also varies. The maximum number of lanes supported for each communication protocol can be set according to the actual situation.

[0041] In this embodiment, the general verification platform includes a multi-protocol processing script 20. When protocol configuration information for different communication protocols is input, the multi-protocol processing script 20 converts the configuration information into configuration files with a unified format. These configuration files include parameter information such as the protocol type, supported communication rate, bit width, and number of channels for each communication protocol. Because the configuration files have a unified format, the test management module 30 can quickly obtain the required parameter information when it needs to call these configuration files, facilitating the generation of the required test sequences and thus improving testing efficiency. Furthermore, when generating test sequences, the required parameter information is obtained based on the unified format configuration files. The format of the configuration files is independent of the communication protocol type, which achieves desensitization processing between test sequence generation and communication protocol type, further improving the efficiency of test sequence generation.

[0042] Furthermore, since this embodiment includes a protocol configuration module 21, when a new communication protocol needs to be added, only the protocol type and corresponding protocol configuration information, such as supported communication rates and bit widths, need to be input into the general verification system. The multi-protocol processing script 20 will then automatically generate the corresponding configuration file. Specifically, the configuration file adds the corresponding parameter information of the new communication protocol, such as the supported communication rate, bit width, and maximum number of supported channels. Moreover, the general verification system does not require adjustments to the subsequent test management module 30, protocol adaptability module 40, or test top-level module 50. Therefore, the operational difficulty of adding new communication protocols is greatly reduced, and no adjustments to the framework of the general verification system are needed, enabling the general verification system to flexibly add communication protocols.

[0043] If modifications to the protocol configuration information of an existing communication protocol are required, such as changing the supported bit width, 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, by 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, it is not necessary to modify the environment interface and framework of the general verification system, thereby saving time in debugging the test environment and improving testing efficiency.

[0044] The test management module 30 can generate test sequences according to the configuration file generated by the protocol configuration module 21 and the needs of the test cases. Typically, the generated test sequences include multiple sequences, such as test sequence 31…test sequence 38, with different test sequences used to test different functions. The test management module 30 also frames multiple test sequences to form virtual sequences according to the test requirements of the test cases. 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 adaptability module 40.

[0045] The general verification platform can generate a corresponding protocol frame format as an excitation signal and send it to the device under test (DUT) 51 based on the communication protocol type of the device under test 51. For example, if the communication protocol currently used by the DUT 51 is Ethnet, the protocol frame format can be: |Preamble|SFD|Destination MAC Address|Source MAC Address|Type / Length|Data|FCS|, where SFD is used to characterize the start marker of a data frame, 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 DUT 51 is PCIe, the protocol frame format can be |Header|Data|ECRC|, where the Header contains routing information (such as RequesterID, Tag), transaction type (MemoryRead / Write), etc., and ECRC contains a CRC checksum.

[0046] Furthermore, the general verification system selects an appropriate encoding method for the test sequence based on the type of communication protocol, such as NRZ or PAM4 encoding. It also randomly selects values ​​for each domain segment according to the range allowed by the communication protocol. For example, if a communication protocol supports communication rates including 2.5G, 5G, 8G, 16G, 32G, and 64G, then one of these supported rates can be randomly selected as the test rate, and the test sequence can be generated accordingly. Since each type of communication protocol often has a corresponding encoding method, selecting an appropriate encoding method ensures that the generated test sequence meets the encoding format requirements of the corresponding communication protocol, avoiding the problem of the device under test (DUT) 51 being unable to correctly recognize the test sequence due to a mismatch between the encoding format of the test sequence and the communication protocol.

[0047] The protocol adaptable module 40 includes a sequence generator 41, a driver 42, and a monitor 43. The sequence generator 41 receives test sequences sent by the test management module 30, i.e., multiple test sequences from a virtual sequence, and sends these test sequences to the device under test 51 in a set order via the driver 42. Since different test cases involve different test steps and functions, different test sequences need to be invoked based on the actual situation of the current test case and the currently used communication protocol, thus forming a set of virtual sequences.

[0048] After receiving the test sequence, the device under test 51 responds accordingly 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.

[0049] The top-level test module 50 is used to communicate with the device under test (DUT) 51. Specifically, it sends the test sequence output by the driver 42 to the DUT 51 as an excitation signal, and simultaneously receives the data returned by the DUT 51 and sends it back to the monitor 43. Of course, the top-level test module 50 also needs to output a clock signal to the DUT 51 and generate an interface for data transmission with the DUT 51 according to the protocol configuration information.

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

[0051] The coverage collection module 62 collects and analyzes the coverage status of the device under test 51 based on the data received from the device under test 51 by the monitor 43. For example, it analyzes the operation of each coverage point to form the current coverage data of the device under test 51. Furthermore, the coverage collection module 62 can display the coverage data in a visual manner, allowing testers to intuitively understand the performance of the device under test 51.

[0052] 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 under test 51. Specifically, it is necessary to define the functional coverage points to be tested, such as communication rate, bit width, power status, etc. When conducting tests, it is necessary to generate corresponding test sequences according to the functional coverage points to be tested.

[0053] For example, a function coverage point can be a rate level, with a supported rate range of [0:9] set in the configuration file, covering PCIe, Gen1 to Gen6, USB2, USB3, USB4, Ethernet, etc. If the communication protocol used by the device under test 51 is Gen4, the function coverage point is set to bin=4, thus hitting the rate to be tested. Another example is a bit width, with supported bin values ​​in the configuration file including 16, 32, 64, and 128, applicable to communication protocols such as USB4 and PCIe x16. During simulation testing, if a 64-bit bit width needs to be configured, the corresponding bin will be recorded as a hit. Yet another example is a power state, with supported power states in the configuration file including L0 (active), L1 (power saving), and L2 (off), each time the device under test 51 enters the corresponding power state, the corresponding function coverage point bin is recorded as a hit.

[0054] 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.

[0055] In addition, when setting functional coverage points, the functional coverage collection module can also obtain functional coverage points from multiple dimensions based on the protocol type of the test cases to form cross-dimensional functional coverage point groups (CrossCoverage). This involves cross-dimensional combination and cross-combination of functional coverage points to form a complete coverage space, facilitating the discovery of test blind spots. For example, combining communication rate, bit width, and power status functional coverage points into a cross-dimensional functional coverage point group creates a three-dimensional coverage matrix. Each cross-dimensional functional coverage point group corresponds to a coverage bin, enabling the detection of whether all parameter combinations are covered. For instance, in a certain test scenario, the cross-dimensional functional coverage point group is set to: Gen4 + 64bit + L0. This means testing whether the device under test (DUT) 51 can support the Gen4 communication rate requirement, with a bit width of 64 bits and power status including active states. If this bin is not hit, it indicates that this combination has not been verified.

[0056] If different coverage points are combined arbitrarily, unreasonable cross-dimensional functional coverage point groups may occur, such as combinations 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 cross-dimensional functional coverage point groups to avoid affecting the accuracy of coverage statistics.

[0057] The code coverage collection module can support interfaces of one or more chip design tools. When the device under test 51 is being 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. This allows multiple test cases or returned test results to be automatically integrated to generate an overall code coverage report, enabling testers to intuitively understand the code coverage of the device under test 51.

[0058] As can be seen, when configuring multiple communication protocols in a unified manner, the `$plusarg` function can be used to input protocol configuration information from an external source. The general verification system defines a configuration file with a unified format through the protocol configuration module 21. The configuration file contains parameters such as protocol name, version, rate, maximum channel data volume, and bit width. Furthermore, the need for functions such as EQ training and dynamic equalization adaptation can be determined based on the actual test cases. In the test case configuration, switches for enabling or disabling functions such as EQ training and dynamic equalization adaptation can be set, and these switches can be enabled or disabled according to actual testing needs to achieve the corresponding function activation or deactivation.

[0059] The general verification system can generate corresponding test sequences based on the current test function and the communication protocol used. Each test case can frame multiple test sequences to form a virtual sequence according to the test requirements, and the virtual sequence drives each test sequence, sending each test sequence to the device under test 51 in a pre-set order. After receiving the test sequence, the device under test 51 performs the corresponding operation 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.

[0060] The configuration file generated by the protocol configuration module 21 contains parameter information that the device under test (DUT) can actually set the coverage points. For example, the communication rate configuration file includes communication rates supported by the PCIE communication protocol, such as 2.5G, 5G, 8G, 16G, 32G, and 64G. Therefore, when setting the coverage points of the DUT 51 under the PCIE communication protocol, the test cases can select one of the multiple parameters (2.5G, 5G, 8G, 16G, 32G, and 64G) as the functional coverage point for testing. Thus, when a new communication protocol needs to be added or the protocol configuration information of an existing communication protocol needs to be updated, only the configuration file needs to be updated, without requiring changes to the test management module 30, the protocol adaptability module 40, or the top-level test module 50. This improves testing efficiency while ensuring compatibility with multiple communication protocol tests.

[0061] Example of chip verification method:

[0062] Before verifying the chip, the aforementioned general verification system must first be constructed. (See also...) Figure 3 When constructing the above-mentioned general verification system, step S1 is executed first to generate a framework for a general verification system that supports multiple protocols based on a pre-set template. Since the data within the framework is not set, the generated framework does not have a configuration file, meaning that the framework has not yet obtained the protocol configuration information.

[0063] Then, step S2 is executed to generate the interface file for the test top-level module, enabling the instantiation of the device under test. The generated interface file for the test top-level module allows the test top-level module to transmit data with the device under test, thereby enabling the instantiation of the device under test.

[0064] Next, step S3 is executed to establish connections between the various modules within the universal verification system. For example, connections are established between UVM components, monitors, and checkers. The checker in the universal verification system receives data returned by the device under test (DUT) and checks the DUT's operational status based on the received data to determine whether the DUT meets the expected design requirements.

[0065] Then, step S4 is executed, and the general verification system automatically generates test case files, which are stored in the test case module. Additionally, parameters such as power supply and communication speed are modified and improved based on the configuration file.

[0066] Finally, step S5 is executed to categorize the test cases. A test case list is automatically generated by a script, preferably categorized according to the function tested by the test cases, the corresponding communication protocol, etc. Furthermore, the pass rate and coverage of each test case are statistically analyzed, and test cases requiring analysis are marked, such as marked failed test cases. These marked test cases will be analyzed later to determine the reasons for their failure.

[0067] After the general testing system is built, the built general verification system is used to verify the chip. 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 top-level test module of the general verification system.

[0068] See Figure 4 When verifying the chip, step S11 is executed first. After the general verification system is started, the general verification system is first reset at the system level to ensure that the simulation environment is initialized to a deterministic state, so as to avoid the interference of historical states on the current test, especially to avoid the interference of previously executed tests on the current test.

[0069] Specifically, a reset sequence is generated based on the interface and configuration information of the device under test (DUT). This generated reset sequence includes both hardware and software reset sequences, which are used to reset the general-purpose verification system. Before each test, the general-purpose verification system performs a reset operation to avoid the influence of the previously executed test on the current test, thus enabling more accurate verification and testing of the DUT.

[0070] Then, in step S12, the general verification system acquires configuration information for two or more protocols and applies a multi-protocol processing script to convert the configuration information into a configuration file with a unified format. As mentioned earlier, the generated configuration file contains various parameter information such as protocol type, communication rate, bit width, and power status for multiple communication protocols.

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

[0072] Next, in 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 then be sent to the device under test to start the device under test, so as to ensure that the universal verification platform and the device under test are clock synchronized, thereby ensuring that the device under test can correctly identify the data output by the universal verification platform.

[0073] Then, step S15 is executed. A reset operation is performed. Specifically, the general verification system will only perform the reset operation after the clock signal stabilizes, so that the device under test is removed from the verification environment from the reset state and enters the normal working state. Next, the configuration file generated in steps S12 and S13 and the obtained rate configuration information are written into the memory of the general verification system. In addition, for communication protocols with physical layer link training, such as PCIe and USB4, the links in the receiving and transmitting directions are reset respectively to ensure normal communication initialization.

[0074] Next, step S16 is executed. After completing the basic configuration described above, a power-on operation is triggered, causing the device under test to enter the power-on state and the interactive working stage. At this time, the general verification system can send data to the device under test, and the device under test can respond to the data sent by the general verification system.

[0075] Then, in step S17, the general verification system sends data streams and functional stimulus signals to the device under test (DUT). For example, the driver sends multiple test sequences to the DUT in a pre-set order. After receiving these test sequences, the DUT performs the corresponding operations. The general verification system receives the data returned by the DUT through the monitor.

[0076] Finally, step S18 is executed. The coverage collection module calculates the current coverage data of the device under test based on the data returned by the device under test, and completes the functional verification of the device under test in conjunction with the checker. The checker can detect various aspects of the device under test, such as timing, protocol behavior, and data integrity, thereby completing the functional-level verification of the device under test.

[0077] As can be seen, the universal verification system of the present invention is compatible with a variety of different communication protocols. During the configuration phase, it can convert the configuration information of multiple protocols into a configuration file with a unified format. 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 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 and improves testing efficiency.

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

Claims

1. A universal verification system supporting multiple protocols, characterized in that, include: The protocol configuration module is used to receive two or more types of protocol configuration information and convert the various types of protocol configuration information into a configuration file with a unified format, wherein the configuration file includes parameter information of various protocols; The test management module is used to generate test sequences according to the configuration file and the needs of the test cases, and to frame multiple test sequences into a virtual sequence according to the test requirements of the test cases. The protocol is adaptable to a module for sending the test sequence to the device under test and receiving data returned by the device under test. The coverage collection module is used to collect coverage data of the device under test based on the data returned by the device under test. The parameter information in the configuration file contains the coverage points that the test cases need to test, and when generating the test sequence, the required parameter information is obtained based on the configuration file in a unified format, and the format of the configuration file is independent of the communication protocol type. The virtual sequence is used to drive multiple test sequences and send the multiple test sequences to the protocol adaptable module.

2. The universal verification system supporting multiple protocols according to claim 1, characterized in that: The protocol-adaptable module includes a sequence generator, a driver, and a monitor. The sequence generator receives multiple test sequences from 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 general verification system also includes a top-level test module, which is used to send excitation signals to the device under test and send the data returned by the device under test to the monitor.

3. The universal verification system supporting multiple protocols according to claim 1 or 2, characterized in that: The protocol configuration module is also used to receive protocol configuration information of a new protocol, and add the parameter information of the new protocol to the configuration file according to the protocol configuration information of the new protocol.

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

5. The universal verification 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 communication protocol.

6. The universal verification 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 verification 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 from 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 statistically analyzes the coverage data of the cross-dimensional functional coverage point group based on the data returned by the device under test.

8. A chip verification method, wherein the chip is verified using a universal verification system supporting multiple protocols as described in any one of claims 1 to 7, characterized in that, include: Receive two or more protocol configuration information and convert the various protocol configuration information into a configuration file with a unified format; Test sequences are generated according to the configuration file and the needs of the test cases, and multiple test sequences are framed to form a virtual sequence according to the test requirements of the test cases. The test sequence is sent to the device under test (DUT), and the data returned by the DUT is received. The coverage data of the DUT is calculated based on the data returned by the DUT, and the functional verification of the DUT is completed in conjunction with the checker.

9. The chip verification method according to claim 8, characterized in that: Before receiving configuration information from two or more protocols, perform a hardware reset operation on the general verification system. After the master clock signal of the general verification system stabilizes, a 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 de-reset operation is also performed on the links in the receiving and transmitting directions respectively.

Images