Interrupt monitoring module verification system and method based on UVM verification methodology

Abstract

The invention relates to an interrupt monitoring module verification system and method based on UVM verification methodology, an advanced verification platform integrating error injection, collection and check of an interrupt monitoring module is built through a SystemVerilog language, and the system comprises a basic test component, an instantiated peripheral, a Cortex-M microcontroller, a storage unit and the interrupt monitoring module to be verified. A real interrupt service program processing process is simulated through interaction of the peripheral and the Cortex-M microcontroller, so that the verification process of the interrupt monitoring module is more in line with a real use scene, meanwhile, the accuracy and completeness of verification of the interrupt monitoring module are guaranteed through combination of multiple scenes such as high randomness of a test case and error injection, and the verification efficiency of the interrupt monitoring module is improved. The synchronization of the interrupt monitoring module to be tested and the verification environment is realized with low configuration cost, and the verification efficiency of the interrupt monitoring module is greatly improved.

Description

Technical Field

[0001] The invention belongs to the technical field of chip verification, and relates to an interrupt monitoring module verification system and method based on UVM verification methodology. Background Art

[0002] In the early days of computer development, the CPU could only access and process various hardware peripherals in the order in which the program was written. This working method is called polling. Since the status of the input and output devices must be checked after each task is completed, it leads to delayed response time, the device cannot count and process requests, and low resource utilization efficiency. After that, interrupt technology was used on computers for the first time. When a hardware peripheral has a transaction that needs to be processed by the CPU, it can send an interrupt request signal (IRQ). When the CPU receives the interrupt request signal from the hardware peripheral, the CPU will temporarily interrupt the execution of the current task and execute the new transaction corresponding to the interrupt request signal. After the new transaction is processed, it will continue to execute the current interrupted task. The existence of interrupts significantly improves the system's responsiveness and the computer's resource utilization, making multi-tasking scenario processing more efficient and improving overall performance.

[0003] With the rapid development of hardware peripherals and computers, the CPU needs to process more and more interrupts in a short period of time. In order to ensure that key tasks can be processed in time, the concept of interrupt priority is born. In the Cortex-M series microcontroller, it supports up to 240 interrupt sources and adopts the Nested-Vectored-Interrupt-Controller (NVIC), allowing users to configure multiple interrupt priorities to achieve nested interrupt processing. The internal priorities of the nested vectored interrupt controller are divided into preemption priority and response priority. The preemption priority is expressed as follows: if the preemption priority of an interrupt is higher than the currently executing interrupt, it can interrupt the current interrupt and be executed first. The smaller the value of the preemption priority, the higher the priority; the response priority is expressed as follows: if two interrupts arrive at the same time and their preemption priorities are the same, the interrupt with a higher response priority will be responded to first. The smaller the value of the response priority, the higher the priority. The response priority and preemption priority of each interrupt can be determined by configuring the NVIC.

[0004] In order to ensure that the processor can handle interrupts according to the required priority, the Interrupt Monitor module is designed and used to detect errors in the interrupt processing process. When the Cortex-M microcontroller handles interrupts abnormally due to incorrect NVIC configuration or random hardware failure, that is, the interrupt processing priority is inconsistent with the preset priority, the Interrupt Monitor module will generate an alarm and record it and report it to the Cortex-M microcontroller to avoid further errors.

[0005] In order to ensure the correctness of the interrupt monitoring module, it is necessary to conduct comprehensive testing and verification of the interrupt monitoring module. At present, the testing of the interrupt monitoring module through FPGA (Field-Programmable Gate Array) has the problems of difficult construction of incentives and incomplete scenario coverage. Therefore, how to build a complete verification platform for the interrupt monitoring module, accurately simulate the real interrupt priority processing scenario based on the Cortex-M microcontroller and use a large number of random incentives to ensure the completeness of its functions is a technical problem that the verification personnel urgently need to solve. Summary of the invention

