System-on-chip detection method, device, equipment and medium

Abstract

The invention discloses a system-on-chip detection method, device and equipment and a medium, and relates to the technical field of computers, and the method comprises the following steps: reading scene attribute summary information of a reset matrix; based on the reset matrix scene attribute summary information, generating a test case, an assertion check file, an assertion coverage rate file and a top-layer reset starting process code of a reset scene; starting a test according to a basic environment set by the top-layer reset starting process code, and then detecting functions of the whole system on chip and the subsystem in the reset scene by using a test case of the reset scene; and verifying the detection result in the resetting process by using the assertion check file and the assertion coverage rate file. Therefore, different application scenes can be covered, errors or omission caused by manual writing can be eliminated, the time cost of handwriting detection of the component is greatly reduced, the iterative modifiability of the architecture is considered, the workload of repeated modification caused by iterative modification of cases and components is reduced, and the detection efficiency and the detection accuracy are improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and particularly to a method, device, equipment and medium for on-chip system detection. Background Art

[0002] On-chip system (SoC) detection is a series of test activities for an on-chip system. Usually, the traditional method is to manually write test components. If there are handwritten errors, multiple simulation debuggings and modifications are required; and during the iteration process, iterative modifications are made to the reset matrix name, assertion check, and module timing. This method is cumbersome and time-consuming, requires a large amount of computing resources, invests a lot of energy, wastes human and material resources, and is prone to human errors, resulting in low detection efficiency. Summary of the Invention

[0003] The object of the present invention is to provide a method, device, equipment and medium for on-chip system detection, which can eliminate errors or omissions caused by manual writing, reduce the time cost of handwritten test components, and take into account the iterative modification of the architecture, improving the detection efficiency and detection accuracy.

[0004] To solve the above technical problems, the present invention provides an on-chip system detection method, the method comprising:

[0005] Reading the summary information of the reset matrix scenario attributes;

[0006] Based on the read summary information of the reset matrix scenario attributes, generating test cases for the reset scenario, an assertion check file, an assertion coverage file, and top-level reset startup process code;

[0007] According to the basic environment set by the top-level reset startup process code, after starting the test, using the test cases of the reset scenario to detect the functions of the on-chip system as a whole and the subsystems in the reset scenario, and obtaining a detection result;

[0008] Using the assertion check file and the assertion coverage file to verify the detection result during the reset process.

[0009] To solve the above technical problems, the present invention also provides an on-chip system detection device, the device comprising:

[0010] An information reading module, configured to read the summary information of the reset matrix scenario attributes;

[0011] A code file generation module, configured to generate test cases for the reset scenario, an assertion check file, an assertion coverage file, and top-level reset startup process code based on the read summary information of the reset matrix scenario attributes;

[0012] A function detection module, which is used to start a test according to the basic environment set by the top-level reset startup process code, and then use the test cases of the reset scenario to detect the functions of the overall system-on-chip and subsystems in the reset scenario, so as to obtain a detection result;

[0013] A result verification module, which is used to verify the detection result by using the assertion check file and the assertion coverage file during the reset process.

[0014] To solve the above technical problems, the present invention also provides an electronic device, which includes:

[0015] A memory, which is used to store a computer program;

[0016] A processor, which is used to implement the steps of the above system-on-chip detection method when executing the computer program.

[0017] To solve the above technical problems, the present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above system-on-chip detection method are implemented.

[0018] As can be seen from the above technical solutions, a system-on-chip detection method provided by the present invention includes: reading summary information of reset matrix scenario attributes; generating test cases, assertion check files, assertion coverage files, and top-level reset startup process codes for the reset scenario based on the read summary information of reset matrix scenario attributes; starting a test according to the basic environment set by the top-level reset startup process code, and then using the test cases of the reset scenario to detect the functions of the overall system-on-chip and subsystems in the reset scenario, so as to obtain a detection result; verifying the detection result by using the assertion check file and the assertion coverage file during the reset process.

[0019] The beneficial effects of the present invention are as follows. For the on-chip system detection method provided by the present invention, first, the summary information of the reset matrix scenario attributes is read. Then, based on this summary information of the reset matrix scenario attributes, test cases for the reset scenario are generated, and the assertion check file, the assertion coverage file, and the top-level reset startup process code are asserted. After that, the test is started according to the basic environment set by the top-level reset startup process code. The functions of the overall on-chip system and subsystems in the reset scenario are detected through the test cases of the reset scenario. Finally, the assertion check file and the assertion coverage file are used to verify the detection results during the reset process. This can cover different application scenarios, eliminate errors or omissions caused by manual writing, improve the accuracy rate, ensure the completeness of the address allocation detection work through the analysis of the assertion coverage results, greatly reduce the time cost of handwritten detection components, eliminate human errors in manual writing at the same time, reduce the time of repeated simulation and debugging, and take into account the iterative modification of the architecture. Only the summary table needs to be iteratively refreshed, reducing the workload of repeated modification caused by iterative modification of test cases and components. The overall method reflects the reusability, efficiency, and completeness of the detection platform, improving the detection efficiency and detection accuracy.

[0020] In addition, the present invention also provides a corresponding on-chip system detection device, electronic device, and computer-readable storage medium for the on-chip system detection method, which have the same or corresponding technical features as the above-mentioned on-chip system detection method, and the effects are the same. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0022] Figure 1 It is a flowchart of the on-chip system detection method provided by the embodiment of the present invention;

[0023] Figure 2 It is a flowchart of generating various codes and files based on the content of the reset matrix table provided by the embodiment of the present invention;

[0024] Figure 3 It is a schematic structural diagram of the on-chip system detection device provided by the embodiment of the present invention;

