System-on-chip verification method and system

Abstract

The invention provides a system-on-chip verification method and system.The method comprises the steps that a verification case list is read, a compiler configuration file of the first verification case is obtained to update a compiling file, and the compiling file is used for compiling source codes in the verification cases; for each source code, generating a corresponding executable file by compiling the file, each source code corresponding to one to-be-tested design DUT; sending the executable file to a verification platform, and generating DUT verification environments with the same number as the source codes according to the configuration file; and finally, compiling and simulating the verification platform and environment, and verifying the chip based on a simulation result. According to the invention, the flexibility, efficiency and universality of chip verification can be improved, and the reliability and accuracy of the verification process are ensured.

Description

Technical Field

[0001] The present application relates to the field of chip detection technology, and in particular to a system-level chip verification method and system. Background Art

[0002] In the rapidly developing semiconductor industry, the complexity of chip design is increasing, which poses a higher challenge to chip verification. Traditional chip verification methods often rely on manual testing and simulation, which is not only time-consuming and labor-intensive, but also prone to errors, and cannot meet the needs of modern chip design for efficient and accurate verification.

[0003] Existing automated verification solutions still have some limitations. For example, some verification platforms lack flexibility and are difficult to adapt to the verification needs of chip designs of different scales and interfaces. At the same time, existing verification processes are often not efficient enough, especially when dealing with large-scale, highly complex chip designs. The verification cycle is too long and the cost is high. In addition, with the continuous advancement of storage technology, chips may need to interact with a variety of storage media, and existing verification methods often lack sufficient consideration of the differences in storage media, resulting in inaccurate verification results. At the same time, for chips without processors, how to effectively load and verify programs is also an issue that needs to be solved. Summary of the invention

[0004] In view of this, the embodiments of the present application provide a system-level chip verification method and system, which can improve the flexibility, efficiency and versatility of chip verification and ensure the reliability and accuracy of the verification process.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] In a first aspect, an embodiment of the present application provides a system-level chip verification method, the method comprising:

[0007] Read the verification case list, obtain the compiler configuration file of the first verification case in the verification case list, and update the compilation file based on the compiler configuration file; wherein the compilation file is used to compile at least one source code in the verification case;

[0008] For each source code in the at least one source code, compile each source code by using the compilation file to generate an executable file corresponding to each source code; wherein each source code corresponds to a design under test (DUT);

[0009] Sending the generated executable file corresponding to each source code to a verification platform, and generating a verification environment according to a verification platform configuration file; wherein the verification environment includes the same number of DUTs as the at least one source code;

[0010] The verification platform and the verification environment are compiled and simulated, and the chip is verified based on the simulation results.

[0011] In a second aspect, an embodiment of the present application further provides a system-on-chip verification system, which executes the system-on-chip verification method described in any one of the first aspects to verify the chip.

[0012] The embodiments of the present application have the following beneficial effects:

[0013] (1)Flexible configuration of verification platform:

[0014] The embodiment of the present application allows for flexible configuration of the number of instantiations of the system under test and their interface connections in the top layer of the verification platform. This feature greatly improves the adaptability of the verification platform, enabling it to easily cope with chip design verification requirements of different scales and different interfaces.

[0015] (2) Test program running across storage media:

[0016] The embodiment of the present application enables the test program to run in different storage media and can be flexibly switched to simulate the same use case. This function is crucial for evaluating the impact of storage media on chip performance, and also provides developers with more test options and convenience.

[0017] (3) Convenient viewing and evaluation of simulation results:

[0018] The embodiments of the present application provide convenient tools and methods for viewing and evaluating simulation results, which not only helps verification engineers to quickly locate problems, but also improves the accuracy and efficiency of verification.

[0019] (4) Intuitive function coverage confirmation:

[0020] The embodiments of the present application can intuitively confirm the covered functions. This feature enables verification engineers to clearly understand the verification progress and effect, so as to optimize the verification strategy more specifically.

[0021] (5) Efficient automated verification process:

