A physical layer verification method, device, equipment and storage medium

Abstract

The present application discloses a physical layer verification method, apparatus, device and storage medium, which relates to the field of chip design and verification technology. The method includes: obtaining a target test case and cloning the target test case based on a preset number of clones to obtain a cloned test case; determining the protocol mode selected by the physical layer in the target test case and the corresponding verification IP; using an automated parsing tool to generate an input configuration file with the same number of preset clones according to the verification IP, and parsing the input configuration file to obtain a corresponding executable configuration file; based on the executable configuration file, calling an automated regression verification tool to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage. Through the technical solution of the present application, automated verification of the physical layer can be achieved, repeated modification and compilation time of the environment can be reduced, and rational deployment of verification IP can be achieved.

Description

Technical Field

[0001] The present invention relates to the field of chip design and verification technology, and in particular to a physical layer verification method, device, equipment and storage medium. Background Art

[0002] In recent years, with the continuous development and improvement of computer architecture, people's requirements for computer performance have continued to increase. As a key part of the continuous improvement of computer architecture, improving data transmission rate and system scalability has received more and more attention. PCI-e (peripheral component interconnect express, PCI-Express), as a high-speed serial computer expansion bus standard, abandons the traditional parallel bus design method and uses a high-speed differential serial bus to transmit data through the PCI-e link. Compared with the parallel bus, the serial bus greatly improves the data transmission rate. Due to its superior performance in data transmission, the PCI-e bus occupies an extremely important position in computer architecture. As Figure 1 As shown in FIG, the PCI-e bus architecture mainly includes a root node (Root Complex), a switch (Switch), an end device (Endpoint) and a bridge (Bridge).

[0003] Nowadays, high-end electronic systems such as radar and communications are facing increasing demands for storing massive amounts of data. In this context, the pursuit of high-capacity, high-bandwidth, and reliable storage devices is becoming an inevitable trend. Current storage products such as hard drives and flash drives lack sufficient performance. Consequently, a number of integrated solutions based on the PCI-e protocol and combined with NVMe (Non-Volatile Memory Express), SATA (Serial Advanced Technology Attachment), and RAID (Redundant Array of Independent Disks) have emerged. To support this integration, a multi-protocol, multi-channel physical layer (PHY) is an essential component. To support flexible support for multiple protocols and external devices, the PHY incorporates bifurcation and aggregation capabilities. For example, a single external x16 PHY might internally consist of multiple smaller PHYs, each with its own configurable channels.

[0004] However, there are currently the following problems with physical layer verification. 1. Multi-channel, multi-protocol PHYs have numerous bifurcation scenarios. For example, a x16 PHY that needs to support both PCI-e and SATA protocols has numerous bifurcation scenarios. Comprehensively covering these bifurcation and aggregation scenarios while ensuring data path and transmission accuracy is a relatively challenging task. 2. For a complete verification environment, different bifurcation and aggregation scenarios require different VIPs (Verification Internet Protocols). Achieving flexibility and minimizing the need for verification environment modifications with each solution change is also a verification challenge. 3. For different bifurcation and aggregation solutions, there are many system-level low-power solutions. For solutions without external devices, power and clock shutdown can be implemented. However, these solutions require constant modification based on the solution and require recompilation after modification, adding additional time and impacting verification progress. 4. For complex systems requiring multiple VIPs, verification is independent of each module and function. Proper allocation of VIP licenses is also a challenge. For example, when verifying PCI-e-related functions, if the environment cannot properly select VIPs based on bifurcation and aggregation configurations, VIP usage will be wasted.

[0005] In summary, how to achieve a high degree of unification of the design and verification environment, rationally allocate VIP resources, reduce the manpower consumption of verification engineers, and save the compilation time and debugging time caused by configuration modifications are issues that need to be urgently addressed. Summary of the Invention

[0006] In view of this, the purpose of the present invention is to provide a physical layer verification method, apparatus, device, and storage medium that can achieve a high degree of uniformity in the design and verification environment, rationally allocate VIP resources, reduce the manpower consumption of verification engineers, and save the compilation time and debugging time caused by configuration modifications. The specific solution is as follows:

[0007] In a first aspect, the present application discloses a physical layer verification method, comprising:

[0008] Obtaining a target test case and cloning the target test case based on a preset number of clones to obtain a cloned test case;

[0009] Determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes;

[0010] Using an automated parsing tool to generate an input configuration file having the same number of clones as the preset number based on the verification IP, and parsing the input configuration file to obtain a corresponding executable configuration file;

[0011] Based on the executable configuration file, an automated regression verification tool is called to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage.

[0012] Optionally, before obtaining the target test case and cloning the target test case based on a preset number of clones to obtain the cloned test case, the method further includes:

[0013] Reading a verification plan including a plurality of test cases, and determining whether the target test case exists in the verification plan;