[0025] Figure 4 It is a schematic structural diagram of the electronic device provided by the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0026] The detection of system-on-chip helps to promptly identify design issues and make corrections, thereby shortening the time from design to market for products. However, system-on-chip detection typically requires a large investment of human resources. With the development of technology, the complexity of system-on-chip chips is continuously increasing, and the challenges faced in the detection work are also rising. During the verification process of system-on-chip chips, it has the characteristics of a large number, simple structure, strong repeatability, and iterativeness. Repeatability means that the reset system of the system-on-chip manages the reset matrix of each subsystem, and the reset matrix structures of each sub-module are similar. Strong iterativeness means that as the chip design gradually matures, it is inevitable that the domain of the reset matrix is iterated repeatedly. The traditional approach to reset matrix verification is to manually write test components, and if there are handwritten errors, multiple simulation and debugging are required for modification. Moreover, during the iteration process, iterative modifications are made to the reset matrix name, assertion check, and module timing. This approach is cumbersome and time-consuming, requires a large amount of computing resources, invests a lot of effort, wastes human and material resources, and is prone to human errors, resulting in low detection efficiency. To solve the above technical problems, the present invention provides a system-on-chip detection method.

[0027] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the protection scope of the present invention.

[0028] To enable those skilled in the art of this technology to better understand the solution of the present invention, the present invention will be further described in detail below in conjunction with the drawings and specific implementation manners. Figure 1 It is a flowchart of the system-on-chip detection method provided by the embodiment of the present invention, as Figure 1 shown, the method includes:

[0029] S101. Read the summary information of the reset matrix scenario attributes.

[0030] It should be noted that the present invention can be based on the traditional approach to reset matrix verification, and then, in view of the characteristics of the reset matrix, through the standard documents of the architecture and design, summarize the verification excitation method, check mechanism, and coverage statistics, and can be summarized into a reset matrix scenario attribute table in a fixed format. When executing step S101, the summary information of the reset matrix scenario attributes in the reset matrix scenario attribute table can be directly read.

[0031] S102. Based on the read summary information of the reset matrix scenario attributes, generate test cases for the reset scenario, assertion check files, assertion coverage files, and top-level reset startup process code.

[0032] In implementation, the present invention can generate component codes of general verification methodologies such as test cases, assertion checks, and assertion coverage rates for common reset scenarios based on the reset matrix scenario attribute table read in step S101; meanwhile, generate the top-level code of the test bench (TB).

[0033] S103. According to the basic environment set by the top-level reset startup process code, after starting the test, use the test cases of the reset scenario to detect the functions of the overall system-on-chip and subsystems in the reset scenario, and obtain the detection results.

[0034] It should be noted that the present invention can initialize the reset startup process using the basic environment set by the top-level reset startup process code, and use the test cases generated in step S102 to check one by one the overall functions of the system-on-chip and the functions of each subsystem in the specific scenario of reset. For example, check whether the system can be correctly initialized after reset, whether each subsystem can return to the expected initial state, and whether the relevant functions can operate normally. Through the function detection of the overall system-on-chip and subsystems, corresponding detection results will be obtained eventually.

[0035] S104. Use the assertion check file and assertion coverage file to verify the detection results during the reset process.

[0036] In implementation, the present invention can perform an assertion check verification each time the test is started. Considering the characteristics of simple structure and strong repeatability of the reset matrix, the verification method is optimized. The present invention adopts a method of directly binding assertions for verification, which is more efficient. The assertion check file contains a series of pre-set assertion statements, which define various conditions and expected results that the system should meet in a specific reset scenario. During the reset process, the detection results are compared with the expectations in the assertion check file. If the detection results are consistent with the assertions, it indicates that the function of the system in this aspect meets the expectations; if not, it indicates that there is a problem with the system and further investigation is needed. The assertion coverage file is mainly used to measure the comprehensiveness and sufficiency of the test. It records the triggering and verification situations of each assertion in the assertion check file during the entire reset process, that is, which assertions are executed and which are not. By analyzing the assertion coverage file, it can be understood whether the test cases cover all key function points and logical branches in the system reset process. If the assertion coverage rate is low, it indicates that there may be some reset scenarios that have not been fully tested, and further test cases need to be supplemented to improve the integrity of the test and ensure that the system can work properly under various possible reset conditions.

[0037] In the above-mentioned on-chip system detection method provided by the embodiments of the present invention, first read the summary information of the reset matrix scenario attributes, then generate test cases for the reset scenario based on the summary information of the reset matrix scenario attributes, assert the check file, the assertion coverage file, and the top-level reset startup process code, and then start the test according to the basic environment set by the top-level reset startup process code. Use the test cases of the reset scenario to detect the functions of the on-chip system as a whole and the subsystems under the reset scenario; finally, use the assertion check file and the assertion coverage file to verify the detection results during the reset process. This can cover different application scenarios, eliminate errors or omissions caused by manual writing, improve the accuracy, ensure the completeness of the address allocation detection work through the analysis of the assertion coverage results, greatly reduce the time cost of handwritten detection components, eliminate human errors in manual writing, reduce the time of repeated simulation and debugging, and take into account the iterative modification of the architecture. Only need to iterate and refresh the summary table, reducing the workload of repeated modification caused by iterative modification of test cases and components. The overall method reflects the reusability, efficiency, and completeness of the detection platform, improving the detection efficiency and detection accuracy.