[0022] After the system-level use case development is completed, the subsequent verification process is automatically completed by the script. This automated process significantly improves the verification efficiency, reduces human intervention and errors, and makes the verification process more reliable and efficient.

[0023] (6) Enhanced versatility:

[0024] For chips without processors, the present application embodiment also provides a solution for program loading via JTAG or other interfaces. This feature makes the method not only applicable to processor chips, but also widely applicable to other types of chip designs, greatly enhancing its versatility and application scope. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0026] Figure 1a It is a schematic diagram of the prior art provided by the embodiment of the present application;

[0027] Figure 1b It is a schematic diagram of system-level chip verification provided by an embodiment of the present application;

[0028] Figure 2 It is a flowchart of steps S201-S204 provided in an embodiment of the present application;

[0029] Figure 3 It is a flowchart of steps S301-S302 provided in an embodiment of the present application;

[0030] Figure 4 It is a flowchart of steps S401-S403 provided in an embodiment of the present application;

[0031] Figure 5 It is a flowchart of steps S501-S503 provided in an embodiment of the present application;

[0032] Figure 6 It is a flowchart of steps S601-S602 provided in an embodiment of the present application;

[0033] Figure 7 It is a diagram of the implementation process of the system-level chip verification method provided in the embodiment of the present application. DETAILED DESCRIPTION

[0034] To make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of explanation and description and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn in real proportion. The flowchart used in this application shows the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowchart can be implemented out of sequence, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art can add one or more other operations to the flowchart under the guidance of the content of the present application, or remove one or more operations from the flowchart.

[0035] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0036] In addition, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The components of the embodiments of the present application described and shown in the drawings here can be arranged and designed in various configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the application claimed for protection, but merely represents the selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without making creative work belong to the scope of protection of the present application.

[0037] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0038] It should be noted that the term "comprising" will be used in the embodiments of the present application to indicate the existence of the features declared thereafter, but does not exclude the addition of other features.

[0039] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0040] When implementing the embodiments of the present application, the applicant discovered that the prior art has the following problems:

[0041] See also Figure 1a , Figure 1a It is a prior art schematic diagram provided by an embodiment of the present application. As shown in FIG1 , a verification case or an assembly verification case generates a BIN file or a DAT format file through an IDE compilation environment. According to the link file configuration in the compiler, the generated data is stored in the corresponding address of the corresponding storage medium. The BOOTROM of the SOC chip starts executing the program from this address according to the solidified BOOT program. The correctness of the function will be judged in the program, or the checker component will be used to judge the result.

[0042] Verification cases are developed using C language or assembly language. To improve the readability of the cases, drivers are developed in the early stages of the project. The advantage is that the program is closer to the customer and can construct more complex applications. Secondly, using this environment, it is convenient to directly use the customer's executable files or prototype verification test cases to locate problems. Thirdly, it is convenient for netlist-level simulation and peak or typical application power consumption evaluation. Finally, it is convenient for chip performance evaluation.

[0043] However, the existing technical solutions lack flexibility for complex verification scenarios, such as BOOT function verification and performance evaluation of different storage media, verification of different numbers of DUTs, and interface connections between DUTs in different verification scenarios. In the present invention, different system verification environments can be automatically constructed for each application scenario through the environment configuration file of each verification use case, such as the configuration of C language compilation options, modification of link files, and the number of DUTs in the verification platform and the interface connections between them.

[0044] In the existing technical solutions, there is no more convenient way to determine whether certain system-level functions that the verification personnel are concerned about have been verified or whether the construction of certain verification cases meets the intention of the test case developer, except observing the waveform. In the present invention, by adding function coverage and assertion coverage to the system-level verification platform, the coverage of these functions is counted to ensure the correctness of the development of verification cases.

[0045] In view of this, the present application embodiment provides a system-level chip verification method, see Figure 1b and Figure 2 , Figure 1b is a schematic diagram of system-level chip verification provided by an embodiment of the present application, Figure 2 is a flow chart of steps S201-S204 of the system-level chip verification method provided in the embodiment of the present application, which will be combined with Figure 1b and Figure 2 Steps S201-S204 are shown for explanation.

[0046] like Figure 1b As shown, the system-level verification use case in the embodiment of the present application consists of five parts:

[0047] The first part is the compiler configuration file ide_cfg, which is mainly used to configure the link file, program storage medium and starting address required by this verification case. According to this configuration, the compilation environment generates a BIN executable file or a DAT data file based on the C or assembly test file.

[0048] The second part is the verification platform configuration file tb_cfg, which is mainly used to configure the number of DUTs to be tested in the top level of top.sv, the connection between each DUT interface, whether to mount EPROM / SDRAM / JTAG driver, etc. The connection method is maintained through an Excel spreadsheet.

[0049] The third part is the system-level verification use case code, which is implemented in C or assembly and is used to verify specific functions. If it involves the linkage of multiple SOCs, multiple source files are required.

[0050] The fourth part is the checker, which is used to judge the execution results of the functional verification program. If the program can automatically judge the correctness, specific information is written to the last address of the SRAM, and the checker will judge the success or failure of the program execution based on this information. If the program itself cannot automatically judge, add assertions. The checker is also used to collect key print information in the verification program, such as parameters for performance analysis. In addition, the checker also contains the expected results after the program is executed, which is used to check whether the actual execution results of the design under test are consistent with the expected results.

[0051] The fifth part is the coverage collector. It is used to collect functional coverage and assertion coverage to ensure that the expected function points or function point combinations have been covered. The system platform has only one overall coverage collector. At the beginning of system-level verification, all the covergroups of system verification use cases are integrated into this component.

[0052] The following will explain it with reference to specific steps.

[0053] In step S201, read the verification case list, obtain the compiler configuration file of the first verification case in the verification case list, and update the compilation file based on the compiler configuration file; wherein the compilation file is used to compile at least one source code in the verification case.

[0054] Here, verification cases are read from a predefined list. These verification cases contain different test scenarios and conditions. For the first verification case in the list, its corresponding compiler configuration file is obtained. The configuration file is used to update the compilation file to ensure that the compilation process meets the specific requirements and specifications.

[0055] Specifically, the compilation file includes a link file and a compilation script; wherein the link file is used to link the compiled target file into an executable file, and the compilation script is used to define the compilation and linking rules, dependencies and the target file.

[0056] Here, the compilation files include link files and compilation scripts, which together define how to compile source code into executable files and how these executable files are associated with the design under test (DUT). The link file is an important part of the compilation process. Its main responsibility is to link the compiled target files (usually .o or .obj files) together to form an executable file. The compilation script defines the specific rules, dependencies, and generation methods of the target files for compilation and linking.

[0057] In step S202, for each source code in the at least one source code, each source code is compiled by the compilation file to generate an executable file corresponding to each source code; wherein each source code corresponds to a design under test (DUT).

[0058] Here, for at least one source code file in the verification case, the updated compilation file is used to compile separately. Each source code file corresponds to a design under test (DUT), that is, the chip design part that needs to be verified. After compilation, an executable file corresponding to each source code is generated. Specifically, the compilation environment first reads the compilation script to obtain all the information required for compilation, including a list of source files, compiler options, dependencies, etc. For each source code file, the compilation environment calls the specified compiler and compiles it according to the options in the compilation script. This process converts the source code into assembly code, and then further converts it into machine code (i.e., target file). After the compilation is completed, the linker will link all target files (and possible library files) together according to the information of the link file to generate the final executable file (such as a BIN file) or a data file (such as a DAT file). Depending on the verification requirements, the compilation environment may generate an executable file (for running tests on the verification platform) or a data file (for use as input or reference data).

[0059] In step S203, the generated executable file corresponding to each source code is sent to a verification platform, and a verification environment is generated according to a verification platform configuration file; wherein the verification environment includes the same number of DUTs as the at least one source code.

[0060] Here, all generated executable files are sent to the verification platform, and according to the verification platform configuration file, the same number of DUT verification environments (verification platform top level) as the source code are generated. This means that each source code file will correspond to a verification environment.

[0061] In step S204, the verification platform and the verification environment are compiled and simulated, and the chip is verified based on the simulation results.

[0062] Here, the verification platform and verification environment are compiled to ensure that they can run correctly in the simulation environment, and simulation is performed to simulate the behavior of the chip in actual work. Based on the simulation results, the design of the chip is verified, including checking whether the chip works as expected and whether it meets the design requirements.

[0063] In some embodiments, see Figure 3 , Figure 3 It is a flowchart of steps S301-S302 provided in an embodiment of the present application. The method also includes steps S301-S302, which will be described in combination with each step.

[0064] In step S301, a connection profile is determined based on verification requirements; wherein the connection profile represents the interaction relationship between different DUTs.

[0065] In step S302, based on the connection configuration file, the DUTs having an interactive relationship in the verification environment are connected.

[0066] Here, the connection configuration file is a key file that defines the connection mode and interaction relationship between various DUTs in the verification environment. This file usually contains the following information:

[0067] DUT List: Lists all DUTs that need to be connected in the verification environment.

[0068] Interaction relationship: defines how each DUT connects and communicates with each other, including the type, direction, and connection method of the signal.

[0069] Configuration parameters: Provide specific parameters required for the connection, such as clock frequency, communication protocol, data format, etc.

[0070] Once the connection profile is defined and confirmed, the verification environment can automatically or manually connect each DUT based on this file. First, the verification environment parses the connection profile and extracts information such as the DUT list, interaction relationships, and configuration parameters. Based on the information in the connection profile, the verification environment configures the corresponding hardware and software resources, including setting up communication interfaces, allocating memory space, etc. Based on the interaction relationships, the verification environment connects each DUT. This may involve physical connections (such as through cables or buses) or logical connections (such as through software interfaces or communication protocols). After the connection is completed, the verification environment also needs to perform a series of checks and tests to ensure that the connections between all DUTs are correct and can communicate as expected.

[0071] In some embodiments, see Figure 4 , Figure 4 It is a flowchart of steps S401-S403 provided in an embodiment of the present application. The method also includes steps S401-S403, which will be described in combination with each step.

[0072] In step S401, if the specific DUT does not include a processor and / or the specific DUT specifies an external connection, an external connection relationship is determined based on an external connection requirement of the specific DUT.

[0073] In step S402, the external connection relationship is written into and updated in the connection configuration file.

[0074] In step S403, an external module is connected to the specific DUT based on the updated connection configuration file, wherein the external module includes at least one of EPROM, SDRAM, and JTAG driver.

[0075] Here, first you need to identify which DUTs do not contain a processor or specify external connections, which is usually determined by checking the design documents or verification requirements of the DUT. For these specific DUTs, you need to determine the external connection relationship based on their external connection requirements. This may include determining the type, quantity, connection method (such as parallel, serial), communication protocol, etc. of the external modules that need to be connected. Write the determined external connection relationship into and update the connection configuration file. This ensures that the verification environment accurately reflects the external connection requirements of these specific DUTs.

[0076] According to the updated connection profile, prepare the corresponding external modules. These modules include EPROM (Programmable Read Only Memory), SDRAM (Synchronous Dynamic Random Access Memory), JTAG driver (for debugging and testing), etc. Based on the updated connection profile, connect the external module to the specific DUT, which specifically involves physical connection (such as through a socket, cable or bus) or logical connection (such as through a software interface or communication protocol). After the connection is completed, a series of checks and tests are performed to ensure that the connection between the external module and the specific DUT is correct and that communication and data transmission can be carried out as expected.

[0077] In some embodiments, see Figure 5 , Figure 5 It is a flowchart of steps S501-S503 provided in an embodiment of the present application. The method also includes steps S501-S503, which will be described in combination with each step.