[0014] If the target test case exists in the verification plan, triggering the step of obtaining the target test case and cloning the target test case based on a preset number of clones to obtain a cloned test case;

[0015] If the target test case does not exist in the verification plan, a prompt is given that the current program is running in error and the current program is exited.

[0016] Optionally, the step of using an automated parsing tool to generate an input configuration file having the same number of clones as the preset number based on the verification IP includes:

[0017] Using an automated parsing tool to randomly generate an input configuration file having the same number of clones as the preset number based on the verification IP;

[0018] Alternatively, an automated tool is used to customize and generate an input configuration file having the same number of clones as the preset number based on the verification IP.

[0019] Optionally, after using an automated parsing tool to generate an input configuration file having the same number of clones as the preset number based on the verification IP, the method further includes:

[0020] When the automated parsing tool is used to randomly generate an input configuration file having the same number of clones as the preset number according to the verification IP, the input configuration file is stored in the simulation path;

[0021] When the automated parsing tool is used to customize and generate input configuration files having the same number of clones as the preset number according to the verification IP, the input configuration files are stored in a directory corresponding to the clone test case.

[0022] Optionally, the process of calling an automated regression verification tool to execute the cloned test case and collect coverage based on the executable configuration file further includes:

[0023] The cloned test cases and the executable configuration file are copied to the simulation path so that a plurality of the cloned test cases are executed in parallel.

[0024] Optionally, after calling the automated regression verification tool to execute the cloned test case and collect coverage, the method further includes:

[0025] Determining whether the coverage rate reaches 100%;

[0026] If the coverage reaches 100%, then the calling of the automated regression verification tool is terminated;

[0027] If the coverage rate does not reach 100%, the step of using an automated parsing tool to generate an input configuration file having the same number of clones as the preset number according to the verification IP is performed again.

[0028] Optionally, parsing the input configuration file to obtain a corresponding executable configuration file includes:

[0029] The input configuration file is parsed to obtain an output configuration file, a verification IP interconnection configuration file, and a test case configuration file; wherein the output configuration file is a file that controls the input signal according to the protocol mode, the verification IP interconnection configuration file is a file that stores relevant data information of the verification IP, and the test case configuration file is a C file that stores program running initialization information and the physical layer related configuration information.

[0030] In a second aspect, the present application discloses a physical layer verification device, comprising:

[0031] A test case cloning module, configured to obtain a target test case and clone the target test case based on a preset number of clones to obtain a cloned test case;

[0032] A configuration mode determination module is used to determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes;

[0033] An automatic parsing module, configured to generate an input configuration file having the same number of clones as the preset number according to the verification IP using an automatic parsing tool, and parse the input configuration file to obtain a corresponding executable configuration file;

[0034] The regression verification module is used to call an automated regression verification tool based on the executable configuration file to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage.

[0035] In a third aspect, the present application discloses an electronic device, comprising a processor and a memory; wherein the memory is used to store a computer program, and the computer program is loaded and executed by the processor to implement the physical layer verification method as described above.

[0036] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein the computer program implements the aforementioned physical layer verification method when executed by a processor.

[0037] In this application, the target test case is first obtained and cloned based on a preset number of clones to obtain a cloned test case; then the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes are determined; an automated parsing tool is used to generate an input configuration file with the same number of clones as the preset number based on the verification IP, and the input configuration file is parsed to obtain a corresponding executable configuration file; finally, based on the executable configuration file, an automated regression verification tool is called to execute the cloned test case and collect coverage to verify whether the protocol mode matches the verification IP according to the coverage. It can be seen that by using the verification IP corresponding to each of the protocol modes selected by the physical layer to generate an input configuration file with the same number of clones as the preset number, multiple copies of the target test case for a data path are made to obtain cloned test cases, and using different input configuration files can meet the full coverage of various complex scenarios. At the same time, the input configuration file is parsed by the automated parsing tool to obtain the corresponding executable configuration file, adding fork-related allocation logic to the verification environment, which can realize the automatic allocation and interconnection of different channels for different configurations, solving the pain points and difficulties of verification. In addition, in the verification environment, calling the automated regression verification tool can regress all cloned test cases, which not only saves the time of modifying the test cases, but also saves the time of modifying the environment and configuration files. The mounting of the verification IP can be reasonably verified according to the fork and aggregation configuration. It is not only flexible and convenient, but also saves manpower and the number of verification IPs used. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0039] Figure 1 A schematic diagram of a PCI-e bus topology disclosed in this application;

[0040] Figure 2 A flow chart of a physical layer verification method disclosed in this application;

[0041] Figure 3 A schematic diagram of a file structure and cloning principle disclosed in this application;

[0042] Figure 4 This is a schematic diagram of the framework of a high-speed memory chip subsystem disclosed in this application;

[0043] Figure 5 This is a pseudo code diagram of an input configuration file disclosed in this application;

[0044] Figure 6 This is a pseudo code diagram of an output configuration file disclosed in this application;

