vhdl - 为什么 HDL 仿真(来自源代码)可以访问仿真器的 API？

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

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

我可以想到一些可能的用例，但它们并不是不能以其他方式完成的。例如，可以有一个通用的“测试平台 Controller ”，它可以根据泛型/参数调用某些模拟器行为。 (编辑:在重新阅读您的一个链接后，我看到这就是确切的用例。)

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

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，我觉得它很吸引人。但不完整。或者至少是准系统。我发现脚本测试非常有用(我们在我工作的地方使用它们)。 VerTCL 是一个很好的方法(如果你喜欢 TCL)。但它确实需要一些围绕它的框架来读取信号、驱动信号和管理模拟。