config总是set和get成对出现的。在build_phase中，要写上如下的两句话才能把pre_num_max和pre_num_min的值更新为case的设置值：
uvm_config_db#(int)::get(this,””,”pre_num_max”,pre_num_max);
uvm_config_db#(int)::get(this,””,”pre_num_max”,pre_num_min);
这里只有两个变量，尚且还能忍受，如果是有100个变量，那么写上这么100行古怪的语法，那将会是相当痛苦的一件事情。
其实在一些特定的情况下，get是可以省略。super.build_phase(phase)；
只有把mac_driver注册到factory时，顺便使用field_automation机制把要get的变量注册，那么当UVM执行到driver的super.build_phase(phase)这句话时，就会自动执行那两个get的语句。这是相当便利的，在前面介绍field_automation机制时，一直是以一个transaction为例子进行介绍的，其实对于派生自uvm_object的类（如transaction）和uvm_component的类（如uvm_driver）中，是都可以使用field_automation机制的。
不过，这里存在一个问题，那就是如果要让super.build_phase(phase)能够自动get到设置的值的话，那么在set的时候，set的第三个参数必须与要get的变量的名字相一致。
2. 跨层次的多重set
前面一直强调的一个概念就是set和get成对出现的，但是加入set多次，而get一次，那么最终get到的是哪一个set值呢？ 假设uvm_test_top和env中都对driver的值进行了set，在uvm_test_top中的set语句如下：
uvm_config_db#(int)::set(this,”env.agent.driver”,”pre_num_max”,100);
在enc的set语句如下：
uvm_config_db#(int)::set(this,”agent.driver”,”pre_num_max”,99);
那么driver中get到的值是100还是99呢？答案是100.UVM规定层次越高，那么他set的优先级越高。在整个UVM树中，uvm_test_top的位置是高于env的，所以uvm_test_top的set的优先级高。
看起来UVM似乎很势利，狗眼看人低，见到高层次的就点头哈腰，马上就从了。UVM这样设置是有其内在道理的。对于用户来说，是uvm_test_top更接近用户还是env更接近用户呢？答案肯定是前者。我们会在uvm_test_top中写不同的sequence，从而衍生出很多不同的case来。而对于env，它在uvm_test_top中实例化。有时候，这个env根本就不是用户自己开发的，很可能是别人已经开发好一个非常成熟的可重用的模块。对于这种成熟的模块，如果觉得其中某些参数不合要求，那么难道要修改到env中相关set参数吗？显然这是不合理的。比较合理的就是在uvm_test_top的build_phase中通过set的方式修改，所以说，UVM这种看似势利的行为其实极大的方便了用户的使用。
3. 统一层次的多重set
当跨层次来看待问题时，是高层次的set优先，当处于同一层次时，则是时间优先。
当上面两句胡同时出现在test的build_phase中时，driver最终get到的值将会是99。