[0045] Figure 7 A pseudo code diagram for verifying an IP interconnection configuration file disclosed in this application;

[0046] Figure 8 A pseudo code diagram of a test case configuration file disclosed in this application;

[0047] Figure 9 A schematic diagram of an output file generated by an automated parsing tool disclosed in this application;

[0048] Figure 10 This is a pseudo code diagram of a configuration file of an automated regression verification tool disclosed in this application;

[0049] Figure 11 A flow chart of a specific physical layer verification method disclosed in this application;

[0050] Figure 12 This is a schematic diagram of an automated physical layer verification disclosed in this application;

[0051] Figure 13 A flow chart of a specific physical layer verification method disclosed in this application;

[0052] Figure 14 A bifurcated logic structure and interconnection diagram disclosed in this application;

[0053] Figure 15 This is a schematic diagram of the structure of a physical layer verification device disclosed in this application;

[0054] Figure 16 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0055] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0056] Currently, the pursuit of high-capacity, high-bandwidth, and reliable storage devices is an inevitable development trend. However, the physical layer (PHY), as an indispensable component, faces many challenges during the verification process. For example, it is relatively difficult to fully cover both bifurcation and aggregation scenarios while ensuring the correctness of data paths and transmissions. Furthermore, it is also crucial to achieve flexible physical layer integration, minimize verification environment modifications for each solution change, and recompile after each solution change, which adds additional time and impacts verification progress. Furthermore, it is also crucial to ensure the proper allocation of VIP licenses.

[0057] To this end, this application provides a physical layer verification solution that can achieve a high degree of unification of the design and verification environment, rationally allocate VIP resources, reduce the manpower consumption of verification engineers, and save compilation time and debugging time caused by configuration modifications.

[0058] The embodiment of the present invention discloses a physical layer verification method, see Figure 2 As shown, the method includes:

[0059] Step S11: Acquire a target test case and clone the target test case based on a preset number of clones to obtain a cloned test case.

[0060] In the embodiment of the present application, it is necessary to determine the target test case for implementing the physical layer verification in the verification plan, which can be one or more test cases that meet the requirements. It should be pointed out that the test case contains a description of the test task. Generally, this test case contains information such as basic register access and basic data transmission access. By cloning the target test case, the target test case can be copied into multiple copies, so that full coverage of different scenarios can be achieved in the subsequent use of the configuration file. In addition, in the cloning process, the number of clones required for the target test case, that is, the preset number of clones can be arbitrarily modified through simple script processing.

[0061] Specifically, a verification plan including multiple test cases is read, and it is determined whether the target test case exists in the verification plan; if the target test case exists in the verification plan, it means that the target test case can be further cloned; if the target test case does not exist in the verification plan, a prompt is given that the current program is running in error and the current program is exited.

[0062] In the embodiment of the present application, each test case contains three types of files: 1) icrun.cfg file, which is mainly used to implement the scripts and files that need to be executed before the test is run, copying and linking, and basic commands for the test case to run; 2) test.sv file is mainly the main body of the test case, mainly including basic register configuration and path checking, etc.; 3) test.c file, which is mainly used to ensure the initialization information and physical layer bifurcation and aggregation related configuration information to ensure the normal operation of the system. 1) and 3) are both automatically generated. Figure 3 Shown is the file structure and cloning principle diagram.

[0063] Step S12: Determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes.

[0064] In the embodiment of the present application, in order to flexibly control the bifurcation and aggregation logic of the physical layer, it is necessary to first determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes. This method reduces the consumption of verification IP resources. For multi-protocol PHY, the general verification environment will connect to multiple verification IPs. For scenarios with only a single protocol, it will cause a waste of verification IP resources. This method obtains the protocol mode and verification IP according to the target test case and reasonably allocates verification IP resources. Figure 4 The embodiments of the present application are described with reference to an example.

[0065] Figure 4 This is a specific architectural design for a subsystem within a high-speed storage chip. This subsystem includes one x16 PCI-e controller, one x8 PCI-e controller, two x4 PCI-e controllers, four x2 PCI-e controllers, and two x8 SATA controllers. Hardware bifurcation and aggregation logic is used to switch between different modes. The entire system primarily supports two protocol modes: PCI-e or SATA. Each subsystem has four PHYs, for a total of 16 channels. In principle, each channel can be configured to a different protocol. However, since each PHY can only support one protocol, each channel is configured in x4 units. One x4 unit can support two x2 units or four x1 units. Table 1 shows an example of configuration information for each channel.

[0066] Table 1

[0067]

[0068] Step S13: using an automated parsing tool to generate input configuration files with the same number of clones as the preset number based on the verification IP, and parsing the input configuration files to obtain corresponding executable configuration files.

