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

Question

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

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

所以我的问题是：

为什么模拟（从机）应该拥有其模拟器（主机）的能力？
典型的用例是什么？

进一步阅读：

call questa sim commands from SystemVerilog test bench
VerTcl - 用 VHDL

Answer 1

为什么？谁能回答"why"？好吧，也许推动创建此类行为的 Mentor 产品工程师或开发人员可以回答这个问题。但缺乏这一点，我们只能猜测。这就是我在这里所做的。

我可以想到一些可能的用例，但它们并非无法通过其他方式完成。例如，可以有一个通用的 "testbench controller"，它依赖于 generics/parameters 可以调用某些模拟器行为。（编辑：重新阅读您的其中一个链接后，我发现这是确切的用例。）

例如，假设我有这个 "generic" 测试平台代码：

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 /*
}

其他用例可能是 on/off 捕获覆盖率数据、列表文件，甚至可能是结束模拟的古怪情况。

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

至于VerTCL，我觉得很有趣。但不完整。或者至少是准系统。我发现脚本化测试非常有用（我们在工作的地方使用它们）。而 VerTCL 是一个很好的方法（如果你喜欢 TCL）。但它确实需要围绕它的一些框架来读取信号、驱动信号和管理模拟。

Answer 2

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

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

因此仿真工具厂商开发了命令行界面（CLI）来满足用户调试分析的需求。这些 CLI 足够强大，可以创建激励和检查行为，以确保 CLI 代码的功能与测试台源代码中的功能重叠。因此，为您的模拟器 CLI 添加 API 可以更轻松地控制命令流向模拟器并避免重复过程。

例如，您可能想在设计退出复位后开始记录信号以添加到波形中。在 CLI 中，您必须在复位信号上设置监视条件，以便在复位变为非活动状态时执行日志记录命令。使用模拟器 API，您可以将该命令放在您的工作台上，在您的 where release reset 位置。

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

Why should an HDL simulation (from source code) have access to the simulator's API?

vhdl

verilog

simulation

questasim