[0078] In step S501, at least one function is determined based on verification requirements; wherein each of the at least one function is implemented through a single DUT or multiple DUTs in linkage.

[0079] In step S502, for each of the at least one function, verification case codes equal in number to the at least one function are constructed; wherein each verification case code corresponds to verifying one function, and the verification case codes correspond one-to-one to the at least one function.

[0080] In step S503, the at least one function is verified based on the verification case code.

[0081] Here, we first need to clarify the verification requirements of the chip, which usually come from the chip's design specifications, functional requirements, performance indicators, etc. According to the verification requirements, identify at least one function that needs to be verified. These functions may be implemented by a single DUT (design under test) or by multiple DUTs working together. For example, one function may be the computing power of a single processor, while another function may be the communication capability between multiple processors.

[0082] For each identified function, build the corresponding verification case code. The verification case code is specially designed to verify whether a specific function works as expected. Each verification case code corresponds to a function to ensure the completeness and accuracy of the verification. A one-to-one correspondence is established between the verification case code and the function, which means that each function has a corresponding verification case code to verify whether the function meets the design requirements.

[0083] Run each verification case code in the simulation environment. The simulation environment simulates the actual working environment of the chip, including hardware and software resources. After running the verification case code, collect the simulation results. These results may include test data, performance indicators, error information, etc. Then, analyze the simulation results to evaluate whether the function works as expected. Based on the analysis results, determine whether each function has passed verification. If the function meets the design requirements, the verification passes; otherwise, the verification fails.

[0084] In some embodiments, see Figure 6 , Figure 6 It is a flowchart of steps S601-S602 provided in an embodiment of the present application. The method also includes steps S601-S602, which will be described in combination with each step.

[0085] In step S601, a checker is constructed based on a checker configuration file; wherein the checker is used to judge the execution result of a functional verification program, and the functional verification program is implemented by a single DUT or multiple DUTs in linkage.

[0086] In step S602, the execution result is collected by the checker; wherein the execution result includes whether the functional verification program can automatically perform correctness judgment and key parameter information; if the functional verification program can automatically perform correctness judgment, specific information is written to the last address of the storage medium; if the functional verification program cannot automatically perform correctness judgment, an assertion is added; the checker judges and collects the execution result based on the specific information or the assertion; the checker also includes expected information for detecting whether the execution result is consistent with the expected result.

[0087] Here, we first build the checker based on the checker configuration file. This configuration file defines the checker's behavior, rules, and the type of information that needs to be collected. The main function of the checker is to judge the execution results of the functional verification program. These functional verification programs may be implemented by a single DUT (design under test) or multiple DUTs in conjunction.

[0088] The execution results collected by the checker include whether the functional verification program can automatically make correctness judgments and key parameter information.

[0089] Automatic Correctness Judgment: If the functional verifier is able to automatically make a correctness judgment, the checker will write specific information at the last address of the storage medium. This usually means that the functional verifier has successfully completed its task and the results are as expected.

[0090] Add assertions: If the functional verifier cannot automatically determine correctness, the checker adds assertions. An assertion is an explicit statement that specifies that a condition must be true in order for the functional verifier to be considered successful.

[0091] The checker determines the execution result of the functional verification program based on specific information written on the storage medium or added assertions. The checker also includes expected information for detecting whether the execution result is consistent with the expected result. This information is usually defined when building the checker and is used to compare with the collected execution results.

[0092] In some embodiments, after reading the verification case list and before obtaining a compiler configuration file for a first verification case in the verification case list, the method further includes:

[0093] Find the storage path of each verification case in the verification case list;

[0094] Finding the coverage collection component of each verification case based on the storage path of each verification case, and integrating the coverage collection component of each verification case into the coverage collector of the verification platform;

[0095] The method further comprises:

[0096] Collecting functional coverage and assertion coverage based on the coverage collector; wherein the functional coverage represents the coverage of the functional verification program that can automatically make a correctness judgment, and the assertion coverage represents the coverage of the functional verification program that cannot automatically make a correctness judgment;