[0006] In view of the problems existing in the above-mentioned traditional technology, the present invention proposes an interrupt monitoring module verification system based on UVM verification methodology and an interrupt monitoring module verification method based on UVM verification methodology, which can construct a real and complete interrupt priority processing scenario and fully verify the basic functions of the interrupt monitoring module.

[0007] In order to achieve the above objectives, the embodiments of the present invention adopt the following technical solutions: On the one hand, an interrupt monitoring module verification system based on UVM verification methodology is provided, including a verification platform built with SystemVerilog language, a basic test component is created based on the verification platform and an instantiation design integration is performed; the basic test component is used to create a verification environment and construct various test cases for realizing peripherals to send interrupts according to various verification scenarios, and each test case includes a non-error injection case and an error injection case; The design integration includes peripherals, Cortex-M microcontrollers, storage units and interrupt monitoring modules to be verified. The verification environment communicates with the design code of the design integration by modifying the content of the flag address in the storage unit. The Cortex-M microcontroller reads and writes peripherals, reads and writes registers of the interrupt monitoring module and exits the interrupt service program by fetching instructions. After the peripheral configuration generates an interrupt, it is sent to the interrupt monitoring module and the Cortex-M microcontroller. When selecting the test function, if the test case is selected as a non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to have the same interrupt processing priority, and the same interrupt request is selected. The external interrupt is configured to start. After all interrupts are set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemption priority. The interrupt monitoring module monitors the highest priority interrupt and is expected not to generate abnormal alarms. The non-error injection case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior. If the test case is selected as an error injection case, the interrupt processing priorities of the configured Cortex-M microcontroller and the interrupt monitoring module are inconsistent, and the interrupt monitoring module generates an exception alarm and records it in the error record; by comparing the expected exception alarm result in the error record with the actual exception alarm result, if the results are inconsistent, stop the simulation, otherwise end the simulation.

[0008] On the other hand, a UVM-based interrupt monitoring module verification method is provided, which is applied to an interrupt monitoring module verification system based on the UVM-based verification methodology. The interrupt monitoring module verification system includes a verification platform built using the SystemVerilog language, and a basic test component is created based on the verification platform and an instantiation design integration is performed; the basic test component is used to create a verification environment and construct various test cases for realizing peripherals sending interrupts according to various verification scenarios, and each test case includes a non-error injection case and an error injection case; The design integration includes peripherals, Cortex-M microcontrollers, storage units and interrupt monitoring modules to be verified. The verification environment communicates with the design code of the design integration by modifying the content of the flag address in the storage unit. The Cortex-M microcontroller reads and writes peripherals, reads and writes registers of the interrupt monitoring module and exits the interrupt service program by fetching instructions. After the peripheral configuration generates an interrupt, it is sent to the interrupt monitoring module and the Cortex-M microcontroller. The interrupt monitoring module verification method based on UVM verification methodology includes the following steps: When selecting the test function, if the test case is selected as a non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured with the same interrupt processing priority and the same interrupt request is selected; The interrupt is set outside the configuration, and after waiting for all interrupts to be set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemption priority; the interrupt monitoring module monitors the highest priority interrupt and is expected not to generate abnormal alarms. The non-error injection use case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior; If the test case is selected as an error injection case, the interrupt processing priorities of the configured Cortex-M microcontroller and the interrupt monitoring module are inconsistent; the interrupt monitoring module generates an abnormal alarm and records it in the error log; By comparing the expected abnormal alarm results in the error record with the actual abnormal alarm results, if the results are inconsistent, the simulation is stopped, otherwise the simulation is ended.

