A system-on-chip verification method and system

Abstract

This application provides a system-level chip verification method and system. The method includes: reading a list of verification test cases; obtaining the compiler configuration file of the first verification test case to update the compilation file, which is used to compile the source code in the verification test case; for each source code, generating a corresponding executable file through the compilation file, with each source code corresponding to a design under test (DUT); sending the executable file to a verification platform and generating a DUT verification environment with the same number of source codes as the configuration file; finally, compiling and simulating the verification platform and environment, and verifying the chip based on the simulation results. This application can improve the flexibility, efficiency, and versatility of chip verification, and ensure the reliability and accuracy of the verification process.

Description

Technical Field

[0001] This application relates to the field of chip testing technology, and in particular to a system-level chip verification method and system. Background Technology

[0002] In the rapidly evolving semiconductor industry, the increasing complexity of chip design presents greater challenges to chip verification. Traditional chip verification methods often rely on manual testing and simulation, which are not only time-consuming and labor-intensive but also prone to errors, making it difficult to meet the demands 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 struggle to adapt to the verification needs of chip designs of different sizes and interfaces. Furthermore, existing verification processes are often inefficient, especially when dealing with large-scale, highly complex chip designs, resulting in excessively long verification cycles and high costs. In addition, with the continuous advancement of storage technology, chips may need to interact with various storage media, and existing verification methods often lack sufficient consideration of the differences in storage media, leading to inaccurate verification results. Moreover, how to effectively load and verify programs for chips without processors is also a problem that urgently needs to be solved. Summary of the Invention

[0004] In view of this, embodiments of this 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 this application embodiment is implemented as follows:

[0006] In a first aspect, embodiments of this application provide a system-on-a-chip verification method, the method comprising:

[0007] Read the list of verification test cases, obtain the compiler configuration file of the first verification test case in the 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 test case;

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

[0009] The executable file corresponding to each of the generated source codes is sent to the verification platform, and a verification environment is generated according to the verification platform configuration file; wherein, the verification environment includes DUTs with the same number 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] Secondly, embodiments of this application also provide a system-on-a-chip verification system, wherein the system-on-a-chip verification system performs the system-on-a-chip verification method described in any one of the first aspects to verify the chip.

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

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

[0014] This application allows for flexible configuration of the number of instantiated systems under test (SUTs) and their interface connections in the top layer of the verification platform. This feature greatly enhances the adaptability of the verification platform, enabling it to easily meet the verification needs of chip designs of different sizes and with different interfaces.

[0015] (2) Running the test program across storage media:

[0016] The embodiments of this application enable test programs to run on different storage media and to flexibly switch between them to simulate the same use case. This functionality is crucial for evaluating the impact of storage media on chip performance, and also provides developers with more testing options and convenience.

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

[0018] This application provides convenient tools and methods for viewing and evaluating simulation results. This not only helps verification engineers quickly locate problems, but also improves the accuracy and efficiency of verification.

[0019] (4) Intuitive confirmation of functional coverage:

[0020] The embodiments of this application can intuitively confirm the covered functions. This feature allows verification engineers to clearly understand the verification progress and results, thereby enabling them to optimize verification strategies more effectively.

[0021] (5) Highly efficient automated verification process:

[0022] In this embodiment of the application, after the system-level use case development is completed, the subsequent verification process is automatically completed by scripts. This automated process significantly improves verification efficiency, reduces human intervention and errors, and makes the verification process more reliable and efficient.

[0023] (6) Enhanced versatility:

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

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1a These are prior art schematic diagrams provided in the embodiments of this application;

[0027] Figure 1b This is a schematic diagram of the system-on-a-chip verification provided in an embodiment of this application;

[0028] Figure 2 This is a flowchart illustrating steps S201-S204 provided in the embodiments of this application;

[0029] Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application;

[0030] Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application;

[0031] Figure 5 This is a flowchart illustrating steps S501-S503 provided in the embodiments of this application;

[0032] Figure 6 This is a flowchart illustrating steps S601-S602 provided in the embodiments of this application;

[0033] Figure 7 This is a flowchart illustrating the implementation process of the system-on-a-chip verification method provided in this application. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0035] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is 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] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0037] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this 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 this application to indicate the presence 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 commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit this application.

[0040] When implementing the embodiments of this application, the applicant discovered the following problems with the prior art:

