Unified time management in SystemVerilog / Verilator / SPICE / Verilog-AMS targets

[sgherbst]

The meaning of time flow between different kinds of simulation targets has diverged, and even within a given target there are some inconsistencies (e.g., some delays are in seconds, some nanoseconds, and some in time units).

I've reported my observations below on how time is handled in all four transient simulation targets. Lines numbers are with respect to the most recent master branch commit, which is 400b988177fd7091739c9a078f6c76dd10c0e02e. I suggest we give some thought to how to unify and simplify handling of time in these various targets.

• SystemVerilogTarget
  • Summary: uses "#" delay statements to increment time in the simulator.
  • Relevant instantiation arguments
    • "timescale": something like "1ns/1ps" representing the time unit and time precision, respectively. affects behavior of initial delay, "eval", and "step" actions
    • "clock_step_delay": Half-period for clock waveform in time units (not necessarily seconds)
    • "num cycles": Number of nanoseconds (not time units) for which the simulation should run. If a statement like "$finish" is encountered before this, the simulation will end earlier.
  • Line 35: delay 20 time units before start of test bench
  • Line 310: poke action can include a delay in seconds
  • Line 314: standalone delay in seconds
  • Line 476: eval causes a delay of "1" time units
  • Line 482: step causes delays lasting "clock_step_delay" time units each
• VerilatorTarget
  • Summary: time represented via "main_time" variable with user-controlled dumping to a VCD file.
  • Relevant instantiation arguments
    • None
  • Line 58: assertion causes a delay of "1" time units
  • Line 397: eval causes a delay of "1" time units
  • Line 407: step causes delays lasting "1" time units each
• SpiceTarget
  • Summary: time stamps for actions are computed in "compile_actions" using the "t" variable
  • Relevant instantiation arguments
    • "t_step": Print interval hint for SPICE simulator
    • "clock_step_delay": Half-period for clock waveform in nanoseconds (not time units as with SystemVerilogTarget)
    • "t_tr": Rise/fall time for voltage stimuli in seconds
  • Lines 319 and 321: poke causes a delay of in seconds if specified, and if not causes a delay of "clock_step_delay" nanoseconds
  • Line 329: standalone delay in seconds
  • Line 339-340: time points to implement the rise/fall time of voltage stimuli are added.
• VerilogAMSTarget
  • Summary: inherits time management from SystemVerilogTarget
  • Relevant instantiation arguments
    • "stop_time": Stop time in seconds for the SPICE simulation engine. Must be greater than or equal to the runtime of the testbench; this is not determined automatically.

[leonardt]

This has come up in FB's use cases, I think there's also some inconsistency between the SystemVerilog timing model w.r.t. to clocks (this is only for synchronous circuits) and Verilator (e.g. do poke values happen before or after the clock edge).

I'm going to draft a proposal for a new SynchronousTester that reworks how clock timing semantics are handled. I suspect these changes maybe orthogonal to the discrete simulator time steps, but figured it's worth mentioning. For now I'm going to do it in a separate Tester object so we don't break existing test benches that rely on the current timing semantics.