[0009] One of the above technical solutions has the following advantages and beneficial effects: The above-mentioned interrupt monitoring module verification system and method based on UVM verification methodology adopts UVM verification environment, and builds an advanced verification platform integrating error injection, collection and inspection of the interrupt monitoring module through SystemVerilog language, which includes basic test components and instantiates design integration, and the design integration includes peripherals, Cortex-M microcontrollers, storage units and interrupt monitoring modules to be verified. The real interrupt service program processing process is simulated through the interaction between the peripherals and the Cortex-M microcontroller, so that the verification process of the interrupt monitoring module is more in line with the real usage scenario. At the same time, the combination of high randomness of test cases and multiple scenarios such as error injection ensures the accuracy and completeness of the verification of the interrupt monitoring module, so as to achieve the synchronization of the interrupt monitoring module to be tested and the verification environment with low configuration cost, and greatly improve the verification efficiency of the interrupt monitoring module. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the conventional technology, the drawings required for use in the embodiments or the conventional technology descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0011] Figure 1 It is a module structure block diagram of an interrupt monitoring module verification system based on UVM verification methodology in one embodiment; Figure 2 A schematic diagram of an interrupt processing flow of an interrupt monitoring module verification system based on UVM verification methodology in one embodiment; Figure 3 The figure is a flow chart of an interrupt monitoring module verification method based on UVM verification methodology in one embodiment. DETAILED DESCRIPTION

[0012] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention is further described in detail below in conjunction with the accompanying drawings and Examples. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art of the present invention. The terms used in the specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention.

[0013] It should be noted that the reference to "embodiment" in this article means that the specific features, structures or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The presentation of this phrase at various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It will be appreciated by those skilled in the art that the embodiments described herein may be combined with other embodiments. The term "and / or" used in the specification of the present invention and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0014] The following will describe the implementation of the present invention in detail with reference to the accompanying drawings in the embodiment diagram of the present invention.

[0015] In one embodiment, Figure 1 As shown, an interrupt monitoring module verification system based on UVM verification methodology is provided, including a verification platform testbench (i.e., TB) built using SystemVerilog language, a basic test component base_test (test case base class) is created based on the verification platform testbench and instantiated design integration; the basic test component base_test is used to create a verification environment env and construct various test cases for implementing peripherals to send interrupts according to various verification scenarios, and is used to declare environment variables, environment configuration information, and create various functions for test cases to call; the test cases include non-error injection cases and error injection cases.

[0016] The design integration includes peripherals, Cortex-M microcontrollers, storage units and interrupt monitoring modules to be verified. The verification environment communicates with the design code of the design integration by modifying the content of the flag address in the storage unit. The Cortex-M microcontroller reads and writes peripherals, reads and writes registers of the interrupt monitoring module and exits the interrupt service routine by fetching instructions. After the peripheral configuration generates an interrupt, it is sent to the interrupt monitoring module and the Cortex-M microcontroller.

[0017] When selecting the test function, if the test case is selected as a non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to have the same interrupt processing priority, and the same interrupt request is selected. The external interrupt is configured to start. After all interrupts are set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemption priority. The interrupt monitoring module monitors the highest priority interrupt and is expected not to generate abnormal alarms. The non-error injection case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior. If the test case is selected as an error injection case, the interrupt processing priorities of the configured Cortex-M microcontroller and the interrupt monitoring module are inconsistent, and the interrupt monitoring module generates an abnormal alarm and records it in the error record; by comparing the expected result with the actual result in the error record, if the expected result is inconsistent with the actual result, the simulation is stopped, otherwise the simulation is ended.

[0018] It can be understood that the design of each component in the above-mentioned verification platform testbench follows the existing UVM verification methodology. According to the functional verification needs of the interrupt monitoring module to be verified, the components of the corresponding functions are configured based on the verification platform testbench and the basic operations such as connection and connectivity testing between the components are completed to ensure normal data flow between the components during the verification process.

[0019] The created top-level simulation file is used to initialize the verification platform testbench (top-level file), start test cases and other basic operations. Based on the verification platform testbench, the design integration containing the module to be verified (i.e., the interrupt monitoring module) is instantiated. The design integration includes the Cortex-M microcontroller, storage unit, optional peripherals and the interrupt monitoring module to be tested, such as Figure 1 As shown. Based on the verification platform testbench, a backdoor write function is created for the storage space where the flag address, register address and data address for accessing the Cortex-M microcontroller are located, which is used to access the registers of the peripherals or the registers in the Cortex-M microcontroller. Based on the verification platform testbench, a backdoor read and backdoor write function for the interrupt flag address accessed by the Cortex-M microcontroller is also created to enable the verification environment env to sense whether the Cortex-M microcontroller has entered the interrupt service program, and to control the Cortex-M microcontroller to exit the interrupt service program. In order to simulate the real interrupt service program, after the verification environment env senses that the Cortex-M microcontroller has entered the interrupt service program, it will wait for a random time to clear the interrupt, and then wait for a random time to clear the data in the interrupt flag address, so that the Cortex-M microcontroller exits the interrupt service program.

