Question

这是一个受此问答答案启发的问题：call questa sim commands from SystemVerilog test bench

问题询问Verilog代码如何控制执行模拟器（QuestaSim）。我也看到了类似的VHDL问题和方法。

所以我的问题是：

模拟器（主机）为什么要具有模拟器（主机）的功能？
什么是典型用例？

进一步阅读：

call questa sim commands from SystemVerilog test bench
VerTcl - 用VHDL实现的Tcl解释器

Answer 1

为什么呢？任何人都可以回答＆＃34;为什么＆＃34;？好吧，也许产品工程师或Mentor的开发人员推动了这种行为的创建可以回答这个问题。但缺乏这一点，我们只能猜测。这就是我在这里做的事情。

我可以想到一些可能的用例，但它们不是以另一种方式无法完成的事情。例如，可以有一个通用的＆＃34;测试平台控制器＆＃34;这取决于泛型/参数可以调用某些模拟器行为。（编辑：重新阅读其中一个链接后，我发现这是确切的用例。）

例如，假设我有这个＆＃34;泛型＆＃34; testbench代码为：

module testbench;

parameter LOG_SIGNALS = 1'b0;

initial
begin
  if LOG_SIGNALS
  begin
    // Log all signals in the design
    mti_fli::mti_Cmd("add wave -r /*")
  end

endmodule

然后，可以将其调用为：

vsim -c -gLOG_SIGNALS=1 work.testbench

最大的用例可能是从某些环境调用vsim。如果要做一个do文件，我不确定是否可以将参数传递给脚本。假设有一个do文件：

if {$log_signals} {
  add wave -r /*
}

如何从命令行设置$log_signals？我想通过环境变量可以做到这一点，例如：

if { [info exists ::env(LOG_SIGNALS)] } {
  add wave -r /*
}

其他用例可能是打开/关闭覆盖数据，列表文件的捕获，甚至是结束模拟的奇特案例。

但当然，所有这些都可以用其他方式处理。我认为礼仪更清晰，更容易维护。

对于VerTCL，我发现它很有吸引力。但不完整。或者至少是准系统。我发现脚本的testenches非常有用（我们在工作的地方使用它们）。 VerTCL是一个很好的方法（如果你喜欢TCL）。但它确实需要一些框架来读取信号，驱动信号，以及管理模拟。

Answer 2

理想情况下，如果HDL足够全面，可以完成当前留给模拟器的所有功能，那么您就不需要模拟器API。在开始时，Verilog被实现为一种解释语言，命令行是 Verilog语言，而不是我们今天基于Tcl看到的其他命令行界面。

但随着模拟器变得越来越复杂，它们需要与文件系统，平台，操作系统以及其他功能交互的命令，其速度要比HDL标准能够跟上的速度更快。 IEEE HDL标准停留在任何特定于实现的细节上。

因此，仿真工具供应商开发了命令行界面（CLI）以满足用户调试和分析的需求。这些CLI足够强大，可以创建激励和检查行为，这些行为可能与CLI代码的功能重叠，而不是您的测试平台源代码中的内容。因此，为模拟器CLI提供API可以更容易地控制到模拟器的命令流，并避免重复过程。

例如，您可能希望在设计复位后开始记录信号以添加到波形中。在CLI中，您必须在复位信号上设置监视条件，该复位信号在复位变为非活动状态时执行logging命令。使用模拟器API，您可以将该命令放在替补发布重置位置的工作台中。

为什么HDL仿真（源代码）可以访问模拟器的API？

2 个答案: