常用知识点记录

linux cmd相关

1、进程占用

can’t remove xx directory,device or resource busy

出现上面这种提示时说明要删除的文件夹有进程在占用，解决方法如下：
第一步：lsof +D xxdirectory
查看xxdir这个目录无法删除是因为哪个进程占用
第二步：kill -9 PID
使用第一步中得到的PID，用kill -9来解除占用。

2、远程登录server并执行命令

使用ssh远程执行命令时，如果命令分多个步骤完成，例如先source xxsetup文件，再执行某个脚本时。建议建立一个顶层的脚本，将所需的步骤都包括进去。然后再使用ssh执行这个顶层脚本

grep用法

grep string_need_serch path -nr 在path下面及其下层文件夹中grep 字符
grep “*F” abcd45678_.*/*.log -rl 查找abcd45678_文件夹下的所有log文件是否含有 *F字眼，将符合情况的文件列出来

gvim使用相关

1、正则表达-匹配

(*)中匹配到的内容可以用\1 \2这样的形式来引用

sv与uvm相关

1、uvm_event

在使用uvm_event.reset这种函数时，相当于调用function,只执行一次的话并不会随仿真时间的推荐而一直更新值，所以需要在适当的时间重新调用function。

2、仿真时间与forever语句

在forever语句中，如果没有消耗仿真时间的语句。程序将持续停留在当前时间点不往下执行，会导致hang死。

3、uvm信息控制

uvm_info是根据low/medium/high来决定要不要显示出来
uvm_fatal，一旦执行，立即结束仿真
uvm_error，根据计数值来决定是否结束仿真。计数值可以通过set_report_max_quit_count来设置。
uvm_fatal/uvm_error/uvm_warning对应的默认行为（display log/exit/stop)均可以在uvm_report_server中修改，使用uvm_set_severity来进行修改。

4、assert

assert($cast(xx,xxr)) 将xxr类型转换成xx，assert将check类型转换过程是否正常完成

5、process进程

process main=》process是SV的内置类，用来控制进程

main = process::self => 使用self获得当前进程A的句柄main（一般进程由initial…begin…end,final…begin…end,always block,fork join里面的statement。在sv中进程与线程的区别就是进程与小进程的区别）
在另一个begin…end也就是另一个进程B中判断main.status,也就是在B中获取A的状态，status一般有三种：FINISHED-进程结束 RUNNING-正在进行 WAITING-正在正待阻塞条件。如果A的状态main.status不满足条件，可以使用main.kill来强制关闭main所代表的进程，即kill 进程A。

6、objection机制

当验证环境中的一些组件在run_phase中保持无限循环执行，而另一些组件则有raise/drop objection行为时。验证环境将会check在仿真过程中有多少组件raise objection。如果这些raise ojection的组件均drop了，那么验证环境将会强制结束掉run phase,也就是kill掉没有objection行为的其他组件的进程，进行下一阶段的phase。
在仿真结束时，验证环境将check是否有组件raise了但没drop就异常结束，将这些组件显示在object info下面。

7、uvm_compare过程

当在scoreboard中调用 item1.compare(item2,compare_policy)进行两个object的比较时
compare function下将调用m_uvm_field_automation这个function,rhs即为item2

而m_uvm_field_automation这个function是通过下面操作实现的。参考链接

1、通过下面这堆操作，将item2转换为了local_data, what__即为uvm_compare。

2、如果item1中的arg1的flag为uvm_all_on，那么根据步骤1，what__=uvm_compare,将跳转至下图高亮处执行。
首先会判断item1.arg1.flag是否为uvm_nocompare,如果不是，那么再比较item1.arg1与local_data__.arg1(也就是item2.arg1)。

总结，在执行item1.compare(item2.compare_policy)时，将根据item1中的arg的flag是否为nocompare（nocompare标志位是否拉高）来确定是否要执行两个item中arg的比较。虽然说最好是两个item都将flag置为nocompare,但执行过程中其实只check了一个item的arg.flag。

8、关于bit与logic

当验证环境中使用bit这种双状态变量时，而design中相应信号出现X态时，这种X态的信号可能被转换成0或者1。这将造成如果golden数据为1或者为0,而design给出的actual value=X,最终反而match的现象。因而，验证环境中需要比较的数据，最好用logic这种类型。

verilog与仿真工具

关于define

用脚本处理的define语句 -> #ifdef
verilog能识别的define ->`ifdef `else `end

非全部比特位被驱动导致的几种问题

背景条件：module test有两个输入信号A和B，A的位宽定义为10比特，B的位宽定义也为10比特
**case1**:
wire [4:0] fake_A;
test inst_test( .A( fake_A ), .B( { fake_A } ) );
分析：这种情况下，module test的输入A和B的位宽都是不足的，表面上都是只有5比特输入。但仿真时，输入A的高5比特将被标记为高阻态Z，表明未被驱动，而输入B的高5比特将被仿真工具自动填充为0。

**case2:**
wire [4:0] fake_A;
wire [7:0] fake_B = {3'b0,fake_A};
test inst_test(.A( {3'b0,fake_A} ),.B( {fake_B} ) );
分析：在这种情况下，module test的输入A和B的位宽依然不足，表面上都只有8比特输入。但仿真时，输入A的高2比特将被标记为高阻态Z，而输入B的高2比特将被仿真工具自动填充为0.

从上面两种情况中可以看出，在例化接口上使用位拼接符可能会隐藏一些问题，而且不一定使用位拼接符时缺失比特就一定会被工具填充为0。当比特位缺失时，被标记位高阻态才是正确的行为。但以上两种情况在编译时均会报出相应的warning来表明缺少比特位，需要进行check。

**case3:**
wire [4:0] fake_A ;
wire [9:0] fake_B = fake_A;
test inst_test(.A( fake_B ),.B( {fake_B} ) );
分析：在这种情况下，输入A和B的位宽依然是不足的，但高5比特均会被工具填充为0，并且这时无法在编译阶段检查出问题，即不会报warning。只有进行lint check时，工具才会标记fake_B的高5比特没有被驱动。

关于assign 和 always@*