[0069] In a specific implementation, for example, for a x16 system, the number and type of verification IPs docked in the verification environment are different depending on the configuration. For example, a system configuration is PCI-ex8+SATA 8P, which means that a PCI-e verification IP and 8 SATA verification IPs need to be docked in the verification environment. At the same time, it is also necessary to determine whether the PCI-e is docked with the first 8 channels or the last 8 channels, so that the connection relationship changes dynamically for different configurations. In order to solve this problem, a bifurcation logic is added to the verification environment, that is, an automated parsing tool is used to generate different input configuration files based on the verification IP, mainly to achieve dynamic connection and allocation of differential signal pairs for different configurations. In this verification method, a single input source, that is, an input configuration file, is used to achieve a high degree of unified control of test cases, test environments, and verification IPs, avoid inconsistencies in modifications from multiple sources, and reduce the manpower consumption of verification engineers.

[0070] Table 2 shows several examples of commonly used configurations. The application layer can configure each channel according to the specific application scenario, and can also dynamically configure and close unnecessary channels.

[0071] Table 2

[0072]

[0073]

[0074] Further, such as Figure 5 The pseudocode for a specific input configuration file, bifurcation.cfg, is shown. This file primarily translates the configuration in Table 1. Using an exhaustive approach to verify the entire bifurcation and aggregation functionality is relatively difficult. This requires modifying the verification environment, configuration, connection methods, and recompiling to account for different data flows, all of which consumes significant manpower and resources. Therefore, using automated tools to parse the input configuration file allows for automated configuration of various file outputs and verification environments based on the resulting qualified input configuration file.

[0075] In the embodiment of the present application, three executable configuration files can be obtained after parsing the input configuration file, namely, the output configuration file, the verification IP interconnection configuration file and the test case configuration file.

[0076] In the embodiment of the present application, the output configuration file (user.do) is a file that controls the input signal according to the protocol mode. This file mainly generates a configuration file that matches the design item based on the analysis of the input channel configuration file, so as to achieve the unification of the design and verification environment. The lanex_bifurcation_mode is assigned a value by force. In this way, before the test case is run, it is judged in the tcl script whether there is a user-defined executable file user.do. If it exists, it is executed, thereby achieving the control of the input mode signal value. At the same time, this method does not require recompilation. Each time the automated parsing tool is started, it automatically judges and executes, saving the time of recompiling the environment. It should be noted that the hierarchical structure is different for different levels of verification, so when generating this file, the user needs to give the level of the input signal in the verification environment, and the automated tool will add and process them together. Figure 6 The following is the pseudo code of the user.do file generated by the automated parsing tool.

[0077] In the embodiment of the present application, the verification IP interconnection configuration file (stack.cfg) is a file that stores the relevant data information of the verification IP. This file is mainly used to solve the connection problem of the verification IP in the verification environment. Different configurations have different channel connection relationships and connection orders. Compared with SATA, PCI-e connection is more complicated because PCIe can support relatively more modes, while SATA mode is only x1. For the connection of PCI-e verification IP, the user needs to know how many verification IPs are connected, which mode to choose, and at the same time need to be informed of their connection relationship. For example, if the configuration is PCI-e x4 + PCI-e x4 + SATAx8, the user needs to inform the verification environment that two PCI-e verification IPs and 8 SATA verification IPs need to be connected, and the two PCI-e x4s are connected from channel 0 to channel 7, and the SATA is connected from channel 8 to channel 15. If the configuration is SATA x8 + PCI-e x4 + PCI-e x4, although the number of verification IPs does not change, their connection relationship has changed, and the channel numbers of the connections have also been reversed. Secondly, in system-level applications, there may be a situation where the link channel given by PCI-e is x4, but only one x2 device is connected. This also requires verification and support. In the verification environment, the automated parsing tool will allocate the number and docking relationship of verification IPs according to the mode of stack.cfg, realizing flexible allocation and docking of channels. At the same time, when PCI-e or SATA does not exist in the mode selection, the verification IP will be disabled through the parsing of stack.cfg, thus reducing the waste of verification IP resources. Figure 7 The following is pseudo code for the Stack.cfg file generated by the automated parsing tool.

[0078] In the embodiment of the present application, the test case configuration file (test.c) is a C file that stores the program running initialization information and the physical layer related configuration information. The file is in C format. The main reason for using C language is that the configuration is dynamic and changeable. If other types of files are modified before running, they must be recompiled. However, C files can be compiled separately before running. This saves time and realizes the flexible configuration of the verification environment. Figure 8 Shown is the pseudo code generated by the automated tool.

[0079] like Figure 9 As shown in the figure, it is a flowchart of how the automatic parsing tool generates output files. That is, the user.do file, stack.cfg file and test.c file are all automatically generated by the automatic parsing tool. As long as the input configuration file is provided and combined with the automatic parsing tool, it can meet the full coverage of various complex scenarios. Among them, the code of the automatic parsing tool is completed in Python. Figure 9 First, parse the input channel configuration file and analyze which protocol each channel uses. Secondly, according to the configuration file, determine the relationship between each channel and the channel binding relationship, so as to determine the connection relationship of the verification IP.

