Maia is a lightweight verification language, and was created specifically to automate the test and specification of HDL designs. You don't need to know any Verilog or VHDL to use it: in fact, you don't even need to know anything about verification. You don't need to do any low-level coding. If you know what outputs your device should produce from a given set of inputs, then you can write a test.
You can use Maia to quickly create automated self-checking testbenches. In production environments, Maia is primarily used in a Test Driven Development flow, and for creating automated regression and unit test environments.
You can download a free compiler from the 'Latest Release' or 'Downloads' links on the left. Maia compiles your code into low-level Verilog, so you'll also need a Verilog simulator to test Verilog designs, or a mixed-language simulator to test VHDL designs.
The problem...
You're probably writing your low-level testbenches in Verilog, SystemVerilog, VHDL, or even Python. However, all these languages have exactly the same issue: they are far too low-level for the problem you're trying to solve. When you write code in these languages, your primary concerns are how to generate resets and clocks, how to respond to clock edges, how to avoid race conditions, how to read file data or generate formatted output, how to detect and record test failures, how and when to sample device outputs, whether you should use blocking or non-blocking assignments, and any number of other trivial, pointless, and time-consuming details. None of this has any bearing on whether or not your DUT does what it's meant to do: it's just busywork. If you're using SystemVerilog, you'll already know that it does nothing to help: the problems it is trying to solve are at a far higher level.
In other words: writing testbenches is just Plain Hard Work, and is completely unlike designing hardware. It's 'programming', and requires a knowledge of large parts of VHDL or Verilog which are completely unlike the synthesisable subset used by most engineers. The result: hardware designers, by and large, don't write testbenches; and large parts of many designs (particularly in FPGAs) are never verified.
...and the solution.
Would you write your high-level app in x86 assembler code? Probably not, given that the first compilers appeared nearly 70 years ago. And that's exactly what Maia does: it compiles your test into low-level Verilog. This lets you concentrate on your DUT functionality: in other words, how does your device respond to a given set of inputs? Maia defines a simple control language which allows easy and direct access to your RTL code, and which greatly simplifies the process of driving the RTL, and checking the resulting outputs. The language features include:
- Generation of self-checking testbenches
- DUT ports and internal signals can be driven directly from your code, and tested against arbitrary expressions
- Automated error detection and reporting
- Simplified version of C, with hardware-related extensions (2-state and 4-state variables, arbitrary bit widths, arbitrary-precision arithmetic, direct bitslice accesses, and so on)
- Delta-delay or full timing simulation, with SDC-compatible syntax for declaring clocks and timing
Many simple C programs will run directly when compiled as Maia code and run on an HDL simulator. There is a full built-in preprocessor, and many features (including scoping, expression syntax, operator precedence, arrays, structures, initialisation, and control statements) are identical to C, with some extensions. The major differences are covered in Maia and C.
You can download a free compiler ('mtv') from the downloads section, for both Linux and Windows. mtv translates a Maia program into a Verilog testbench. You can add this testbench to your project in exactly the same way as any other file, and simulate your design with your favourite simulator. If you haven't got a simulator, you will need to get one first. If you are testing VHDL designs, you will need a mixed-language simulator; if you are testing Verilog designs, a Verilog simulator will be sufficient. The simulator must support Verilog-2005 (IEEE 1364-2005). No SystemVerilog support is required.
The download also includes a compiler driver ('rtv'). You don't need rtv to simulate the Verilog output file produced by mtv, but it does automate the process of carrying out a full batch-mode simulation. rtv is driven by a configuration file, which lists the instructions required to run supported simulators. If your simulator isn't currently supported, it's straightforward to add your own instructions to this file.
Because rtv automates batch-mode simulations, it can be used to build regression and unit test environments. The tutorials code in the distribution includes a Tcl-based infrastructure which runs rtv and automates the execution and test of the tutorial examples. This is driven from a list of the tests to be run, and can be easily modified to run your own regressions or unit tests. You will need to install Tcl if you intend to use rtv in this way. You can find out more about the test framework here.
Where next?
Check out the Introduction section on the menu. This includes some simple examples of language usage, and some background on the history of the language and its development. You'll also find tutorials and a language reference.
As a first step, you should try downloading one of the distributions and working through the Tutorial code. This will be enough to get you up and running quickly, and should take no more than a couple of hours.