A uvm-based soc chip verification environment and method

CN121683642BActive Publication Date: 2026-08-11CHANGSHA CHIXIN SEMICON TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-12-17
Publication Date
2026-08-11

AI Technical Summary

Technical Problem

涉及多模块的协同工作如DMA(Direct MemoryAccess,直接内存访问)搬运数据的场景时,模块级验证往往难以覆盖,因而需等待至子系统级/系统级验证开发相关测试用例,存在的问题难以在前期发现

Benefits of technology

本发明实施例提供的一种基于UVM的SOC芯片验证环境及方法,所述验证环境包括通用环境组件以及模块定制化环境组件;所述通用环境组件包括Testbench通用部分、Test通用部分、Virtual_sequence通用部分、Env通用部分以及Virtual_sequencer通用部分;所述模块定制化环境组件包括Testbench模块定制化部分、Test模块定制化部分、Virtual_sequence模块定制化部分、Env模块定制化部分以及Virtual_sequencer模块定制化部分,通过通用环境组件以及模块定制化环境组件,避免了验证在模块级验证、子系统级验证、系统级验证、后仿真中的重复开发测试用例工作,只需进行一次测试用例开发,极大地提高了验证效率;

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121683642B_ABST
    Figure CN121683642B_ABST
Patent Text Reader

Abstract

This invention provides a UVM-based SOC chip verification environment and method. The verification environment includes general environment components and module-customized environment components. The general environment components include a general Testbench part, a general Test part, a general Virtual_sequence part, a general Env part, and a general Virtual_sequencer part. The module-customized environment components include module-customized Testbench parts, a module-customized Test part, a module-customized Virtual_sequence part, a module-customized Env part, and a module-customized Virtual_sequencer part. This invention provides a UVM-based SOC chip verification environment and method that, through the general environment components and module-customized environment components, avoids the repetitive development of test cases in module-level verification, subsystem-level verification, system-level verification, and post-simulation. Only one test case development is required, greatly improving verification efficiency.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of SOC chip verification environment technology, and in particular to a UVM-based SOC chip verification environment and method. Background Technology

[0002] System-on-a-Chip (SoC) is currently the mainstream chip form factor. A typical SoC chip integrates one or more processor cores, various dedicated hardware accelerators (such as GPUs, NPUs, and DSPs), rich peripheral interfaces (such as USB, PCIe, SDIO, and UART), complex interconnect buses, and a large number of memory modules. This high degree of integration and complexity makes SoC design verification the most critical, time-consuming, and resource-intensive part of the entire chip development process.

[0003] Currently, the mainstream SOC chip verification process is a hierarchical verification process, which involves first performing module-level verification, then subsystem-level verification, and finally system-level verification.

[0004] Module-level verification targets a single functional module, primarily focusing on the correctness of its internal functional implementation. It typically involves a high level of verification depth, requiring 100% code and functional coverage. During module-level verification, verification engineers must invest time in: building a customized environment for the module, developing components such as stimulus generation models and reference models, and developing test cases. Because the module-level verification environment is strongly correlated with module interface signals, changes to the module interface design necessitate simultaneous modifications to the verification environment, resulting in high maintenance costs. In scenarios involving multi-module collaboration, such as DMA (Direct Memory Access) data transfer, module-level verification often falls short of coverage, necessitating the development of test cases at the subsystem / system level, making it difficult to identify problems early on.

[0005] Therefore, it is necessary to provide a UVM-based SOC chip verification environment and method to effectively solve the above problems. Summary of the Invention

[0006] This invention addresses the problems and shortcomings of existing technologies by providing a UVM-based SOC chip verification environment and method. Through general-purpose environment components and module-customized environment components, it avoids the repetitive development of test cases in module-level verification, subsystem-level verification, system-level verification, and post-simulation. Only one test case development is required, which greatly improves verification efficiency.