[0080] Step S14: Based on the executable configuration file, call an automated regression verification tool to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage.

[0081] In an embodiment of the present application, a target test case including a configuration path and a data path is selected, and multiple cloned test cases are generated. The automated parsing tool automatically generates an input configuration file bifurcation.cfg randomly under each cloned test case file according to the physical layer bifurcation and aggregation scenarios, and finally automatically generates the three output files required for the test case according to the automated script in the automated parsing tool. In this way, calling the automated regression verification tool can regress all test cases, which not only saves the modification time of the test cases, but also saves the time for modifying the environment and configuration files. This method is flexible and convenient, saves manpower and the number of verification IPs used. According to different executable configuration files, full coverage of the bifurcation function can be achieved when calling the automated regression verification tool. This verification method realizes a closed loop. First, the input configuration files required for all bifurcated and aggregated functional points are generated according to the actual needs of the design, and the full regression of multiple functional points is achieved in combination with the automated regression verification tool.

[0082] like Figure 10The figure shows a pseudo-code diagram of a configuration file of an automated regression verification tool disclosed in this application; this configuration file is randomly generated when cloning the target test case. The user can customize the configuration file according to needs, so that the regression tool will generate a customized configuration file based on the template.

[0083] In this application, the target test case is first obtained and cloned based on a preset number of clones to obtain a cloned test case; then the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes are determined; an automated parsing tool is used to generate an input configuration file with the same number of clones as the preset number based on the verification IP, and the input configuration file is parsed to obtain a corresponding executable configuration file; finally, based on the executable configuration file, an automated regression verification tool is called to execute the cloned test case and collect coverage to verify whether the protocol mode matches the verification IP according to the coverage. It can be seen that by using the verification IP corresponding to each of the protocol modes selected by the physical layer to generate an input configuration file with the same number of clones as the preset number, multiple copies of the target test case for a data path are made to obtain cloned test cases, and using different input configuration files can meet the full coverage of various complex scenarios. At the same time, the input configuration file is parsed by the automated parsing tool to obtain the corresponding executable configuration file, adding fork-related allocation logic to the verification environment, which can realize the automatic allocation and interconnection of different channels for different configurations, solving the pain points and difficulties of verification. In addition, in the verification environment, calling the automated regression verification tool can regress all cloned test cases, which not only saves the time of modifying the test cases, but also saves the time of modifying the environment and configuration files. The mounting of the verification IP can be reasonably verified according to the fork and aggregation configuration. It is not only flexible and convenient, but also saves manpower and the number of verification IPs used.

[0084] The present application embodiment discloses a specific physical layer verification method, see Figure 11 As shown, the method includes:

[0085] Step S21: Acquire a target test case and clone the target test case based on a preset number of clones to obtain a cloned test case.

[0086] Step S22: Determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes.

[0087] Step S23: using an automated parsing tool to generate input configuration files with the same number of clones as the preset number according to the verification IP, and parsing the input configuration files to obtain corresponding executable configuration files.

[0088] For more specific processing procedures of the above-mentioned steps S21, S22, and S23, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0089] Step S24: Based on the executable configuration file, call an automated regression verification tool to execute the cloned test case and collect coverage, and determine whether the coverage reaches 100%.

[0090] In an embodiment of the present application, after obtaining the corresponding executable configuration file based on the input configuration file of the cloned test case, the automated regression verification tool is called to determine whether the coverage of the application scenario reaches 100%. Only when the coverage reaches 100%, it is proved that full coverage of the verification scenario has been achieved.

[0091] Step S25: If the coverage reaches 100%, then the calling of the automated regression verification tool is terminated; if the coverage does not reach 100%, then the step of using the automated parsing tool to generate an input configuration file with the same number of clones as the preset number based on the verification IP is re-executed.

[0092] like Figure 12 The figure shows an automated schematic diagram for physical layer verification. An automated parsing tool is used to generate multiple input configuration files, which are stored in the paths of cloned test cases. The main implementation is to first obtain the name of the test case to be cloned from the verification plan, search for the number of clones under the test case name, and generate the same number of input configuration files after successful acquisition, and store them in the paths of cloned test cases. When the automated regression verification tool is called, the test cases are executed and the coverage is collected. It should be pointed out that the test cases executed are cloned test cases. When the coverage reaches 100%, the call of the automated regression verification tool can be terminated. If it does not reach 100%, it means that there are still uncovered scenarios, and the input configuration files will continue to be generated to achieve full coverage of the scenarios.

[0093] In the embodiment of the present application, the verification method only needs to be compiled once during the entire verification process, and subsequent modifications to the configuration file do not require recompilation to achieve configuration reloading, saving the compilation time and test case debugging time caused by configuration modifications.

