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

Question

This is a question inspired by this question and answer pair: call questa sim commands from SystemVerilog test bench

The questions asks how Verilog code could control the executing simulator (QuestaSim). I saw similar questions and approaches for VHDL, too.

So my question is:

• Why should a simulation (slave) have power of its simulator (master)?
• What are typical use cases?

Further reading:

• call questa sim commands from SystemVerilog test bench
• VerTcl - A Tcl interpreter implemented in VHDL

Baroscope

There's a sharp similarity with the functionality of a VPI, or VHPI for which the VHPI Standard Specification Draft 4.7 1.1.1 VHDL Procedural interface requirements and guidelines gave as enabling development of applications such as: design traversals, netlisters, connectivity extractors, co-simulation, backplane interfaces, behavioral models, debugging environments, simulation test bench and verification, VHDL code profiles and coverage tools, VHDL decompilers and delay calculators. Transferring programmatic control from the simulator to foreign code allows you to do just about anything. – Invincible

Nick Gasson's nvc has a Tcl shell that can be invoked by a command line option and has an overhead burden on the simulation run time of around 70 KB. Kevin Thibedeau hasn't updated anything but the documentation for VerTCL (and vhdl-extras, together ~20,000 lines of VHDL) since moving to github (expecting Google Code loss). There's cocotb which allows a higher level of abstraction than you'd get using VHPI ( or VPI, or FLI) directly overcoming VHDL's lack of system description language features. – Invincible

Answer 1

Why? Can anyone answer "why"? Well, perhaps the product engineer, or developer at Mentor that drove the creation of such behavior can answer that. But lacking that, we can only guess. And that's what I'm doing here.

I can think of a few possible use cases, but they aren't something that cannot be done in another manner. For example, one could have a generic "testbench controller" that depending on generics/parameters could invoke certain simulator behavior. (Edit: After re-reading one of your links, I see that's the exact use case.)

For example, say I have this "generic" testbench code as:

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

Then, one could invoke this as:

vsim -c -gLOG_SIGNALS=1 work.testbench

The biggest use case for this might be if vsim is invoked from some environment. If one were to do a do file, I'm not sure one can pass parameters to the script. Say one had the following do file:

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

How does one set $log_signals from the command line? I suppose one could do that through environment variables, such as:

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

Other uses cases might be to turn on/off the capturing of coverage data, list files, maybe even a quirky case of ending simulation.

But of course, all of these can be handled in other manners. And in manners I think are much more clear and much easier to maintain.

As for VerTCL, I find it fascinating. But incomplete. Or at very least barebones. I find scripted testenches exceedingly useful (we use them where I work). And VerTCL is a great way to do it (if you like TCL). But it does need some framework around it to read signals, drive signals, and otherwise manage a simulation.

Cymar

Answer 2

Ideally, you wouldn't need a simulator API if the HDL was comprehensive enough to do all the functions that are currently left to the simulator. At its inception, Verilog was implemented as an interpreted language and the command line was the Verilog language instead of some other command line interface we see today based on Tcl.

But as simulators became more complex, they needed commands that interacted with the file system, platform, OS, as well as other features at faster pace than the HDL standard could keep up with. The IEEE HDL standards stop at any implementation specific details.

So simulation tool vendors developed command line interfaces (CLI) to meet user needs for debugging and analysis. These CLIs are robust enough to create stimulus and check behaviors that there can be an overlap in functionality of the CLI code versus what's in your testbench source code. So having an API to your simulators CLI can make it easier to control the flow of commands to the simulator and avoid duplication of procedures.

For example, maybe you want to start logging signals to add to a waveform after the design gets out of reset. From the CLI, you would have to set a watch condition on the reset signal that executes the logging command when reset goes inactive. Using the simulator API, you could just put that command in your bench in the spot in your where release reset.

Painting