[0041] Please see Figure 1a , Figure 1a Figure 1 shows a schematic diagram of the prior art provided in this application embodiment. Verification test cases or assembly verification test cases are compiled into BIN or DAT format files by the IDE compilation environment. According to the linker configuration in the compiler, the generated data is stored at the corresponding address on the corresponding storage medium. The SOC chip's BOOTROM executes the program from this address based on the embedded BOOT program. The program performs functional correctness checks or uses a checker component to determine the results.

[0042] Verification test cases are developed using C or assembly language. To improve readability, drivers are developed in the early stages of the project. The advantages are: firstly, the program is closer to the customer's specifications and can construct relatively complex applications; secondly, using this environment facilitates the direct use of customer-provided executable files or prototype verification test cases for problem localization; thirdly, it facilitates netlist-level simulation and peak or typical application power consumption evaluation; and finally, it facilitates chip performance evaluation.

[0043] However, 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 this invention, different system verification environments can be automatically constructed for each application scenario through environment configuration files for each verification case, such as configuring C language compilation options, modifying linker files, and determining the number of DUTs and their interface connections in the verification platform.

[0044] In existing technical solutions, besides observing waveforms, there is no more convenient way to verify whether certain system-level functions of interest to verification personnel have been verified or whether the construction of certain verification test cases conforms to the intentions of test case developers. This invention incorporates functional coverage and assertion coverage into the system-level verification platform, statistically analyzing the coverage of these functions to ensure the correctness of the development of verification test cases.

[0045] In view of this, embodiments of this application provide a system-on-a-chip verification method, please refer to... Figure 1b and Figure 2 , Figure 1b This is a schematic diagram of the system-on-a-chip verification provided in an embodiment of this application. Figure 2 This is a flowchart illustrating steps S201-S204 of the system-on-a-chip verification method provided in this application embodiment, which will be combined with... Figure 1b and Figure 2 Steps S201-S204 are explained below.

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

[0047] The first part is the compiler configuration file ide_cfg, which is mainly used to configure the linker file, program storage medium, and starting address required for this verification test case. Based on this configuration, the compilation environment generates a BIN executable file or a DAT data file from 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 in the top-level top.sv, the connection between the interfaces of each DUT, whether to mount EPROM / SDRAM / JTAG drivers, etc. The connection method is maintained through an Excel spreadsheet.

[0049] The third part is the system-level verification test case code, implemented in C or assembly, used to verify specific functions. If multiple SOCs are involved, multiple source files are required.

[0050] The fourth part is the checker, which is used to evaluate the execution results of the functional verification program. If the program can automatically determine its correctness, specific information is written to the last address of SRAM, and the checker uses this information to determine whether the program executed successfully or failed. If the program itself cannot determine this automatically, assertions are added. The checker is also used to collect key printed information from the verification program, such as parameters used for performance analysis. In addition, the checker also contains the expected results after the program execution is completed, used to check whether the actual execution results of the design under test are consistent with the expected results.

[0051] The fifth part consists of the coverage collector. This collector gathers functional coverage and assertion coverage to ensure that the desired functionalities or combinations of functionalities have been covered. The system platform has only one overall coverage collector; at the start of system-level verification, all system verification test cases' covergroups are integrated into this component.

[0052] The following will explain the specific steps.

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

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

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

[0056] Here, the compilation files include linker files and compiler scripts, which together define how the source code is compiled into executable files and how these executable files are associated with the design under test (DUT). The linker file is a crucial component of the compilation process; its primary responsibility is to link the compiled object files (usually .o or .obj files) together to form an executable file. The compiler script defines the specific rules for compilation and linking, dependencies, and how the object files are generated.

[0057] In step S202, for each source code in the at least one source code, the compilation file is used to compile each source code 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 test case, the updated compilation file is used for compilation. Each source code file corresponds to a design under test (DUT), i.e., 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 the 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 into machine code (i.e., object files). After compilation, the linker links all object files (and any library files that may be needed) together according to the information in the linker file to generate the final executable file (such as a BIN file) or 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 executable file corresponding to each of the generated source codes is sent to the verification platform, and a verification environment is generated according to the verification platform configuration file; wherein, the verification environment includes DUTs with the same number as the at least one source code.

[0060] Here, all generated executable files are sent to the verification platform. Based on the verification platform's configuration file, a DUT verification environment (the top level of the verification platform) is generated, matching the number of source code files. This means that each source code file will correspond to one 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, perform simulations, simulate the behavior of the chip in actual operation, and verify the chip design based on the simulation results, including checking whether the chip works as expected and whether it meets the design requirements.