[0097] The function coverage and the assertion coverage are displayed through a human-computer interaction interface; wherein the display method includes visual charts and / or text.

[0098] Here, we first traverse the list of verification cases. For each verification case, the system needs to determine the specific location where it is stored. The storage path involves the file system, database, or other storage system, depending on the configuration of the verification environment. Based on the storage path of each verification case, the system further locates the coverage collection components associated with the verification case. These components are responsible for capturing and recording coverage information during the verification process and are key tools for evaluating the comprehensiveness and effectiveness of verification.

[0099] The found coverage collection components will be integrated into the coverage collector of the verification platform to ensure that coverage data can be uniformly managed and collected during the verification process. When the verification platform runs the verification case, the coverage collector will capture and record the coverage data in real time, including functional coverage, that is, the coverage of the functional verification program that can automatically determine the correctness, and assertion coverage, that is, the coverage of the verification program that needs to rely on assertions to determine the correctness.

[0100] The collected coverage data will be displayed through the human-computer interaction interface so that verification engineers can intuitively understand the verification progress and results. The display methods can be diverse, including visual charts (such as bar charts, pie charts, line charts, etc.) and / or text descriptions to meet the needs and preferences of different users. Visual charts can intuitively present the coverage trend and distribution, which helps to quickly locate the weak links in verification and take targeted improvement measures.

[0101] In some embodiments, the method further comprises:

[0102] When the verification of the first verification case is completed, obtaining the next verification case from the verification case list;

[0103] The next verification case is verified based on the method described in any one of the above embodiments until all verification cases in the verification case list are verified.

[0104] Here, when the verification platform completes the verification of the first verification case, this marks the end of the current verification phase. The verification platform then retrieves the next case to be verified from the verification case list. For each new verification case retrieved from the list, the verification platform repeats the verification process described previously, which includes reading the compiler configuration file of the verification case, building the checker, collecting execution results, judging correctness, integrating coverage collection components, and collecting and displaying coverage. The above verification process will continue until all cases in the verification case list have been verified. This ensures the comprehensiveness and completeness of the verification, which helps to ensure the accuracy and reliability of the chip design.

[0105] In some embodiments, the method further comprises:

[0106] For each verification case in the verification case list, record verification log information;

[0107] When all verification cases in the verification case list are verified, analysis is performed based on the log information of all verification cases and an analysis report is provided.

[0108] Here, for each verification case in the verification case list, the verification platform will record its verification log information. This log information includes the execution time, execution results, errors or warnings encountered, coverage data, etc. of the verification case. Verification logs are usually stored in specific log files or managed and accessed through a database. In this way, verification engineers can access this log information at any time for subsequent analysis and debugging.

[0109] When all verification cases in the verification case list are verified, the verification platform will analyze the log information of all verification cases and provide a detailed analysis report. This report is designed to summarize the verification process, point out potential problems, and provide suggestions for improvement. The analysis report may include a summary of the verification progress, coverage statistics, detailed information on errors and warnings, performance evaluation indicators, etc. It can also contain in-depth analysis and solution suggestions for any problems found during the verification process. The analysis report can be generated by automated tools or scripts and presented to the verification engineer in an easy-to-understand format (such as PDF, HTML, etc.). In this way, the verification engineer can quickly understand the verification results and take appropriate actions based on the suggestions in the report.

[0110] See also Figure 7 , Figure 7 This is a diagram of the implementation process of the system-level chip verification method provided in the embodiment of the present application. Figure 7 The embodiments of the present application are fully described.

[0111] like Figure 7As shown, in a complete implementation:

[0112] 1. The Python script tb_gen.py reads the verification case list, finds the coverage collection component for each CASE according to the verification case storage path, and integrates it into the platform's total coverage collector top_cov.sv.

[0113] 2. Read the verification case list, read the compiler configuration file of the first case, and update the link file and compilation script.