[0020] The verification environment communicates with the design code by modifying the content of the flag address in the storage unit. Figure 1 The double arrows in the figure indicate that the Cortex-M microcontroller implements operations such as reading and writing peripherals, reading and writing registers of the interrupt monitoring module, and exiting the interrupt service program by fetching instructions. After the peripheral configuration generates an interrupt, it is sent to the interrupt monitoring module and the Cortex-M microcontroller. The basic test component base_test (test case base class) is used to create the platform environment env, declare environment variables, configuration information, and create various functions for test case calls. These environment variables, configuration information, and various functions can be selected on the verification platform according to the verification requirements of the interrupt monitoring module to be tested. Among them, the environment variables can realize the control of the clock frequency of the peripherals, the Cortex-M microcontroller, and the interrupt monitoring module, and the created initialization function can realize the initialization of the verification platform environment, the Cortex-M microcontroller, and the peripherals.

[0021] In order to correctly cover the preemption priority and response priority functions in the Cortex-M microcontroller, different test cases can be created based on the test case base_test base class to enable the peripherals to send interrupts according to the required functional verification scenarios, such as all interrupts are generated at the same time or the same interrupt is generated randomly in different orders. In order to ensure that the interrupt monitoring module can correctly output interrupt exception alarms, an error injection case that violates the expected interrupt processing priority is also constructed. When the interrupt processing priority of the Cortex-M microcontroller and the interrupt monitoring module is consistent, it will be checked that the interrupt monitoring module cannot issue an interrupt exception alarm. When the interrupt processing priority of the Cortex-M microcontroller and the interrupt monitoring module is inconsistent, it will be checked that the interrupt monitoring module can definitely issue an interrupt exception alarm.

[0022] Specifically, when selecting a test function, different functions can be implemented by changing the corresponding register configuration. For example, configure the interrupt processing priority of the Cortex-M microcontroller and the interrupt monitoring module to be consistent, configure the interrupt random time generation, etc. When developing an error injection use case, you can configure the interrupt processing priority of the interrupt monitoring module to be inconsistent with that of the Cortex-M microcontroller, or when the Cortex-M microcontroller enters the interrupt service routine, clear the interrupt that does not match the current interrupt service routine.

[0023] If the current test case is selected as a non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to the same interrupt processing priority and the same interrupt request is selected. After the external interrupt is configured and all interrupts are set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemption priority, and the interrupt monitoring module monitors the highest priority interrupt. After simulating the software behavior, the test case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller. At this time, it is expected that the interrupt monitoring module will not generate an abnormal alarm. If the current test case is an error injection case, the interrupt monitoring module is expected to generate an abnormal alarm and record it in the error record.

[0024] Since the error log can record the abnormal alarm generated by the expected interrupt monitoring module and the abnormal alarm actually generated by the interrupt monitoring module, the corresponding simulation result can be obtained by comparing the results in the error log. For example, if the result comparison fails, that is, the abnormal alarm generated by the expected interrupt monitoring module is inconsistent with the abnormal alarm actually generated by the interrupt monitoring module, then the comparison failure log is output and the simulation is stopped. If the result comparison is successful, that is, the abnormal alarm generated by the expected interrupt monitoring module is consistent with the abnormal alarm actually generated by the interrupt monitoring module, then the comparison pass log is output and the simulation ends.