[0007] This invention provides a UVM-based SOC chip verification environment, which includes general environment components and module-customized environment components. The general environment components include a Testbench general component, a Test general component, a Virtual_sequence general component, an Env general component, and a Virtual_sequencer general component; The module customization environment components include the Testbench module customization part, the Test module customization part, the Virtual_sequence module customization part, the Env module customization part, and the Virtual_sequencer module customization part.

[0008] Preferably, the Testbench general part is used to instantiate SOC chip code, and the Test customization part is started through the run_test method of UVM to define the simulation waveform dump option; The Test general part inherits from UVM's uvm_test, and is used to instantiate the Env general part, generate the configuration of the bus master stimulus generation model, and connect the bus master stimulus generation model signal with the SOC chip's internal bus master signal; The general part of Virtual_sequence is inherited from uvm_sequence of UVM and is used to define the tasks used by all modules for verifying the bus host stimulus generation model, SOC chip initialization process task, and SOC chip clock reset switch task. The Env general part inherits from UVM's uvm_env and is used to instantiate the bus host stimulus generation model and the Virtual_sequencer general part. The general part of Virtual_sequencer is inherited from uvm_sequencer of UVM and is used to declare the sequncer handle of the bus master stimulus generation model.

[0009] Preferably, the bus master stimulus generation model is used to replace the bus master in the SOC chip to initiate access in accordance with the bus protocol, quickly establish the bus communication path in the early stage of verification, and generate stimuli through SV test cases to fully verify each bus slave module.

[0010] Preferably, the customized code of each Testbench module exists independently in different SV files and is imported into the general part of the Testbench through the include method. The customized code of the Testbench module includes instantiating the module type model developed by the verification engineer for connection with the SOC chip.

[0011] Preferably, the customized part of the Test module inherits from the general part of Test, includes all the contents of the general part of Test, and specifies that the customized part of the Virtual_sequence module is launched on the general part of Virtual_sequencer.

[0012] Preferably, the Virtual_sequence module customization part includes module customization tasks and module customization sequences. The module customization tasks of each module exist independently in different SV files and are imported into the Virtual_sequencer general part through the include method. The module customization tasks are used to define the tasks used by the corresponding module, such as the register configuration process. The module customization sequences are inherited from the Virtual_sequence general part and are used to define the specific process of the test cases.

[0013] Preferably, the customized Env module code for each module exists independently in different SV files and is imported into the general Env part through the include method. The customized Env module code includes the instantiation of the UVM_component type model developed by the verification engineer for connection with the SOC chip.

[0014] Preferably, the customized code of the Virtual_sequencer module for each module exists independently in different SV files and is imported into the general part of the Virtual_sequencer through the include method. This is used to declare and verify the sequncer handle of the UVM_component type model developed by the engineer for module customization.

[0015] This invention also provides a verification method based on the UVM-based SOC chip verification environment described above. All of the module-customized environment components described herein are developed on a verification environment composed of the general environment components; Each of the module-customized environment components is independent of each other, and the module-customized environment component of the target module takes effect when compiling the SOC chip verification environment; When verifying the collaborative operation of multiple modules, the module-customized environment components of all targets in the SOC chip verification environment are simultaneously activated; All customized parts of the Test module are simulated before running on the SOC chip verification environment, and all test cases developed in C language in the customized parts of the Test module are simulated after running on the SOC chip verification environment.

[0016] Preferably, when the customized parts of the Testbench module, the customized task, the customized part of the Env module, and the customized part of the Virtual_sequencer module are imported into the corresponding general parts through the include method, the import is confirmed by judging the macro definition. For example, for the customized environment component of the DMA module, if the definition of DMA_TEST exists at compile time, it is imported; if the definition of DMA_TEST does not exist, it is not imported. When compiling the SOC chip verification environment, macro definitions for the target module are added in the command line using the +define method; During the compilation process, the module customization environment component of the corresponding module with macro definitions takes effect, and finally generates a simv executable file containing the name of the effective module; Run the simv executable file containing the name of the effective module, specify the customized part of the Test module to run in the command line, and obtain the simulation results.