[0038] It should be noted that the on-chip system detection method of the present invention can be automated. For example, test cases for automatically generating reset scenarios, assertion check files, assertion coverage files, and top-level reset startup process codes are generated. Its importance and advantages are multifaceted, including: (1) Improving efficiency and accuracy: Automated detection can significantly improve the efficiency of the detection process, reduce repetitive work, and enable detection engineers to focus on more complex tasks. At the same time, automated tools can run test cases reliably and accurately, reduce human errors, and improve the accuracy and clarity of test results. (2) Enhancing test coverage: Automated testing can cover the test scope more widely and accurately. Some test scenarios that are difficult for humans to reproduce or cover can also be effectively detected, improving the comprehensiveness and effectiveness of testing. (3) Optimizing the development process: The combination of automated testing and development can reduce repetitive manual testing and debugging time, accelerate the product release speed and iteration cycle, and thus optimize the entire development process. (4) Reducing costs: Although the development and maintenance costs of automated testing may be higher than those of manual testing, as the number of test repetitions increases, it can save human, time, and material resource costs, which helps reduce testing costs in the long run. (5) Adapting to complexity: As the complexity of chip design increases, manual detection methods become increasingly impractical. Automated detection tools can handle larger-scale designs, support designs of over one billion gates, achieve rapid version iteration and debugging, and support rapid design transplantation and startup speed. (6) Improving design quality and reliability: Automated detection helps build confidence in the correctness of the design, ensures that the chip behaves correctly in the actual environment, and improves the quality and reliability of the chip. (7) Supporting digital transformation: In the era of the digital economy, digital transformation has become the core driving force for innovation and development in all industries. As part of digital transformation, automated detection helps improve the level of digital applications and intelligent management capabilities, and promotes the development of the certification and accreditation inspection and testing industry.

[0039] Using assertions to specifically check and verify the detection results during the reset process, the advantages mainly include: (1) Improving design visibility and controllability: Assertions make the observation points closer to the places where errors occur, thus enhancing visibility and helping to detect design errors immediately when they occur, without waiting for the error results to be transmitted to the design boundary. (2) Shortening the debugging time: Since assertions improve design visibility, verification engineers can detect errors earlier at a more accurate location, thereby saving debugging time. (3) Simplifying the verification of reusable IP cores: Applying assertions to verify the interfaces between IP cores and the system can improve verification efficiency. (4) Making it more convenient to record functional coverage: Assertion coverage can be recorded during simulation, so checking assertion coverage becomes a form of functional coverage. (5) Detecting errors (bugs) early: Assertions can help verification engineers conduct checks as soon as possible. (6) Reducing simulation time: Assertion is a white-box verification technique. Once a design error occurs, the assertion can detect it immediately without waiting for the error results to be transmitted to the design boundary, and there is no need to search for and locate the error. (7) Implementing the on / off switch of assertions in the design through global control: Implementing the on / off switch of assertions in the design through global control is convenient for management. (8) The built-in coverage statistics function of assertions: Using the built-in coverage statistics function (cover) of assertions can more easily obtain the coverage of functions. (9) The readability of assertions is easier to understand than general description languages: The readability of assertions is easier to understand than general description languages, which helps to improve the maintainability of the code. (10) Accelerating simulation / acceleration: Since assertion synthesis is now mature, this means that assertions are very useful during simulation and can accelerate the simulation. (11) Supporting global on / off: Assertions support the global on / off mechanism, which helps to maintain the code in a simpler way.

[0040] Furthermore, in specific implementation, in the above-mentioned on-chip system detection method provided by the embodiments of the present invention, step S101 of reading the summary information of the reset matrix scenario attributes may specifically include: determining the naming structure of the reset matrix scenario attribute table; the naming structure includes the subsystem level, the first-level sub-modules, and the output signals after reset generation; determining the reset scenarios related to the reset matrix; the reset scenarios include hard reset, module reset, watchdog reset, soft reset, and initialization reset; corresponding the determined naming structure with the reset scenarios and filling them into the reset matrix scenario attribute table; reading the summary information of the reset matrix scenario attributes in the reset matrix scenario attribute table.

[0041] In implementation, the present invention can summarize the information in the reset matrix scenario attribute table, as shown in Table 1 below.

[0042] Table 1 Example Table of Reset Matrix

[0043]

[0044] As can be seen from Table 1, the naming is divided into three levels. The first level is the subsystem level, the second level is the sub-module at the first layer, and the third level is the output signal after reset generation. To ensure the flexibility of reset for the main functions, it is necessary to implement the control of reset input sources for multiple scenarios. The header information includes Subsys (subsystem name), which represents different subsystems in the system-on-chip; Module (module name), which represents the specific modules included in each subsystem; RGU name (reset unit name), which represents the reset signal name corresponding to each module; Hw_rst (hard reset), Module_rst (module reset), WDT_rst (watchdog reset), SW_rst (soft reset), FSM_rst (initialization reset, also known as state machine reset), which represent different reset scenarios respectively; MR_rstreg name and Bits, which represent the module reset register name and the corresponding bit position respectively, used to clarify the register and bit information for specific operations in the module reset scenario. Among them, R indicates that the module will be subject to a reset operation in the corresponding reset scenario, U indicates that the behavior of the module in this reset scenario is uncertain or undefined, pre indicates that it must be released first, and all indicates that there is a fixed reset delay. Taking the row of "UNCORE-STAR_SP" as an example, "Cpu_power_rst_n_o" is the reset unit name. In the hard reset and module reset scenarios, this module will be subject to reset operations (marked as R). The register corresponding to the module reset is Mr_rst_a, and the bit position is 0; in the watchdog reset (WDT_rst) and soft reset scenarios, it will also be subject to reset operations. The register corresponding to the soft reset is SW_rst_a, and the bit position is 0, and it is marked as All in the state machine reset, indicating that this reset will affect the entire module. Taking the row of "PER_SYS-I2C-I2c_0_rst_n_o" as another example, it is R in both the hard reset and module reset scenarios. The module reset register is Mr_rst_b, and the bit position is 0; it is R in the soft reset scenario. The soft reset register is SW_rst_b, and the bit position is 0. It is undefined (U) in the watchdog reset scenario and is marked as All in the state machine reset. Due to different scenarios, the implementation and inspection methods of reset are also different, so only representative reset unit names are listed in the table.

