|
分类：验证平台设计
自封闭系统的困扰
当验证平台编译完成后，验证平台以可执行库文件的形式存在。看上去像一根自封闭的小岛。“晴川历历汉阳树，芳草萋萋鹦鹉洲”，虽然看上去很美，但是交通不便。
自封闭系统是不方便的。
例如，当我们在Debug问题时，发现需要获取某个验证组件的UVM_HIGH等级的打印信息。但系统设置的打印级别verbosity是UVM_LOW，即UVM_HIGH的信息不能打印。此时是修改验证平台的打印等级重新编译吗？重新编译就意味着漫长的等待……
其实，验证平台在编译完成后，并不是一个自封闭系统，在验证平台和脚本环境中，有一座桥梁，这座桥就是uvm_cmdline_processor。
uvm_cmdline_processor举例
使用方式1，在仿真脚本中添加相关信息。
其中，L3-L4都是uvm_cmdline_processor提供的已经架设好的桥梁。
使用方式2，在仿真过程中，将参数通过命令行写入。 这种方式，可以交互式的控制仿真过程，一般仅在比较大型的仿真时使用。
UVM的两种桥梁 UVM为用户提供了“已经架设好的桥梁”和“需要自己架设的桥梁”。而“需要自己架设的桥梁”给了验证平台更大的灵活性，耐心看到最后的人，不会觉得浪费了时间的。
已经架设好的桥梁
uvm_cmdline_processor 已经架设好了很多桥，方便大家使用。
+UVM_TESTNAME +UVM_TESTNAME= 这个参数应该是经常使用的，一般是在脚本中添加+UVM_TESTNAME=待执行用例的类名。其实，这个参数可以应用的更灵活：在回归验证时，如果你将所有用例都一起编译形成一个库，那么，这个库只需要编译一次，而后续执行回归用例都不需要编译了，只需要修改+UVM_TESTNAME后的参数即可。经实践检验，这么做可以大大节省回归验证在编译上花费的时间。
+UVM_VERBOSITY +UVM_VERBOSITY= 这个参数大家也经常用，用来修改所有组件的打印级别。例如，在回归验证时，一般打印较少的LOG信息，但是，当回归出现错误时，需要让更多的信息打印出来。例如： +UVM_VERBOSITY=UVM_HIGH
+uvm_set_verbosity +uvm_set_verbosity= +uvm_set_verbosity= 设置某个组件（comp），某类标识（id），某段时间（phase或time,）的打印等级（verbosity）。例如： +uvm_set_verbosity=uvm_test_top.env0.agent1.*,_ALL_,UVM_FULL,main_phase +uvm_set_verbosity=uvm_test_top.env0.agent1.*,_ALL_,UVM_FULL,time,800
+uvm_set_action +uvm_set_action= 设置某个组件（comp），某个标识（id），某个严重程度（severity）的某种动作（action）。例如： +uvm_set_action=uvm_test_top.env0.*,_ALL_,UVM_ERROR,UVM_NO_ACTION
可选的action包括： UVM_NO_ACTION（无动作）； UVM_DISPLAY（标准输出）； UVM_LOG（log文件）； UVM_COUNT（错误计数，判断是否达到max_quit_count）； UVM_EXIT（立即退出仿真）； UVM_CALL_HOOK（调用report的钩子函数）； UVM_STOP（暂停，进入交互模式，类似于仿真过程中的ctrl+c）； UVM_RM_RECORD（让reporter做记录）。
+uvm_set_severity +uvm_set_severity= 修改某个组件（comp），某个标识（id），某个严重程度（current severity）为新的严重程度（new severity）。例如，如果某个组件的问题已知，但还可以接受，为了节省编译时间，可以让该组件暂时不报Error或Fatal，暂时执行下去。例如： +uvm_set_severity=uvm_test_top.env0.*,BAD_CRC,UVM_ERROR,UVM_WARNING
+UVM_TIMEOUT +UVM_TIMEOUT= UVM全局时间门限，如果超出了门限，就退出。其中，overridable是说用户是否还可以在验证平台中修改UVM_TIMEOUT时间。例如： +UVM_TIMEOUT=200000,NO
+UVM_MAX_QUIT_COUNT +UVM_MAX_QUIT_COUNT= UVM最大错误计数门限，如果超出了门限，就退出。其中，overridable是说用户是否还可以在验证平台中修改UVM_MAX_QUIT_COUNT时间。例如： +UVM_MAX_QUIT_COUNT=5,NO
以下是4个TRACE开关： +UVM_PHASE_TRACE +UVM_OBJECTION_TRACE +UVM_RESOURCE_DB_TRACE +UVM_CONFIG_DB_TRACE
+uvm_set_inst_override +uvm_set_type_override +uvm_set_inst_override= +uvm_set_type_override= 工厂模式，修改组件类型，可以基于例化（inst的full_inst_path）的特定替换，或者基于类型（type）的整体替换。
+uvm_set_config_int +uvm_set_config_string +uvm_set_config_int= +uvm_set_config_string= 修改UVM内部特定组件（comp），特定变量域段（field）为特定值（value）。特定值为数值（int）或字符串（string）。例如： +uvm_set_config_int=uvm_test_top.soc_env,mode,5
+uvm_set_default_sequence +uvm_set_default_sequence=seqr>, 该功能需UVM-1.2支持，使用户可以修改特定Sequencer（seqr），特定时期（phase），为特定sequence类型（type）。例如： +uvm_set_default_sequence=path.to.sequencer,main_phase,seq_type
需要自己架设的桥梁
UVM提供了以下函数接口，可以在验证平台中使用。 functionvoid get_args (output string args[$]) 获取所有参数，结果存储在args字符串队列中；
function void get_plusargs (output stringargs[$]) 获取以“+”开头的参数，如“+incdir”，“+UVM_TESTNAME”，结果存储在args字符串队列中；
function void get_ uvmargs (output stringargs[$]) 获取所有包含“uvm”，“UVM”的参数，如“-uvm”、“+UVM_TESTNAME”，结果存储在args字符串队列中；
function int get_arg_matches (string match,ref string args[$]) 获取与字符串match的内容匹配的参数，结果存储在args字符串队列中；
functionint get_arg_value (string match, ref string value) 获取与字符串match匹配的参数值，如“+incdir+”后面的信息，仅获取第一个参数；
functionint get_arg_values (string match, ref string values[$]) 获取与字符串match匹配的参数值，如“+incdir+”后面的信息，获取所有参数值；
function string get_tool_name () 获取工具名称，结果存储在返回值中，如ncsim(64)；
function string get_tool_version () 获取工具版本，结果存储在返回值中，如13.20。
以上高亮的三个参数，是较为推荐和常用的。
自己架设桥梁使用实例
uvm_cmdline_process是单例（Singleton）模式（参见“设计模式”相关资料），提供的函数是staticfunction uvm_cmdline_processor get_inst()，使用时，建议按单例模式使用。
若脚本如下：
则打印信息为i_arg_value= 1234。 之前有将-svseed 1234的信息，当做序列号传入验证平台的做法。我不推荐使用该方法。首先，-svseed 1234是两个参数，获取时不太方便（需要先找到-svseed，然后索引加1获取后面的参数）。另一个问题是，-svseed有其设置随机种子的作用，将该信息当做序列号并不合适。推荐的做法是如文中所示，使用“seq_num=”作为参数前缀。而且，这样可以传递多个参数。 参考资料说明
|
|
|