[0025] The above-mentioned interrupt monitoring module verification system based on UVM verification methodology adopts UVM verification environment and builds an advanced verification platform integrating error injection, collection and inspection of the interrupt monitoring module through SystemVerilog language, which includes basic test components and instantiates design integration. The design integration includes peripherals, Cortex-M microcontrollers, storage units and interrupt monitoring modules to be verified. The real interrupt service program processing process is simulated through the interaction between the peripherals and the Cortex-M microcontroller, so that the verification process of the interrupt monitoring module is more in line with the real usage scenario. At the same time, the combination of high randomness of test cases and multiple scenarios such as error injection ensures the accuracy and completeness of the verification of the interrupt monitoring module, so as to achieve the synchronization of the interrupt monitoring module to be tested and the verification environment with low configuration cost, and greatly improve the verification efficiency of the interrupt monitoring module.

[0026] In one embodiment, if all interrupts are set at the same time, the Cortex-M microcontroller enters the interrupt service routine that responds to the highest priority.

[0027] It can be understood that if all interrupts are set at the same time, the Cortex-M microcontroller will enter the interrupt service routine with the highest response priority, and configure the interrupt processing priority of the interrupt monitoring module to be consistent with the response priority of the Cortex-M microcontroller. At this time, the interrupt monitoring module is expected not to generate an abnormal alarm. Otherwise, the interrupt monitoring module is expected to generate an abnormal alarm and be recorded in the error record.

[0028] In one embodiment, the verification platform also creates a coverage collection component and uses a makefile file to connect the flielist of the design code of the design integration and the filelist of the verification environment. The coverage collection component is used to collect functional coverage for verification of the interrupt monitoring module.

[0029] It can be understood that a makefile can be written on the verification platform, and after selecting the compilation tool for compilation, the flielist of the code and the filelist of the verification environment can be connected. Compilation macros and coverage collection items can also be added. Through the makefile, the test case can also be automatically run for a specified number of times, such as Figure 2 As shown: configure the NVIC register of the Cortex-M microcontroller, select the interrupt request to be tested, randomly configure the priority of the interrupt to be tested, and randomly configure the proportion of the response priority and the preemption priority; enable the interrupt monitoring module to enter the working state and pass the interrupt request to be tested, and configure the priority of the corresponding channel of the interrupt monitoring module according to the interrupt priority of the interrupt to be tested; configure the peripheral enable corresponding to the interrupt to be tested and generate an interrupt; wait for a certain time after the Cortex-M microcontroller enters the interrupt state, wait for a certain time after clearing the interrupt and check whether the interrupt monitoring module issues an abnormal alarm at the same time; exit the interrupt service program and handle the next interrupt.

[0030] Each component in the above-mentioned interrupt monitoring module verification system based on UVM verification methodology can be implemented in whole or in part by software, hardware and a combination thereof. The above-mentioned components can be embedded in or independent of a device with data processing function in the form of hardware, or can be stored in the memory of the aforementioned device in the form of software, so that the processor can call and execute the operations corresponding to the above-mentioned modules. The aforementioned device can be, but is not limited to, various types of chip verification computers already available in the art.

[0031] In one embodiment, a method for verifying an interrupt monitoring module based on UVM verification methodology is provided, which is applied to an interrupt monitoring module verification system based on UVM verification methodology. The interrupt monitoring module verification system includes a verification platform built using SystemVerilog language, and a basic test component is created based on the verification platform and an instantiation design integration is performed; the basic test component is used to create a verification environment and construct various test cases for realizing that a peripheral sends an interrupt according to various verification scenarios, and each test case includes a non-error injection case and an error injection case; The design integration includes peripherals, Cortex-M microcontrollers, storage units and interrupt monitoring modules to be verified. The verification environment communicates with the design code of the design integration by modifying the content of the flag address in the storage unit. The Cortex-M microcontroller reads and writes peripherals, reads and writes registers of the interrupt monitoring module and exits the interrupt service program by fetching instructions. After the peripheral configuration generates an interrupt, it is sent to the interrupt monitoring module and the Cortex-M microcontroller. like Figure 3 As shown, the above interrupt monitoring module verification method based on UVM verification methodology may include the following processing steps S10 to S16: S10, when selecting the test function, if the test case is selected as a non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to have the same interrupt processing priority, and the same interrupt request is selected; S12, configure the external interrupt setting, wait for all interrupts to be set, and then the Cortex-M microcontroller enters the interrupt service routine with the highest preemption priority; the interrupt monitoring module monitors the highest priority interrupt and does not generate abnormal alarms as expected, and the non-error injection use case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior; S14, if the test case is selected as an error injection case, the interrupt processing priorities of the configured Cortex-M microcontroller and the interrupt monitoring module are inconsistent; the interrupt monitoring module generates an abnormal alarm and records it in the error record; S16, by comparing the expected abnormal alarm result in the error record with the actual abnormal alarm result, if the results are inconsistent, stop the simulation, otherwise end the simulation.

