Setting up the software
You should first modify the settings.sh file in the distribution to identify your simulator. You can find instructions in Simulator selection.
Both rtv (the compiler driver) and mtv (the compiler itself) must be in the search path, and a number of environment variables must be set. The easiest way to do this is to source the settings.sh file (or, if you're running csh or a csh-derived shell, the settings.csh file). If the mtv installation is at /eda/mtv, then you should:
$ cd /eda/mtv $ source settings.sh
The path and environment variables must be set for every new terminal window that you open. The easiest way to do this is to add these commands to one of your shell start-up files:
pushd /eda/mtv source settings.sh popd
If you are running bash, this file will normally be any one of ~/.bash_profile, ~/.bash_login, or ~/.profile. It is also common to add setup commands to ~/.bashrc, but this will only work if that file is itself sourced in ~/.bash_profile.
Design Flow
The instructions below are for running batch-mode simulations using rtv. This is convenient, because a complete test can be run with a single command, which also allows regression and unit testing to be automated. However, you can, if you wish, instead run the tutorial examples 'manually', using your simulator GUI.
For the first exercise, the test file is tut1.tv. You can compile this to test.v by running
$ cd /eda/mtv/tutorial # if the distribution is at /eda/mtv $ mtv tvl/tut1.tv
This creates test.v, which should be added to the GUI, together with either verilog/counter.v, or vhdl/counter.vhd. If you intend to run the tutorials in this way, you can ignore the 'Running a testbench' section below (which describes how to carry out a batch-mode simulation).
Running a testbench
There are two ways to run a Maia testbench: the hard way, and the easy way.
The hard way is to carry out the individual steps yourself. To do this, you'll need to compile your .tv file with mtv, to create the Verilog testbench. You'll then need to simulate this output file, together with your DUT files. The simulation step might itself involve up to three separate steps: compiling the Verilog and VHDL sources, linking them, and then running the linker output. This process can be time-consuming and is error-prone, but there is a simpler alternative.
The easy way is to use rtv, which automates the entire process, and allows you to run a complete batch-mode simulation with one command. rtv is driven from a configuration file (simulators.conf), which you'll find in the top level of the Maia distribution. The Simulator selection page describes this file and includes instructions for selecting your simulator.
If you're planning on using ModelSim for Verilog simulation, for example, then you can set the required simulator and run the first tutorial example as follows:
$ export RTV_SIMULATOR=modelsim $ cd /eda/mtv/tutorial # if the distribution is at /eda/mtv $ rtv tvl/tut1.tv verilog/counter1.v
If you're instead planning on using ModelSim for VHDL simulation, you can set the simulator and run the first tutorial example as follows:
$ export RTV_SIMULATOR=modelsim_mixed $ rtv tvl/tut1.tv vhdl/counter1.vhd
In both cases, the terminal output should include the line:
# (Log) (180 ns) 18 vectors executed (18 passes, 0 fails)
If you don't see this, something has failed; you'll need to recheck the steps above.
Automation
Even if you don't finish the tutorial exercises, make sure that you check out the Automation page. This briefly introduces regression and unit testing, using the tutorial files as an example.
Type checking level
Maia is a typed language, and the compiler carries out 'static type checking' on your source code, to try to find errors in it. Most of the tutorials use the default level of type checking (Level 1), which is approximately C-like. However, some use a simplified form (Level 0), which is more script-like. The 'Level 0' tests are simpler, but not necessarily 'better'. See FAQ 18 for a discussion on which level you should use in your own source code.
Using a network simulator
If you don't have the required simulator on your local system, but you do have network access to another system which runs that simulator, then you may still be able to run your testbench. See here for instructions.