Test case generation method and device, equipment and storage medium
By generating multiple test cases for the ICR module, covering flexible interaction scenarios of its internal pathways, the problems of verification blind spots and insufficient flexibility in ICR module verification are solved, and more comprehensive verification coverage is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- PHYTIUM TECH CO LTD
- Filing Date
- 2026-01-07
- Publication Date
- 2026-05-01
AI Technical Summary
Existing technologies for ICR module verification suffer from blind spots and low flexibility in verification scenarios.
By acquiring the functional points to be verified in the ICR module, arranging and combining the associated interrupt handling commands, generating multiple command combinations corresponding to multiple test scenarios, and building a simulated test environment to execute test cases, so as to cover the flexible interaction scenarios of different interrupt handling commands in the internal path.
This improves the flexibility of verification scenarios during ICR module verification, reduces verification blind spots, and ensures the verification coverage and completeness of the ICR module.
Smart Images
Figure CN121958112A_ABST
Abstract
Description
Test case generation methods, devices, equipment, and storage media Technical Field
[0001] This application relates to the field of module verification technology, and more specifically, to a test case generation method, apparatus, device, and storage medium. Background Technology
[0002] In integrated circuit design, the verification of individual modules is mainly used to ensure the correctness and functional integrity of the module's design. As SOC (System on Chip) design continues to advance and improve, the functions implemented by modules will become more and more complete, and the verification test scenarios (building complex scenarios, timing debugging, etc.) will also become increasingly complex.
[0003] In related technologies, the ICR (Interrupt Controller Redistributor) module, as an important component in system-on-a-chip (SoC) design, can provide localized interrupt management and configuration resources for each processor core. However, when verifying the ICR module, the verification is based on a comprehensive interrupt test scenario, resulting in limited verification functionality.
[0004] However, in related technologies, there are blind spots in the verification of ICR modules, resulting in low flexibility in verification scenarios. Summary of the Invention
[0005] The purpose of this application is to provide a test case generation method, apparatus, device, and storage medium to address the shortcomings of the prior art and solve the aforementioned technical problems in the related art.
[0006] To achieve the above objectives, the technical solution adopted in this application embodiment is as follows: In a first aspect, this application embodiment provides a test case generation method, including: obtaining a function point to be verified of an interrupt controller redistribution (ICR) module; arranging and combining each interrupt handling command associated with the function point to be verified to obtain multiple command combinations of the function point to be verified; the multiple command combinations respectively correspond to multiple test scenarios of the function point to be verified; generating multiple test cases of the function point to be verified according to the conditions of the interrupt handling commands in the multiple command combinations, each test case including: a test execution unit encapsulated by the conditions of each interrupt handling command in the command combination.
[0007] Optionally, the step of arranging and combining the interrupt handling commands associated with the function point to be verified to obtain multiple command combinations for the function point to be verified includes: arranging and combining the interrupt handling commands associated with the function point to be verified according to the command constraints of the ICR module for the function point to be verified to obtain multiple command combinations for the function point to be verified.
[0008] Optionally, generating multiple test cases for the functional point to be verified based on the conditions of the interrupt handling commands in the multiple command combinations includes: encapsulating the conditions of the interrupt handling commands in the command combinations to obtain multiple test execution units corresponding to the command combinations; adjusting the timing interval of the test execution units corresponding to adjacent commands in the multiple test execution units to obtain a test case for the functional point to be verified under the test scenario corresponding to the command combination.
[0009] Optionally, the method further includes: constructing a simulation test environment for the ICR module, the test environment including at least: a first simulation component and a second simulation component, wherein the first simulation component is used to simulate an interrupt controller distributing an ICD module that communicates with the ICR module, and the second simulation component is used to simulate a processor that communicates with the ICR module; using the simulation test environment, executing the plurality of test cases to verify the functional points to be verified of the ICR module.
[0010] Optionally, constructing the simulation test environment for the ICR module includes: constructing a bidirectional data interaction path between the first simulation component and the ICR module through an extensible stream interface; and constructing message interaction of the standard protocol between the second simulation component and the ICR module.
[0011] Optionally, the step of using the simulated test environment to execute the multiple test cases to verify the unverified functional points of the ICR module includes: using the simulated test environment to execute the multiple test cases; if the ICR module has sent a voltage setting command to the second simulation component and the ICR module has received a voltage clearing command sent by the first simulation component, then the second simulation component sends a voltage release command to the ICR module to verify the path function between the ICR module, the first simulation component, and the second simulation component; using the simulated test environment to execute the multiple test cases; if the ICR module has not sent the voltage setting command to the second simulation component and the ICR module has received a voltage clearing command sent by the first simulation component, then the ICR module internally generates the voltage release command to verify the path function between the ICR module, the first simulation component, and the second simulation component.
[0012] Optionally, the step of using the simulated test environment to execute the multiple test cases to verify the functional points to be verified of the ICR module includes: using the simulated test environment to execute the multiple test cases, if the first simulated component sends a power-down message to the ICR module, the ICR module receives the power-down message and sends a power-down message to the second simulated component to control the second simulated component to power down; using the simulated test environment to execute the multiple test cases, if the first simulated component sends a power-on message to the ICR module, the ICR module receives the power-on message and sends a power-on message to the second simulated component to control the second simulated component to power on.
[0013] Secondly, embodiments of this application also provide a test case generation apparatus, comprising: an acquisition module for acquiring a function point to be verified of an interrupt controller redistribution (ICR) module; a combination module for arranging and combining various interrupt handling commands associated with the function point to be verified to obtain multiple command combinations of the function point to be verified; the multiple command combinations respectively correspond to multiple test scenarios of the function point to be verified; and a generation module for generating multiple test cases of the function point to be verified according to the conditions of the interrupt handling commands in the multiple command combinations, each test case comprising: a test execution unit encapsulated by the conditions of each interrupt handling command in the command combination.
[0014] Optionally, the combination module is specifically used to arrange and combine the interrupt handling commands associated with the function point to be verified according to the command constraints of the ICR module for the function point to be verified, so as to obtain multiple command combinations of the function point to be verified.
[0015] Optionally, the generation module is specifically used to encapsulate the conditions of the interrupt handling command in the command combination to obtain multiple test execution units corresponding to the command combination; and to adjust the timing interval of the test execution units corresponding to adjacent commands in the multiple test execution units to obtain a test case of the function point to be verified under the test scenario corresponding to the command combination.
[0016] Optionally, the apparatus further includes: a construction module for constructing a simulated test environment for the ICR module, the test environment including at least: a first simulation component and a second simulation component, wherein the first simulation component is used to simulate an interrupt controller distributing an ICD module communicating with the ICR module, and the second simulation component is used to simulate a processor communicating with the ICR module; and an execution module for using the simulated test environment to execute the plurality of test cases to verify the functional points to be verified of the ICR module.
[0017] Optionally, the building module is specifically used to build a bidirectional data interaction path between the first simulation component and the ICR module through an extensible stream interface; and to build a standard protocol message interaction between the second simulation component and the ICR module.
[0018] Optionally, the execution module is specifically used to execute the multiple test cases in the simulated test environment. If the ICR module has sent a voltage setting command to the second simulation component and the ICR module has received a voltage clearing command sent by the first simulation component, then the second simulation component sends a voltage release command to the ICR module to verify the path function between the ICR module, the first simulation component, and the second simulation component. If the ICR module has not sent the voltage setting command to the second simulation component and the ICR module has received a voltage clearing command sent by the first simulation component, then the ICR module internally generates the voltage release command to verify the path function between the ICR module, the first simulation component, and the second simulation component.
[0019] Optionally, the execution module is specifically used to execute the multiple test cases using the simulated test environment. If the first simulated component sends a power-down message to the ICR module, the ICR module receives the power-down message and sends a power-down message to the second simulated component to control the second simulated component to power down. Alternatively, when executing the multiple test cases using the simulated test environment, if the first simulated component sends a power-on message to the ICR module, the ICR module receives the power-on message and sends a power-on message to the second simulated component to control the second simulated component to power on.
[0020] Thirdly, embodiments of this application also provide a test case generation device, including: a memory and a processor, wherein the memory stores a computer program executable by the processor, and the processor executes the computer program to implement the test case generation method described in any of the first aspects above.
[0021] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when read and executed, implements the test case generation method described in any of the first aspects above.
[0022] The beneficial effects of this application are as follows: This application provides a test case generation method, which includes: obtaining the function point to be verified of the Interrupt Controller Redistribution (ICR) module; arranging and combining the interrupt handling commands associated with the function point to be verified to obtain multiple command combinations for the function point to be verified; each command combination corresponds to multiple test scenarios for the function point to be verified; and generating multiple test cases for the function point to be verified based on the conditions of the interrupt handling commands in the multiple command combinations. Each test case includes a test execution unit encapsulated by the conditions of each interrupt handling command in a command combination. Arranging and combining the interrupt handling commands associated with the function point to be verified in the ICR module covers test scenarios where different interrupt handling commands interact flexibly within the internal path. In other words, the test scenarios covered by multiple command combinations are more comprehensive, greatly reducing verification blind spots and improving the flexibility of verification scenarios when verifying the ICR module. Attached Figure Description
[0023] 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.
[0024] Figure 1 is a flowchart illustrating a test case generation method according to an embodiment of this application; Figure 2 is a flowchart illustrating a test case generation method according to an embodiment of this application; Figure 3 is a flowchart illustrating a test case generation method according to an embodiment of this application; Figure 4 is an architectural diagram of a simulated test environment according to an embodiment of this application; Figure 5 is a flowchart illustrating a test case generation method according to an embodiment of this application; Figure 6 is a complete flowchart illustrating a test case generation method according to an embodiment of this application; Figure 7 is a structural diagram of a test case generation device according to an embodiment of this application; Figure 8 is a structural diagram of a test case generation equipment according to an embodiment of this application. Detailed Implementation
[0025] 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. Obviously, the described embodiments are some embodiments of this application, but not all embodiments.
[0026] 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.
[0027] In the description of this application, it should be noted that if the terms "upper", "lower", etc. appear to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, or the orientation or positional relationship that the product of this application is usually placed in, it is only for the convenience of describing this application and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.
[0028] Furthermore, the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0029] It should be noted that, where there is no conflict, the features in the embodiments of this application can be combined with each other.
[0030] This application provides a test case generation method, which is applied to a test case generation device. The test case generation device can be a terminal device or a server. For example, the terminal device can be any of the following: a computer device, a tablet computer, a laptop computer, or a smartphone.
[0031] The following explains a test case generation method provided in an embodiment of this application.
[0032] Figure 1 is a flowchart of a test case generation method provided in an embodiment of this application. As shown in Figure 1, the method may include: S101, obtaining the functional points to be verified of the ICR module.
[0033] The ICR (Interrupt Controller Redistributor) module can also be called the interrupt controller redistribution module.
[0034] It should be noted that the ICR module is an important component in system-on-a-chip design. It interacts closely with the ICD (Interrupt Controller Distributor) component and the CPU (Central Processing Unit) core (or CPU interface). The ICR module can provide localized interrupt management and configuration resources for each CPU core (or CPU interface).
[0035] In some implementations, the functional points to be verified related to the ICR module are extracted from the pre-design specification document of the ICR module. The functional points to be verified include: correct access to ICR-related registers and control of power-on and power-off of CPUIF (CPU Interface); verification of the path function between ICR and ICD and CPUIF respectively; sending and replying to interrupt handling commands; stress testing, including a large number of random tests on the number and types of interrupts.
[0036] S102. Arrange and combine the interrupt handling commands associated with the function point to be verified to obtain multiple command combinations of the function point to be verified.
[0037] The various command combinations correspond to multiple test scenarios for the functionalities to be verified. Interactions between the interrupt handling commands are also considered; one command combination corresponds to one test scenario for the functionality to be verified. Different combinations of the same command correspond to different test scenarios.
[0038] In some implementations, the commands involved in the icdp (data path from the ICD component to the ICR module) & icpd (data path from the ICR module to the ICD component) paths are selected as the command range to be combined. The command range to be combined can be considered as the interrupt handling commands associated with the function point to be verified. The interrupt handling commands associated with the function point to be verified are arranged and combined to obtain multiple command combinations of the function point to be verified.
[0039] For example, commands involved on the ICDP & ICPD pathway may include: VSET (sets an interrupt to a pending state), CLEAR (clears the interrupt pending state), RELEASE (releases an interrupt that CPUIF cannot handle), and POWER_DOWN (enters low-power or power-off mode). Specifically, VSET sets an interrupt to a pending state; CLEAR clears the interrupt pending state; RELEASE releases an interrupt that cannot be handled; and POWER_DOWN disables unnecessary functions to save power.
[0040] S103. Based on the conditions of the interrupt handling command in the various command combinations, generate multiple test cases for the functional points to be verified.
[0041] Each test case includes a test execution unit encapsulated with the conditions of each interrupt handling command in a command combination.
[0042] In some implementations, multiple test cases are generated for the functional points to be verified based on the relevant conditions of the interrupt handling command in the combination of multiple commands, so that the functional points to be verified of the ICR module can be tested in multiple test scenarios based on the multiple test cases.
[0043] It is important to note that testing the interrupt handling commands associated with the functional points to be verified involves two dimensions. The first is to verify the correctness of each interrupt handling command's response to and processing of interrupts; the second is to test multiple command combinations to achieve testing under multiple test scenarios.
[0044] In summary, this application provides a test case generation method, which includes: obtaining the function point to be verified of the Interrupt Controller Redistribution (ICR) module; arranging and combining the interrupt handling commands associated with the function point to be verified to obtain multiple command combinations for the function point to be verified; each command combination corresponds to multiple test scenarios for the function point to be verified; and generating multiple test cases for the function point to be verified based on the conditions of the interrupt handling commands in the multiple command combinations. Each test case includes a test execution unit encapsulated by the conditions of each interrupt handling command in a command combination. Arranging and combining the interrupt handling commands associated with the function point to be verified in the ICR module covers test scenarios where different interrupt handling commands interact flexibly in the internal path. In other words, the test scenarios covered by multiple command combinations are more comprehensive, greatly reducing verification blind spots and improving the flexibility of verification scenarios when verifying the ICR module.
[0045] Optionally, the process of arranging and combining the interrupt handling commands associated with the function point to be verified in S102 above to obtain multiple command combinations of the function point to be verified may include: arranging and combining the interrupt handling commands associated with the function point to be verified according to the command constraints of the ICR module for the function point to be verified to obtain multiple command combinations of the function point to be verified.
[0046] The command constraints for the function points to be verified are pre-set based on the actual functions of the ICR module.
[0047] In this embodiment, based on the command constraints of the ICR module for the function point to be verified, the interrupt handling commands associated with the function point to be verified are arranged and combined. This avoids invalid arrangements and combinations, thereby avoiding invalid test scenarios, and ensures that all possible combinations are covered, guaranteeing the completeness of the ICR module verification. This results in comprehensive and effective coverage of the various command combinations for the function point to be verified.
[0048] For example, the command constraints of the function point to be verified may include the sequential dependencies between the interrupt handling commands associated with the function point to be verified, such as executing the VSET command first and then the VCLEAR command.
[0049] Optionally, Figure 2 is a flowchart of a test case generation method provided in an embodiment of this application. As shown in Figure 2, the process of generating multiple test cases for the functional points to be verified according to the conditions of the interrupt handling command in the multiple command combinations in S103 may include: S201, encapsulating the conditions of the interrupt handling command in the command combination to obtain multiple test execution units corresponding to the command combination.
[0050] In the embodiments of this application, the interrupt handling commands interact with each other, and the interrupt handling commands in different command combinations constitute independent test scenarios. The conditions of each interrupt handling command in the command combination are encapsulated into an independent sequence, which can be flexibly invoked at various times.
[0051] A sequence is a mechanism for independently encapsulating commands or operations, typically used to build reusable, modular test scenarios or control flows. Multiple independent sequences encapsulated within a command combination can be considered as multiple test execution units corresponding to that command combination.
[0052] It should be noted that the conditions of each interrupt handling command in each command combination can be encapsulated independently at the same time, or the conditions of each interrupt handling command in each command combination can be encapsulated independently in sequence. This application embodiment does not impose specific restrictions on this.
[0053] S202. Adjust the timing interval of the test execution units corresponding to adjacent commands in multiple test execution units to obtain a test case of the function point to be verified under the test scenario corresponding to the command combination.
[0054] The ICR module has high timing requirements, so the timing interval between adjacent commands in multiple test execution units needs to be adjusted.
[0055] In some implementations, in response to an input adjustment operation, the timing intervals of adjacent command-corresponding test execution units across multiple test execution units are adjusted to obtain a test case. Using the same method, multiple test cases can be obtained, ensuring that every path within the ICR module is covered.
[0056] In this embodiment, each interrupt handling command is encapsulated into a sequence for independent invocation, which breaks through the limitation of the prior art in that interrupt handling commands are executed sequentially in a preset test scenario. This application no longer focuses only on whether the function of a single interrupt handling command is implemented, but ensures that all scenarios of flexible interaction between different interrupt handling commands in the internal path are fully covered by means of order adjustment and timing interval control.
[0057] For example, taking the VCLEAR command as an example, related technologies only need to verify whether the corresponding interrupt can be correctly released after the ICD module issues the VCLEAR command. They do not consider the timing of the interaction between the VCLEAR and VSET commands, which leads to a lack of verification scenarios for the ICR module to self-drive the generation of the RELEASE command. However, in this embodiment, by encapsulating the interrupt handling command into a sequence, precise timing adjustments can be made to flexibly control the interaction between the VCLEAR and VSET commands at different points in the path, covering all possible path test scenarios.
[0058] It should be noted that the conditions of the interrupt handling commands in the command combination are encapsulated into independent sequences. Based on the analysis of the complex relationships within the ICR module, the construction of all test scenarios related to each interrupt handling command path is designed by strictly controlling the timing and order of the interaction of each interrupt handling command sequence.
[0059] Optionally, Figure 3 is a flowchart of a test case generation method provided in an embodiment of this application. As shown in Figure 3, the method may further include: S301, constructing a simulation test environment for the ICR module, wherein the test environment includes at least: a first simulation component and a second simulation component.
[0060] The first simulation component is used to simulate the interrupt controller distributing the ICD module to communicate with the ICR module, and the second simulation component is used to simulate the processor communicating with the ICR module. The first simulation component can also be called the ICD agent, and the second simulation component can also be called the CPUIF agent.
[0061] In some implementations, by analyzing and sorting out the functions and related interfaces of the ICR module, components such as ICD agent, CPUIF agent and scoreboard are constructed, and the simulation test environment is configured through config_db (configuration resource database in UVM), where UVM is the standard methodology for integrated circuit verification.
[0062] Figure 4 is a schematic diagram of the architecture of a simulation test environment provided in an embodiment of this application. As shown in Figure 4, the simulation test environment includes a first simulation component, a second simulation component, and an ICR module. The first simulation component and the ICR module interact with each other, and the second simulation component and the ICR module can also interact. In this embodiment, a modular and reusable approach is adopted to build an independent verification environment for the ICR module by constructing the first simulation component and the second simulation component. This not only enables accurate coverage of the ICR module's functional verification but also supports functional expansion and maintenance after subsequent module functional iterations.
[0063] S302. Use a simulated testing environment to execute multiple test cases to verify the functional points of the ICR module to be verified.
[0064] The simulation test environment is a modular verification environment that constitutes an efficient and reusable system.
[0065] In some implementations, a first and second simulation component in a simulated test environment are used in conjunction with a real ICR module with a specific physical structure to execute multiple test cases; the interaction between the interface signals and data acquisition are driven by the first and second simulation components, and the results are compared based on the scoreboard component to verify whether the verification function can be implemented correctly.
[0066] Among them, the ICR module, as a DUT (Design Under Test), has built-in logic for independently parsing command messages, which can identify the command type and extract valid information according to the protocol fields; at the same time, the ICR module can also generate response reports or send commands to the ICD agent, and the output data format also conforms to the protocol specifications.
[0067] It should be noted that the simulation test environment provided in this embodiment is based on the UVM layered architecture and componentization concept, realizing a logical closed loop of stimulus injection, data monitoring, result comparison, and coverage analysis. In the UVM architecture, data interaction between different modules can be achieved through the config_db mechanism.
[0068] In this embodiment, when executing test cases, a set operation (which refers to storing configuration information in the configuration database using the uvm_config_db mechanism) can be performed on the virtual interface at the top level of the simulated test environment. Then, the Driver and Monitor in the ICD agent and CPUIF agent complete the corresponding get operations (which refer to retrieving configuration information from the configuration database using the uvm_config_db mechanism), thus realizing data monitoring and collection. The Driver can drive the ICR module through the virtual interface, triggering the functional behavior of the ICR module.
[0069] Specifically, through the interaction between the ICD agent and the CPUIF agent's driver interface signals, the driver in the ICD agent drives the excitation to the input interface of the ICR module via a virtual interface; the output interface of the ICR module drives the driver component of the ICD agent via a virtual interface; the output interface of the ICR module drives the driver component of the CPUIF agent via a virtual interface; and the driver of the CPUIF agent drives the input interface of the ICR module via a virtual interface.
[0070] In addition, the Monitors in the ICD agent and CPUIF agent monitor and collect signal changes from the ICR module, transmitting the data to the scoreboard via the TLM (Transaction Level Modeling) mechanism. The Monitor in the ICD agent transmits data to the scoreboard via TLM. The interrupt number and its corresponding core number are extracted from the data, packaged into a structure, and pushed into the queue q_irqs. The Monitor in the CPUIF agent transmits the data to the scoreboard via TLM. If the CPUIF agent detects that the interrupt has been successfully processed, it indicates that the ICR module correctly sent the interrupt to the CPUIF agent and processed it. Simultaneously, the structure corresponding to the interrupt number is deleted from q_irqs.
[0071] It should be noted that if no structure corresponding to the processed interrupt is found in q_irqs, it is determined that there is a retransmission or mistransmission exception during the interrupt transmission process. In the report_phase stage of the scoreboard component (used to generate verification reports and statistics), it is checked whether the size of q_irqs is ultimately 0. If it is not 0, it means that there is an interrupt loss in the interrupt handling process of the ICR module. For these two types of exceptions, scoreboard will automatically report error information.
[0072] Optionally, Figure 5 is a flowchart of a test case generation method provided in an embodiment of this application. As shown in Figure 5, the process of building a simulated test environment for the ICR module in S301 above may include: S401, building a bidirectional data interaction path between the first simulation component and the ICR module through an extensible stream interface.
[0073] It is worth noting that the first simulation component serves as the behavioral simulation carrier for the ICD module. This component establishes a bidirectional data interaction path with the ICR module via the AXI_STREAM interface (Advanced Extensible Stream Interface). It supports the simulation of interaction between all messages in the ICDP & ICPD paths, covering all functions of the ICR module, such as uplink / downlink paths, interrupt sending and replying, and command sending and replying.
[0074] S402. Establish message interaction of the standard protocol between the second simulation component and the ICR module.
[0075] The second simulation component simulates the behavior of the CPUIF, interacts with the ICR module via standard protocol messages, and performs the simulation function of the CPU interface interrupt handling process. Its core functions include: receiving and transmitting interrupt request messages reported by the ICR module, parsing interrupt types and priorities, and simulating interrupt response actions of the CPU interface. For example, interrupt response actions may include interrupt identification / acknowledgment, setting interrupt priority masking, defining interrupt preemption strategies, and interrupt status management.
[0076] In addition, the information exchange between the first simulation component, the ICD Agent, and the ICR module is conducted through the ICDP & ICPD pathway. Since the simulation test environment of the ICR module does not include a real ICD module, the relevant interrupt handling commands need to be independently encapsulated in the form of sequences according to a fixed message format to obtain the corresponding test execution units.
[0077] In this embodiment, the command paths that the ICR module needs to verify are encapsulated into independent sequences. Then, during the verification process of different test cases, the calling order and interval sequence between different command sequences can be specified more flexibly according to actual needs. Unlike related technologies, where command sending must be sequential and delays cannot be precise down to each clock cycle, this makes the verification of the ICR module more flexible.
[0078] Optionally, the process of using a simulated test environment to execute multiple test cases in S302 above to verify the functional points to be verified of the ICR module may include: using a simulated test environment to execute multiple test cases; if the ICR module has sent a voltage setting command to the second simulated component and the ICR module has received a voltage clearing command sent by the first simulated component, then the second simulated component sends a voltage release command to the ICR module to verify the path function between the ICR module, the first simulated component, and the second simulated component.
[0079] Using a simulated test environment, multiple test cases are executed. If the ICR module does not send a voltage setting command to the second simulated component, and the ICR module receives a voltage clearing command sent by the first simulated component, a voltage release command is generated internally by the ICR module to verify the path function between the ICR module, the first simulated component, and the second simulated component.
[0080] The VSET command is used to set an interrupt to a pending state, while the VCLEAR command is used to clear the pending state. These two commands can act at different times, with different driving logic responsible for clearing the interrupt. This application's embodiment uses the interaction between the VSET and VCLEAR commands as an example to illustrate a test scenario of timing-based interaction. During the execution of test cases, the interrupt handling commands involved are not limited to the interaction of these two commands.
[0081] In some implementations, a simulated test environment is used to execute multiple test cases. If the VSET command has been forwarded to the CPUIF agent by the ICR module, and the ICR module has received the VCLEAR command sent by the ICD agent, then the CPUIFagent driver sends a RELEASE command to the ICR module of the cpuif_rel path.
[0082] The cpuif_rel path refers to the release command signal path between the processor interface and the ICR module. Its core function is to handle interrupts that CPUIF cannot process by re-leasing them.
[0083] In other implementations, a simulated test environment is used to execute multiple test cases. If the ICR module has prepared the VSET command but has not sent it to the CPUIF agent, the ICR module receives the VCLEAR command sent by the ICDagent. The ICR module abandons forwarding the VSET command to the CPUIF agent and directly uses the switch_rel path inside the ICR module to form the VRELEASE command and reply to the ICD module.
[0084] The switch_rel path refers to the control or status signal path related to release within the ICR module. In other words, the switch_rel path is the path within the ICR module that self-drives the generation of the RELEASE command.
[0085] In the embodiments of this application, the interaction method and driving logic of the VSET and VCLEAR commands can be different at different times, thus covering a wider range of test scenarios and making the verification of the ICR module more flexible and comprehensive.
[0086] Optionally, the process of using a simulated test environment to execute multiple test cases in S302 above to verify the functional points to be verified of the ICR module may include: using a simulated test environment to execute multiple test cases; if the first simulated component sends a power-down message to the ICR module, the ICR module receives the power-down message and sends all power-down messages to the second simulated component to control the second simulated component to power down.
[0087] Using a simulated testing environment, multiple test cases are executed. If the first simulated component sends a power-on message to the ICR module, the ICR module receives the power-on message and sends a power-on message to the second simulated component to control the power-on of the second simulated component.
[0088] In some implementations, a simulated test environment is used to execute multiple test cases. The ICD agent sends a power-down message carrying the target CPU serial number to the ICR module. The ICR module receives the power-down message, parses it to obtain the parsed power-down message, and sends a power-down message conforming to the protocol specification to the CPUIF agent according to the parsed power-down message, so as to control the target CPUIF corresponding to the target CPU serial number in the second simulation component to power on.
[0089] In other implementations, a simulated test environment is used to execute multiple test cases. The ICD agent sends a power-on message carrying the target CPU serial number to the ICR module. The ICR module receives the power-on message, parses it to obtain the parsed power-on message, and sends a power-on message conforming to the protocol specification to the CPUIF agent according to the parsed power-on message, so as to control the target CPUIF corresponding to the target CPU serial number in the second simulation component to power on.
[0090] In addition, when executing test cases to verify stress testing, a large number of interrupt requests are continuously sent to the ICR module on the ICD agent side, and monitoring is performed on the CPUIF agent side to verify whether there are any abnormal situations such as interrupt loss, retransmission, or incorrect transmission in high-load scenarios.
[0091] It should be noted that in some test scenarios, interrupt handling commands and power-down messages may appear. The following explains the different processing order in such scenarios. The power-down message for the target CPU number can be the CPUIF (CPU interface) power-down command.
[0092] For example, in some test scenarios, there may be interaction between the interrupt VSET command and the CPUIF power-down command. The VSET command can be executed both before and after the CPUIF power-down command. If the CPUIF power-down command is sent first and then the VSET command is sent, the ICR module will not forward the VSET command to the CPUIF agent. After the CPUIF power-on command is sent subsequently, the ICR module will automatically forward the interrupt VSET command to the CPUIF agent for processing. If the VSET command is sent to the ICR module first and then the CPUIF power-down command is executed, the interrupt will be released.
[0093] It should be noted that this example in this application uses the interaction between the interrupt VSET command and the CPUIF power-down command as an example to illustrate different processing order scenarios. During the execution of the test cases, the commands involved are not limited to the interaction between these two commands.
[0094] The test case generation method provided in this application embodiment is applicable to all SOC (System on a Chip) design architectures that include ICR modules. Based on the UVM methodology, it verifies all functions and pathways involved in the ICR module through test scenarios.
[0095] When testing in a full-scale UT environment (module-level environment), the focus is primarily on interactions between modules, such as message interactions (reading / writing registers / command information, etc.) between the ITS (Interrupt Translation Service) module and the ICD module, and message interactions (SET (set interrupt to pending state) / ACTIVATE (interrupt being processed by CPUIF) / CLEAR (clear interrupt pending state), etc.) between the ICD module and the ICR module. However, this embodiment verifies the ICR module in an independent environment, thus providing a more complete view of the internal pathways of the ICR module.
[0096] For example, the ICR module has two paths for sending VSET commands: a bypass path and a u_dn_sw path. The bypass path is used first, and the u_dn_sw path is only used if the CPUIF agent fails to respond promptly. However, in the overall UT verification process, only the correct interrupt handling of VSET commands sent from the ICD module to the ICR module is monitored, thus ignoring the u_dn_sw path. Therefore, building an independent ICR module environment that covers every path within the ICR module is essential for complete coverage.
[0097] In this embodiment, by constructing a first simulation component and a second simulation component, an independent simulation test environment is built for the ICR module. Furthermore, the command paths that the ICR module needs to verify are encapsulated into independent sequences; that is, the conditions of each interrupt handling command in the command combination are encapsulated into independent sequences. This allows for flexible control of the verification scenario into a configurable and more complete framework, enabling more efficient completion of the verification requirements of complex ICR modules. Based on sequences, all functions and internal paths involved in the ICR module can be fully covered for testing, thus meeting the high coverage requirements in verification work. Optionally, in this embodiment, before obtaining the functional points to be verified in the ICR module, each interrupt handling command related to the ICR module can also be encapsulated into an independent sequence.
[0098] Figure 6 is a complete flowchart of a test case generation method provided in an embodiment of this application. As shown in Figure 6, the test case generation method may include: developing a verification environment and encapsulating the conditions of each interrupt handling command related to the ICR module into an independent sequence; obtaining the functional points to be verified in the ICR module and a complete verification plan report; constructing test scenarios for the functional points to be verified and flexibly controlling the order and delay between sequences; and executing test cases to verify the functional points to be verified.
[0099] In this way, each interrupt handling command is encapsulated into a sequence, which can be called more flexibly at different times. This allows for flexible control of the calling order and interaction timing of different command sequences, thus creating a rich scenario where various interrupt handling commands interact at different times and in different orders within the internal path, thereby addressing the problem of significant functional coverage deficiencies in some paths.
[0100] The following describes the test case generation apparatus, test case generation device, and storage medium used to execute the test case generation method provided in this application. For the specific implementation process and technical effects, please refer to the relevant content of the test case generation method above, which will not be repeated below.
[0101] Figure 7 is a schematic diagram of a test case generation device provided in an embodiment of this application. As shown in Figure 7, the device includes: an acquisition module 101, used to acquire the function point to be verified of the Interrupt Controller Redistribution (ICR) module; a combination module 102, used to arrange and combine the interrupt handling commands associated with the function point to be verified to obtain multiple command combinations of the function point to be verified; the multiple command combinations correspond to multiple test scenarios of the function point to be verified; and a generation module 103, used to generate multiple test cases of the function point to be verified according to the conditions of the interrupt handling commands in the multiple command combinations, each test case including: a test execution unit encapsulated by the conditions of each interrupt handling command in the command combination.
[0102] Optionally, the combination module 102 is specifically used to arrange and combine the interrupt handling commands associated with the function point to be verified according to the command constraints of the ICR module for the function point to be verified, so as to obtain multiple command combinations of the function point to be verified.
[0103] Optionally, the generation module 103 is specifically used to encapsulate the conditions of the interrupt handling command in the command combination to obtain multiple test execution units corresponding to the command combination; and to adjust the timing interval of the test execution units corresponding to adjacent commands in the multiple test execution units to obtain a test case of the function point to be verified under the test scenario corresponding to the command combination.
[0104] Optionally, the apparatus further includes: a construction module for constructing a simulated test environment for the ICR module, the test environment including at least: a first simulation component and a second simulation component, wherein the first simulation component is used to simulate an interrupt controller distributing an ICD module communicating with the ICR module, and the second simulation component is used to simulate a processor communicating with the ICR module; and an execution module for using the simulated test environment to execute the plurality of test cases to verify the functional points to be verified of the ICR module.
[0105] Optionally, the building module is specifically used to build a bidirectional data interaction path between the first simulation component and the ICR module through an extensible stream interface; and to build a standard protocol message interaction between the second simulation component and the ICR module.
[0106] Optionally, the execution module is specifically used to execute the multiple test cases in the simulated test environment. If the ICR module has sent a voltage setting command to the second simulation component and the ICR module has received a voltage clearing command sent by the first simulation component, then the second simulation component sends a voltage release command to the ICR module to verify the path function between the ICR module, the first simulation component, and the second simulation component. If the ICR module has not sent the voltage setting command to the second simulation component and the ICR module has received a voltage clearing command sent by the first simulation component, then the ICR module internally generates the voltage release command to verify the path function between the ICR module, the first simulation component, and the second simulation component.
[0107] Optionally, the execution module is specifically used to execute the multiple test cases using the simulated test environment. If the first simulated component sends a power-down message to the ICR module, the ICR module receives the power-down message and sends a power-down message to the second simulated component to control the second simulated component to power down. Alternatively, when executing the multiple test cases using the simulated test environment, if the first simulated component sends a power-on message to the ICR module, the ICR module receives the power-on message and sends a power-on message to the second simulated component to control the second simulated component to power on.
[0108] The above-described device is used to execute the method provided in the foregoing embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.
[0109] These modules can be one or more integrated circuits configured to implement the above methods, such as one or more Application Specific Integrated Circuits (ASICs), one or more digital signal processors (DSPs), or one or more Field Programmable Gate Arrays (FPGAs). Alternatively, when a module is implemented using processing element scheduler code, the processing element can be a general-purpose processor, such as a Central Processing Unit (CPU) or other processor capable of calling program code. Furthermore, these modules can be integrated together as a system-on-a-chip (SOC).
[0110] Figure 8 is a schematic diagram of a test case generation device provided in an embodiment of this application. As shown in Figure 8, the test case generation device includes a processor 201 and a memory 202.
[0111] The memory 202 is used to store programs, and the processor 201 calls the programs stored in the memory 202 to execute the above method embodiments. The specific implementation and technical effects are similar, and will not be described in detail here.
[0112] Optionally, this application also provides a program product, such as a computer-readable storage medium, including a program that, when executed by a processor, performs the above-described method embodiments.
[0113] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0114] The units described as separate components may or may not be physically separate. The components shown as units 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.
[0115] Furthermore, 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. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.
[0116] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0117] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A test case generation method, characterized in that, include: Obtain the functional points to be verified in the Interrupt Controller Redistribution (ICR) module; The interrupt handling commands associated with the function point to be verified are arranged and combined to obtain multiple command combinations for the function point to be verified; the multiple command combinations correspond to multiple test scenarios for the function point to be verified. Based on the conditions of the interrupt handling commands in the various command combinations, multiple test cases are generated for the functional points to be verified. Each test case includes a test execution unit encapsulated by the conditions of each interrupt handling command in the command combination.
2. The method according to claim 1, characterized in that, The step of arranging and combining the interrupt handling commands associated with the function point to be verified to obtain multiple command combinations for the function point to be verified includes: arranging and combining the interrupt handling commands associated with the function point to be verified according to the command constraints of the ICR module for the function point to be verified to obtain multiple command combinations for the function point to be verified.
3. The method according to claim 1, characterized in that, The step of generating multiple test cases for the functional point to be verified based on the conditions of the interrupt handling commands in the various command combinations includes: encapsulating the conditions of the interrupt handling commands in the command combinations to obtain multiple test execution units corresponding to the command combinations; adjusting the timing interval of the test execution units corresponding to adjacent commands in the multiple test execution units to obtain a test case for the functional point to be verified under the test scenario corresponding to the command combination.
4. The method according to claim 1, characterized in that, The method further includes: constructing a simulation test environment for the ICR module, the test environment including at least: a first simulation component and a second simulation component, wherein the first simulation component is used to simulate an interrupt controller distributing an ICD module that communicates with the ICR module, and the second simulation component is used to simulate a processor that communicates with the ICR module; using the simulation test environment, executing the plurality of test cases to verify the functional points to be verified of the ICR module.
5. The method according to claim 4, characterized in that, The construction of the simulation test environment for the ICR module includes: constructing a bidirectional data interaction path between the first simulation component and the ICR module through an extensible stream interface; and constructing message interaction of the standard protocol between the second simulation component and the ICR module.
6. The method according to claim 4, characterized in that, The step of executing the multiple test cases in the simulated test environment to verify the functional points of the ICR module includes: executing the multiple test cases in the simulated test environment; if the ICR module has sent a voltage setting command to the second simulation component and the ICR module has received a voltage clearing command sent by the first simulation component, then the second simulation component sends a voltage release command to the ICR module to verify the path function between the ICR module, the first simulation component, and the second simulation component; and executing the multiple test cases in the simulated test environment; if the ICR module has not sent the voltage setting command to the second simulation component and the ICR module has received a voltage clearing command sent by the first simulation component, then the ICR module internally generates the voltage release command to verify the path function between the ICR module, the first simulation component, and the second simulation component.
7. The method according to claim 4, characterized in that, The step of executing the multiple test cases in the simulated test environment to verify the functional points to be verified of the ICR module includes: executing the multiple test cases in the simulated test environment; if the first simulated component sends a power-down message to the ICR module, the ICR module receives the power-down message and sends a power-down message to the second simulated component to control the second simulated component to power down; and executing the multiple test cases in the simulated test environment; if the first simulated component sends a power-on message to the ICR module, the ICR module receives the power-on message and sends a power-on message to the second simulated component to control the second simulated component to power on.
8. A test case generation device, characterized in that, include: The acquisition module is used to acquire the functional points to be verified from the Interrupt Controller Redistribution (ICR) module. The combination module is used to arrange and combine the interrupt handling commands associated with the function point to be verified to obtain multiple command combinations of the function point to be verified; the multiple command combinations correspond to multiple test scenarios of the function point to be verified. The generation module is used to generate multiple test cases for the functional point to be verified based on the conditions of the interrupt handling commands in the various command combinations. Each test case includes a test execution unit encapsulated by the conditions of each interrupt handling command in the command combination.
9. A test case generation device, characterized in that, include: A memory and a processor, wherein the memory stores a computer program executable by the processor, and the processor executes the computer program to implement the test case generation method according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when read and executed, implements the test case generation method according to any one of claims 1-7.