[0017] Compared with the prior art, the technical solution of the embodiments of the present invention has the following beneficial effects: This invention provides a UVM-based SOC chip verification environment and method. The verification environment includes general environment components and module-customized environment components. The general environment components include a general Testbench part, a general Test part, a general Virtual_sequence part, a general Env part, and a general Virtual_sequencer part. The module-customized environment components include a module-customized Testbench part, a module-customized Test part, a module-customized Virtual_sequence part, a module-customized Env part, and a module-customized Virtual_sequencer part. By using the general environment components and module-customized environment components, the repetitive development of test cases in module-level verification, subsystem-level verification, system-level verification, and post-simulation is avoided. Only one test case development is required, greatly improving verification efficiency. Furthermore, it prevents issues such as verification code adaptation encountered when switching verification levels; Furthermore, it supports multiple verification engineers to perform verification work on different modules in parallel, which improves the efficiency of verification work compared to simple system-level verification. Furthermore, it can support scenarios such as inter-module collaborative work and low-power processes in the early stages of SOC chip verification, thus exposing potential problems in advance. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention, but not all embodiments. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of a UVM-based SOC chip verification environment according to a preferred embodiment of the present invention. Figure 2 This is a flowchart illustrating a preferred embodiment of a UVM-based SOC chip verification method according to the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0022] This invention addresses the problems and shortcomings of existing technologies by providing a UVM-based SOC chip verification environment and method. Through general-purpose environment components and module-customized environment components, it avoids the repetitive development of test cases in module-level verification, subsystem-level verification, system-level verification, and post-simulation. Only one test case development is required, which greatly improves verification efficiency.

[0023] Figure 1 This is a schematic diagram of a UVM-based SOC chip verification environment according to a preferred embodiment of the present invention. Figure 2 This is a flowchart illustrating a preferred embodiment of a UVM-based SOC chip verification method according to the present invention.

[0024] Now see Figure 1 The present invention provides a UVM-based SOC chip verification environment, which includes general environment components and module-customized environment components; The general environment components include a Testbench general component, a Test general component, a Virtual_sequence general component, an Env general component, and a Virtual_sequencer general component; The module customization environment components include the Testbench module customization part, the Test module customization part, the Virtual_sequence module customization part, the Env module customization part, and the Virtual_sequencer module customization part.

[0025] In specific implementation, the Testbench general part is used to instantiate SOC chip code, and the Test customized part is started through the UVM run_test method to define the simulation waveform dump option; The Test general part inherits from UVM's uvm_test, and is used to instantiate the Env general part, generate the configuration of the bus master stimulus generation model, and connect the bus master stimulus generation model signal with the SOC chip's internal bus master signal; The general part of Virtual_sequence is inherited from uvm_sequence of UVM and is used to define the tasks used by all modules for verifying the bus host stimulus generation model, SOC chip initialization process task, and SOC chip clock reset switch task. The Env general part inherits from UVM's uvm_env and is used to instantiate the bus host stimulus generation model and the Virtual_sequencer general part. The general part of Virtual_sequencer is inherited from uvm_sequencer of UVM and is used to declare the sequncer handle of the bus master stimulus generation model.

[0026] In practical implementation, the bus master stimulus generation model is used to replace the bus master in the SOC chip to initiate access in accordance with the bus protocol, quickly establish the bus communication path in the early stage of verification, and generate stimuli through SV test cases to fully verify each bus slave module.

[0027] In practice, the customized code of each Testbench module exists independently in different SV files and is imported into the general part of the Testbench through the include method. The customized code of the Testbench module includes instantiating the module type model developed by the verification engineer for connection with the SOC chip.

