1. 事件驱动的仿真器和和基于周期的仿真器有什么区别？
事件驱动的仿真器顾名思义就是根据事件(event)触发仿真进行的，在进入一个周期中，它会获取每个事件并通过设计传播求值，直到达到稳定状态的条件，接着进入下一个周期。事件被定义为一个设计中的任何输入刺激的变化。由于输入的到达时间和来自下游设计的信号反馈不同，一个设计可能在一个周期中被求值多次。主流EDA工具都是采用事件驱动的仿真器，比如Mentor QuestaSim，Synopsys VCS和Cadence Xcelium。
基于周期的仿真器没有时钟周期内的概念，每个逻辑单元在每个周期只求值一次，这有助于显著提高仿真速度。缺点是它不能真正检测信号的任何毛刺，并且它只能在完全同步的逻辑设计中工作的很好。由于在仿真期间没有考虑设计的时序，因此需要使用静态时序分析工具进行时序验证。基于周期的仿真器用的比较少，但在一些开发大型设计的公司中，它们是定制的。
2. 您将如何跟踪验证项目的进度？
要写好验证计划，验证计划根据场景和设计规格列出随机用例、直接用例和需要收齐的覆盖率的详细情况，并包含了验证环境开发的细节，包括激励生成和检查方法。
在项目早期阶段时，通过跟踪验证环境(激励生成器、检查器、监视器)、测试用例开发和功能覆盖率模型开发的完备性来跟踪验证进度。一旦开发了大多数测试用例和受约束随机生成其，那么测试用例通常会在服务器上做大规模回归，这时候可以根据回归通过率、漏洞率和功能覆盖率收敛情况来监控进度。
3. 您如何衡量验证的完备性，或者何时/如何说验证已经完成了？
当设计的实现行为与需求规范和设计规范匹配且没有任何错误时，可以称为功能验证完成了。为了实现这一点，我们需要对设计灌入各种激励，以涵盖所有可能得输入场景，并验证设计符合规范，没有任何错误。然而，随着设计的复杂性不断增加，几乎不可能定义所有可能得输入激励场景。此外，资源和时间的限制也使这种完备性的理想定义变得不切实际。
因此，在大多数项目中，验证的完整性是关于通过一组度量标准和最小化设计缺陷风险的过程所获得的信心。以下是为实现验证完备性的高可信度而需要遵循的一些度量标准和过程：
- 评审验证计划和设计规范，确保所有细节都被理解和捕获；
- 根据评审过的验证计划，确保环境开发、测试用例开发和功能覆盖率模型方面的开发的完备性，符合验证计划要求；
- 审查验证环境的激励生成器、约束、检查器、断言和覆盖率模型的实现；
- 确保所有的测试用例在回归模式下被启用，并且连续几周都没有失败，所有的覆盖率指标都得到满足或解释；
- 确保bug率和未解决的bug为0，或可以很好解释为对设计没有影响；
- 重要场景的波形检查；
- 如果可能得话，确保formal验证也已经做完了；
- 将最新的bug率和bug趋势与过去类似复杂度的成功项目进行比较；
4. 我们什么时候需要参考模型来验证RTL设计？使用参考模型的优点是什么？
参考模型通常是设计规范的不可综合模型，通常用C或者SystemVerilog等高级编程语言编写。参考模型有时是为了在周期级高精度或更高级别边界上匹配设计规范而实现的。例如：CPU的参考模型应该准确地模拟指令边界的状态，而AMBA总线协议的参考模型应该根据协议精确到周期级别。
参考模型通常用于checker/scoreboard，来对给定的激励输出预期的响应，这样就可以和实际结果或设计中的输出进行比较。
5. 什么是总线功能模型(BFM: Bus Functional Model)？
传统上，总线功能模型(BFM)是用高级编程语言(如C/SystemVerilog)编写的不可综合的模型，它对总线接口的功能进行建模，并且可以连接到设计接口以模拟设计。在BFM的一侧将有一个在信号级别实现总线协议的接口，而另一侧将有一个支持发送或接收事务级传输类型包的接口。
随着这个定义的不断发展，在像UVM这样的方法论中，没有想BFM这样的真正组件，但功能是由driver, monitor和sequence等组件的集合实现的。
