在验证流程中分析代码覆盖率是个费时费力的体力活，运气不好的话设计没时间，不配合，验证更是一个头两个大。而我们之所以要分析覆盖率, 目的是为了防止激励不充分而导致漏掉feature没有验证到。所以有助于补充case就是有效劳动，如果能借此发现隐藏的bug更是赚到。然而，最令人沮丧的是一顿操作猛如虎，分析出来却是unreachable. 或者，设计太复杂分析到最后设计验证俩人大眼瞪小眼，没人敢排版这根线能不能滤掉。

    怎么办？今天要介绍的功能就是借助工具找到这些unreachable的部分。新版的VCS中提供一个叫UNR(unreachability analysis)的功能，可以帮我们完成这部分工作。操作起来也很简单，只需要5步--虽然1 step还能省一步，但这里以最常见的2 step编译flow为例。

1. 将设计文件正常编译一遍vhdl用vhdlan, verilog用vlogan, 之前咋编现在还咋编

2. 带上coverage选项elab一次vcs 

3. 使用生成的simv带上coverage正常跑完一次仿真simv 

4. 带上unr选项再elab一次这里需要提供一个配置文件，其中至少要包含DUT top名。例如DUT定义是：module dut ...那么，在配置文件中就写上：-top dut(注意这里dut是module name，不是例化名，经过实测，这里不要填写设计提供的顶层文件，需要填写tb的最上层top module名，否则.vdb文件加载.el文件后覆盖率不会提升)然后在elab上将它带上：vcs -unr=unr.cfg 

5. 使用生成的unrSimv带上unr选项再跑一次仿真unrSimv -unr=unr.cfg  运行完毕后会生成一个unreachable.el的exclude文件，在verdi exclude时即可使用。

这里注意，如果在VHDL中使用，配置文件中需要加上：

-appVar fml_enable_vhdl_cov true

  在实际验证中，一个一般代码量的模块，产生unreachable.el文件都特别慢，24h都产生不了，只适合特别小的模块分析，适合在formal fca来做.