[0032] The above-mentioned interrupt monitoring module verification method based on UVM verification methodology adopts UVM verification environment and builds an advanced verification platform integrating error injection, collection and inspection of the interrupt monitoring module through SystemVerilog language, which includes basic test components and instantiates design integration. The design integration includes peripherals, Cortex-M microcontrollers, storage units and interrupt monitoring modules to be verified. The real interrupt service program processing process is simulated through the interaction between the peripherals and the Cortex-M microcontroller, so that the verification process of the interrupt monitoring module is more in line with the real usage scenario. At the same time, the combination of high randomness of test cases and multiple scenarios such as error injection ensures the accuracy and completeness of the verification of the interrupt monitoring module, so as to achieve the synchronization of the interrupt monitoring module to be tested and the verification environment with low configuration cost, and greatly improve the verification efficiency of the interrupt monitoring module.

[0033] In one embodiment, if all interrupts are set at the same time, the Cortex-M microcontroller enters the interrupt service routine that responds to the highest priority.

[0034] In one embodiment, before selecting the test function, the above-mentioned interrupt monitoring module verification method based on UVM verification methodology also includes the steps of: The instruction fetch address and behavior of the Cortex-M microcontroller are constrained according to the set instruction fetch configuration; the setting instruction fetch configuration includes that when the data in the flag address used by the Cortex-M microcontroller to access the storage unit for indicating whether there is an operation currently is 0, the Cortex-M microcontroller will repeatedly access the flag address, and when the data in the flag address is not 0, the Cortex-M microcontroller determines the behavior of the next operation according to the data in the flag address; The interrupt processing behavior of the Cortex-M microcontroller is constrained according to the set behavior configuration; the set behavior configuration includes that the Cortex-M microcontroller enters the interrupt service program after receiving the interrupt sent by the peripheral, and under the interrupt service program, the Cortex-M microcontroller sends the interrupt sequence number corresponding to the currently processed interrupt to the interrupt flag address and cyclically reads the interrupt flag address, and exits the interrupt service program when the Cortex-M microcontroller reads the interrupt flag address and finds that the data is cleared.

[0035] It can be understood that the establishment of the verification platform also needs to constrain the instruction fetch address and behavior of the Cortex-M microcontroller: Specifically, the Cortex-M microcontroller will access the flag address in the storage unit to indicate whether there is an operation currently. When the data in the flag address is 0, the Cortex-M microcontroller will repeatedly access the flag address; when the data in the flag address is not 0, the next behavior of the Cortex-M microcontroller, such as read or write, is determined according to the data read from the flag address. After reading the data in the flag address, the Cortex-M microcontroller will access the register address used to indicate the register to be accessed for the next operation. After the Cortex-M microcontroller obtains the register address, if the flag indicates that the current behavior of the Cortex-M microcontroller is read, the Cortex-M microcontroller will read the data of the register corresponding to the register address; if the flag indicates that the current behavior of the Cortex-M microcontroller is write, the Cortex-M microcontroller will access the data address used to indicate the write data, and write the data read from the flag address to the register corresponding to the register address.