[0114] 3. Read the source code of the first use case. If it is C language source code, call Makefile_C. If it is assembly language, call Makefile_ASM. According to the multiple source codes corresponding to multiple DUTs, compile them separately to generate executable BIN files or data DAT files casename_1.bin, casename_2.bin,..., casename_n.bin and casename_1.dat, casename_2.dat,..., casename 3.dat.

[0115] 4. Determine whether to add ECC or parity check to the data based on the function of the storage medium.

[0116] 5. Move the data to the designated location to facilitate platform use and initialize the DUT storage medium.

[0117] 6. Read the platform configuration file of this verification case, and instantiate N DUTs in the top level of the verification platform according to the configuration. And connect multiple SOCs according to the DUT receiving connection configuration table file. If needed, you can instantiate and connect external storage or JTAG driver.

[0118] 7. Read the checker configuration file and construct the checker for this verification case.

[0119] 8. Use EDA software to compile the verification platform and DUT, then run the simulation and save the simulation log and checker log.

[0120] 9. Repeat the above 3 to 8 processes for the next verification case until all verification cases are simulated.

[0121] 10. Extract logs and summarize success and failure information.

[0122] 11. Statistical coverage.

[0123] In the above technical solution, by implementing process 6, the number of instantiations of the system to be tested in the top layer of the verification platform and their interface connections can be flexibly configured.

[0124] By implementing processes 2 and 4, the test program can be run in different storage media. If there is a need to simulate the same use case for different storage media, this technical solution can be flexibly switched.

[0125] By implementing steps 7 and 8, the simulation results can be easily viewed and evaluated.

[0126] By implementing process 11, the covered functions can be confirmed more intuitively.

[0127] In the present invention, after the system-level use case is developed, all subsequent verification processes are automatically completed by the script, which can significantly improve the verification efficiency. For chips without processors, programs can also be loaded through JTAG or other interfaces, and the versatility is greatly improved.

[0128] In summary, the embodiments of the present application have the following beneficial effects:

[0129] (1)Flexible configuration of verification platform:

[0130] The embodiment of the present application allows for flexible configuration of the number of instantiations of the system under test and their interface connections in the top layer of the verification platform. This feature greatly improves the adaptability of the verification platform, enabling it to easily cope with chip design verification requirements of different scales and different interfaces.

[0131] (2) Test program running across storage media:

[0132] The embodiment of the present application enables the test program to run in different storage media and can be flexibly switched to simulate the same use case. This function is crucial for evaluating the impact of storage media on chip performance, and also provides developers with more test options and convenience.

[0133] (3) Convenient viewing and evaluation of simulation results:

[0134] The embodiments of the present application provide convenient tools and methods for viewing and evaluating simulation results, which not only helps verification engineers to quickly locate problems, but also improves the accuracy and efficiency of verification.

[0135] (4) Intuitive function coverage confirmation:

[0136] The embodiments of the present application can intuitively confirm the covered functions. This feature enables verification engineers to clearly understand the verification progress and effect, so as to optimize the verification strategy more specifically.

[0137] (5) Efficient automated verification process:

[0138] After the system-level use case development is completed, the subsequent verification process is automatically completed by the script. This automated process significantly improves the verification efficiency, reduces human intervention and errors, and makes the verification process more reliable and efficient.

[0139] (6) Enhanced versatility:

[0140] For chips without processors, the embodiments of the present application also provide a solution for program loading via JTAG or other interfaces. This feature makes the method not only applicable to processor chips, but also widely applicable to other types of chip designs, greatly enhancing its versatility and application scope.

[0141] The embodiment of the present application also provides a system-on-chip verification system, which executes the method described in the above embodiment to verify the chip.

