6

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

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

所以我的问题是：

  • 为什么一个模拟（从）应该拥有它的模拟器（主）的权力？
  • 什么是典型的用例？

进一步阅读：

4

2 回答 2

2

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

我可以想到一些可能的用例，但它们并不是不能以其他方式完成的。例如，可以有一个通用的“测试台控制器”，它依赖于泛型/参数可以调用某些模拟器行为。（编辑：重新阅读您的链接之一后，我发现这是确切的用例。）

例如，假设我有这个“通用”测试台代码：

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）。但它确实需要一些围绕它的框架来读取信号、驱动信号以及以其他方式管理模拟。

于 2016-06-23T23:13:15.630 回答
2

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

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

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

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

于 2016-06-24T07:51:47.893 回答