[0063] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S302 provided in the embodiments of this application. The method further includes steps S301-S302, which will be explained in conjunction with each step.

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

[0065] In step S302, based on the connection configuration file, a connection is made to the DUTs that have an interactive relationship in the verification environment.

[0066] Here, the connection configuration file is a crucial file, defining the connection methods and interaction relationships between the various DUTs in the verification environment. This file typically contains the following information:

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

[0068] Interaction relationships: Define how each DUT connects and communicates with each other, including signal type, direction, connection method, etc.

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

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

[0071] In some embodiments, see Figure 4 , Figure 4 This is a flowchart illustrating steps S401-S403 provided in the embodiments of this application. The method further includes steps S401-S403, which will be explained in conjunction with each step.

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

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

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

[0075] First, it's necessary to identify which Design Underlying Units (DUTs) do not contain processors or have specified external connections. This is typically determined by examining the DUT's design documentation or verification requirements. For these specific DUTs, the external connection relationships need to be determined based on their external connection requirements. This may include determining the types, number, connection methods (e.g., parallel, serial), and communication protocols of the external modules that need to be connected. The determined external connection relationships are then written into and the connection configuration file is updated. This ensures that the verification environment accurately reflects the external connection requirements of these specific DUTs.

[0076] Prepare the necessary external modules based on the updated connection profile. These modules include EPROM (Programmable Read-Only Memory), SDRAM (Synchronous Dynamic Random Access Memory), JTAG drivers (for debugging and testing), etc. Connect the external modules to the specific DUT based on the updated connection profile, specifically involving physical connections (e.g., via sockets, cables, or buses) or logical connections (e.g., via software interfaces or communication protocols). After connection, perform a series of checks and tests to ensure that the connection between the external modules and the specific DUT is correct and that communication and data transfer can proceed as expected.

[0077] In some embodiments, see Figure 5 , Figure 5 This is a flowchart illustrating steps S501-S503 provided in the embodiments of this application. The method further includes steps S501-S503, which will be explained in conjunction 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 by a single DUT or multiple DUTs working together.

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

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

[0081] First, it's necessary to clarify the chip's verification requirements, which typically stem from the chip's design specifications, functional requirements, and performance metrics. Based on these requirements, identify at least one function that needs verification. These functions may be implemented by a single DUT (Design Under Test) or by multiple DUTs working in tandem. For example, one function might be the computing power of a single processor, while another might be the communication capability between multiple processors.

[0082] For each defined function, corresponding verification test case code is constructed. The verification test case code is specifically designed to verify whether a particular function works as expected. Each verification test case code corresponds to a function, ensuring the completeness and accuracy of the verification. A one-to-one correspondence is established between the verification test case code and the function, meaning that each function has a corresponding verification test case code to verify whether that function meets the design requirements.

[0083] In the simulation environment, each verification test case code is run. The simulation environment mimics the actual operating environment of the chip, including hardware and software resources. After running the verification test case code, simulation results are collected. These results may include test data, performance metrics, error messages, etc. The simulation results are then analyzed to evaluate whether the function works as expected. Based on the analysis results, it is determined 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 This is a flowchart illustrating steps S601-S602 provided in the embodiments of this application. The method further includes steps S601-S602, which will be explained in conjunction with each step.

[0085] In step S601, an inspector is constructed based on the inspector configuration file; wherein, the inspector is used to judge the execution result of the functional verification program, which 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 a correctness judgment and key parameter information; if the functional verification program can automatically perform a correctness judgment, specific information is written to the last address of the storage medium; if the functional verification program cannot automatically perform 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.

[0087] Here, the checker is first constructed based on the checker configuration file. This configuration file defines the checker's behavior, rules, and the types of information to be collected. The checker's main function is to evaluate the execution results of functional verification procedures. These functional verification procedures may be implemented by a single DUT (Design Under Test) or multiple DUTs working in tandem.

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

[0089] Automatic correctness check: If the functional verification program can automatically perform a correctness check, the checker will write specific information to the last address of the storage medium. This usually means that the functional verification program has successfully completed its task and the result is as expected.

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

[0091] The checker evaluates the execution results of the functional verification procedure based on specific information written to the storage medium or added assertions. The checker also includes expected information to detect whether the execution results match the desired results. This information is typically defined when the checker is built and is used to compare with the collected execution results.

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

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