[0094] In the embodiments of the present application, a high-speed, effective, and random verification method is provided for chips with increasingly higher integration, especially chips containing a large number of high-speed I / O interfaces. First, this method can not only be applied to the functional verification of multi-channel and multi-protocol PHY, but can also be applied to modules in other system scenarios that have many scenarios but require exhaustive verification; secondly, verification IP is indispensable in verification, and the VIP resource allocation method of the present invention can also be applied to the system verification environment to achieve reasonable allocation of VIP resources.

[0095] In this application, a target test case is first obtained and cloned based on a preset number of clones to obtain a cloned test case; then, the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes are determined; an input configuration file equal to the preset number of clones is generated based on the verification IP using an automated parsing tool, and the input configuration file is parsed to obtain a corresponding executable configuration file; finally, based on the executable configuration file, an automated regression verification tool is called to execute the cloned test case and collect coverage, and it is determined whether the coverage reaches 100%. If the coverage reaches 100%, the call to the automated regression verification tool is terminated; if the coverage does not reach 100%, the step of using the automated parsing tool to generate an input configuration file equal to the preset number of clones based on the verification IP is re-executed. It can be seen that by using the verification IP corresponding to each of the protocol modes selected by the physical layer to generate an input configuration file equal to the preset number of clones, multiple copies of the target test case for a data path are made to obtain cloned test cases, and using different input configuration files can meet full coverage of various complex scenarios. At the same time, an automated parsing tool is used to parse the input configuration file to obtain the corresponding executable configuration file. The fork-related allocation logic is added to the verification environment, which can realize the automatic allocation and interconnection of different channels for different configurations, solving the pain points and difficulties of verification. In addition, in the verification environment, calling the automated regression verification tool can regress all cloned test cases, saving not only the time of modifying the test cases, but also the time of modifying the environment and configuration files. The mounting of the verification IP can be reasonably verified according to the fork and aggregation configuration. It is not only flexible and convenient, but also saves manpower and the number of verification IPs used.

[0096] The present application embodiment discloses a specific physical layer verification method, see Figure 13 As shown, the method includes:

[0097] Step S31: Acquire a target test case and clone the target test case based on a preset number of clones to obtain a cloned test case.

[0098] Step S32: Determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes.

[0099] For more specific processing procedures of the above-mentioned steps S31 and S32, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be elaborated here.

[0100] Step S33: using an automated parsing tool to randomly generate input configuration files with the same number of clones as the preset number based on the verification IP, and parsing the input configuration files to obtain corresponding executable configuration files.

[0101] In a specific implementation, the automated parsing tool will randomly generate an input configuration file based on the verification IP. At this time, it is proved that a universal configuration file is used. The file is stored in the simulation path. When the automated script in the automated parsing tool is executed, the output of various files and the automatic configuration of the verification environment will be realized according to the file.

[0102] Step S34: using an automated tool to generate input configuration files with the same number of clones as the preset number based on the verification IP, and parsing the input configuration files to obtain corresponding executable configuration files.

[0103] In another specific implementation, the automated parsing tool will customize the generated input configuration file based on the verification IP. At this time, the test case has its own separate configuration mode, and the file needs to be stored in the test case directory. When the automated script in the automated parsing tool is executed, it will first search for the input configuration file in the test case directory. If it exists, it will be parsed first. If it does not exist, the configuration file under the simulation path will be parsed.

[0104] like Figure 14 The figure shows the bifurcation logic structure provided by the embodiment of the present application and the connection relationship diagram between the DUT (Device Under Test) and the verification IP. According to the configuration input lanex_bifurcation_mode signal, each channel is determined to select PCI-e or SATA, and txp / txn are respectively assigned to txp_pcie / txn_pcie or txp_sata / txn_sata according to the configuration. For example, for channel 0, if RC0 is selected, that is, the PCI-e protocol is selected, then txp[0] / txn[0] is connected to txp_pcie[0] / txn_pcie[0], and txp_sata[0] / txn_sata[0] is connected to the default value. In this way, there will be no actual sending and receiving behavior on the verification IP. The same principle applies to other channels and receiving directions.

[0105] Step S35: Based on the executable configuration file, call an automated regression verification tool to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage.

[0106] In an embodiment of the present application, when an automated parsing tool is used to automatically generate files related to the verification environment, the only input file generated is the bifurcation.cfg file (input configuration file), and the output files include three types: the user.do file, which mainly gives a reasonable value to the input signal lanex_bifurcation_mode of the cross-logic in the verification environment, and the value is consistent with the initialization configuration of the design; the stack.cfg file (verification IP interconnection configuration file), which is mainly used to determine the number of verification IP dockings and the docking relationship of its channels; the test case configuration file (test.c), which is mainly used to generate a channel configuration file for the DUT and a series of system operation initialization and low-power configurations.