[0036] Constrain the interrupt processing behavior of the Cortex-M microcontroller: Specifically, when the Cortex-M microcontroller receives an interrupt from a peripheral, the Cortex-M microcontroller will enter the interrupt service routine. Under the interrupt service routine, the Cortex-M microcontroller sends the interrupt sequence number corresponding to the currently processed interrupt to the interrupt flag address, and reads the interrupt flag address cyclically. When the Cortex-M microcontroller reads the interrupt flag address and finds that the data is cleared, the Cortex-M microcontroller will exit the interrupt service routine. This process is regarded as the Cortex-M microcontroller processing an interrupt.

[0037] The above constraints allow the verification platform to be directly initialized and used when delivered for verification, so as to more conveniently ensure the accuracy and completeness of the verification of the interrupt monitoring module without the need for additional separate Cortex-M microcontroller behavior configuration.

[0038] In one embodiment, the above-mentioned interrupt monitoring module verification method based on UVM verification methodology also includes the steps of: The coverage collection component created by the verification platform is used to collect the functional coverage of the interrupt monitoring module.

[0039] It can be understood that since the interrupt monitoring module can support interrupt monitoring of multiple (for example, 8) channels at the same time, the interrupt monitoring module can cover all peripheral interrupts and various possible priority nesting situations, such as Figure 1 As shown, a coverage collection component cov is also set. Complete coverage collection requires ensuring that all peripheral interrupts can correctly enter the interrupt monitoring module. The interrupt monitoring module can arbitrarily select interrupt channel enable, all interrupt priority combinations, and the waiting time and clearing time of each interrupt, etc., so that various scenarios such as high randomness and error injection of test cases can be combined with coverage collection to make the verification more complete.

[0040] For the specific limitations of the interrupt monitoring module verification method based on the UVM verification methodology, please refer to the corresponding limitations of the interrupt monitoring module verification system based on the UVM verification methodology above, which will not be repeated here.

[0041] It should be understood that although Figure 2 and Figure 3 The steps in the method are shown in sequence as indicated by the arrows, but the steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of the steps, and the steps can be executed in other orders. Figure 2 and Figure 3At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequentially, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0042] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided by the present invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus dynamic random access memory (RambusDRAM, referred to as RDRAM) and interface dynamic random access memory (DRDRAM).

[0043] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0044] The above embodiments only express several implementation methods of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of protection of the invention. It should be pointed out that, for those of ordinary skill in the art, several modifications and improvements can be made without departing from the concept of the present invention, which all belong to the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the attached claims.

Claims

1. An interrupt monitoring module verification system based on UVM verification methodology, characterized in that, It includes a verification platform built with SystemVerilog language, based on which a basic test component is created and instantiated design integration is performed; the basic test component is used to create a verification environment and construct various test cases for implementing peripherals to send interrupts according to various verification scenarios, and each of the test cases includes a non-error injection case and an error injection case; The design integration includes peripherals, a Cortex-M microcontroller, a storage unit and an interrupt monitoring module to be verified, and the verification environment communicates with the design code of the design integration by modifying the content of the flag address in the storage unit; The Cortex-M microcontroller reads and writes the peripherals, reads and writes the registers of the interrupt monitoring module and exits the interrupt service program by fetching instructions, and the peripheral configuration generates an interrupt and sends it to the interrupt monitoring module and the Cortex-M microcontroller; When selecting the test function, if the test case is selected as the non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to have the same interrupt processing priority, and the same interrupt request is selected, the peripheral is configured to start the interrupt, and after waiting for all interrupts to be set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemption priority, and the interrupt monitoring module monitors the highest priority interrupt and does not generate an abnormal alarm; the non-error injection case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating the software behavior; If the test case is selected as the error injection case, the interrupt processing priorities of the Cortex-M microcontroller and the interrupt monitoring module are configured inconsistently, and the interrupt monitoring module generates an abnormal alarm and records it in the error record; by comparing the expected abnormal alarm result in the error record with the actual abnormal alarm result, if the results are inconsistent, the simulation is stopped, otherwise the simulation is ended.