[0028] In specific implementation, the customized part of the Test module inherits from the general part of Test, includes all the contents of the general part of Test, and specifies that the customized part of the Virtual_sequence module is started on the general part of Virtual_sequencer.

[0029] In specific implementation, the Virtual_sequence module customization part includes module customization tasks and module customization sequences. The module customization tasks of each module exist independently in different SV files and are imported into the Virtual_sequencer general part through the include method. The module customization tasks are used to define the tasks used by the corresponding module, such as the register configuration process; the module customization sequences are inherited from the Virtual_sequence general part and are used to define the specific process of test cases.

[0030] In practice, the customized Env module code for each module exists independently in different SV files and is imported into the general Env part through the include method. The customized Env module code includes the instantiation of the UVM_component type model developed by the verification engineer for connection with the SOC chip.

[0031] In practice, the customized code of the Virtual_sequencer module for each module exists independently in different SV files. It is imported into the general part of Virtual_sequencer through the include method and is used to declare and verify the sequncer handle of the UVM_component type model developed by the engineer for module customization.

[0032] Now see Figure 2 This invention also provides a verification method based on the UVM-based SOC chip verification environment described above. All of the module-customized environment components described herein are developed on a verification environment composed of the general environment components; Each of the module-customized environment components is independent of each other, and the module-customized environment component of the target module takes effect when compiling the SOC chip verification environment; When verifying the collaborative operation of multiple modules, the module-customized environment components of all targets in the SOC chip verification environment are simultaneously activated; All customized parts of the Test module are simulated before running on the SOC chip verification environment, and all test cases developed in C language in the customized parts of the Test module are simulated after running on the SOC chip verification environment.

[0033] In specific implementation, when the customized parts of the Testbench module, the customized task of the module, the customized part of the Env module, and the customized part of the Virtual_sequencer module are imported into the corresponding general parts through the include method, the import is confirmed by judging the macro definition. For example, the customized environment component of the DMA module is imported if the definition of DMA_TEST exists at compile time, and not imported if the definition of DMA_TEST does not exist. When compiling the SOC chip verification environment, macro definitions for the target module are added in the command line using the +define method; During the compilation process, the module customization environment component of the corresponding module with macro definitions takes effect, and finally generates a simv executable file containing the name of the effective module; Run the simv executable file containing the name of the effective module, specify the customized part of the Test module to run in the command line, and obtain the simulation results.

[0034] In summary, the present invention provides a UVM-based SOC chip verification environment and method. The verification environment includes general environment components and module-customized environment components. The general environment components include a general Testbench part, a general Test part, a general Virtual_sequence part, a general Env part, and a general Virtual_sequencer part. The module-customized environment components include a module-customized Testbench part, a module-customized Test part, a module-customized Virtual_sequence part, a module-customized Env part, and a module-customized Virtual_sequencer part. By using the general environment components and module-customized environment components, the repetitive development of test cases in module-level verification, subsystem-level verification, system-level verification, and post-simulation is avoided. Only one test case development is required, greatly improving verification efficiency. Furthermore, it prevents issues such as verification code adaptation encountered when switching verification levels; Furthermore, it supports multiple verification engineers to perform verification work on different modules in parallel, which improves the efficiency of verification work compared to simple system-level verification. Furthermore, it can support scenarios such as inter-module collaborative work and low-power processes in the early stages of SOC chip verification, thus exposing potential problems in advance.