[0107] It's important to note that when using automated regression verification tools for regression verification, all test cases, compiled simv files, and other executable files must be copied to the simulation directory. This ensures that multiple cloned test cases do not interfere with each other and can run in parallel. All generated files, including those generated, must be placed in the simulation directory. This is done in the icrun.cfg file within the test case.

[0108] In this application, first, a target test case is obtained and cloned based on a preset number of clones to obtain a cloned test case; then, the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes are determined; an automated parsing tool is used to randomly generate an input configuration file with the same number of clones as the preset number based on the verification IP, and the input configuration file is parsed to obtain a corresponding executable configuration file; or, an automated tool is used to customize the input configuration file with the same number of clones as the preset number based on the verification IP, and the input configuration file is parsed to obtain a corresponding executable configuration file; finally, based on the executable configuration file, an automated regression verification tool is called to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage. It can be seen that by using the verification IP corresponding to each of the protocol modes selected by the physical layer to generate an input configuration file with the same number of clones as the preset number, multiple copies of the target test case for a data path are made to obtain cloned test cases, and using different input configuration files can meet the full coverage of various complex scenarios. At the same time, an automated parsing tool is used to parse the input configuration file to obtain the corresponding executable configuration file. The fork-related allocation logic is added to the verification environment, which can realize the automatic allocation and interconnection of different channels for different configurations, solving the pain points and difficulties of verification. In addition, in the verification environment, calling the automated regression verification tool can regress all cloned test cases, saving not only the time of modifying the test cases, but also the time of modifying the environment and configuration files. The mounting of the verification IP can be reasonably verified according to the fork and aggregation configuration. It is not only flexible and convenient, but also saves manpower and the number of verification IPs used.

[0109] Accordingly, the present application also discloses a physical layer verification device, see Figure 15 As shown, the device includes:

[0110] A test case cloning module 11 is configured to obtain a target test case and clone the target test case based on a preset number of clones to obtain a cloned test case;

[0111] Configuration mode determination module 12, used to determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes;

[0112] An automatic parsing module 13 is configured to generate an input configuration file having the same number of clones as the preset number according to the verification IP using an automatic parsing tool, and parse the input configuration file to obtain a corresponding executable configuration file;

[0113] The regression verification module 14 is configured to call an automated regression verification tool based on the executable configuration file to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage.

[0114] Among them, for more specific working processes of the above modules, please refer to the corresponding contents disclosed in the aforementioned embodiments, which will not be repeated here.

[0115] As can be seen, through the above-mentioned solution of this embodiment, the target test case is first obtained and cloned based on a preset number of clones to obtain a cloned test case; then, the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each protocol mode are determined; an automated parsing tool is used to generate an input configuration file with the same number of clones as the preset number based on the verification IP, and the input configuration file is parsed to obtain a corresponding executable configuration file; finally, based on the executable configuration file, an automated regression verification tool is called to execute the cloned test case and collect coverage, so as to verify whether the protocol mode and the verification IP match based on the coverage. As can be seen, by using the verification IP corresponding to each protocol mode selected by the physical layer to generate an input configuration file with the same number of clones, multiple copies of the target test case for a data path are made to obtain cloned test cases. Using different input configuration files can meet the full coverage of various complex scenarios. At the same time, by using the automated parsing tool to parse the input configuration file to obtain the corresponding executable configuration file, the fork-related allocation logic is added to the verification environment, which can realize the automatic allocation and interconnection of different channels for different configurations, solving the pain points and difficulties of verification. In addition, in the verification environment, calling the automated regression verification tool can regress all cloned test cases, which not only saves the time of modifying the test cases, but also saves the time of modifying the environment and configuration files. The mounting of the verification IP can be reasonably verified according to the fork and aggregation configuration. It is not only flexible and convenient, but also saves manpower and the number of verification IPs used.

[0116] Furthermore, the embodiment of the present application also discloses an electronic device, Figure 16 This is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content in the diagram cannot be considered as any limitation to the scope of use of the present application.

[0117] Figure 16This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the physical layer verification method disclosed in any of the aforementioned embodiments. Furthermore, the electronic device 20 in this embodiment may be a computer.

[0118] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0119] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, a magnetic disk, or an optical disk. The resources stored thereon may include an operating system 221, a computer program 222, and data 223. The data 223 may include various data. The storage method can be temporary storage or permanent storage.

[0120] The operating system 221 is used to manage and control the hardware devices on the electronic device 20 and the computer program 222. The operating system 221 can be Windows Server, NetWare, Unix, Linux, etc. In addition to including a computer program capable of performing the physical layer verification method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program capable of performing other specific tasks.

[0121] Furthermore, the embodiments of the present application also disclose a computer-readable storage medium, where the computer-readable storage medium includes a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a magnetic disk, or an optical disk, or any other form of storage medium known in the technical field. When the computer program is executed by a processor, the aforementioned physical layer verification method is implemented. For the specific steps of the method, reference can be made to the corresponding content disclosed in the aforementioned embodiments, and no further description will be given here.