[0094] Based on the storage path of each verification test case, the coverage collection component for each verification test case is located, and the coverage collection component for each verification test case is integrated into the coverage collector of the verification platform.

[0095] The method further includes:

[0096] The coverage collector collects functional coverage and assertion coverage; wherein, the functional coverage represents the coverage that the functional verification program can automatically perform correctness judgment, and the assertion coverage represents the coverage that the functional verification program cannot automatically perform correctness judgment.

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

[0098] Here, the system first iterates through the list of verification test cases. For each test case, the system needs to determine its specific storage location. The storage path involves a file system, database, or other storage system, depending on the configuration of the verification environment. Based on the storage path of each verification test case, the system further locates the coverage collection components associated with that test 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 the verification.

[0099] The identified coverage collection components will be integrated into the verification platform's coverage collector to ensure unified management and collection of coverage data during the verification process. When the verification platform runs verification test cases, the coverage collector will capture and record coverage data in real time. This includes functional coverage (coverage of functional verification programs that can automatically determine correctness) and assertion coverage (coverage of verification programs that rely on assertions to determine correctness).

[0100] The collected coverage data will be displayed through a user-friendly interface, allowing validation engineers to intuitively understand the validation 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 trends and distribution of coverage changes, helping to quickly identify weak points in the validation process and take targeted improvement measures.

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

[0102] Once the first verification case has been verified, the next verification case is obtained from the list of verification cases.

[0103] The next verification case is verified based on any of the methods described in the above embodiments until all verification cases in the verification case list have been verified.

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

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

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

[0107] Once all verification cases in the verification case list have been verified, an analysis report is provided based on the log information of all verification cases.

[0108] Here, for each verification test case in the verification test case list, the verification platform records its verification log information. This log information includes the execution time of the verification test case, the execution result, errors or warnings encountered, coverage data, etc. 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] Once all verification cases in the verification case list have been verified, the verification platform analyzes the log information of all verification cases and provides a detailed analysis report. This report aims to summarize the verification process, identify potential problems, and provide improvement suggestions. The analysis report may include a verification progress summary, coverage statistics, detailed information on errors and warnings, performance evaluation metrics, etc. It may also include in-depth analysis and solution suggestions for any issues discovered during the verification process. The analysis report can be generated by automated tools or scripts and presented to verification engineers in an easy-to-understand format (such as PDF, HTML, etc.). This allows verification engineers to quickly understand the verification results and take appropriate actions based on the recommendations in the report.

[0110] Please see Figure 7 , Figure 7 This is a flowchart illustrating the implementation process of the system-on-a-chip verification method provided in this application. The following will be combined with... Figure 7 The embodiments of this application will be described in full.

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

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

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

[0114] 3. Read the source code of the first test case. If it is C language source code, call Makefile_C; if it is assembly language, call Makefile_ASM. Since there are 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 ECC or parity checks need to be added to the data based on the function of the storage medium.

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

[0117] 6. Read the platform configuration file for this verification test case and instantiate N DUTs in the top layer of the verification platform according to the configuration. Connect multiple SOCs based on the connection configuration table file received by the DUTs. External storage or JTAG drives can be instantiated and connected as needed.

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

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

[0120] 9. Repeat steps 3 to 8 above for the next verification test case until all verification test cases have been simulated.

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

[0122] 11. Statistical coverage.

[0123] In the above technical solution, the number of instantiations of the system under test and their interface connections in the top layer of the verification platform can be flexibly configured through implementation process 6.

[0124] By implementing processes 2 and 4, test programs can be run on different storage media. If there is a need to simulate the same use case on 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 this invention, once the system-level use case development is complete, all subsequent verification processes are automatically completed by scripts, significantly improving verification efficiency. For chips without processors, programs can also be loaded via JTAG or other interfaces, greatly enhancing versatility.

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

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

[0130] This application allows for flexible configuration of the number of instantiated systems under test (SUTs) and their interface connections in the top layer of the verification platform. This feature greatly enhances the adaptability of the verification platform, enabling it to easily meet the verification needs of chip designs of different sizes and with different interfaces.

[0131] (2) Running the test program across storage media:

[0132] The embodiments of this application enable test programs to run on different storage media and to flexibly switch between them to simulate the same use case. This functionality is crucial for evaluating the impact of storage media on chip performance, and also provides developers with more testing options and convenience.

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