[0035] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A UVM-based SOC chip verification environment, characterized in that, The verification environment includes general environment components and module-customized environment components; The general environment components include a Testbench general component, a Test general component, a Virtual_sequence general component, an Env general component, and a Virtual_sequencer general component; The module customization environment components include a Testbench module customization section, a Test module customization section, a Virtual_sequence module customization section, an Env module customization section, and a Virtual_sequencer module customization section; The Virtual_sequence module customization part includes module customization sequence and module customization task, and the module customization task of each module exists independently in different SV files; When the customized parts of the Testbench module, the customized parts of the Test module, the customized task of the module, the customized parts of the Env module, and the customized parts of the Virtual_sequencer module are imported into the corresponding general parts through the include method, the import is confirmed by judging the macro definition. For any module, if the macro definition corresponding to the module exists at compile time, the module customization environment component of the module is imported; otherwise, it is not imported. When compiling the SOC chip verification environment, macro definitions for the target module are added in the command line using the +define method; During the compilation process, the module customization environment component of the corresponding module with macro definition takes effect, and finally generates a simulation executable file containing the name of the effective module; Run the simulation executable file containing the name of the effective module, specify the customized part of the Test module to run in the command line, and obtain the simulation results.

2. The UVM-based SOC chip verification environment according to claim 1, characterized in that, The Testbench general part is used to instantiate SOC chip code, and the Test module customization part is started by the run_test method of UVM to define the simulation waveform dump option; The Test general part inherits from UVM's uvm_test, and is used to instantiate the Env general part, generate the configuration of the bus master stimulus generation model, and connect the bus master stimulus generation model signal with the SOC chip's internal bus master signal; The general part of Virtual_sequence is inherited from uvm_sequence of UVM and is used to define the tasks used by all module verification, including the bus host stimulus generation task, the SOC chip initialization process task, and the SOC chip clock reset switch task. The Env general part inherits from UVM's uvm_env and is used to instantiate the bus host stimulus generation model and the Virtual_sequencer general part. The general part of Virtual_sequencer is inherited from uvm_sequencer of UVM and is used to declare the sequencer handle of the bus host stimulus generation model.

3. The UVM-based SOC chip verification environment according to claim 2, characterized in that, The bus master stimulus generation model is used to replace the bus master in the SOC chip to initiate access in accordance with the bus protocol. It quickly establishes the bus communication path in the early stage of verification and generates stimuli through SV test cases to fully verify each bus slave module.

4. The UVM-based SOC chip verification environment according to claim 1, characterized in that, The customized code for each Testbench module exists independently in different SV files and is imported into the general Testbench section using the include method. The customized code for each Testbench module includes instantiating the module type model developed by the verification engineer for connection with the SOC chip.

5. The UVM-based SOC chip verification environment according to claim 1, characterized in that, The customized part of the Test module inherits from the general part of Test, contains all the contents of the general part of Test, and specifies that the customized part of the Virtual_sequence module is launched on the general part of Virtual_sequencer.

6. The UVM-based SOC chip verification environment according to claim 1, characterized in that, The module-customized task is imported into the Virtual_sequence general part through the include method; the module-customized task is used to define the register configuration process of the corresponding module; the module-customized sequence is inherited from the Virtual_sequence general part and is used to define the specific process of test cases.

7. The UVM-based SOC chip verification environment according to claim 1, characterized in that, The customized Env module code for each module exists independently in different SV files and is imported into the general Env part through the include method. The customized Env module code includes the instantiation of the UVM_component type model developed by the verification engineer for connection with the SOC chip.

8. The UVM-based SOC chip verification environment according to claim 1, characterized in that, The customized code of the Virtual_sequencer module for each module exists independently in different SV files. It is imported into the general part of Virtual_sequencer through the include method and is used to declare and verify the sequencer handle of the UVM_component type model developed by the engineer for module customization.

9. A verification method based on the UVM SOC chip verification environment as described in any one of claims 1-8, characterized in that, All of the module-customized environment components described herein are developed on a verification environment composed of the general environment components; Each of the module-customized environment components is independent of each other, and the module-customized environment component of the target module takes effect when compiling the SOC chip verification environment; When verifying the collaborative operation of multiple modules, the module-customized environment components of all target modules in the specified SOC chip verification environment are simultaneously effective; All customized parts of the Test module are simulated before running on the SOC chip verification environment, and all test cases developed in C language in the customized parts of the Test module are simulated after running on the SOC chip verification environment.