uvm实战学习笔记
- 格式:docx
- 大小:42.71 KB
- 文档页数:12
UVM实战指南Callback——最简单的callback2021-01-21 22:06:01| 分类:SystemVerilog|字号订阅在RVM、VMM、OVM/UVM中,常常提到callback这个概念。
指在事先设置好的地方留下一个接口,通过向这个接口添加一些函数对象,来到达不改变代码结构而动态修改代码行为。
下面用systemverilog来举一个简单的callback 例子:1 class callback;23 virtual task cb_pre_run();4 $display("base callback run");5 endtask:cb_pre_run67 endclass:callback89 class widget;1011 callback cb_queue[$];1213 function void add_cb(callback cb);14 cb_queue.push_back(cb);15 endfunction:add_cb1617 task run();18 // add callback here19 foreach(cb_queue[i])begin20 cb_queue[i].cb_pre_run();21 end22 $display("widget run....");23 endtask:run24 endclass:widget2526 module top;2728 class ext_callback extends callback;29 task cb_pre_run();30 $display("ext callback run");31 endtask:cb_pre_run32 endclass:ext_callback33 widget w;34 callback cb0;35 ext_callback cb_ext;363738 initial begin39 w =new;40 cb0 =new;41 cb_ext =new;42 w.run;43 w.add_cb(cb0);44 $display("=========== After Add base Callback");45 w.run;46 w.add_cb(cb_ext);47 $display("=========== After Add extention Callback");48 w.run;49 end5051 endmodule;// top在sysverilog中,没有函数指针的概念,因此必须将函数包装成为一个对象,就是上面例子中的callback class. 而为了在widget的对象中使用这个函数对象,必须事先在设计好的调用点对callback对象中的函数进行逐个调用〔代码19-21行〕。
UVM(Universal Verification Methodology)是一种用于硬件验证的标准方法学。
它是由Accellera组织开发的,旨在提供一种统一的验证方法学,以加快硬件设计验证的速度和效率。
以下是UVM的一些基础知识:
1. UVM构建在SystemVerilog语言的基础上,利用了SystemVerilog的各种特性,如类、继承、多态等。
2. UVM采用了基于类的面向对象编程方法,通过创建各种类来描述和模拟硬件设计中的各个组件和行为。
3. UVM提供了一套丰富的验证组件,包括顶层环境(uvm_env)、测试用例(uvm_test)、代理(uvm_agent)、驱动器(uvm_driver)、监视器(uvm_monitor)等,这些组件可以根据设计的需求进行组合和扩展。
4. UVM采用了基于事务的验证方法,通过定义和交换事务来模拟和验证设计中的数据传输和交互。
5. UVM提供了一套丰富的验证功能,如随机性、覆盖率、
错误注入、消息传递等,可以帮助验证工程师更好地设计和执行验证计划。
6. UVM还提供了一套强大的报告和调试机制,可以帮助验证工程师快速定位和解决验证中的问题。
总之,UVM是一种用于硬件验证的标准方法学,通过利用SystemVerilog的特性和提供丰富的验证组件和功能,可以帮助验证工程师更高效地进行硬件设计验证。
UVM实战指南——第3部分第3部分:UVM实战在前两部分中,我们介绍了UVM框架的基本概念和基本用法。
在这一部分,我们将进一步探讨UVM的实际应用,并提供一些实战技巧和建议。
1.重要性分析在开始UVM实战前,首先需要进行重要性分析。
这包括确定哪些功能是需要覆盖的,哪些功能是必要的,以及哪些可能引发错误的功能需要特殊关注。
这些分析可以帮助您确定测试计划的优先级,并在测试开发过程中更好地分配资源。
2.测试计划开发根据重要性分析的结果,您可以开始开发测试计划。
测试计划应该详细描述实施哪些测试以及对每个测试的期望结果。
它还应包括测试开发和验证团队的人员分配和时间表安排。
通过制定清晰的测试计划,您可以确保测试开发工作有条不紊地进行,并及时识别和解决问题。
3.环境开发在开发测试计划后,您可以开始开发UVM环境。
环境是UVM中最关键的部分之一,它包含了用于模拟验证环境的各种组件和接口。
在环境开发过程中,您需要根据测试计划中的需求,选择和实例化适当的UVM组件,并将它们连接在一起以形成完整的验证环境。
4.测试用例开发测试用例是验证过程中的核心功能。
在开发测试用例时,您需要通过实例化适当的测试类,指定测试目标,并配置测试环境。
您还需要定义测试封包,设置或生成输入数据,以及从模拟输出中提取和分析结果。
测试用例的开发应该遵循UVM的最佳实践,并确保测试覆盖范围广泛且有效。
5.仿真运行和调试一旦测试用例开发完成,您可以开始运行仿真并进行调试。
在仿真过程中,您可能会遇到各种问题,如信号不正确、仿真停滞、错误输出等。
为了有效解决这些问题,您可以使用UVM提供的调试功能,如消息和日志记录、波形查看和追踪。
通过运用这些工具,您可以更快地找到问题所在,并采取适当的措施进行修复。
6.结果分析和测试报告当仿真运行完成后,您需要对结果进行分析,并生成测试报告。
在UVM中,您可以通过访问测试类中的结果和统计信息来执行结果分析。
您还可以使用UVM提供的报告和日志功能,将结果以易于阅读和理解的方式呈现给项目团队和其他相关人员。
UVM相关要点范文UVM(Universal Verification Methodology)是一种验证方法学,用于验证集成电路设计的正确性。
UVM的目标是提供一种可重用的、可扩展的、可配置的验证框架,可以适用于不同规模和复杂度的设计。
以下是UVM相关的要点。
1.UVM基本概念:UVM基于SystemVerilog语言,结构化验证环境,采用面向对象的设计方法。
它提供了一套验证组件,包括验证环境(env),顶层测试(test),驱动(driver),监视器(monitor),事务(transaction)等。
通过配置和连接这些组件,可以创建一个完整的验证环境。
2.UVM构建模块:3.UVM构建方法:UVM采用构建块方法构建验证环境。
首先,创建UVC,对外部接口进行建模,并实现相应的驱动和监视器。
然后,创建UVM Testbench,配置和连接UVC,并实现顶层测试。
最后,创建UVM Testcase,定义测试数据和验证规则。
4.UVM验证过程:UVM的验证过程包括四个阶段:创建、配置、运行和收尾。
在创建阶段,实例化UVM Testbench和UVM Testcase,并配置UVC。
在配置阶段,连接组件,设置参数和启动模拟器。
在运行阶段,执行测试,并生成日志和报告。
在收尾阶段,清理资源,关闭模拟器。
5.UVM核心概念:UVM的核心概念包括交易、序列、驱动、监视器和函数。
交易是验证过程中传递的数据包,包含信号、地址、数据和控制信息。
序列是交易的序列化表示,可以定义多个交易之间的顺序关系。
驱动是产生和驱动交易的组件,负责发送交易到被测对象。
监视器是接收和监视交易的组件,负责检查交易的正确性。
函数是UVM中的工具函数,用于处理和操作交易和序列。
6.UVM高级特性:UVM提供了一些高级特性,如配置管理、消息传递、注解和覆盖率。
配置管理是通过配置文件和命令行参数来配置UVM测试,方便测试的重用和管理。
消息传递是UVM中不同组件之间传递和处理消息的机制,可以实现进程间通信和事件驱动。
UVM Lab Guide自学笔记——快速入门UVMfrom Monchy(蒙奇)在2020年秋招前根据Synopsys的SystemVerilog Verification UVM1.1Lab Guide自学UVM验证,在此分享前两章详细的学习笔记,几乎是指南的中文翻译,大量的过程截图对初学者很友好。
(UVM Lab Guide是Synopsys给出的UVM官方入门指南,里面包涵源码和实验指导,可以在网上自行下载。
建议参考《UVM实战》(张强))1UVM Environment1学习目标创建一个简单的UVM测试环境嵌入报告消息编译测试环境运行仿真并观察结果将数据、sequencer和驱动程序类添加到环境编译并仿真环境以观察行为2实验准备UVM由一组编码准则以及一组基类和宏组成。
这组基类和宏可帮助你开发外观和感觉上一致的测试平台。
这套编码准则使您能够开发鲁棒且高度可重复使用的测试平台组件,从而减少了修改、维护验证基础架构的时间,并花费更多时间验证您的设计。
第一个实验将按照UVM编码准则,使用UVM基类和宏开始构建UVM验证环境的过程:UVM lab文件夹有3个目录:labs(实验文件夹,里面的程序待补充)、solutions(lab的参考代码)和rtl(被测试的rtl代码)。
3搭建UVM测试平台任务1.创建简单的UVM 测试文件test_collection.svSolution:`ifndef TEST_COLLECTION_SV `define TEST_COLLECTION_SV `include "router_env.sv"class test_base extends uvm_test;`uvm_component_utils(test_base)router_env env;function new(string name,uvm_component parent);super.new(name,parent);`uvm_info("TRACE",$sformatf("%m"),UVM_HIGH);endfunction:newvirtual function void build_phase(uvm_phase phase);super.build_phase(phase);`uvm_info("TRACE",$sformatf("%m"),UVM_HIGH);env =router_env::type_id::create("env",this);endfunction:build_phasevirtual function void start_of_simulation_phase(uvm_phase phase);super.start_of_simulation_phase(phase);`uvm_info("TRACE",$sformatf("%m"),UVM_HIGH);//Note:If you want to see the topology as a tree format try://uvm_top.print_topology(uvm_default_tree_printer);uvm_top.print_topology();factory.print();endfunction:start_of_simulation_phase endclass:test_base`endiftest.sv Solution:program automatic test;import uvm_pkg::*;`include "test_collection.sv"initial begin$timeformat(-9,1,"ns",10);run_test();end endprogram编译并仿真简单的UVM 测试平台:$vcs -sverilog -ntb_opts uvm-1.1test.sv 编译开关-ntb_opts 用于使能UVM$simv +UVM_TESTNAME=test_base 可以通过factory configuration 修改测试。
《UVM实战(卷1)》学习笔记看了第1/2/3/4/5/6/8/9.1 这几个章节。
第一章是综述,第二章是一个具体的例子,学习笔记从第三章相关内容开始。
我个人觉得UVM重要的部分(特点的部分):1)factory机制(override config_db)2)TLM传递3)phase机制4)sequence-sequencer 以及virtual seq/sqr内容中的截图基本来自于UVM源代码、书自带的例子和《uvm1.1应用指南及源代码分析》这个PDF里的。
需要结合书(《UVM实战(卷1)》第1版)来看这个笔记。
第3章UVM基础3.1 uvm_component和uvm_object常用的类名字:这个图是从作者张强的《uvm1.1应用指南及源代码分析》里截得,不如书上3.1.1里的图好。
uvm_sequencer也是代码里必须有的,所以我加了uvm_sequenceruvm_void是一个空的虚类。
在src/base/uvm_misc.svh中定义:红框的是我们搭testbench的时候用的比较多的基类。
常用的uvm_object派生类:sequencer给driver的transaction要派生自uvm_sequence_item,不要派生自uvm_transaction所有的sequence要派生自uvm_sequence或者uvm_sequence的派生类,可以理解为sequence是sequence_item的组合(集合)。
driver向sequencer索要item,sequencer检查是否有sequence要发送item,当发现有item待发送时,就把这个item发给driver.常用的uvm_component派生类:所有的driver要派生自uvm_driver. driver用来把sequence_item中的信息驱动到DUT端口上,从transaction-level向signal-level的转换。
uvm system verilog总结### UVM System Verilog 总结#### 导语UVM(Universal Verification Methodology)与System Verilog的结合,为芯片设计验证领域带来了革新。
这种方法论不仅提高了验证效率,还增强了验证的可重用性和覆盖率。
本文将全面总结UVM与System Verilog的相关概念、特点以及应用。
---#### 一、UVM与System Verilog概述**1.1 UVM简介**UVM是建立在System Verilog基础上的一个标准化验证方法论,旨在提供一种通用的、模块化的验证平台。
它通过将验证环境分层,实现了环境的可重用性和易于维护性。
**1.2 System Verilog简介**System Verilog是一种硬件描述和验证语言,结合了Verilog和VHDL的优点,并增加了面向对象编程的特性。
它在芯片设计和验证中广泛应用。
---#### 二、UVM的核心特点**2.1 面向对象**UVM采用面向对象的设计思想,将验证环境分为不同的类和层次,便于管理和重用。
**2.2 模块化**UVM的模块化设计使得验证环境可以根据不同的测试需求灵活组合和配置。
**2.3 自动化**UVM支持自动化测试,包括自动生成测试序列、自动检查和报告错误等。
---#### 三、System Verilog在UVM中的应用**3.1 非阻塞赋值**System Verilog的非阻塞赋值在UVM中用于描述硬件行为。
**3.2 面向对象编程**System Verilog的面向对象编程特性使得UVM可以定义基类和派生类,实现代码的复用。
**3.3 功能覆盖**利用System Verilog的功能覆盖(Functional Coverage)特性,UVM 可以全面检查设计功能的覆盖率。
---#### 四、UVM与System Verilog的结合优势**4.1 提高验证效率**UVM与System Verilog的结合使得验证人员可以快速搭建验证环境,提高验证效率。
UVM学习笔记(⼀)UVM(Universal verification methodology)简介 所有的验证⽅法学服务⽬的都在于提供⼀些可以重⽤的类来减轻在项⽬之间⽔平复⽤和垂直复⽤的⼯作量UVM类库地图 ---> P260类库地图的分类:核⼼基类⼯⼚(factory)类事务(transaction)和序列(sequence)结构创建(structure creation)类环境组件(environment component)类通信管道(channel)类信息报告(message report)类寄存器模型类线程同步(thread synchronization)类事务接⼝(transaction interface)类⼯⼚机制概述⼯⼚机制也是软件的⼀种典型设计模式(design pattern)⼯⼚的意义UVM⼯⼚的存在就是为了更⽅便地替换验证环境中的实例或者注册了的类型,同时⼯⼚的注册机制也带来了配置的灵活性实例或者类型替代在UVM中称作覆盖(override),⽽被⽤来替换的对象或者类型,应该满⾜注册(registration)和多态(polymorphism)的要求UVM验证环境构成可以分为两部分,⼀部分构成了环境的层次,这部分代码是通过uvm_component类完成,另外⼀部分构成了环境的属性(配置)和数据传输,这⼀部分通过uvm_object类完成uvm_component类继承于uvm_object类,⽽这两种类也是进出⼯⼚的主要模具和⽣产对象模具:通过注册,可以利⽤⼯⼚完成对象创建对象由⼯⼚⽣产,也是利⽤了⼯⼚⽣产模具可灵活替代的好处,使得在不修改原有验证层次和验证包的同时,实现了对环境内部组件类型或者对象的覆盖uvm_{component,object}的例化创建uvm_component对象时,comp_type::type_id::create(string name, uvm_component parent);创建uvm_object对象时,object_type::type_id::create(string name);⼯⼚提供的便利——创建(create)⼀般来说,运⽤factory的步骤可分为:将类注册到⼯⼚在例化前设置覆盖对象和类型(可选的)对象创建在两种类comp1和obj1的注册中,分别使⽤了UVM宏 `uvm_component_utils和`uvm_object_utils宏做的事情就是将类注册到factory中,在解释注册函数之前,我们需要懂得在整个仿真中,factory是独有的,即有且只有⼀个,这保证了所有类的注册都在⼀个“机构”中class comp1 extends uvm_component;`uvm_component_utils(comp1) //将对象已经注册在⼯⼚中function new(string name="comp1", umv_component parent=null);super.new(name,parent); //继承了⽗类的new$display($sformatf(“%s is created”,name));endfunction: newfunction void build_phase(uvm_phase phase);super.build_phase(phase);endfunction: build_phaseendclassclass obj1 extends uvm_object;`uvm_object_utils(obj1) //将对象已经注册在⼯⼚中function new(string name="obj1");super.new(name,parent); //继承了⽗类的new$display($sformatf(“%s is created”,name));endfunction: newendclasscomp1 c1, c2;obj1 o1, o2;initial beginc1 = new("c1");o1 = new("o1");c2 = comp1::type_id::create("c2", null);o2 = obj1::type_id::create("o2");end。
UVM基础总结——基于《UVM实战》示例UVM(Universal Verification Methodology)是一种用于验证集成电路设计和系统级设计的方法学。
它提供了一种强大的框架,可以加速和规范验证过程,提高设计的质量和效率。
在《UVM实战》这本书中,通过讲解一系列示例,向读者介绍了UVM的基础知识和使用方法。
本书首先介绍了UVM的基本概念和工作原理。
UVM使用一种基于对象和类的面向对象方法来描述和组织验证环境。
它将验证环境划分为几个层次,包括顶层、环境、代理、驱动器、监视器等。
每个层次都包含不同的类和方法,用于实现不同的功能。
通过继承和实例化这些类,可以快速构建一个完整的验证环境。
接下来,本书介绍了UVM中的一些重要概念和方法。
例如,本书详细讲解了UVM的组件和接口。
组件是UVM中最基本的单元,用于实现特定的功能。
接口定义了组件之间的通信和数据交换方式。
UVM使用一种称为TLM(Transaction Level Modeling)的方法来进行通信,通过事务的方式传递数据。
本书还介绍了UVM中的一些重要机制,例如配置和工厂。
配置机制用于配置和管理验证环境中的各个组件和接口的参数。
它可以实现灵活的参数化配置,以适应不同的测试需求。
工厂机制用于管理对象的创建和销毁。
通过注册和继承,可以快速生成对象,并实现对象的多态。
本书还详细介绍了UVM中的测试用例和事务。
测试用例是验证环境中的最高层次,用于描述和控制验证过程。
测试用例可以包括多个事务,每个事务描述一个特定的操作或数据传输过程。
通过编写测试用例和事务,可以实现不同的功能和覆盖率要求。
最后,本书还介绍了一些高级的UVM特性和技术。
例如,本书介绍了UVM中的随机性和约束,用于实现随机的测试用例和事务。
本书还介绍了UVM中的一些重用机制,例如组件和测试用例的复用,以提高测试效率和质量。
通过《UVM实战》这本书的学习,我深入了解了UVM的基础知识和使用方法。
《UVM实战(卷1)》学习笔记看了第1/2/3/4/5/6/8/9.1 这几个章节。
第一章是综述,第二章是一个具体的例子,学习笔记从第三章相关内容开始。
我个人觉得UVM重要的部分(特点的部分):1)factory机制(override config_db)2)TLM传递3)phase机制4)sequence-sequencer 以及virtual seq/sqr内容中的截图基本来自于UVM源代码、书自带的例子和《uvm1.1应用指南及源代码分析》这个PDF里的。
需要结合书(《UVM实战(卷1)》第1版)来看这个笔记。
第3章UVM基础3.1 uvm_component和uvm_object常用的类名字:这个图是从作者张强的《uvm1.1应用指南及源代码分析》里截得,不如书上 3.1.1里的图好。
uvm_sequencer也是代码里必须有的,所以我加了uvm_sequenceruvm_void是一个空的虚类。
在src/base/uvm_misc.svh中定义:红框的是我们搭testbench的时候用的比较多的基类。
常用的uvm_object派生类:sequencer给driver的transaction要派生自uvm_sequence_item,不要派生自uvm_transaction 所有的sequence要派生自uvm_sequence或者uvm_sequence的派生类,可以理解为sequence 是sequence_item的组合(集合)。
driver向sequencer索要item,sequencer检查是否有sequence 要发送item,当发现有item待发送时,就把这个item发给driver.常用的uvm_component派生类:所有的driver要派生自uvm_driver. driver用来把sequence_item中的信息驱动到DUT端口上,从transaction-level向signal-level的转换。
uvm_driver需要参数(REQ RSP),比uvm_component 增加了几个成员。
重要的是seq_item_port和req/rsp. (src/comps/uvm_driver.svh)monitor/scoreboard 派生自uvm_monitor和uvm_scoreboard,但是uvm_monitor和uvm_scoreboard并没有在uvm_component基础上做扩展。
src/comps/uvm_monitor.svhsequencer 要派生自uvm_sequencer. sequencer 做了很多扩展,但是如果我们自己写的reference_model 派生自uvm_component.agent 要派生自uvm_agent. uvm_agent 里多了一个is_active 的成员。
一般根据这个active 来决定是否实例化driver 和sequencer. is_active 变量的数值需要在env 的build_phase 里设置完成(可以直接设置,也可以用uvm_config_db#(int)::set )。
env 要派生自uvm_env. uvm_env 没有对uvm_component 扩展。
src/comps/uvm_env.svh所有的test 都要派生自uvm_test 或者它的派生类。
uvm_test 也没扩展src/comps/uvm_test.svhuvm_object 和uvm_component 的macromacro 非常重要,事关把这些类的对象注册到factory 机制中去。
uvm_object macro1)对于2)对于对于driver monitor reference_model scoreboard sequencer case agent env 这些uvm_component 派生类都要加上:`uvm_component_utils(类名)uvm_component 里的成员也可以像uvm_object 里成员一样,用field_automation 机制。
field_automation 机制:对于uvm_object 派生类来说,field_automation 机制让对象自动有的copy compare print pack unpack 等函数,简化了实现uvm_component 派生类里一些function/task 的工作量对于uvm_component 派生类来说,field_automation 机制最重要的是 可以在build_phase 中自动获取uvm_config_db#()::set()的数值(必须加super.build_phase(phase))---- 也就是不用写uvm_config_db#()::get()注意:field_automation的macro的类型要和uvm_config_db的参数类型一致:如下示例代码,field_int vs uvm_config_db#(bit[47:0]) 这个时候super.build_phase()是不起作用的。
想要起作用的话,需要用clone = new + copy 源代码中可以看到clone函数一上来会做一次create,然后调copy函数src/base/uvm_object.svh3.2 UVM的树形结构uvm_component的new/create要注意第一个参数是名字,第二个参数是parent指针。
UVM真正的树根是“uvm_top”. 根据上面这个树结构,可以看出一个个component的parent 是什么。
uvm_top的parent是null。
当一个component在实例化的时候,如果parent参数设成null,那么parent参数会被仿真器自动设置成uvm_root的实例uvm_top.在6.6.1章节里也提到了,sequence在uvm_config_db#()::get()的时候,第一个参数设成“null”,实际就是uvm_root::get() 3.5.1章节也提到了这个层次结构函数:get_parent() get_child(string name) 这两个分别获取parent指针和指定名字的child指针。
get_children(ref uvm_component children[$]) 获取所有的child指针get_num_children() 获取child个数get_first_child(ref string name) get_next_child(ref string name) 获取child的名字(反映到string name 上),返回值是0/1两种情况应用参考代码如下(改动的2.5.2例子中的my_agent.sv):注意:上述代码是在connet_phase中实现的。
上述代码的打印结果如下:This should be i_agt. my_agent's name is uvm_test13.3 field automation 机制注意数组类型的field macro比一般的要少real和event的macro. 一般的对于enum类型有3个参数,而数组的只有2个参数。
联合数组的macro比较多常用函数需要注意pack unpack pack_bytes unpack_bytes pack_ints unpack_ints 返回值都是bit个数。
field-automation标记位17bit中bit0✍copy bit1✍no_copy bit2✍compare bit3✍no_compare bit4✍print bit5✍no_printbit6✍record bit7✍no_record bit8✍pack bit9✍no_packUVM_ALL_ON是‘UVM_ALL_ON|UVM_NO_PACK 这样就会忽略掉pack bit这个ps:我觉得这个地方代码其实写成像3.3.3里的有一个crc_error的rand bit的更合理一些。
然后crc_error是UVM_ALL_ON|UVM_NOPACK,而crc是UVM_ALL_ON3.4 UVM打印信息控制get_report_verbosity_level()set_report_verbosity_level(UVM_HIGH) 只对当前调用的component起作用set_report_verbosity_level_hier(UVM_HIGH) 对当前及下面所有的component起作用simv +UVM_VERBOSITY=UVM_HIGH 命令行方式------ 我觉得用这个就可以了重载打印信息:set_report_severity_override(UVM_WARNING,UVM_ERROR);上述函数都是在connect_phase及后面的phase使用设置UVM_ERROR到达一定数量结束仿真set_report_max_quit_count(int) 设成0就是无论多少error都不退出get_report_max_quit_count() 返回如果是0,说明无论多少error都不退出设置在main_phase前调用。
simv +UVM_MAX_QUIT_COUNT=103.4.4 3.4.5 3.4.6 3.4.7 我觉得应该用不大到,就不做笔记了3.5 config_db机制uvm_config_db#(类型)::set/get(component指针,”…”,”变量名字”,para4)都是4个参数:第一个参数是一个component指针,如果是null的话,相当于uvm_root::get()第二个参数是个路径字符串,第一和第二两个参数组和成一个完整的路径第三个参数对于set、get要完全一致,是变量名字set的para4是数值,get的para4是变量component中的成员变量如果:1)component用uvm_component_utils宏注册2)变量用field-automation宏注册3)component的build_phase函数里有super.build_phase(phase)那么可以省略get语句跨层次多重set的时候,看set的第一个参数,层级越高,优先级越高。
调用set的时候,第一个参数尽量使用this同层次设置的时候是时间优先非直线设置的时候注意第一和第二参数的使用,如果需要parent指针,则要用this.m_parent config_db机制支持通配符,但是作者不推荐使用通配符。