[0045] Hard reset is to force the system back to the initial state through a hardware signal (such as pressing the reset button), which will clear all registers and status in the system. Soft reset is a reset operation triggered by software instructions, which may only reset some registers or system status. Initialization reset is a reset operation performed when the system starts up, used to set the system to a known initial state. Watchdog reset is when the system encounters an exception (such as a program running wild), and the watchdog timer times out, which will trigger a reset operation to make the system resume normal operation. Module reset is to reset only a specific module in the system without affecting the normal operation of other modules.

[0046] The reset matrix scenario attribute table provided by the present invention clearly shows the reset signals, related registers and bit information, and reset behaviors of each subsystem and its modules in different reset scenarios, which helps designers comprehensively understand the reset mechanism of the system and facilitates reset-related design, debugging, and verification work.

[0047] Further, in specific implementation, in the above-mentioned on-chip system detection method provided by the embodiment of the present invention, after executing step S101 to read the reset matrix scenario attribute summary information, it may further include: generating a macro definition file of the signal hierarchy and register addresses based on the read reset matrix scenario attribute summary information; the macro definition file is a test case, which provides a reference method for signal and register addresses for assertion checking and assertion coverage.

[0048] Correspondingly, when step S102 generates test cases, assertion check files, and assertion coverage files for the reset scenario, it may further include: using the macros in the macro definition in the test cases, assertion check files, and assertion coverage files for the reset scenario.

[0049] In implementation, the present invention can automatically generate a macro definition file of the signal hierarchy and register addresses, mainly to support the use of macros in test cases, assertion checking, and assertion coverage, forming a simple and clear code style, which facilitates the testers to clearly locate problems. In practical applications, after the macro definition file is generated, the testers can manually define the hierarchy and register addresses according to the actual situation.

[0050] Further, in specific implementation, in the above-mentioned on-chip system detection method provided by the embodiment of the present invention, generating a macro definition file of the signal hierarchy may include: generating subsystem input signals related to the reset signal and output signals of the reset generation module; detecting the input signals to judge the correctness of the connection between subsystems; detecting the output signals to distinguish the on-chip system detection environment and the detection environment of the reset generation module.

[0051] In implementation, the present invention can generate two levels of output signals and input signals for the reset signal. The input signal is the input signal of the subsystem, which can detect the correctness of the connection between subsystems. The output signal is only the output level of the reset generation module; mainly to distinguish the on-chip system detection environment and the detection environment of the separate reset generation module.

[0052] It should be noted that the present invention automatically generates a macro definition file for the signal hierarchy and register addresses, mainly to support the use of macro definitions for test cases, assertion checks, and assertion coverage, forming a simple and clear code style, which is convenient for testers to clearly locate problems. The naming rules for the macro definitions of the signal hierarchy are listed as the uppercase combination of "subsystem name + module name + reset generation unit signal name". The naming rule for the register address is the uppercase combination of "register name + ADDR". The following is a pseudo-code example for automatically generating macro definitions.

[0053]

[0054] The above code is a macro definition file common_define.sv written in SystemVerilog language. Its main function is to simplify the use of complex names and fixed values in subsequent code through macro definitions. In the scenarios of hardware design and verification, signals often reside in complex hierarchical structures. Here, the define keyword is used to define long and complex hierarchical signal paths as short and memorable macro names. Taking UNCORE_STAR_SP_CPU_POWER_RST_N_O as an example, it is defined as soc_top_tb.xxxxx.Cpu_power_rst_n_o. In subsequent code, whenever UNCORE_STAR_SP_CPU_POWER_RST_N_O is used, the compiler will automatically replace it with soc_top_tb.xxxxx.Cpu_power_rst_n_o. Generally, _O represents an output signal, _I represents an input signal, and rst_n usually represents an active-low reset signal. Similarly, using the define keyword, the addresses of registers are defined as macro names. This can make the code more readable and maintainable, avoiding directly using hard-to-remember hexadecimal addresses in the code. For example, MODULE_RST_REG_A_ADDT is defined as 0x200000. When accessing this register in subsequent code, the macro name MODULE_RST_REG_A_ADDT can be used instead of writing 0x200000 every time. From the increment rule of the addresses (increasing by 0x4 each time), it can be speculated that these registers may be word-aligned (usually 32 bits, 4 bytes). This code can simplify complex signal paths and register addresses through macro definitions, facilitating their use in subsequent SystemVerilog code and improving the readability and maintainability of the code.

[0055] Furthermore, in specific implementation, in the above-mentioned on-chip system detection method provided by the embodiments of the present invention, step S102 of generating test cases for the reset scenario may specifically include: generating test cases for integrating multiple reset scenarios of the on-chip system and test cases for the reset scenario of subsystem detection; among them, the test cases for integrating multiple reset scenarios of the on-chip system include test cases triggered by the reset matrix for secondary reset; the implementation categories of multiple reset scenarios are divided into registers and port signals.

[0056] Accordingly, step S103 uses the test cases of the reset scenario to detect the functions of the overall system-on-chip and subsystems in the reset scenario. Specifically, it may include: using the test cases integrated with multiple reset scenarios of the system-on-chip to detect the functions of the overall system-on-chip in the reset scenario; using the reset scenario test cases for subsystem detection to detect the functions of each subsystem in the reset scenario; during the detection process, according to the characteristics of synchronous release of asynchronous reset, incentive operations are performed on the assertion, de-assertion of the reset signal, and restoration of the set state during secondary reset to simulate the behaviors of the system-on-chip and / or subsystems under different reset conditions.

[0057] In implementation, the present invention can automatically generate test case files integrated with multiple reset scenarios, including scenarios such as hard reset, soft reset, initialization reset, watchdog reset, module reset, etc. Considering the characteristics of synchronous release of asynchronous reset, an incentive driver for realizing reset assertion, de-assertion, and restoration to normal during secondary reset will be implemented. Since only the assertion of the reset register bit is related to the module reset scenario and the subsystem reset, and the issue of coupling needs to be considered, it is necessary to poll the de-assertion of each bit and the generation of incentives for the assertion of other bits.