[0134] This application provides convenient tools and methods for viewing and evaluating simulation results. This not only helps verification engineers quickly locate problems, but also improves the accuracy and efficiency of verification.

[0135] (4) Intuitive confirmation of functional coverage:

[0136] The embodiments of this application can intuitively confirm the covered functions. This feature allows verification engineers to clearly understand the verification progress and results, thereby enabling them to optimize verification strategies more effectively.

[0137] (5) Highly efficient automated verification process:

[0138] In this embodiment of the application, after the system-level use case development is completed, the subsequent verification process is automatically completed by scripts. This automated process significantly improves verification efficiency, reduces human intervention and errors, and makes the verification process more reliable and efficient.

[0139] (6) Enhanced versatility:

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

[0141] This application also provides a system-on-a-chip verification system, which performs the methods described in the above embodiments to verify the chip.

[0142] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system described above can be referred to the corresponding process in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, 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 displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

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

[0144] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0145] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A system-on-a-chip verification method, characterized in that, The method includes: Read the list of verification test cases, obtain the compiler configuration file of the first verification test case in the 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 test case; For each source code in the at least one source code, the compilation file is used to compile each source code to generate an executable file corresponding to each source code; wherein each source code corresponds to a design under test (DUT). The executable file corresponding to each of the generated source codes is sent to the verification platform, and a verification environment is generated according to the verification platform configuration file; wherein, the verification environment includes DUTs with the same number 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; The method further includes: The connection configuration file is determined based on the verification requirements; wherein, the connection configuration file represents the interaction relationship between different DUTs; the connection configuration file includes a list of DUTs, interaction relationships, and configuration parameters; Based on the connection configuration file, connections are made to the DUTs that have interactive relationships in the verification environment.

2. The method according to claim 1, characterized in that, The method further includes: If a particular DUT does not include a processor and / or the particular DUT specifies external connections, the external connection relationship is determined based on the external connection requirements of the particular DUT; Write the external connection relationships into and update the connection configuration file; External modules are connected to the specific DUT based on the updated connection profile, wherein the external modules include at least one of EPROM, SDRAM, and JTAG driver.

3. The method according to claim 1, characterized in that, The chip verification based on simulation results includes: At least one function is determined based on the verification requirements; wherein, each of the at least one function is implemented through a single DUT or multiple DUTs working together. For each of the at least one function, construct a number of verification test case codes equal to the number of the at least one function; wherein each verification test case code corresponds to verifying one function, and there is a one-to-one correspondence between the verification test case codes and the at least one function; The at least one function is verified based on the verification test case code.

4. The method according to claim 1, characterized in that, The method further includes: The inspector is built based on the inspector configuration file; wherein, the inspector is used to judge the execution result of the functional verification program, which is implemented by a single DUT or multiple DUTs in linkage; The execution results are collected by the inspector; wherein, the execution results include 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 inspector judges and collects the execution results based on the specific information or the assertion; the inspector also includes expected information for detecting whether the execution results are consistent with the expected results.

5. The method according to claim 4, characterized in that, After reading the list of validation test cases and before obtaining the compiler configuration file of the first validation test case in the list of validation test cases, the method further includes: Locate the storage path of each verification case in the verification case list; Based on the storage path of each verification test case, the coverage collection component for each verification test case is located, and the coverage collection component for each verification test case is integrated into the coverage collector of the verification platform. The method further includes: The coverage collector collects functional coverage and assertion coverage; wherein, the functional coverage represents the coverage that the functional verification program can automatically perform correctness judgment, and the assertion coverage represents the coverage that the functional verification program cannot automatically perform correctness judgment. The functional coverage and assertion coverage are displayed through a human-computer interaction interface; wherein, the display method includes visual charts and / or text.

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

7. The method according to claim 1, characterized in that, The method further includes: Once the first verification case has been verified, the next verification case is obtained from the list of verification cases. The next verification case is verified based on the method described in any one of claims 1-6 until all verification cases in the verification case list have been verified.

8. The method according to any one of claims 1-6, characterized in that, The method further includes: For each verification case in the verification case list, record verification log information; Once all verification cases in the verification case list have been verified, an analysis report is provided based on the log information of all verification cases.

9. A system-on-a-chip verification system, characterized in that, The system-on-a-chip verification system verifies the chip by performing the method described in any one of claims 1-8.

Images