[0122] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0123] The physical layer verification or algorithm steps described in conjunction with the embodiments disclosed herein can be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0124] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0125] The above is a detailed introduction to the physical layer verification method, device, equipment and storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for general technical personnel in this field, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A physical layer verification method, characterized in that: include: Obtaining a target test case and cloning the target test case based on a preset number of clones to obtain a cloned test case; Determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes; Using an automated parsing tool to generate an input configuration file having the same number of clones as the preset number based on the verification IP, and parsing the input configuration file to obtain a corresponding executable configuration file; Based on the executable configuration file, calling an automated regression verification tool to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage; The step of using an automated parsing tool to generate an input configuration file having the same number of clones as the preset number based on the verification IP includes: Using an automated parsing tool to randomly generate an input configuration file having the same number of clones as the preset number based on the verification IP; Alternatively, an automated tool is used to customize and generate an input configuration file having the same number of clones as the preset number based on the verification IP; After the automated parsing tool is used to generate an input configuration file having the same number of clones as the preset number according to the verification IP, the method further includes: When the automated parsing tool is used to randomly generate an input configuration file having the same number of clones as the preset number according to the verification IP, the input configuration file is stored in the simulation path; When the automated parsing tool is used to customize the verification IP to generate the same number of input configuration files as the preset number of clones, the input configuration files are stored in the directory of the corresponding clone test case; The step of parsing the input configuration file to obtain a corresponding executable configuration file includes: The input configuration file is parsed to obtain an output configuration file, a verification IP interconnection configuration file, and a test case configuration file; wherein the output configuration file is a file that controls the input signal according to the protocol mode, the verification IP interconnection configuration file is a file that stores relevant data information of the verification IP, and the test case configuration file is a C file that stores program running initialization information and the physical layer related configuration information.

2. The physical layer verification method according to claim 1, wherein: Before obtaining the target test case and cloning the target test case based on a preset number of clones to obtain the cloned test case, the method further includes: Reading a verification plan including a plurality of test cases, and determining whether the target test case exists in the verification plan; If the target test case exists in the verification plan, triggering the step of obtaining the target test case and cloning the target test case based on a preset number of clones to obtain a cloned test case; If the target test case does not exist in the verification plan, a prompt is given that the current program is running in error and the current program is exited.

3. The physical layer verification method according to claim 1, wherein: The process of calling an automated regression verification tool to execute the cloned test case and collect coverage based on the executable configuration file further includes: The cloned test cases and the executable configuration file are copied to the simulation path so that a plurality of the cloned test cases are executed in parallel.

4. The physical layer verification method according to claim 1, wherein: After calling the automated regression verification tool to execute the cloned test case and collect coverage, the method further includes: Determining whether the coverage rate reaches 100%; If the coverage reaches 100%, then the calling of the automated regression verification tool is terminated; If the coverage rate does not reach 100%, the step of using an automated parsing tool to generate an input configuration file having the same number of clones as the preset number according to the verification IP is performed again.

5. A physical layer verification device, characterized in that: include: A test case cloning module, configured to obtain a target test case and clone the target test case based on a preset number of clones to obtain a cloned test case; A configuration mode determination module is used to determine the protocol mode selected by the physical layer in the target test case and the verification IP corresponding to each of the protocol modes; An automatic parsing module, configured to generate an input configuration file having the same number of clones as the preset number according to the verification IP using an automatic parsing tool, and parse the input configuration file to obtain a corresponding executable configuration file; A regression verification module is used to call an automated regression verification tool based on the executable configuration file to execute the cloned test case and collect coverage, so as to verify whether the protocol mode matches the verification IP according to the coverage; The automatic parsing module is specifically used to: Using an automated parsing tool to randomly generate an input configuration file having the same number of clones as the preset number based on the verification IP; Alternatively, an automated tool is used to customize and generate an input configuration file having the same number of clones as the preset number based on the verification IP; When the automated parsing tool is used to randomly generate an input configuration file having the same number of clones as the preset number according to the verification IP, the input configuration file is stored in the simulation path; When the automated parsing tool is used to customize the verification IP to generate the same number of input configuration files as the preset number of clones, the input configuration files are stored in the directory of the corresponding clone test case; The input configuration file is parsed to obtain an output configuration file, a verification IP interconnection configuration file, and a test case configuration file; wherein the output configuration file is a file that controls the input signal according to the protocol mode, the verification IP interconnection configuration file is a file that stores relevant data information of the verification IP, and the test case configuration file is a C file that stores program running initialization information and the physical layer related configuration information.

6. An electronic device, characterized in that: The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, and the computer program is loaded and executed by the processor to implement the physical layer verification method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that Used to store a computer program; wherein when the computer program is executed by a processor, the physical layer verification method according to any one of claims 1 to 4 is implemented.

Images