[0058] The following are the test cases for automatically generating the reset scenario of the system-on-chip, including the trigger of the reset matrix for secondary reset, which can check whether the system can be normally reset after the release of asynchronous reset; the implementation categories of multiple scenarios are mainly divided into two types: register and force port signals; in order to control the simulation time and debugging process, multiple scenario variable selections are provided, as shown in the pseudocode. Its display code includes scenario name comments, reset register read and write operations, status printing, etc.

[0059]

[0060] This code mainly performs excitation operations on different types of reset signals in a hardware verification environment (based on UVM, Universal Verification Methodology) to simulate the behavior of the hardware system under different reset conditions. $display is a system task in SystemVerilog used to output information to the console during simulation. The information output here is "Waiting bootdone", indicating that the current simulation is waiting for the system to complete startup. vm_hdl_force is a function in UVM used to force the driving of signal values. HW_RST_I is the hardware reset input signal defined previously in a macro definition file (such as common_define.sv). First, HW_RST_I is forced to a low level (0) for 1 microsecond (#1us) to simulate the effective reset signal; then it is driven to a high level (1) to indicate the release of the reset signal. After waiting for 10 microseconds, HW_RST_I is driven to a low level again for 1 microsecond and then released, and finally, it waits for 20 microseconds. reg_write is a custom function used to write data to a register at a specified address. MODULE_RST_REG_A_ADDR is the module reset register address defined previously in the macro definition file. Set the specified bit (bit) of Wdata to 1 to enable the reset; then call the reg_write function to write this data to the module reset register for 1 microsecond; then set this bit to 0 to release the reset and write to the register again, and finally wait for 10 microseconds. Repeat the above operations, but the waiting time becomes 20 microseconds. In summary, the main purpose of this code is to excite different types of reset signals in the hardware simulation environment to verify the stability and correctness of the hardware system under various reset conditions.

[0061] Further, in specific implementation, in the above-mentioned on-chip system detection method provided by the embodiments of the present invention, during the process of step S102 of generating the assertion check file, it may specifically include: binding the input signals and output signals of the assertion check module to the corresponding hierarchical macro definitions respectively; when in the on-chip system detection environment, using the signal input of the subsystem as the inspection object; when in the environment of the Reset Generation Unit (RGU) sub-module, adopting the method of signal output hierarchical signal binding; modularizing the assertion check into components, including sequence components, property components, assertion start components, and assertion coverage start components.

[0062] In implementation, the present invention can automatically generate code for assertion detection. It uses the bind method to bind to the input and output signals of the assertion check module. If it is a system-on-chip detection environment, the signal input of the subsystem is used as the object to be checked. If it is the environment of the reset generation unit sub-module, the signal output hierarchical signal is used for binding. The assertion check is modularized into components, mainly including sequence components, property components, assertion start and assertion coverage start components, which increases the logical layering and positioning convenience of the assertion check.

[0063] The sequence component is used to describe the time sequence relationship of signals; in hardware verification, the changes of signals often have a specific time order. The sequence component can define the change sequence of these signals over a period of time to check whether the signals change in the expected order. The property component is used to define the properties and constraint conditions of signals; for example, the value range of signals, the logical relationship between signals, etc. The property component can describe the conditions that signals should meet at a certain moment or within a certain period of time to check whether the signals meet these conditions. The assertion start component is used to start the operation of assertion check; it triggers the assertion check at an appropriate time to ensure that the assertion logic can be started in time when it is necessary to perform the check. The assertion coverage start component is used to start the statistics of assertion coverage; assertion coverage is an important indicator to measure the integrity of assertion check. By counting the assertion coverage, it can be known which assertions are triggered and which assertions are not triggered, so as to discover possible test vulnerabilities.

[0064] Furthermore, in specific implementation, in the above-mentioned system-on-chip detection method provided by the embodiment of the present invention, during the process of generating the assertion coverage file in step S102, it may specifically include: adding assertion coverage content in the script to achieve a closed loop of assertion coverage; wherein, the assertion coverage content includes the trigger scenarios of all constraints of the input signals in the reset scenario, the content obtained by collecting the trigger situations of the assertion attributes of the module reset output, and the trigger conditions and results of the assertion and revocation operations of the reset signal.

[0065] In implementation, the present invention can automatically generate assertion coverage. It should be noted that the script will automatically add three parts of assertion coverage content. The first part is the trigger scenarios of all constraints of the input signals in the reset scenario; the second part is to collect whether the assertion attributes of the module reset output are triggered; the third part is to supplement whether the assertion attributes of all scenarios are triggered, and check the trigger conditions and results of the assertion and revocation of the reset, such as the secondary reset scenario and the module register reset scenario, etc. In this way, a complete closed loop of assertion coverage can be achieved.

[0066] The present invention automatically generates the main code content of Verilog (a hardware description language) assertion checks and assertion coverage, adds the startup of assertions and assertion coverage, and performs binding operations on the top-level part of the device under test (DUT) in the reset matrix module; wherein the input and output signals of the assertions are bound to the corresponding hierarchical macro definitions. In the top-level module of the test environment built based on the universal verification methodology, the assertion files are introduced into the current code environment in an include (an instruction or keyword) manner, so as to use these assertions to check the correctness of the design during the verification process. The following is the pseudo-code for automatically generating assertion coverage.

[0067]

[0068]

[0069] This piece of code is an assertion module `assertion_rgu` written in SystemVerilog. Its core purpose is to verify the behavior of the reset signal in the hardware design and collect relevant coverage information. A module named `assertion_rgu` is defined. Multiple input signals are declared, such as `Hw_rst_n` (hardware reset signal, active low), `Star_SP_rst_n`, `SW_rst_n` (soft reset signal, active low), etc. Multiple output signals are declared, such as `Cpu_power_rst_n_o` (CPU power reset output signal, active low), `Cpu_sys_rst_n_o` (CPU system reset output signal, active low), `I2c_0_rst_n_o` (I2C device 0 reset output signal, active low), etc. The `S_Hw_rst_rose` sequence: After the rising edge of the `Cpu_power_rst_n_o` signal appears, within 1 to an infinite number of clock cycles, the rising edges of signals such as `Cpu_sys_rst_n_o` and `I2c_0_rst_n_o` must also appear simultaneously, simulating the situation where the power and clock signals are released first. The function of the `S_Start_sp_rst_rose` sequence is similar to that of `S_Hw_rst_rose`, and it is used to detect the reset release situation triggered by the `Star_SP_rst_n` signal. The `S_Hw_rst_fell` sequence requires the falling edges of signals such as `Cpu_power_rst_n_o`, `Cpu_sys_rst_n_o`, and `I2c_0_rst_n_o` to appear simultaneously, and it is used to detect the situation when the hardware reset signal is active. The function of the `S_SW_rst_fell` sequence is similar to that of `S_Hw_rst_fell`, and it is used to detect the reset situation triggered by the soft reset signal `SW_rst_n`. The `hw_rst_rose_check` property is triggered at the rising edge of the `rcu_clk` clock. When the `enable_off` signal is high, the assertion is disabled. After the rising edge of the `Hw_rst_n` signal appears, within 1 to an infinite number of clock cycles, the `S_Hw_rst_rose` sequence must hold. The `hw_rst_fell_check` property is also triggered at the rising edge of the `rcu_clk` clock. When the `enable_off` signal is high, the assertion is disabled. After the falling edge of the `Hw_rst_n` signal appears, within 1 to an infinite number of clock cycles, the `S_Hw_rst_fell` sequence must hold. The `assert property` statement is used to start the assertion. `a_hw_rst_rose_check` and `a_hw_rst_fell_check` are the instance names of the assertions respectively. When the corresponding assertion properties are not satisfied, the simulation tool will report an error. The `cover property` statement is used to start the assertion coverage collection.c_hw_rst_rose_check and c_hw_rst_fell_check are coverage instance names respectively, used to collect coverage information of the hw_rst_rose_check and hw_rst_fell_check attributes, helping developers understand the sufficiency of verification. The bind keyword is used to bind the assertion_rgu module to dut_module_rgu_top (the top-level module under test in the design). assertion_rgu_inst is the name of the bound instance, and (.*) means connecting all ports of the assertion_rgu module to the ports with the same name in dut_module_rgu_top.

[0070] The above code realizes the verification of the reset signal behavior and coverage analysis in the hardware design by defining assertion sequences, assertion attributes, starting assertions and coverage collection, and binding the assertion module to the module under test, which helps to ensure the correctness of the hardware design and the sufficiency of verification.

[0071] Figure 2 This is the flowchart for generating various codes and files based on the summary information of the reset matrix scenario attributes provided by the embodiments of the present invention. According to Figure 2 The process shown demonstrates the implementation principle. Only the main tree structure is listed, and repetitive content is omitted. As Figure 2 shown, sample the table content of the reset matrix, and judge the sampled data to check if it is a system-on-chip component. If it is a system-on-chip component, enter the process branch of generating system-on-chip component C code. Under this branch, system-on-chip component C code based on processor access and a macro definition file for C code will be further generated. The system-on-chip component code based on processor access is used to implement the operations and controls of the processor on the system-on-chip component, while the macro definition file for C code provides unified macro definitions such as constants and addresses for subsequent code writing, improving the readability and maintainability of the code. If it is not a system-on-chip component, continue to judge if it is a single component of the subsystem. If not, enter the process of generating code components for all subsystems, where a series of codes and files related to all subsystems can be generated. If it is a single component of the subsystem, the subsystem name needs to be input, and then enter the branch of generating code components for a certain single subsystem. Under this branch, test cases for this subsystem, a macro definition file for SV (SystemVerilog) code, an assertion check file, and an assertion coverage file will be generated. Subsystem test cases are used to detect the functional correctness of this subsystem in different scenarios; the macro definition file for SV code provides macro definitions for the code written in the SV language; the assertion check file is used to verify whether various conditions during system operation meet the expectations; and the assertion coverage file is used to count the execution coverage of assertions and evaluate the sufficiency of testing.

[0072] Through the analysis of the content of the reset matrix table and the judgment of component types, the above process generates different types of codes and files in a targeted manner to support the development, testing, and verification of the system-on-chip and its subsystems, ensuring the correct function and reliability of the system in various scenarios such as reset.

[0073] It should be added that for test cases and assertion checks, considering the simulation time and the focus of simulation scenarios, simulation macro definitions can be automatically added. Before simulation, the tester can select this macro definition to determine whether to perform assertion checks and coverage checks for a certain scenario. This can not only save the simulation time of test cases but also save the simulation time of the corresponding scenario in the SOC environment. In assertion checks, in addition to the reset timing, the present invention can also consider more detailed timing waiting times, which can be specifically reflected in the table to further constrain the details of timing and save the simulation time of assertion checks. Additionally, since the reset release of sub-modules needs to consider the reset delay of different clock domains, the reset checks for different clock domains can also be incorporated into the automated process.

[0074] In the above embodiments, the method for detecting a system-on-chip is described in detail. The present invention also provides corresponding embodiments of a system-on-chip detection device and an electronic device. It should be noted that the present invention describes the embodiments of the device part from two perspectives, one is from the perspective of functional modules, and the other is from the perspective of hardware.

[0075] Figure 3 It is a schematic structural diagram of the system-on-chip detection device provided by an embodiment of the present invention. This embodiment is based on the perspective of functional modules. As Figure 3 shown, the device includes:

[0076] An information reading module 10, configured to read the summary information of the reset matrix scenario attributes;

[0077] A code file generation module 11, configured to generate test cases for the reset scenario, assertion check files, assertion coverage files, and top-level reset startup process codes based on the read summary information of the reset matrix scenario attributes;

[0078] A function detection module 12, configured to start testing according to the basic environment set by the top-level reset startup process code, and then use the test cases of the reset scenario to detect the functions of the overall system-on-chip and its subsystems in the reset scenario to obtain detection results;

[0079] A result verification module 13, configured to verify the detection results during the reset process using the assertion check file and the assertion coverage file.

[0080] In the above-mentioned on-chip system detection device provided by the embodiments of the present invention, through the interaction of the above four modules, different application scenarios can be covered, errors or omissions caused by manual writing can be eliminated, the accuracy can be improved, the completeness of the address assignment detection work can be ensured by analyzing the assertion coverage rate results, the time cost of handwritten detection components can be greatly reduced, the human errors in manual writing can be eliminated at the same time, the time for repeated simulation and debugging can be reduced, and the iterative modification of the architecture can be taken into account. Only the summary table needs to be iteratively refreshed, reducing the workload of repeated modification caused by iterative modification of test cases and components. The overall method reflects the reusability, efficiency, and completeness of the detection platform, improving the detection efficiency and detection accuracy.

[0081] Since the embodiments of the device part correspond to the embodiments of the method part, please refer to the description of the embodiments of the method part for the embodiments of the device part, which will not be elaborated here for the time being. And it has the same beneficial effects as the above-mentioned on-chip system detection method.

[0082] Further, in specific implementation, in the above-mentioned on-chip system detection device provided by the embodiments of the present invention, the information reading module 10 can specifically be used to determine the naming structure of the reset matrix scenario attribute table; the naming structure includes the subsystem level, the first-level sub-module, and the output signal after reset generation; determine the reset scenarios related to the reset matrix; the reset scenarios include hard reset, module reset, watchdog reset, soft reset, and initialization reset; correspond the determined naming structure with the reset scenarios and fill them into the reset matrix scenario attribute table; read the reset matrix scenario attribute summary information in the reset matrix scenario attribute table.

[0083] Further, in specific implementation, in the above-mentioned on-chip system detection device provided by the embodiments of the present invention, the code file generation module 11 can also be used to generate a macro definition file of the signal hierarchy and register addresses based on the read reset matrix scenario attribute summary information; the macro definition file provides a reference method for signals and register addresses for test cases, assertion checks, and assertion coverage rates; use the macros in the macro definition in the test cases, assertion check files, and assertion coverage rate files for the reset scenarios. Among them, generating the macro definition file of the signal hierarchy can include: generating the subsystem input signals related to the reset signal and the output signals of the reset generation module; detecting the input signals to judge the correctness of the connection between subsystems; detecting the output signals to distinguish the on-chip system detection environment and the detection environment of the reset generation module.

[0084] Further, in specific implementation, in the above-mentioned on-chip system detection device provided by the embodiments of the present invention, the code file generation module 11 can specifically be used to generate test cases for integrating various reset scenarios of the on-chip system and reset scenario test cases for subsystem detection; among them, the test cases for integrating various reset scenarios of the on-chip system include test cases triggered by the reset matrix for secondary reset; the implementation categories of various reset scenarios are divided into registers and port signals.

[0085] The function detection module 12 can specifically be used to detect the functions of the entire on-chip system in the reset scenario by using the test cases for integrating various reset scenarios of the on-chip system; detect the functions of each subsystem in the reset scenario by using the reset scenario test cases for subsystem detection; during the detection process, according to the characteristics of synchronous release of asynchronous reset, perform excitation operations on the assertion, revocation, and restoration of the reset signal to the set state for the secondary reset, so as to simulate the behaviors of the on-chip system and / or subsystems under different reset conditions.

[0086] Further, in specific implementation, in the above-mentioned on-chip system detection device provided by the embodiments of the present invention, the code file generation module 11 can specifically be used to bind the input signals and output signals of the assertion check module to the corresponding hierarchical macro definitions respectively; when in the on-chip system detection environment, use the signal input of the subsystem as the inspection object; when in the reset generation unit sub-module environment, adopt the method of signal output hierarchical signal binding; modularize the assertion check into components, including sequence components, property components, assertion start components, and assertion coverage start components.

[0087] Further, in specific implementation, in the above-mentioned on-chip system detection device provided by the embodiments of the present invention, the code file generation module 11 can specifically be used to add assertion coverage content to the script to achieve a closed-loop of assertion coverage; among them, the assertion coverage content includes the trigger scenarios of all constraints of the input signals of the reset scenario, the content obtained by collecting the assertion attribute trigger conditions of the module reset output, and the trigger conditions and results of the assertion and revocation operations of the reset signal.

[0088] Figure 4 It is a schematic structural diagram of the electronic device provided by the embodiments of the present invention. Based on the hardware perspective, as Figure 4 shown, the electronic device includes:

[0089] A memory 20 for storing a computer program;

[0090] A processor 21 for implementing the steps of the on-chip system detection method as mentioned in the above embodiments when executing the computer program.

[0091] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 may be implemented in at least one hardware form of a Digital Signal Processor (DSP), a Field-Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor used to process data in the wake state, also known as the CPU; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may be integrated with a Graphics Processing Unit (GPU), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may further include an Artificial Intelligence (AI) processor, and the AI processor is used to process computational operations related to machine learning.

[0092] The memory 20 may include one or more computer-readable storage media, and the computer-readable storage media may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash storage devices. In this embodiment, the memory 20 is at least used to store the following computer program 201. After the computer program is loaded and executed by the processor 21, it can implement the relevant steps of the on-chip system detection method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the on-chip system detection method mentioned above.

[0093] In some embodiments, the electronic device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26. Those skilled in the art can understand that Figure 4 the structure shown in does not constitute a limitation on the electronic device, and it may include more or fewer components than shown in the figure. The electronic device provided by the embodiments of the present invention includes a memory and a processor. When the processor executes the program stored in the memory, it can implement the on-chip system detection method mentioned above, and the effect is the same.

[0094] Finally, the present invention also provides an embodiment corresponding to a computer-readable storage medium. A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps recorded in the above method embodiment are implemented.

[0095] It can be understood that if the method in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the above methods in various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes. The computer-readable storage medium provided by the present invention can implement the above-mentioned on-chip system detection method, and the effect is the same.

[0096] Finally, the present invention also provides an embodiment corresponding to a computer program product. The computer program product includes computer programs / instructions, and when the computer programs / instructions are executed by a processor, the steps recorded in the above on-chip system detection method embodiment are implemented. The computer program product provided by the present invention can implement the above-mentioned on-chip system detection method, and the effect is the same.

[0097] It should also be noted that in this specification, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or also includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or device including the above element.

[0098] The above has introduced in detail the on-chip system detection method, device, equipment and medium provided by the present invention. The various embodiments in the specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple. For the relevant parts, reference can be made to the description in the method part. It should be noted that for those of ordinary skill in the art in the technical field of the present invention, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A system-on-chip detection method, characterized in that: The method comprises: Read the reset matrix scene attribute summary information; Based on the reset matrix scenario attribute summary information read, a test case for the reset scenario, an assertion check file, an assertion coverage file, and a top-level reset startup process code are generated; After starting the test according to the basic environment set by the top-level reset startup process code, the functions of the entire system on chip and the subsystems in the reset scenario are tested using the test cases of the reset scenario to obtain the test results; The detection result is verified during the reset process using the assertion checking file and the assertion coverage file.

2. The system-on-chip detection method according to claim 1, characterized in that: After reading the reset matrix scene attribute summary information, it also includes: Based on the reset matrix scenario attribute summary information read, a macro definition file of a signal hierarchy and a register address is generated; the macro definition file provides a reference method of a signal and a register address for a test case, an assertion check, and an assertion coverage; Accordingly, when generating the test cases, assertion check files, and assertion coverage files for the reset scenario, the following files are also included: The macro definition in the macro definition is used in the test case of the reset scenario, the assertion check file, and the assertion coverage file.

3. The system-on-chip detection method according to claim 2, characterized in that: Generate a macro definition file for the signal hierarchy, including: generating a subsystem input signal related to a reset signal and an output signal of a reset generation module; Detecting the input signal to determine the correctness of the connection between the subsystems; The output signal is detected to distinguish between the on-chip system detection environment and the reset generation module detection environment.

4. The system-on-chip detection method according to claim 1, characterized in that: Generate test cases for reset scenarios, including: Generate test cases for the integration of multiple reset scenarios of the SoC, as well as reset scenario test cases for subsystem detection; Among them, the test cases for the integration of multiple reset scenarios of the on-chip system include the test cases triggered by the reset matrix of the secondary reset; the implementation categories of multiple reset scenarios are divided into registers and port signals; Accordingly, the test cases of the reset scenario are used to detect the functions of the entire system on chip and its subsystems in the reset scenario, including: Use test cases that integrate multiple SoC reset scenarios to test the overall SoC functionality under reset scenarios. Use the reset scenario test cases of subsystem detection to test the functions of each subsystem in the reset scenario; During the detection process, according to the characteristics of synchronous release of asynchronous reset, the assertion, withdrawal and secondary reset recovery of the reset signal are stimulated to simulate the behavior of the on-chip system and / or subsystem under different reset conditions.

5. The system-on-chip detection method according to claim 1, characterized in that: The process of generating the assertion check file includes: Bind the input signal and output signal of the assertion checking module to the corresponding hierarchical macro definitions respectively; When in a system-on-chip testing environment, the signal input of the subsystem is used as the inspection object; When in the reset generation unit submodule environment, the signal output level signal binding method is adopted; Assertion checking is divided into modular components, including sequence components, property components, assertion startup components, and assertion coverage startup components.

6. The system-on-chip detection method according to claim 1, characterized in that: The process of generating the assertion coverage file includes: Add assertion coverage content to the script to achieve assertion coverage closed loop; The assertion coverage content includes triggering scenarios of all constraints of input signals of the reset scenario, content obtained by collecting the assertion attribute triggering conditions of module reset output, and triggering conditions and results of assertion and revocation operations of the reset signal.

7. The system-on-chip detection method according to claim 1, characterized in that: Read the reset matrix scene attribute summary information, including: Determine the naming structure of the reset matrix scene attribute table; the naming structure includes the subsystem level, the first layer submodule, and the output signal after the reset is generated; Determine a reset scenario associated with the reset matrix; the reset scenario includes hard reset, module reset, watchdog reset, soft reset, and initialization reset; Matching the determined naming structure with the reset scene and filling it into the reset matrix scene attribute table; The reset matrix scene attribute summary information in the reset matrix scene attribute table is read.

8. A system-on-chip detection device, characterized in that: The device comprises: An information reading module is used to read the reset matrix scene attribute summary information; A code file generation module, used to generate a test case for a reset scenario, an assertion check file, an assertion coverage file, and a top-level reset startup process code based on the reset matrix scenario attribute summary information read; A function detection module is used to detect the functions of the entire system on chip and its subsystems in the reset scenario using the test cases of the reset scenario after starting the test according to the basic environment set by the top-level reset startup process code to obtain the detection results; The result verification module is used to verify the detection result during the reset process using the assertion check file and the assertion coverage file.

9. An electronic device, characterized in that: The device comprises: Memory for storing computer programs; A processor, configured to implement the steps of the on-chip system detection method as claimed in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the system-on-chip detection method according to any one of claims 1 to 7 are implemented.

Images