2. The interruption monitoring module verification system based on UVM verification methodology according to claim 1, characterized in that, If all interrupts are set at the same time, the Cortex-M microcontroller enters the interrupt service routine with the highest response priority.

3. The interruption monitoring module verification system based on UVM verification methodology according to claim 1 or 2, characterized in that, The verification platform also creates a coverage collection component and uses a makefile file to connect the flielist of the design code of the design integration and the filelist of the verification environment. The coverage collection component is used to collect functional coverage for verifying the interrupt monitoring module.

4. A method for verifying an interrupt monitoring module based on UVM verification methodology, characterized in that: The invention is applied to an interrupt monitoring module verification system based on UVM verification methodology, wherein the interrupt monitoring module verification system comprises a verification platform constructed by SystemVerilog language, and a basic test component is created based on the verification platform and an instantiation design integration is performed; the basic test component is used to create a verification environment and construct various test cases for realizing peripherals to send interrupts according to various verification scenarios, and each of the test cases comprises a non-error injection case and an error injection case; The design integration includes peripherals, a Cortex-M microcontroller, a storage unit and an interrupt monitoring module to be verified, and the verification environment communicates with the design code of the design integration by modifying the content of the flag address in the storage unit; The Cortex-M microcontroller reads and writes the peripherals, reads and writes the registers of the interrupt monitoring module and exits the interrupt service program by fetching instructions, and the peripheral configuration generates an interrupt and sends it to the interrupt monitoring module and the Cortex-M microcontroller; The interrupt monitoring module verification method based on UVM verification methodology comprises the following steps: When selecting a test function, if the test case is selected as the non-error injection case, the Cortex-M microcontroller and the interrupt monitoring module are configured to have the same interrupt processing priority and the same interrupt request is selected; The peripheral is configured to start an interrupt, and after all interrupts are set, the Cortex-M microcontroller enters the interrupt service routine with the highest preemption priority; the interrupt monitoring module monitors the highest priority interrupt and does not generate an abnormal alarm in expectation, and the non-error injection use case clears the corresponding interrupt according to the current state of the Cortex-M microcontroller after simulating software behavior; If the test case is selected as the error injection case, the interrupt processing priorities of the Cortex-M microcontroller and the interrupt monitoring module are configured to be inconsistent; the interrupt monitoring module generates an abnormal alarm and records it in the error log; By comparing the expected abnormal alarm result in the error record with the actual abnormal alarm result, if the results are inconsistent, the simulation is stopped, otherwise the simulation is ended.

5. The interruption monitoring module verification method based on UVM verification methodology according to claim 4, characterized in that, If all interrupts are set at the same time, the Cortex-M microcontroller enters the interrupt service routine with the highest response priority.

6. according to the interruption monitoring module verification method based on UVM verification methodology described in claim 4 or 5, it is characterized in that, Also includes the steps: The coverage collection component created by the verification platform is used to collect the functional coverage of the interrupt monitoring module verification.

7. The interruption monitoring module verification method based on UVM verification methodology according to claim 6, wherein Before selecting the test function, the steps include: The instruction fetch address and behavior of the Cortex-M microcontroller are constrained according to the set instruction fetch configuration; the set instruction fetch configuration includes that when the data in the flag address used by the Cortex-M microcontroller to access the storage unit for indicating whether there is an operation currently is 0, the Cortex-M microcontroller will repeatedly access the flag address, and when the data in the flag address is not 0, the Cortex-M microcontroller determines the behavior of the next operation according to the data in the flag address; The interrupt processing behavior of the Cortex-M microcontroller is constrained according to the set behavior configuration; the set behavior configuration includes that the Cortex-M microcontroller enters an interrupt service program after receiving the interrupt issued by the peripheral, and under the interrupt service program, the Cortex-M microcontroller sends the interrupt sequence number corresponding to the currently processed interrupt to the interrupt flag address and cyclically reads the interrupt flag address, and exits the interrupt service program when the Cortex-M microcontroller reads the interrupt flag address and finds that the data is cleared.

Images