[0142] Those skilled in the art can clearly understand that, for the convenience and simplicity of description, the specific working process of the system described above can refer to the corresponding process in the method embodiment, and will not be repeated in this application. In the several embodiments provided in this application, it should be understood that the disclosed system, device and method can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation. For example, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0143] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0144] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0145] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A system-on-chip verification method, characterized in that: The method comprises: Read the verification case list, obtain the compiler configuration file of the first verification case in the verification case list, and update the compilation file based on the compiler configuration file; wherein the compilation file is used to compile at least one source code in the verification case; For each source code in the at least one source code, compile each source code by using the compilation file to generate an executable file corresponding to each source code; wherein each source code corresponds to a design under test (DUT); Sending the generated executable file corresponding to each source code to a verification platform, and generating a verification environment according to a verification platform configuration file; wherein the verification environment includes the same number of DUTs as the at least one source code; The verification platform and the verification environment are compiled and simulated, and the chip is verified based on the simulation results.

2. The method according to claim 1, characterized in that The method further comprises: Determine a connection profile based on the verification requirements; wherein the connection profile represents the interaction relationship between different DUTs; Based on the connection configuration file, the DUTs having an interactive relationship in the verification environment are connected.

3. The method according to claim 2, characterized in that The method further comprises: If the specific DUT does not include a processor and / or the specific DUT specifies an external connection, determining an external connection relationship based on an external connection requirement of the specific DUT; Writing the external connection relationship into the connection configuration file and updating it; An external module is connected to the specific DUT based on the updated connection configuration file, wherein the external module includes at least one of an EPROM, an SDRAM, and a JTAG driver.

4. The method according to claim 1, characterized in that: The verifying the chip based on the simulation result includes: Determine at least one function based on the verification requirements; wherein each of the at least one function is implemented by a single DUT or multiple DUTs in linkage; For each of the at least one function, construct verification case codes equal in number to the at least one function; wherein each verification case code verifies one function, and the verification case codes correspond to the at least one function one-to-one; The at least one function is verified based on the verification use case code.

5. The method according to claim 1, characterized in that The method further comprises: Building a checker based on a checker configuration file; wherein the checker is used to judge the execution result of a functional verification program, and the functional verification program is implemented by a single DUT or multiple DUTs in linkage; The execution result is collected by the checker; wherein the execution result includes whether the functional verification program can automatically make a correctness judgment and key parameter information; if the functional verification program can automatically make a correctness judgment, specific information is written to the last address of the storage medium; if the functional verification program cannot automatically make a correctness judgment, an assertion is added; the checker judges and collects the execution result based on the specific information or the assertion; the checker also includes expected information for detecting whether the execution result is consistent with the expected result.

6. The method according to claim 5, characterized in that After reading the verification case list and before obtaining the compiler configuration file of the first verification case in the verification case list, the method further includes: Find the storage path of each verification case in the verification case list; Finding the coverage collection component of each verification case based on the storage path of each verification case, and integrating the coverage collection component of each verification case into the coverage collector of the verification platform; The method further comprises: Collecting functional coverage and assertion coverage based on the coverage collector; wherein the functional coverage represents the coverage of the functional verification program that can automatically make a correctness judgment, and the assertion coverage represents the coverage of the functional verification program that cannot automatically make a correctness judgment; The function coverage and the assertion coverage are displayed through a human-computer interaction interface; wherein the display method includes visual charts and / or text.

7. The method according to claim 1, characterized in that The compiled file includes a link file and a compilation script; wherein the link file is used to link the compiled target file into an executable file, and the compilation script is used to define the compilation and linking rules, dependencies and the target file; the compilation environment compiles each source code based on the link file and the compilation script, and generates an executable BIN file or DAT data file corresponding to each source code.

8. The method according to claim 1, characterized in that The method further comprises: When the verification of the first verification case is completed, obtaining the next verification case from the verification case list; The next verification case is verified based on the method described in any one of claims 1 to 7 until all verification cases in the verification case list are verified.

9. The method according to any one of claims 1 to 8, characterized in that: The method further comprises: For each verification case in the verification case list, record verification log information; When all verification cases in the verification case list are verified, analysis is performed based on the log information of all verification cases and an analysis report is provided.

10. A system-on-chip verification system, characterized in that: The system-level chip verification system executes the method described in any one of claims 1 to 9 to verify the chip.

Images