This is a trivial example which tests a 4-bit register. Of course, in real life, you're not going to write a testbench for a 4-bit register, but this (complete) example shows the essentials of declaring a DUT, driving the DUT inputs, and testing the DUT outputs:

DUT {                            // declare the Device Under Test
   module reg4                   // can paste in the Verilog declaration directly
     (input  CLK,
      input  [3:0] D,
      output [3:0] Q);

   create_clock CLK;             // declare any clocks to be used (default timing)
   [CLK, D] -> [Q];              // declare any drive statements to be used
}

void main() {
   for(bit4 i=0; i<10; i++)      // declare variable 'i', of type 'bit4', and loop
      [.C, i] -> [i];            // drive D, test Q after the clock edge, report errors
}

If this code is saved as test1.tv, and the reg4 module is in reg4.v, the test can be run as:

$ rtv test1.tv reg4.v

If reg4.v is correctly coded the simulator will produce the following output:

(Log)        (100 ns) 10 vectors executed (10 passes, 0 fails)

The module declaration must be entered in this (Verilog) form even if the DUT is coded in VHDL, so some manual work is required to translate the interface to a top-level VHDL module. The only other difference is that the test is instead run as rtv test1.tv reg4.vhd, and a dual-language simulator is required. The DUT can be of any level of complexity; it can be a single module, or the top level of a complete device. rtv accepts a single testbench (.tv) file, and any number of HDL source files, with optional switches, as arguments.

You can alternatively compile the testbench file as follows:

$ mtv test1.tv

This produces a single Verilog output file, with a default name of test.v. You can add this to your project and simulate using your preferred flow, without using rtv.

Your simulator will, in general, produce a lot of other (unnecessary) vendor-specific output in addition to any Maia-generated output. The vendor output has to be filtered out (in other words, ignored) in a Unit Test environment, because it will change with new versions of the simulator, or if you move to a different simulator. The Tcl files in the distribution include filters which detect and remove this output for supported simulators.